• Save
The Dublin Core Abstract Model – a packaging standard?
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

The Dublin Core Abstract Model – a packaging standard?

  • 5,405 views
Uploaded on

A presentation for the Content Packaging for Complex Objects: Technical Workshop organised by UKOLN and held in Bristol, Feb 2007.

A presentation for the Content Packaging for Complex Objects: Technical Workshop organised by UKOLN and held in Bristol, Feb 2007.

More in: Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
5,405
On Slideshare
5,405
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
3

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. The Dublin Core Abstract Model – a packaging standard? Content Packaging for Complex Objects: Technical Workshop flickr photo by amalthya
  • 2. Why Dublin Core?
    • well… maybe…
    this workshop is about content packaging not metadata!? DC is just 15 elements for describing Web pages isn’t it? DC doesn’t do content packaging does it?
  • 3. DC and content packaging
    • this talk is about the DCMI Abstract Model…
    • … and its relationship to content packaging
    • it is not intended as a tutorial
    • but I appreciate that the DCMI Abstract Model is new to many of you
    • I will therefore start by summarising the background, context and main features of the DCAM
    • then I’ll give some examples
    • and finally try to draw some conclusions
    http://dublincore.org/documents/abstract-model/
  • 4. DCMI Abstract Model background
    • in the early days of Dublin Core there was no explicit model associated with DC metadata descriptions
    • there were implicit models and conventional wisdom…
      • largely ‘flat’ in nature – i.e. a set of metadata elements describing a single thing (e.g. a Web page)
    • and there were known problems…
      • like sometimes it was obvious that an element was really being used to describe a second thing (e.g. the author of a Web page)
  • 5. DCMI Abstract Model background
    • as the various DC syntaxes matured
      • XHTML, XML and RDF/XML
    • the underlying model became more important
    • primarily as a mechanism for mapping between syntaxes
    • and there have been a number of attempts at applying the RDF model to DC
  • 6. DCMI Abstract Model key features
    • the DCAM (first published in 2005) attempts to make explicit the model that underpins DC
    • the DCAM starts from the central notion of a ‘description set’
      • a set of ‘descriptions’ about a group of related things (‘resources’)
      • where each ‘description’ is about a single ‘resource’
      • and where each ‘description’ is essentially made up of property/value pair ‘statements’
      • ‘ descriptions sets’ are instantiated as ‘records’ (e.g. using XHTML, XML or RDF/XML) for the purpose of exchanging information between networked systems
  • 7. Model summary record (encoded as HTML, XML or RDF/XML) description set description (about a resource (URI)) statement property (URI) value (URI) vocabulary encoding scheme (URI) value string language (e.g. en-GB) syntax encoding scheme (URI)
  • 8. DCAM and relationships
    • the DCAM is very open about the nature of the relationships between the resources described in a description set
      • whole / part (e.g. book / chapter / section / page)
      • physical / digital (painting / digitised painting)
      • object / human (document / author)
      • conceptual / physical (work / item)
      • or all of the above!
    • the relationships between things is articulated in an ‘application model’ and captured using the properties specified in an ‘application profile’
  • 9. Example 1 – Book application model
    • here is a very simple ‘application model’…
    Book 0..∞ hasPart Chapter
  • 10. Example 1 – pseudo-XML description set
    • <descriptionSet>
    • <description resourceURI=http://example.org/mybook>
    • <statement propertyURI=dcterms:hasPart” valueURI=http://example.org/chapter1 />
    • <statement propertyURI=dcterms:hasPart” valueURI=http://example.org/chapter2 />
    • </description>
    • <description resourceURI=http://example.org/chapter1>
    • <statement propertyURI=dc:title>
    • <valueString>Chapter 1</valueString>
    • </statement>
    • </description>
    • <description resourceURI=http://example.org/chapter2>
    • <statement propertyURI=dc:title>
    • <valueString>Chapter 2</valueString>
    • </statement>
    • </description>
    • </descriptionSet>
  • 11. Note 1 – objects packaged by reference
    • note that objects within the package (the resources described within the description set) are passed ‘by reference’
    • i.e. their URL is provided
    • this is in common with other packaging standards
    • passing ‘by value’ (i.e. embedding the object in-line) is theoretically possible using the DCAM ‘rich representation’ mechanism (but this is not discussed further here)
  • 12. Note 2 - ordering
    • the DCAM has no built-in support for ordering
    • the model is graph-based rather than being an ordered tree
    • for applications requiring ordering, e.g. the chapters in a book, it would therefore be necessary to invent properties (e.g. my:sequenceNumber) to capture the ordering as part of the description
  • 13. Eprints application model ScholarlyWork
    • here is a more complex ‘application model’…
    http://www.ariadne.ac.uk/issue50/allinson-et-al/ Expression 0..∞ isExpressedAs Manifestation isManifestedAs 0..∞ Copy isAvailableAs 0..∞ 0..∞ 0..∞ isCreatedBy isPublishedBy 0..∞ isEditedBy 0..∞ isFundedBy isSupervisedBy AffiliatedInstitution Agent
  • 14. Example 2 – psuedo-XML
    • <descriptionSet>
    • <description resourceURI=http://eprints.gla.ac.uk/503/>
    • <statement propertyURI=dc:title> <valueString>Attempts to detect retrotransposition and de novo deletion of Alus and other dispersed repeats at specific loci in the human genome </valueString> </statement>
    • <statement propertyURI=eprint:isExpressedAs valueRef=expression1 />
    • </description>
    • <description resourceId=expression1 >
    • <statement propertyURI=eprint:isManifestedAs valueRef=pdfmanifestation />
    • </description>
    • <description resourceId=pdfmanifestation >
    • <statement propertyURI=eprint:isAvailableAs
    • valueURI=http://eprints.gla.ac.uk/503/01/Eu_J._Hum_Gen.9(2)143_.pdf />
    • <statement propertyURI=eprint:isAvailableAs
    • valueURI=http://www.nature.com/ejhg/journal/v9/n2/pdf/5200590a.pdf />
    • <description>
    • <!– descriptions of the two copies here -->
    • </descriptionSet>
  • 15. Note 3 - Compound vs. complex objects
    • note that the relationships between objects in this example are more complex than hasPart or isPartOf
      • because the model doesn’t just deal with digital objects
    • it may be worth drawing a distinction between
      • ‘ compound objects’ (where objects have whole / part type structural relationships) and
      • ‘ complex objects (where there are arbitrary relationships between objects) ??
    • most objects in digital libraries are complex… not just compound
  • 16. Summary – why DC?
    • DC (and the DCAM) provides a simple packaging framework
      • where objects within the package are typically passed by reference
      • highly flexible and extensible relationship framework between objects
      • supports multiple syntax encodings
      • compatible with Semantic Web (which allows for possibility of inferencing across complex objects from unknown sources)
    • content packaging is largely about relationships – i.e. it is just metadata
  • 17. Questions…