Hi Graham, I pretty much agree with everything you say, I just cant help always feeling dissatisfied with the citation fudge. The fact is that for practical purposes, like the RAE, we need to have the likes of the journal title (not the article title) available as a separate field. Its difficult to explain to users, colleagues etc that the DC thing to do is store it as part of citation and then pick it apart when we need the constituent bits. That having been said I know it's the current reality, I'm just clogging up a mailing list with a public moan :(
Cheers, Robin. Robin Taylor Main Library University of Edinburgh Tel. 0131 6513808 > -----Original Message----- > From: Graham Triggs [mailto:grahamtri...@gmail.com] > Sent: 28 January 2010 13:20 > To: TAYLOR Robin > Cc: dspace-devel > Subject: Re: [Dspace-devel] RE. Machine readable citations > and metadata encodings > > 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 University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ------------------------------------------------------------------------------ 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
