• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
The JISC DC Application Profiles: Some thoughts on requirements and scope
 

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

on

  • 3,844 views

Presentation to Application Profile Coordination Meeting, JISC, London, Thursday 19 June 2008

Presentation to Application Profile Coordination Meeting, JISC, London, Thursday 19 June 2008

Statistics

Views

Total Views
3,844
Views on SlideShare
3,840
Embed Views
4

Actions

Likes
2
Downloads
12
Comments
0

2 Embeds 4

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

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • 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” &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
    • 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
      Expressing Relationships/Linking
    • 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
      Expressing Relationships/Linking
    • 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 &quot;PeteJ&quot; . }
      • 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