 |
 |
Quoting Rachel Heery <[log in to unmask]>: > I just mention this as it seems a point of difference in the way these > 'properties' are use in DC as opposed to MARC. And I would say by re-using > MARC relator codes DC is 'cherry-picking' from MARC, which you denigrate > wrt re-use of MODS? Hehe heh, you read my mind - yes, in my first draft of that message, I was going to include that case too! ;-) The only real reason (IMHO) that the MARC relator properties have LoC URIs is because they are "owned"/managed/administered by LoC, not by DCMI. Also I think there is a difference between selecting the MARC relators and selecting two/three of the many components of MODS, because - if they are considered only as relations between resources and agents (and that is the ony facet of their use that has been modelled in RDF) - the MARC relators _do_ form a "self-contained" set in a way that the components of the MODS hierarchy do not (because of their interdependence with other components). But yes, you are correct - LoC/DCMI has chosen to model only that one facet of the way the MARC relator codes are used in MARC. > Nice analogy, but I don't think anyone is saying we encourage re-use > 'regardless' of differences in formats, informed people are saying we > think these particular terms are equivalent in the way they are used, can > we do something about it??. > > And taking your analogy a little further away from the well ordered > playroom where kids put their Meccano in one box and their Lego in > another... In digital library world metadata created using different > standards/models is exchanged between applications, and to do this is > converted more or less effectively. So just like little kids out there > bashing their toys together, throwing them into the wrong box and often > breaking them, conversions can be more or less 'lossy'. Toys are being > broken now, data is already getting lost on conversion. > > The benefit of re-use is that the metadata creator, the owners of the > metadata formats and the world in general buy into an agreement 'we agree > these 2 data elements as more or less equivalent, we think you should do > the same'. This is as opposed to creating more and more conversion > programmes mapping between different data elements. > > I would say piecemeal re-use is a step towards interoperability... As long as our standards adopt different meta-models, then there is no alternative to this conversion. There _is_ no option for reuse. A Lego brick can never be (re)used in a Meccano construction, and vice versa. I have to design the equivalent of my Lego nose cone using Meccano, and it will require me to start using Meccano parts and nuts and bolts (which I wouldn't use in Lego). Similarly, the component in the hierarchical model can never be (re)used directly in the triple model. Rather, I have to analyse the information that is represented by a structure based on model A, and then create new components that can represent that same information in a structure based on model B - and as Mikael's examples from the LOM show, with hierarchical models, that analysis has to consider the entire data structure, not just one part of it. Just to be clear - I'm not in principle objecting to having a property called http://www.loc.gov/mods/location owned and managed by LoC, and referenced by the DC Libraries Application Profile. I really don't care what URIs things have or who coins them, as long as they are persistent and I know what they denote so that I know how I should deploy them. I'm just highlighting that the fact that that single property has a LoC/MODS URIref does not signify that it has anything to do with a component used within MODS XML. It is _not_ a "reuse" of the mods:location XML element defined within MODS XML; it is a property, a completely new thing, quite separate from the existing XML element. And the fact that it has that name does not create any sort of "interoperability" between DC Lib AP and the MODS XML format. That "interoperability" would come from the development of an RDF mapping/binding for MODS (which might use MODS properties, MARC properties, DC properties, LOM properties, FOAF properties, etc etc etc). 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. Pete ------- Pete Johnston Research Officer (Interoperability) UKOLN, University of Bath, Bath BA2 7AY, UK tel: +44 (0)1225 383619 fax: +44 (0)1225 386838 mailto:[log in to unmask] http://www.ukoln.ac.uk/ukoln/staff/p.johnston/