1.
The JISC Dublin Core Application Profiles: Some thoughts on requirements & scope Application Profile Coordination Meeting, JISC, London

2.
The JISC Dublin Core Application Profiles <ul><li>Background on Dublin Core Application Profiles </li></ul><ul><li>Working with metadata based on DCAPs </li></ul><ul><ul><li>Linking </li></ul></ul><ul><ul><li>Merging & querying </li></ul></ul><ul><li>The JISC DCAPs </li></ul>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

3.
Background

4.
The DCMI Abstract Model <ul><li>Second Version, DCMI Recommendation, 2007-06-04 </li></ul><ul><ul><li>http://dublincore.org/documents/2007/06/04/abstract-model/ </li></ul></ul><ul><li>DCAM describes </li></ul><ul><ul><li>Components and constructs that make up an information structure (“DC description set”) </li></ul></ul><ul><ul><li>How that information structure is to be interpreted </li></ul></ul><ul><li>Uses Web Architecture/RFC3986 definition of resource </li></ul><ul><ul><li>anything that might be identified by a URI (documents, persons, collections, concepts, etc) </li></ul></ul><ul><li>Layer on top of RDF model </li></ul><ul><ul><li>“ Description sets” & “descriptions” as bounded entities </li></ul></ul><ul><ul><li>Extended model of “statements” </li></ul></ul>

5.
Description Set Description Statement <http:/purl.org/dc/terms/subject> Non-Literal Value Surrogate Non-Literal Value Surrogate <http://example.org/terms/mySH> “ Metadata” &quot;Métadonnées&quot; 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 URI Property URI Vocab Enc Scheme URI Value String Value String Description <http://example.org/org/DCMI> <http://xmlns.com/foaf/ 0.1/name> Literal Value Surrogate “ Dublin Core Metadata Initiative” en Value String Property URI Example: Description set with two descriptions, statements with non-literal value surrogates & literal value surrogates Statement Statement

6.
The DCMI Abstract Model <ul><li>DCAM notes that a description set can be serialised as a “record”… </li></ul><ul><li>… but does not describe how to represent description set in concrete form </li></ul><ul><ul><li>DCMI-defined “Encoding guidelines” </li></ul></ul><ul><ul><li>Formats defined by others, e.g. Eprints DC-XML </li></ul></ul><ul><li>DCAM describes various types of metadata term… </li></ul><ul><li>… but does not specify the use of any fixed set of terms </li></ul><ul><ul><li>DCMI-owned metadata vocabularies </li></ul></ul><ul><ul><li>Vocabularies owned/defined by other agencies </li></ul></ul><ul><li>DCAM articulates a general model of resources related to other resources </li></ul><ul><li>… but does not specify any particular “model of the world” </li></ul><ul><ul><li>Different “domain models” </li></ul></ul>

7.
The DCAM & DC Application Profiles <ul><li>Specification of how to construct description sets (descriptions, statements) to serve some purpose </li></ul><ul><li>At core, a profile of a “description set” </li></ul><ul><ul><li>a set of constraints … </li></ul></ul><ul><ul><li>… based on model of problem space… </li></ul></ul><ul><ul><li>… constructed to meet some requirements </li></ul></ul><ul><li>A DC Application Profile is “packet of documentation” which consists of: </li></ul><ul><ul><li>Functional requirements (desirable) </li></ul></ul><ul><ul><li>Domain model (mandatory) </li></ul></ul><ul><ul><li>Description Set Profile (DSP) (mandatory) </li></ul></ul><ul><ul><li>Usage guidelines (optional) </li></ul></ul><ul><ul><li>Encoding syntax guidelines (optional) </li></ul></ul>

8.
Foundation standards Domain standards Application Profile The “Singapore Framework” for DCAPs

9.
“ Simple Dublin Core” <ul><li>From the perspective of the Singapore Framework… </li></ul><ul><li>“ Simple Dublin Core” is a DC application profile </li></ul><ul><ul><li>Designed primarily to support discovery </li></ul></ul><ul><ul><li>Based on a model in which all resources are described using same 15 attributes/relationship types </li></ul></ul><ul><ul><li>Constrains statements to 15 properties/value strings, but otherwise flexible (“all optional, all repeatable”) </li></ul></ul><ul><li>But “Simple DC” (DCAP) != DCMES (vocabulary) </li></ul><ul><li>Same properties utilised in other DCAPs based on different models </li></ul>

10.
Working with DCAPs

11.
<ul><li>DCAM (and RDF) use URIs to refer to resources being described </li></ul><ul><li>Any description set can refer to any resource </li></ul><ul><ul><li>“ anyone can say anything about anything” </li></ul></ul><ul><li>A DCAP specifies/constrains </li></ul><ul><ul><li>What types of resources described (model) </li></ul></ul><ul><ul><li>What attributes of resources described (model) </li></ul></ul><ul><ul><li>What relationships between resources described (model) </li></ul></ul><ul><ul><li>How that information expressed in description set (DSP) </li></ul></ul><ul><ul><ul><li>vocabularies referenced </li></ul></ul></ul><ul><ul><ul><li>form of statements </li></ul></ul></ul>Expressing Relationships/Linking

12.
<ul><li>Scenario One: </li></ul><ul><ul><li>Two repositories making available metadata based on a single DCAP </li></ul></ul>Expressing Relationships/Linking

13.
hasRevision isRevisionOf RB-E01 RB-M01 PDF RB-I01 Repository B data RA-E01 RA-M01 MSWord RA-W01 isRealizedThrough isRealizationOf isEmbodiedIn isEmbodimentOf RA-M02 PDF RA-I01 RA-I02 isExemplifiedIn isExemplarOf Repository A data

14.
<ul><li>Scenario Two: </li></ul><ul><ul><li>Two repositories making available metadata based on two different DCAPs, based on different domain models </li></ul></ul>Expressing Relationships/Linking

15.
RB-W01 isRealizedThrough isRealizationOf isEmbodiedIn isEmbodimentOf RB-E01 isExemplifiedIn isExemplarOf RB-M02 PDF RB-I02 Repository B data RA-X01 RA-Y01 RA-Y02 Repository A data ?? ??

16.
<ul><li>DCAM (& RDF) neutral of specific vocabularies used </li></ul><ul><li>Construction of queries typically requires some knowledge of structure of descriptions </li></ul><ul><ul><li>e.g. property URIs used, pattern of graph </li></ul></ul>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 &quot;PeteJ&quot; . }

17.
<ul><li>Scenario Three: </li></ul><ul><ul><li>Two repositories making available metadata based on a single DCAP </li></ul></ul><ul><ul><li>Query across aggregation of data </li></ul></ul><ul><li>Query using single graph pattern covers data from both repositories </li></ul>Querying data

18.
<ul><li>Scenario Four: </li></ul><ul><ul><li>Two repositories making available metadata based on two different DCAPs </li></ul></ul><ul><ul><li>Query across aggregation of data </li></ul></ul><ul><li>Depending on difference in DCAPs, data from each repository may have different profile-specific “pattern” </li></ul><ul><li>So query has to accommodate multiple alternative patterns </li></ul><ul><li>Not impossible, but increases complexity for aggregator </li></ul><ul><li>Complexity increases as number of variants increases </li></ul>Querying data

19.
The JISC DCAPs

20.
<ul><li>Funded developed on a resource-type/genre basis </li></ul><ul><ul><li>Scholarly Works </li></ul></ul><ul><ul><li>Images </li></ul></ul><ul><ul><li>Geospatial </li></ul></ul><ul><ul><li>Time-Based Media </li></ul></ul><ul><ul><li>Learning Materials </li></ul></ul><ul><li>Geospatial slightly different </li></ul><ul><ul><li>dealing with specific attributes/relationships applicable to many resource types with relation to “place” </li></ul></ul><ul><ul><li>A “DCAP module” </li></ul></ul><ul><li>Some degree of collaboration/convergence </li></ul><ul><li>Should certainly facilitate merging of data based on same DCAP </li></ul>The JISC DCAPs

21.
<ul><li>Certainly some attributes/relations are specific to certain resource types </li></ul><ul><ul><li>Page count, bit rate, aspect ratio etc </li></ul></ul><ul><li>But others are more generic (or are specialisations of generic attributes) </li></ul><ul><li>Increasingly, relationships of interest cut across resource type boundaries, e.g. </li></ul><ul><ul><li>SWAP addresses papers and presentations, but common now to deal with audio and video of presentation </li></ul></ul><ul><ul><li>TBM involves capturing relations between video and stills, video/audio and transcripts etc </li></ul></ul><ul><li>Sometimes at least, wish to perform functions across resource type boundaries </li></ul><ul><ul><li>List all my works (docs, diagrams, audio, video) published in last month </li></ul></ul>The JISC DCAPs

24.
<ul><li>Is aim for these DCAPs to </li></ul><ul><ul><li>support resource-type specific functions/services? </li></ul></ul><ul><ul><li>support cross-resource type functions/services? </li></ul></ul><ul><li>If providing services across data based on different DCAPs, then do need to consider how data “joins up” </li></ul><ul><ul><li>Compatibility of domain models </li></ul></ul><ul><ul><li>Tension between specificity and generality </li></ul></ul><ul><ul><li>Risk of trying to model “entire world” </li></ul></ul>The JISC DCAPs

25.
<ul><li>Identifying shared resource types/”joinup points”? </li></ul><ul><li>Generic extensions to type-specific models? </li></ul><ul><ul><li>“ See also” etc </li></ul></ul><ul><li>“ Harmonisation” of type-specific models? </li></ul><ul><ul><li>Shared “core” model with specialisations, extensions etc </li></ul></ul><ul><li>Mapping to separate DCAP based on separate “core” model? </li></ul><ul><li>Possible “core” models </li></ul><ul><ul><li>The “Simple DC” model? </li></ul></ul><ul><ul><li>Bibliographic Ontology (BIBO)? </li></ul></ul><ul><ul><li>FRBR? </li></ul></ul><ul><ul><li>ABC Harmony? </li></ul></ul><ul><ul><li>FRBRoo/CIDOC CRM? </li></ul></ul>The JISC DCAPs

26.
<ul><li>Origins in domain of bibliographic description </li></ul><ul><li>High-level conceptual model </li></ul><ul><ul><li>Arguably an outline rather than a complete model </li></ul></ul><ul><ul><li>Some ongoing work </li></ul></ul><ul><li>“ the products of intellectual or artistic endeavour” </li></ul><ul><li>Questions of interpretation </li></ul><ul><ul><li>Two different Works? </li></ul></ul><ul><ul><li>Or two different Expressions of same Work? </li></ul></ul><ul><li>Questions of application to digital resources </li></ul><ul><ul><li>accommodation of Web Architecture concepts? </li></ul></ul><ul><li>Some experimental implementations in RDFS/OWL </li></ul><ul><li>Basis of Resource Description & Access (RDA) </li></ul><ul><ul><li>(revision of AACR2 standard, work-in-progress) </li></ul></ul><ul><li>Some work on harmonisation with CIDOC CRM (FRBRoo) </li></ul>Functional Requirements for Bibliographic Records (FRBR)

27.
The JISC Dublin Core Application Profiles: Some thoughts on requirements & scope Application Profile Coordination Meeting, JISC, London