 |
 |
On Thu, 10 Feb 2005, Pete Johnston wrote: > What are we really achieving by doing this? > > In the absence of a MODS RDF binding, what is anyone gaining by asking LoC to > define two or three RDF properties called > > http://www.loc.gov/mods/location > > (and the other two or three things needed for the DC Lib AP - I've just guessed > the URIrefs) picked pretty much from random parts of the MODS data structure. > > It provides _no_ interoperability whatsoever between DC and MODS XML because > we've just picked out some tiny part of the MODS data structure. > > Why are we _insisting_ on "reuse" in this rather odd piecemeal sort of way, > instead of simply declaring the properties required within DCMI vocabularies? ...and then later... > So given that no RDF binding for MODS exists, (IMHO) the only reason for > choosing to create a new property called > > http://www.loc.gov/mods/location > > rather than choosing to create a new property called > > http://purl.org/dc/terms/location > > is that presumably it would be "owned"/managed by LoC rather than by > DCMI - and I have to admit it seems slightly odd (to me!) that we are > considering asking LoC to do this - to coin a handful of properties, > representing only two or three (fairly arbitrary) facets of the MODS > information model. At a technical level, I agree with you - it doesn't really matter whether a new term is assigned a DC URI or a MODS/LoC URI. And there are certainly some advantages (simplicity being the prime one) in favour of taking the terms we are interested in and plonking them into a DC namespace (i.e. assigning them a DC URI). But, IMHO, the reasons for promoting the use of LoC, LOM and other URIs for existing terms has to do with the fuzzier social and political benefits this brings in terms of ownership, buy-in by the community and so on. I don't think we'll get buy-in to the DCMI approach by effectively saying to those communities, "We liked your XML element so much, we've taken a copy of it and added it to a DCMI namespace"!? Instead, we need to find ways of explaining to them the benefits of the semantic Web approach. We've got to explain why we need an agreed underlying model (such as that provided by RDF) before we can mix and match metadata terms in the way we want. We've got to explain why an approach based on simply merging together lots of XML fragments doesn't scale beyond very limited cases where you've got explicit agreement of all the parties. We need to convince these other communities that it is worth their while re-casting the semantics of their metadata terms in an RDF context. My guess is that other communities will want to feel ownership of the metadata terms that they create (just as we feel most comfortable with dc:title being dc:title and not being redeclared as somethingelse:title). And they'll only feel comfortable with DCMI if they think we are giving more than we are taking. In any case, I don't see that DCMI particularly wants to lumber itself with maintaining a whole set of metadata terms that are already defined and used by other communities. All in all, I think we (primarily the Architecture WG and the Usage Board) need to explain not only the 'Whys' above, but also the 'Hows'. How do I declare my XML element as a property in RDF? How do I assign a URI to my term? How do I declare my controlled vocabulary as a DCMI encoding scheme? Etc, etc. I know that Pete is already working on some of the documentation that will help to do this. None of which is easy on a shoestring! :-( However, I do agree with you that the metadata 'application profile' notion of mixing and matching has tended to be interpretted much too simplisticly - and outside of its original context of the semantic Web - to mean "as long as it's in XML it must be OK" pretty much! But next time someone says to me that they've got an XML element that they're going to use as a DCMI property, rather than saying "you can't do that" (which is probably what it sounded like I said this time!) I'm going to try saying, "OK, but in order to do that, you need to do the following...". Well, maybe... :-) Andy -- Distributed Systems, UKOLN, University of Bath, Bath, BA2 7AY, UK http://www.ukoln.ac.uk/ukoln/staff/a.powell tel: +44 1225 383933 msn: [log in to unmask] Resource Discovery Network http://www.rdn.ac.uk/