Hi MJ, > - for that matter, is there a good example of how to "properly" > serialize DCTERMS for eg. a converted MARC/MODS record in XML (or > RDF/XML)? I see, eg. <http://dublincore.org/documents/dcq-rdf-xml/> > which has been replaced by <http://dublincore.org/documents/dc-rdf/> > but I'm not sure if the latter obviates the former entirely? Also, the > examples at the bottom of the latter don't show, eg. repeated elements > or DCMES elements. Do we abandon http://purl.org/dc/elements/1.1/ > entirely?
This has always been ridiculously confusing! Here's my understanding (though anyone else, please chime in and correct me if I've misunderstood): - With the maturation of the DCMI Abstract Model <http://dublincore.org/documents/abstract-model/>, new bindings were needed to express features of the model not obvious in the old RDF, XML, and XHTML bindings. - For RDF, <http://dublincore.org/documents/dc-rdf/> is stable and fully intended to replace <http://dublincore.org/documents/dcq-rdf-xml/>. - For XML (the non-RDF sort), the most current document is <http://dublincore.org/documents/dc-ds-xml/>, though note its status is still (after 18 months) only a proposed recommendation. This document itself replaces a transition document <http://dublincore.org/documents/2006/05/29/dc-xml/> from 2006 that never got beyond Working Draft status. To get a stable XML binding, you have to go all the way back to 2003 <http://dublincore.org/documents/dc-xml-guidelines/index.shtml>, a binding which predates much of the current DCMI Abstract Model. - Many found the 2003 XML binding unsatisfactory in that it prescribed the format for individual dc and dcterms properties, but not a full XML format - that is, there was no DC-sanctioned XML root element for a qualified DC "record". (This gets at the very heart of the difference in perspective between RDF and XML, properties and elements, etc., I think, but I digress...) The folks I'm aware of that developed workarounds for this were those sharing QDC over OAI-PMH. I find the UIUC OAI registry <http://oai.grainger.uiuc.edu/registry/> helpful for investigations of this sort. A quick glance at their report on Distinct Metadata Schemas used in OAI-PMH data providers <http://oai.grainger.uiuc.edu/registry/ListSchemas.asp> seems to suggest that CONTENTdm uses this schema for QDC <http://epubs.cclrc.ac.uk/xsd/qdc.xsd> and DSpace uses this one <http://dublincore.org/schemas/xmls/qdc/2006/01/06/dcterms.xsd>. The latter doesn't actually define a root element either, but since here a! t least the QDC is inside the wrappers the OAI-PMH response requires it's well-formed. What someone does with that once they get it and unpack it, I don't know, since without a container it won't be well-formed XML. The former goes through several levels of importing other things and eventually ends up importing from an .xsd on the Dublin Core site, but they define a root element themselves along the way. (I think.) - So what does one do? I guess it depends on who your target consumers of this data are. If you're looking to work with more traditional library environments, perhaps those that are using CONTENTdm, etc. the legacy hack-ish format might be the best. (I'm part of an initiative to revitalize the Sheet Music Consortium <http://digital.library.ucla.edu/sheetmusic/> and lots of our potential contributors are CONTENTdm users, so I think this is the direction I'm going to take that project.) But if you're wanting to talk to DCMI-style folks, the dc-ds-xml, or more likely the dc-rdf option seems more attractive. I'm afraid I'm not much help with the implementation details of dc-rdf, though. One of the DC mailing list would be, though, I suspect. There are a lot of active members there. Ick, huh? :-) Jenn ======================== Jenn Riley Metadata Librarian Digital Library Program Indiana University - Bloomington Wells Library W501 (812) 856-5759 www.dlib.indiana.edu Inquiring Librarian blog: www.inquiringlibrarian.blogspot.com
