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

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

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

Background

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”

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

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)

Foundation 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

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

Scenario Two:
Two repositories making available metadata based on two different DCAPs, based on different domain models

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 ?? ??

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

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)

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

by Eduserv Foundation on Jun 20, 2008

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 4

Statistics

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

http://www.tbmap.manchester.ac.uk	3
http://www.slideshare.net	1