the jisc dc application profiles: some thoughts on requirements and scope
DESCRIPTION
Presentation to Application Profile Coordination Meeting, JISC, London, Thursday 19 June 2008TRANSCRIPT
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
19 June 2008Application Profile Coordination Meeting, JISC, London 3
Background
19 June 2008Application Profile Coordination Meeting, JISC, London 4
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”
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
19 June 2008Application Profile Coordination Meeting, JISC, London 6
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”
19 June 2008Application Profile Coordination Meeting, JISC, London 7
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
19 June 2008Application Profile Coordination Meeting, JISC, London 9
“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
19 June 2008Application Profile Coordination Meeting, JISC, London 10
Working with DCAPs
19 June 2008Application Profile Coordination Meeting, JISC, London 11
• 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
19 June 2008Application Profile Coordination Meeting, JISC, London 12
• Scenario One:– Two repositories making available metadata
based on a single DCAP
Expressing Relationships/Linking
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
19 June 2008Application Profile Coordination Meeting, JISC, London 14
• Scenario Two:– Two repositories making available metadata
based on two different DCAPs, based on different domain models
Expressing Relationships/Linking
RB-W01
isRealizedThroughisRealizationOf
isEmbodiedInisEmbodimentOf
RB-E01
isExemplifiedInisExemplarOf
RB-M02PDF
RB-I02
Repository B data
RA-X01
RA-Y01 RA-Y02
Repository A data
??
??
19 June 2008Application Profile Coordination Meeting, JISC, London 16
• 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" .
}
19 June 2008Application Profile Coordination Meeting, JISC, London 17
• 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
19 June 2008Application Profile Coordination Meeting, JISC, London 18
• 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
19 June 2008Application Profile Coordination Meeting, JISC, London 19
The JISC DCAPs
19 June 2008Application Profile Coordination Meeting, JISC, London 20
• 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
19 June 2008Application Profile Coordination Meeting, JISC, London 21
• 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
19 June 2008Application Profile Coordination Meeting, JISC, London 24
• 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
19 June 2008Application Profile Coordination Meeting, JISC, London 25
• 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