The JISC DC Application Profiles: Some thoughts on requirements and scope
Download as PPT, PDF2 likes1,114 views
- The JISC has funded the development of Dublin Core Application Profiles (DCAPs) for specific resource types like scholarly works, images, and geospatial data. - There is a tension between creating DCAPs that are highly specific to resource types versus more general profiles that allow for linking and querying across types. - Existing conceptual models like FRBR provide a possible "core" model that DCAPs could harmonize with to facilitate integration and querying across resource types.
The JISC DC Application Profiles: Some thoughts on requirements and scope
- 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 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
- 3. Background
- 4. The DCMI Abstract Model Second Version, DCMI Recommendation, 2007-06-04 http://dublincore.org/documents/2007/06/04/abstract-model/ 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”
- 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” "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 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 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”
- 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)
- 8. Foundation standards Domain standards Application Profile The “Singapore Framework” for DCAPs
- 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
- 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
- 12. Scenario One: Two repositories making available metadata based on a single DCAP 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. Scenario Two: Two repositories making available metadata based on two different DCAPs, based on different domain models 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. 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" . }
- 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
- 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. The JISC DCAPs
- 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
- 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
- 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
- 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
- 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)
- 27. The JISC Dublin Core Application Profiles: Some thoughts on requirements & scope Application Profile Coordination Meeting, JISC, London