Sorry to say this, Carl, but as a film historian [for the purposes of
argument] attaching a seventeeth century date to a motion picture is an
impossibility! However, that doesn't challenge your point, only your
example. The argument for DATE applying to the 'work' not its digital
instantiation, might have been better illustrated by a scanned first
impression of the published play.
The greatest challenge in the application of the Dublin Core is finding
ways to describe the content of 'document like objects' that result from a
conversion to digital form. This is further complicated when the digital
'version' derives from a surrogate for the original work. We seem to be
making implicit judgements about when these 'degrees of separation' have
meaning in the discovery process. Ricky's points in the discussion of
Resource Type illustrated this.
We need application guidelines that enable the disambiguation of the
various concepts. We also need to acknowledge that there are times [and
perhaps domains] where the answer isn't straightforward, and provide means
to represent the complexity that results.
I hope that the Helsinki meeting can tackle this issue head on, and regret
that I've had to cancel my plans to be there.
jennifer
At 3:25 PM 3/10/97, Carl Lagoze wrote:
>The following is a very short position paper on the DATE element, for
>use in discussion on the matter in Helsinki.
>
>I start with three motivations:
>1. It is unacceptable to have an element in the Dublin Core that
>must be qualified to have meaningful semantics. I thought this was
>obvious until I read a number of e-mail messages that implied or clearly
>stated that the DATE field must be qualified to have meaning.
>2. Any qualifying of an element must not alter the semantics of the
>item. This is what we decided in Canberra, so nothing new here.
>3. The primary goal for the Dublin Core is to assist in resource
>discovery (as opposed to administration, content rating, etc - the other
>things you might do with other metadata in a Warwick Framework setting).
>The meaning/description of fields should be influence by this primary
>role of the DC.
>
>The clearest, and least ambiguous date that we can attach to an object
>(and that is useful for resource discovery) is the date of creation of
>the content. I am not saying that this is unambiguous, but certainly
>less ambiguous than starting to talk about "put in its current form", or
>"issued", or "last modified", which may be extremely confusing to the
>resource discoverer. The following example, which came out of
>discussion with Ron Daniel, helped me with this. If I do a search with
>the semantics "works by english poets and writers of the seventeenth
>century whose last names begin with S" I expect to get back
>Shakespeare's plays in their various forms. One of these may be the
>movie Hamlet that stared Mel Gibson and was released in 1996(?).If I do
>a search with the semantics "works by english poets and writers of the
>twentieth century whose last names begin with S" I expect to get back
>works by Arthur Symons (and NOT the Mel Gibson rendition of the
>Shakespeare play). The unadorned DATE for the "Hamlet" movie should be
>1603.
>
>I have very hard time coming up with qualifiers for this DATE field that
>do not change the semantics stated above. Certainly, DATE.scanned or
>DATE.filmed violate the Canberra qualifier rule. Maybe someone else can
>come up with sensible qualifiers, but there appear to be a very limited
>set.
>
>If we wish to have other date semantics in the DC then we need another
>date field OTHER_DATE whose definition is "other dates in the lifecycle
>of the resource that the creator or manager deems important. Then we
>could have OTHER_DATE.scanned, OTHER_DATE.indexed and all the rest.
>
>Enough said. Many thanks to Ron Daniel for his clarity and "okie
>wisdom".
>
>See you all soon.
>
>Carl
>
>------------------------------------------------------------------------
>Carl Lagoze
>Project Leader, Digital Library Research Group
>Department of Computer Science, Cornell University
>Ithaca, NY 14853
>Phone: +1-607-255-6046
>FAX: +1-607-255-4428
>E-mail: [log in to unmask]
>WWW: http://www2.cs.cornell.edu/lagoze/lagoze.html
--------
J. Trant [log in to unmask]
Partner and Principal Consultant www.archimuse.com
Archives & Museum Informatics
5501 Walnut St., Suite 203 ph. + 1-412-683-9775
Pittsburgh, PA USA 15232 fax + 1-412-683-7366
--------
|