Application Profiles

Diane I. Hillmann

Director of Metadata Initiatives

Information Institute of Syracuse

Interoperability is as much a need within institutions as it is among institutions

Libraries in their digital projects have built and largely accepted an approach that creates non-interoperable silos of dataHow libraries provide discovery services across

these silos is often very clunky and generally unsatisfactory

Much of the metadata for these projects is stored as static objects, unmaintained

6/28/08 2ALA 2008 Anaheim

Human aspectsFocus for consensus buildingDocumentation of shared consensusCommunication of data intentions

Machine aspectsValidation of metadata as conforming to an APIncreasingly specific expectations for metadata

contentImproved ability to assess and improve

metadata


Librarians tend to think about Application Profiles primarily as a documentation activity

We tend to slide over the parts that might require some rethinking:Functional requirements (what are we trying to

do?)Domain model (how does our data world fit

together?)Result: Our AP documents what we do, not

what we should be doing


“The Singapore Framework for Dublin Core Application Profiles is a framework for designing metadata applications for maximum interoperability and for documenting such applications for maximum reusability. The framework defines a set of descriptive components that are necessary or useful for documenting an Application Profile and describes how these documentary standards relate to standard domain models and Semantic Web foundation standards. The framework forms a basis for reviewing Application Profiles for documentary completeness and for conformance with Web-architectural principles.”

-- Singapore Framework http://dublincore.org/documents/singapore-framework/6/28/08 5ALA 2008 Anaheim

http://dublincore.org/documents/singapore-framework/



Singapore Framework


Singapore Framework


Singapore Framework


A DCAP is a specification that represents the metadata requirements for a particular application. To accomplish this

* it describes what a community wants to accomplish with its application (Functional Requirements)

* it characterizes the types of things described by the metadata and their relationships (Domain Model)

* it enumerates the metadata terms to be used and the rules for their use (Description Set Profile and Usage Guidelines)

* it defines the machine syntax that will be used to encode the data (Syntax Guidelines and Data Formats)

--from forthcoming DCMI Application Profile Guidelines6/28/08 9ALA 2008 Anaheim

From: Scholarly Works Application Profile (SWAP) Facilitate identification of open access materials Enable identification of the research funder and

project codeA set of functional requirements may include user

tasks that must be supported, as in these requirements from the Functional Requirements for Bibliographic Records (FRBR):using the data to find materials that correspond to

the user's stated search criteriausing the data retrieved to identify an entity

6/28/08 10ALA 2008 Anaheim

But even if that isn’t a “problem” exactly, there’s some value to be gained from looking at models

FRBR is a model we’ve become familiar with, but it’s not the only one relevant to what we do

We should consider how models allow us to make explicit what we’re describing and how it relates to other parts of the information landscape

6/28/08 11ALA 2008 Anaheim

SWAP (formerly ePrints AP) uses a modified FRBR Model

Their chosen domain is article level scholarly publishing

Note that they include funding for the activity and affiliation of the creator as important aspects of their model

6/28/08 12ALA 2008 Anaheim

Scholarly Works Application Profile Model

6/28/08 13ALA 2008 Anaheim

Built on the model derived from that described in Michael Heaney's An Analytical Model of Collections and their Catalogues and Users and Information Resources: An Extension of the Analytical Model of Collections and their Catalogues into Usage and Transactions. It is both a subset and a simplification of that model.

Includes in its requirements the description of indexes and catalogs themselves (based primarily on the usefulness of these to access collections not primarily web-based)

6/28/08 14ALA 2008 Anaheim

Collections AP Model

6/28/08 15ALA 2008 Anaheim

An AP can provide a basis for automated assessment of metadata quality

Can enable determination of conformance to an AP

Can provide increasingly specific specifications for metadata content

Can improve our ability to assess and “smarten up” metadata in general

6/28/08 16ALA 2008 Anaheim

If an AP is a “template for expectation,” then:Completeness should be able to be assessed

by machine based on obligations in that APEx.: An AP may require Title, Author and

Description, and if Description is missing the metadata can be characterized as “incomplete,” e.g., does not meet expectations

Occurrence of values can be determinedIf only one occurrence is expected, and three are

provided, the metadata is non-conforming

6/28/08 17ALA 2008 Anaheim

Presence or absence of mandatory properties

Absence of recommended valuesUse of text strings as a value for instead of a

URIPresence of properties not valid in the

particular APCompleteness of records in terms of

supplying sufficient information for a user to access a resourceExample of this is where identifiers do not lead

to content, are broken, or lack context6/28/08 18ALA 2008 Anaheim

If data is specified in an AP as associated with a vocabulary, a machine can determineWhether the controlled vocabulary is appropriately

used in association with a particular propertyWhether an allowed string is formatted properly

(for example a date)Whether the string is a valid member of a

particular set of allowed strings (a controlled list)Whether a URI represents a valid term in a

controlled set (URI might represent an outdated or deprecated term)

6/28/08 19ALA 2008 Anaheim

Once expectations and gaps are clear, specific services can be applied:Terminology services to match text

strings with URIsImproved normalization of dataMachine-based services to provide

missing dataEx.: formats for digital resources;

summaries for full text; topics6/28/08 20ALA 2008 Anaheim

Documentation is ALWAYS a good activity, but sometimes we fail to look beyond documentation of current practice towards what we should be doing

Application Profiles can operate at the project, institutional or community/domain level—we should explore all these

Development of RDA and its vocabularies provide a great opportunity to look closer at the benefits of an increased level of machine processing

6/28/08 21ALA 2008 Anaheim

DCMI will publish Guidelines for Application Profiles more oriented to the needs of librarians and others not able to take good advantage of more technical documentation

Publication should be available on the DCMI website this summer or early fall (at the latest)

Look for announcements and consider how the document can be improved or expanded

6/28/08 22ALA 2008 Anaheim

Questions? Email [email protected]

6/28/08 23ALA 2008 Anaheim

Education

Application Profiles