Andy Powell, Eduserv Foundation Feb 2007 The Dublin Core Abstract Model – a packaging standard? Content Packaging for Complex Objects: Technical Workshop flickr photo by amalthya

Feb 2007 Content Packaging for Complex Objects: Technical Workshop 2 Why Dublin Core? well… maybe… this workshop is about content packaging not metadata!? DC is just 15 elements for describing Web pages isnt it? DC doesnt do content packaging does it?

Feb 2007 Content Packaging for Complex Objects: Technical Workshop 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 Ill give some examples and finally try to draw some conclusions

Feb 2007 Content Packaging for Complex Objects: Technical Workshop 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)

Feb 2007 Content Packaging for Complex Objects: Technical Workshop 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

Feb 2007 Content Packaging for Complex Objects: Technical Workshop 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

Feb 2007 Content Packaging for Complex Objects: Technical Workshop 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)

Feb 2007 Content Packaging for Complex Objects: Technical Workshop 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

Feb 2007 Content Packaging for Complex Objects: Technical Workshop 9 Example 1 – Book application model Book 0..hasPart Chapter here is a very simple application model…

Feb 2007 Content Packaging for Complex Objects: Technical Workshop 10 Example 1 – pseudo-XML description set Chapter 1 Chapter 2

Feb 2007 Content Packaging for Complex Objects: Technical Workshop 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)

Feb 2007 Content Packaging for Complex Objects: Technical Workshop 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

Feb 2007 Content Packaging for Complex Objects: Technical Workshop 13 Eprints application model ScholarlyWork Expression 0.. isExpressedAs Manifestation isManifestedAs 0.. Copy isAvailableAs 0.. isCreatedBy isPublishedBy 0.. isEditedBy 0.. isFundedBy isSupervisedBy AffiliatedInstitution Agent here is a more complex application model…

Feb 2007 Content Packaging for Complex Objects: Technical Workshop 14 Example 2 – psuedo-XML Attempts to detect retrotransposition and de novo deletion of Alus and other dispersed repeats at specific loci in the human genome <statement propertyURI=eprint:isAvailableAs valueURI= /> <statement propertyURI=eprint:isAvailableAs valueURI= />

Feb 2007 Content Packaging for Complex Objects: Technical Workshop 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 doesnt 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

Feb 2007 Content Packaging for Complex Objects: Technical Workshop 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

Feb 2007 Content Packaging for Complex Objects: Technical Workshop 17 Questions…