The JISC DC Application Profiles: Some thoughts on requirements and scope

19

Jun

e 2

00

8

Pete Johnston, Eduserv [email protected]

http://www.eduserv.org.uk/foundation

The JISC Dublin Core Application Profiles:Some thoughts on requirements & scope

Application Profile Coordination Meeting, JISC, London

19 June 2008Application Profile Coordination Meeting, JISC, London 2

The JISC Dublin Core Application Profiles

• Background on Dublin Core Application Profiles

• Working with metadata based on DCAPs– Linking

– Merging & querying

• The JISC DCAPs

Title slide photo of “Spice mixture” by Flickr user HarlanH

See http://flickr.com/photos/33063428@N00/2244905667/ Made available under Creative Commons Attribution-NonCommercial License

http://flickr.com/photos/33063428@N00/

http://flickr.com/photos/33063428@N00/2244905667/


Background


The DCMI Abstract Model

• Second Version, DCMI Recommendation, 2007-06-04– http://dublincore.org/documents/2007/06/04/abstract-m

odel/• DCAM describes

– Components and constructs that make up an information structure (“DC description set”)

– How that information structure is to be interpreted• Uses Web Architecture/RFC3986 definition of resource

– anything that might be identified by a URI (documents, persons, collections, concepts, etc)

• Layer on top of RDF model– “Description sets” & “descriptions” as bounded entities– Extended model of “statements”

http://dublincore.org/documents/2007/06/04/abstract-model/

http://dublincore.org/documents/2007/06/04/abstract-model/

Description Set

Description

Statement

Statement

<http:/purl.org/dc/terms/subject>

Non-Literal Value Surrogate

Non-Literal Value Surrogate

<http://example.org/terms/mySH>

“Metadata”

"Métadonnées"

en

fr

<http://purl.org/dc/terms/publisher>

<http://dublincore.org/documents/abstract-model/>

<http://example.org/org/DCMI>Property URI Value URI

<http://example.org/org/mySH/h123> Value URIProperty URI

Vocab Enc Scheme URI

Value String

Value String

Description

Statement

<http://example.org/org/DCMI>

<http://xmlns.com/foaf/0.1/name>

Literal Value Surrogate

“Dublin Core Metadata Initiative” en Value StringProperty URI

Example: Description set with two descriptions, statements with non-literal value surrogates & literal value surrogates


The DCMI Abstract Model

• DCAM notes that a description set can be serialised as a “record”…

• …but does not describe how to represent description set in concrete form

– DCMI-defined “Encoding guidelines”– Formats defined by others, e.g. Eprints DC-XML

• DCAM describes various types of metadata term… • …but does not specify the use of any fixed set of terms

– DCMI-owned metadata vocabularies– Vocabularies owned/defined by other agencies

• DCAM articulates a general model of resources related to other resources

• …but does not specify any particular “model of the world”– Different “domain models”


The DCAM & DC Application Profiles

• Specification of how to construct description sets (descriptions, statements) to serve some purpose

• At core, a profile of a “description set”– a set of constraints…– …based on model of problem space…– …constructed to meet some requirements

• A DC Application Profile is “packet of documentation” which consists of:

– Functional requirements (desirable)– Domain model (mandatory)– Description Set Profile (DSP) (mandatory)– Usage guidelines (optional)– Encoding syntax guidelines (optional)

19 June 2008Application Profile Coordination Meeting, JISC, London 8Foundation standards

Domain standards

Application Profile

The “Singapore Framework” for DCAPs


“Simple Dublin Core”

• From the perspective of the Singapore Framework…

• “Simple Dublin Core” is a DC application profile– Designed primarily to support discovery

– Based on a model in which all resources are described using same 15 attributes/relationship types

– Constrains statements to 15 properties/value strings, but otherwise flexible (“all optional, all repeatable”)

• But “Simple DC” (DCAP) != DCMES (vocabulary)

• Same properties utilised in other DCAPs based on different models


Working with DCAPs


• DCAM (and RDF) use URIs to refer to resources being described

• Any description set can refer to any resource

– “anyone can say anything about anything”

• A DCAP specifies/constrains

– What types of resources described (model)

– What attributes of resources described (model)

– What relationships between resources described (model)

– How that information expressed in description set (DSP)

• vocabularies referenced

• form of statements

Expressing Relationships/Linking


• Scenario One:– Two repositories making available metadata

based on a single DCAP


hasRevisionisRevisionOf RB-E01

RB-M01PDF

RB-I01

Repository B data

RA-E01

RA-M01MSWord

RA-W01

isRealizedThroughisRealizationOf

isEmbodiedInisEmbodimentOf

RA-M02PDF

RA-I01 RA-I02

isExemplifiedInisExemplarOf

Repository A data


• Scenario Two:– Two repositories making available metadata

based on two different DCAPs, based on different domain models


RB-W01

isRealizedThroughisRealizationOf

isEmbodiedInisEmbodimentOf

RB-E01

isExemplifiedInisExemplarOf

RB-M02PDF

RB-I02

Repository B data

RA-X01

RA-Y01 RA-Y02

Repository A data

??

??


• DCAM (& RDF) neutral of specific vocabularies used

• Construction of queries typically requires some knowledge of structure of descriptions

– e.g. property URIs used, pattern of graph

Querying data

PREFIX frbr: <http://purl.org/vocab/frbr/core#>

PREFIX dcterms: <http://purl.org/dc/terms/>

PREFIX ex: <http://example.org/examples/>

PREFIX foaf: <http://xmlns.com/foaf/0.1/>

SELECT ?item

WHERE

{ ?item dcterms:licence <http://creativecommons.org/licenses/by/2.0/uk/> ;

frbr:exemplarOf ?mani .

?mani frbr:embodimentOf ?expr .

?expr frbr:realizationOf ?work .

?work dcterms:creator ?agent .

?agent foaf:name "PeteJ" .

}


• Scenario Three:– Two repositories making available metadata

based on a single DCAP

– Query across aggregation of data

• Query using single graph pattern covers data from both repositories

Querying data


• Scenario Four:

– Two repositories making available metadata based on two different DCAPs

– Query across aggregation of data

• Depending on difference in DCAPs, data from each repository may have different profile-specific “pattern”

• So query has to accommodate multiple alternative patterns

• Not impossible, but increases complexity for aggregator

• Complexity increases as number of variants increases

Querying data


The JISC DCAPs


• Funded developed on a resource-type/genre basis

– Scholarly Works

– Images

– Geospatial

– Time-Based Media

– Learning Materials

• Geospatial slightly different

– dealing with specific attributes/relationships applicable to many resource types with relation to “place”

– A “DCAP module”

• Some degree of collaboration/convergence

• Should certainly facilitate merging of data based on same DCAP

The JISC DCAPs


• Certainly some attributes/relations are specific to certain resource types

– Page count, bit rate, aspect ratio etc

• But others are more generic (or are specialisations of generic attributes)

• Increasingly, relationships of interest cut across resource type boundaries, e.g.

– SWAP addresses papers and presentations, but common now to deal with audio and video of presentation

– TBM involves capturing relations between video and stills, video/audio and transcripts etc

• Sometimes at least, wish to perform functions across resource type boundaries

– List all my works (docs, diagrams, audio, video) published in last month

The JISC DCAPs


• Is aim for these DCAPs to – support resource-type specific functions/services?

– support cross-resource type functions/services?

• If providing services across data based on different DCAPs, then do need to consider how data “joins up”

– Compatibility of domain models

– Tension between specificity and generality

– Risk of trying to model “entire world”

The JISC DCAPs


• Identifying shared resource types/”joinup points”?• Generic extensions to type-specific models?

– “See also” etc

• “Harmonisation” of type-specific models?– Shared “core” model with specialisations, extensions

etc

• Mapping to separate DCAP based on separate “core” model?

• Possible “core” models– The “Simple DC” model?

– Bibliographic Ontology (BIBO)?

– FRBR?

– ABC Harmony?

– FRBRoo/CIDOC CRM?

The JISC DCAPs

02 April 2008DCMI Scholarly Communications Community, OR2008, Southampton

26

• Origins in domain of bibliographic description• High-level conceptual model

– Arguably an outline rather than a complete model

– Some ongoing work

• “the products of intellectual or artistic endeavour”• Questions of interpretation

– Two different Works?

– Or two different Expressions of same Work?

• Questions of application to digital resources– accommodation of Web Architecture concepts?

• Some experimental implementations in RDFS/OWL• Basis of Resource Description & Access (RDA)

– (revision of AACR2 standard, work-in-progress)

• Some work on harmonisation with CIDOC CRM (FRBRoo)

Functional Requirements for Bibliographic Records (FRBR)

19

Jun

e 2

00

8

Pete Johnston, Eduserv [email protected]

http://www.eduserv.org.uk/foundation

The JISC Dublin Core Application Profiles:Some thoughts on requirements & scope

Application Profile Coordination Meeting, JISC, London

The JISC DC Application Profiles: Some thoughts on requirements and scope

Education