On 28 Jan 2010, at 10:46, TAYLOR Robin wrote: > Metadata encodings :- Seems like a good thing to me. Could be used as the > basis for validation of metadata and possibly as a means of reducing some of > the bespoke qualification of DC metadata terms that exists in Dspace.
Validation - that sounds like you are describing authority control, which is a separate feature (but also means additions to the metadata value table). But 'qualification' of DC terms is along the right lines... think of all those values that contain country codes, or time values. My reading of the DC specifications is that they are not prescribed as being a certain format. Country codes could be two letter or three letter. Times may have different representations. Having an encoding / format / type / syntax column would allow you to explicitly state how the value in the field is being represented, and not just infer, guess or resolve to use a de facto standard. > Machine readable citations :- This goes back to an old chestnut viz. a DC > description should only describe one resource. In practice this is > problematic in that typically we want to store information about a journal > along with the information about a journal article. The correct DC way to do > this would be to have two separate DC descriptions, one for the journal and > one for the article, and have each refer to the other by use of hastPart and > isPartOf. Yes, according to DC you could have a separate record for the journal linked via hasPart / isPartOf. And that would be good to have an object that ties a relationship between other objects together, and capture some of the more esoteric data about a journal - where it is published, address of the publisher, etc. It's not entirely true to say it's the same issue with citations. A citation is meant to uniquely identify the article, so it would have the article title, author(s), journal name, volume, issue, start and end page. Now, there is nothing in Dublin Core specified or recommended for storing the start or end page as discrete fields. But they are (almost certainly) unique properties of that article. Certainly, not value(s) on a journal object. > My suspicion is that machine readable citations are a fudge to try and > address this. It allows the various bits that make up a citation to be stored > as one term in the DC description, but in such a way that they can be picked > apart. However, I'm not convinced this is fully thought out, the last time I > looked there were only examples provided for journal articles and conference > papers, nothing for chapters in books. Many sites, ourselves included, store > the information relating to the parent journal in a second schema, we form > the citation from the disparate bits on demand. I guess I just fear that by > moving to a position of supporting machine readable citations we are > encouraging what I consider to be a bit of a hack on the part of the DC > community. Yes, it can be seen as something of a fudge. Ideally would I want to always store discrete metadata? Yes. But I ask myself how much I care. I certainly care more that we simply aren't capturing this information in a way that we can reliably use. I certainly care more that for SWAP - and other integrations - that we are expected to be able to deal with OpenURL context objects. I probably care more that we have something that operates in accordance to a documented standard, than to simply have our own hacks (either at a community or, worse, local level). And I care that we have something explicit enough that we can do an automatic translation to an alternative representation later on if that becomes relevant. G ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
