JISC Metadata Application Profiles, Data Models andInteroperability

Pete Johnston, Eduserv Foundation & Rosemary Russell, UKOLN

1Introduction

The JISC Repositories & Preservation Programme has funded a number of projects towork on metadata application profiles for the description of a range of resources. Themetadata application profiles developed so far - the Scholarly Works ApplicationProfile (SWAP)

, the Images Application Profile (IAP)

,the Geospatial ApplicationProfile (GAP)

- are all Dublin Core Application Profiles, i.e. they are based explicitlyon the Dublin Core Abstract Model. The project currently working on the profile for Time-Based Media (TBMAP) is also operating on this basis.The SWAP, the IAP and the TBMAP each have as their focus the description of a particular class or genre of resources. The GAP differs slightly in that it is intended to be used in conjunction with other profiles; and it focuses on a specific set of characteristics which may be applied to resources of many different types, thedistinguishing characteristic being that they have some relationship with “place”.This note provides some issues for discussion around the possible uses of the profiles.It should be emphasised that it is an attempt to raise some tentative questions, rather than to provide definitive solutions.

2Dublin Core Application Profiles, the DCMI Abstract Model and Domain Models

The DCMI Abstract Model (DCAM)

describes an information structure called a DC“description set” and specifies how those description sets are to be interpreted as providing information about resources and the relationships between resources. It is amodel for/of metadata.Although the current DCMI specification probably doesn’t make this as clear as itshould, the DCAM is based on RDF, so a DC description set is, or can be mapped to,an RDF graph, and the DCAM uses the RDF and RDFS semantics rules for themerging of data and for inferencing on that data.

Note that the DCAM doesn’t specify either a model of the “world” being described byany particular description set, nor does it specify any particular set of metadata termsto be referenced by a description set. A DC description set is not limited to using theset of terms defined/owned by DCMI, and indeed it may be the case that a DCdescription set references none of those terms, and refers only to terms defined/owned by agencies other than DCMI.A Dublin Core Application Profile (DCAP)

is a specification which describes theconstruction of some specific set of DC metadata records. It provides:

•

A specification of the

requirements

to be addressed, what functions/operationsthe metadata should support

•

A “

domain model

” of the entities to be described and their attributes andrelationships (based on the requirements to be supported)1

•

A specification of the

structural constraints

on the description sets, used torepresent instances of that domain model, i.e. a specification of the resources thatmay be described, the properties referenced in statements, and the way valuesurrogates are provided

•

A set of

guidelines

for how to apply the profile

•

A specification of any concrete

syntax(es)

to be usedi.e within the Dublin Core metadata framework, the choice of domain model and thechoice of vocabulary are addressed at the level of the DC Application Profile. It isimportant to note that there is no “global” domain model provided by DCMI tounderpin all DC metadata. In particular, “Simple Dublin Core” is just one DCAP, based on a (not always clearly articulated) “domain model” in which all resources aretreated as having the same set of 15 attributes. The same set of properties used withinthe Simple Dublin Core DCAP (i.e. the Dublin Core Metadata Element Set) may bedeployed in whole or in part in the context of other DCAPs based on other domainmodels.It is perhaps also worth emphasising that two different DCAPs might be based on thesame domain model, or on variants of a single domain model, but differ in terms of the sets of metadata terms referenced and/or the structural constraints imposed by thedescription set profile.

3Linking, Merging and Querying

3.1Relationships & Linking

References to resources within a DC description set are made using URIs, and there isno constraint on whether those URIs are owned by the provider of the description set.A description set can make statements about relationships between any two resources,i.e. “anyone can say anything about anything”.For an individual DCAP, the types of relationships supported are determined by thedesign of the domain model. So an individual DCAP typically refers to various properties for expressing specific types of relationships between resources of specifictypes: “A resource of type Book is-created-by a resource of type Person”, “a resourceof type Work is-realized-in a resource of type Expression”, and so on.

3.1.1Linking based on a Single DCAP

Consider the case of two “repository” services exposing metadata based on the sameDC Application Profile. e.g. two repositories based on the Scholarly WorksApplication Profile.Because the DCAP imposes no limitations on the URIs of the resources describedwithin an individual description set, it is quite possible for a description set exposed by repository B to express a relationship with a resource described in a description setexposed by repository A, and vice versa. The only requirements are that the DCAPsupports the required property/relationship type, and any other structural constraintson the description of the resource are met.2

3.1.2Linking based on Multiple DCAPs

Now consider the case of two “repository” services exposing metadata based on twodifferent DCAPs, based on two different domain models. There may be perfectlygood reasons for those differences, based on the requirements the DCAP designers setout to address. Although in principle, the same consideration as above applies, and adescription set exposed by repository B to express a relationship with a resourcedescribed in a description set exposed by repository A, and vice versa, the additionalfactor to consider here is the compatibility of the domain models underpinning thetwo DCAPs.If for example, repository B deploys a FRBR based model, the expectation may bethat the type of relationship in question is expressed between two FRBR Works or between two FRBR Expressions. This is the case, for example, with whole-partrelationships in FRBR. But if the data exposed by repository A is based on a differentmodel which does not include concepts of Work and Expression, then it may not beclear how those relationships can be expressed using the FRBR-based model.. Theowner of repository B is faced with the choice of remodelling/redescribing theresources within the FRBR model, or trying to adapt their model to encompass somemore general relationship types.3