 |
 |
There is certainly some clarification or discussion required around all this. Under the currently agreed semantics, I think that DC.Identifier and DC.Format offer few problems around surrogates and 1:1. With DC.Type I have been espousing a line in which DC.Type gives the genre of the information, regardless of the instantiation format. For example, text-is-text, whether it is formatted as image/g3fax or sepia/vellum, thus various versions or surrogates of the same resource would retain the DC.Type="text". This principle _appears_ to break down for physical objects. For example, in the 1:1 examples we have been suggesting that in "instantiating" a sculpture as a photograph, the DC.Type changes from "Physical Object" to "Image". So why do we think there is a difference between these two cases? I believe that this is connected to the "IsFormatOf" vs. "IsBasedOn" distinction which arose in the DC.Relation discussions. In the former "IsFormatOf" case, the change in format is intended to be essentially neutral in regard to content or Intellectual Property questions. However, no matter how you try to disguise it, a photograph that "IsBasedOn" a sculpture is a very different thing, with much different "content", and will always be, in rather important ways, a new interpretation of the subject, and thus a creation in its own right. Thus it is a different thing in its essence, and gets its own "new" DC.Type because of this. In both cases, of course, if the original resource is important then it should be indicated using the DC.Relation element. Now I, at least, am still comfortable that application of the 1:1 principle in these ways is not only consistent and defensible, but when used properly (or in Diane Hillman's words "creatively"), is also useful. However, this might depend on rather careful, perhaps subtle analysis of "content" in order to settle on the proper genre or DC.Type. I guess this is why cataloging is such a fine art, but IS IT THE POINT OF DC? There is a dilemma here between the "simple" application domain for DC, and a consistent, logical application of modelling rules and semantics, which are possibly a bit broken anyway in DC because of the oft noted ambiguity within the DC-15, for example. Perhaps it could be partly solved just through more and more examples, but can we expect users to look at these? My feeling is that a case could be made for types such as "surrogate" to satisfy the former, but there is a real danger of this running away from us. There is however, arguably, a real choice here. As for the question of where to record the creator of the physical-object original, perhaps a case could be made for using DC.Contributor, or maybe a "role" on one of these ...? ***NB As noted in my gloss to the "Simon Cox" examples, information that you can't get into anywhere else can pretty much _always_ be jammed into **DC.Description** without offending anyone. ----- In Simon Pockley's examples from film, there is no real problem if the surrogates are frames or digital videos, etc (the DC.Type stays as "image"(1) ) but as soon as the surrogate is something like a text description, then we leave DC.Type="image" behind. I think that some of Simon's problem is the fuzzy boundary between data and metadata. Simon: in the cases where you want to have an on-line text surrogate for an item from your holdings, then why not just let the DC metadata play this role itself? Identify the offline resource, using your own index system, in DC.Identifier. If you want a longish text description then use DC.Description, etc, etc. (1) perhaps "image/moving" when we get around to adding more structure to the vocabularies later on. -- __________________________________________________ Dr Simon Cox - Australian Geodynamics Cooperative Research Centre CSIRO Exploration & Mining, PO Box 437, Nedlands, WA 6009 Australia T: +61 8 9389 8421 F: +61 8 9389 1906 [log in to unmask] http://www.ned.dem.csiro.au/SimonCox/