The document discusses the Dublin Core Abstract Model (DCAM) in relation to content packaging for complex objects. It outlines the evolution of DC from implicit models to a more defined structure that emphasizes relationships between resources, encapsulated in a description set with property/value pairs. The DCAM allows for flexible relationships, supports multiple syntaxes, and aims to facilitate the exchange of information in networked systems.

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…