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/
|