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 data

How 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 ALA 2008 Anaheim

Human aspects

Focus for consensus building

Documentation of shared consensus

Communication of data intentions

Machine aspects

Validation of metadata as conforming to an AP

Increasingly specific expectations for metadata content

Improved 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 ALA 2008 Anaheim

Singapore Framework 6/28/08 ALA 2008 Anaheim

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 Guidelines

From: Scholarly Works Application Profile (SWAP)

Facilitate identification of open access materials

Enable identification of the research funder and project code

A 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 criteria

using the data retrieved to identify an entity

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

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

Scholarly Works Application Profile Model 6/28/08 ALA 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)

Collections AP Model 6/28/08 ALA 2008 Anaheim

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

Can enable determination of conformance to an AP

Can provide i ncreasingly specific specifications for metadata content

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

If an AP is a “template for expectation,” then:

Completeness should be able to be assessed by machine based on obligations in that AP

Ex.: 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 determined

If only one occurrence is expected, and three are provided, the metadata is non-conforming

Presence or absence of mandatory properties

Absence of recommended values

Use of text strings as a value for instead of a URI

Presence of properties not valid in the particular AP

Completeness of records in terms of supplying sufficient information for a user to access a resource

Example of this is where identifiers do not lead to content, are broken, or lack context

If data is specified in an AP as associated with a vocabulary, a machine can determine

Whether the controlled vocabulary is appropriately used in association with a particular property

Whether 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)

Once expectations and gaps are clear, specific services can be applied:

Terminology services to match text strings with URIs

Improved normalization of data

Machine-based services to provide missing data

Ex.: formats for digital resources; summaries for full text; topics

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

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