Hi Age,
> I'm creating an XML structure to store a collection of CDs,
> LPs and DVDs. Each entry is contained within a 'release'
> element with the 'dc:medium' child element (possible values:
> 'cd', 'lp', 'dvd', etc.) to specify what we're dealing with.
> I'm having a bit of trouble dealing with DVDs. This is the
> best I could come up with so far:
>
> <release>
> <dc:title>American Beauty</dc:title>
> <dc:medium>dvd</dc:medium>
> <dc:identifier
> xsi:type="myterm:EAN13">0678149096026</dc:identifier>
> <dc:issued xsi:type="dcterm:W3CDTF">2000</dc:issued>
> <dc:hasPart>
> <dctype:MovingImage>
> <dc:issued
> xsi:type="dcterm:W3CDTF">2000</dc:issued>
> <dc:creator
> xsi:type="myterm:director">Sam Mendes</dc:creator>
> </dctype:MovingImage>
> </dc:hasPart>
> </release>
>
> 'dc:issued' as child of 'release' specifies the date of the
> DVD release and 'dc:issued' specifies the date when the
> actual movie was released.
Just a minor point on syntax, but in the XML format described by [1] the intent is that the XML element names represent the URIs of properties (though I readily admit that the document isn't as clear as it should be on this point!) and the URI of DCMI's "has part" property is http://purl.org/dc/terms/hasPart. It is "in the dcterms namespace", if you like, so conventionally in this XML format it is represented by the XML element name "dcterms:hasPart" where the dcterms prefix is associated with the XML Namespace Name http://purl.org/dc/terms/
Perhaps more importantly, the format described in [1] does not define an interpretation for the subtree structure you use in the example here (i.e. a child element of the dc:hasPart XML element). Essentially the XML format described by [1] supports only the description of a single resource e.g. the DVD, but not the DVD and the movie.
Work is currently in progress on a revised version of the DC-XML specification and that revised version will support the sort of constructs you require (see [2] - N.B. that is just an early working draft! - and the recent discussions on the dc-architecture WG list [3]). But the XML format described by [1] does not - so essentially you are defining your own XML format here. Which is OK - I'm just noting that.
> The problem here is whether or not the relation between the
> DVD and the movie it contains is being specified correctly.
> The reason I'd like to make this distinction is because of
> possible different release dates, the director doesn't apply
> to the DVD itself but the movie, etc.
> Should the 'dc:hasPart' relationship element be used in such a way?
> Basically all 'relation' refinements, except for 'dc:hasPart'
> and 'dc:isPartOf', can only be used to specify a different
> resource which makes me feel like I'm abusing the
> 'dc:hasPart' element at the moment.
> If that's the case, is there currently a way to specify the
> 'this DVD contains movie x' relation I'm trying to create or
> should I introduce additional elements for this?
I think your questions highlight an important point which is sometimes overlooked in implementations of Dublin Core metadata, i.e. that to deploy DC effectively, it is important to have a model of the "part of the world" which is being described within the context of your application. i.e. to specify clearly the classes or entity-types being described, the attributes of those entities, and the nature of the relationship between them.
In its early days at least, I think the DCMI properties were based on an implicit model of a set of homogeneous "document-like objects", and I think that impression probably persists in some of the DCMI documentation.
However, I think that approach has been, or perhaps more accurately, is being, replaced by an approach which recognises that some of the DCMI properties are applicable to different types of resources from others; and that some properties may be applicable to a broad range of resources but some may be applicable to only quite specific types of resources.
Looking more specifically at the question you ask, my initial response would be that - as I think you are probably concluding already! ;-) - the dcterms:hasPart property is probably _not_ appropriate for representing the type of relationship that you wish to represent here. DCMI's definition of the dcterms:hasPart property is
> The described resource includes the referenced resource either physically or logically.
and while I recognise that that may be open to a range of interpretations, I struggle to stretch it to include the relationship between a DVD and the film as an intellectual creation!
And this rather leads me back to the question of what is your data model for "the part of the world" you are describing. You noted that you recognise a distinction between the movie (the resource which has a director and so on) and the DVD (is that a specific copy of the DVD? Or some particular edition, which may exist in the form of many thousands of physical copies?). So it seems to me you already have an embryonic data model with at least two classes/entity types.
You might find it useful to look at the Functional Requirements for Bibliographic Records (FRBR) model [4]. This is based on a view of bibliographic resources which separates out the "intellectual creation" (Work) from its "realisation" (Expression) and "embodiments" of those realisations (Manifestations), of which there may be many exemplars (Items).
And Dublin Core properties can be used to represent instances of a data model based on FRBR. For an example of this, it might be useful to look at the work on the ePrints Dublin Core Application Profile by Andy Powell and Julie Allinson, mentioned in a recent message to this list, which applies a subset of the FRBR model to the domain of scholarly publications [5] (Actually, you may prefer to look at Andy and Julie's work first without grappling with the whole of FRBR!)
I'm not saying that you need to incorporate all of the complexity of FRBR on your model - on the contrary, I suspect you can probably manage with something much simpler, but looking at FRBR may help you clarify what are the entity-types you wish to model, and the nature of the relationshps between them. I think that is perhaps the thing to work through first.
Once that is clearer, you can examine whether the properties provided by DCMI are appropriate/sufficient to represent the attributes and relationships you wish to represent. If they are, all well and good (though I appreciate that even then the DCMI property definitions may leave some ambiguity as to whether they are appropriate or not!). And where you find that they do not meet your requirements, you may need to find or define some additional properties - again the ePrints work provides some good examples of this, I think.
Apologies for the very long-winded response - but it was a good question which raises some interesting issues! ;-)
Cheers
Pete
[1] http://dublincore.org/documents/dc-xml-guidelines/
[2] http://dublincore.org/documents/dc-xml/
[3] http://www.jiscmail.ac.uk/lists/DC-ARCHITECTURE.html
[4] http://www.ifla.org/VII/s13/frbr/frbr.htm
[5] http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0609&L=dc-general&P=889
---
Pete Johnston
Technical Researcher, Eduserv Foundation
Web: http://www.eduserv.org.uk/foundation/
Email: [log in to unmask]
Tel: +44 (0)1225 474323
|