Tony and Ricky may be on the right track with their proposals for
the need for more information to be captured but I'm not sure that jamming
it into the DC record is the right approach for dealing with it. CIMI is
thinking we need to use much more of the Warwick Framework approach to
handling packages of metadata to do the kinds of discovery that we had
originally imagined using plain DC for. We are certainly committed to the
idea of DC but I guess are leaning towards the minimalist camp and looking
at other mechanisms besides DC to handle more complicated metadata.
We think (generally) anyone searching for a museum object on the web
wants the textual information about the object and while they want an image
are not expecting the original paint and canvas but a digital rendition
[1]. They may also want to know details about the artist and other
information associated with the original object. As well as wanting
information about the original object viewers want information about the
renditions such as availability, restrictions, publisher, and yes maybe
even who scanned it.
So we're having trouble telling the data from the metadata. We are
thinking that the information about the original is just metadata about the
rendition so we need to adjust how we think about original and
surrogate/rendition. We suspect that trying to complicate DC may not be
the best way to go but rather we should look at how to apply RDF (Resource
Description Framework) to carry the required information in a way that
doesn't prejudice data over metadata.
While we are thinking about this we don't have a clue how to do it.
We hope to explore these issues when we start our metadata implementation
testbed project later this year. In that work we will have 6-8 CIMI
members looking at what metadata we need to describe a variety of
heterogenous museum collections and imagebases, how far DC will go to
satisfying our needs and how to deliver the information in Z39.50, XML, and
RDF syntaxes.
CIMI has been involved in an implementers testbed for Z39.50 which
was a very valuable exercise in sharpening our thinking and forcing us to
focus on hard implementation issues. A similar testbed for DC would be an
excellent way to keep this work moving ahead. CIMI would participate.
*********
[1] We use the term rendition instead of surrogate because it
accomodates both the case of digital art where the original is digital and
the viewer might well be seeing it, and the more common case where it's
well known that the image of Starry Night being viewed is certainly not the
original.
At 12:15 PM 9/23/97 +0100, Tony Gill wrote:
>I like the approach to 'the surrogacy problem' proposed by Ricky; it's
>simple to understand (and therefore simple to explain to others), easy
>to use, and should be able to accommodate sufficiently rich information
>for resource discovery purposes; I don't think the 'assumed and
>unspoken' surrogacy is problematic in this context.
>
>However, as Ricky points out in an earlier message, it will require some
>careful adjustments to both the element definitions (which need
>overhauling anyway IMO) and the scope of DC itself, so I'm looking
>forward to seeing the RLG proposals in Helsinki. It will also mean that
>TYPE will need to store a lot more than just Internet MIME types!
>
>Is there any mileage in the idea of creating separate DC 'packets' for
>each object in the chain of surrogacy? Something along the lines of:
>
><META NAME=package.begin.1 CONTENT="Dublin Core">
><Information about an original painting for example>
><META NAME=package.end.1 CONTENT="Dublin Core">
>
><META NAME=package.begin.2 CONTENT="Dublin Core">
><Information about a photo of the painting>
><META NAME=package.end.2 CONTENT="Dublin Core">
>
><META NAME=package.begin.3 CONTENT="Dublin Core">
><information about a digital image acquired from the photo>
><META NAME=package.end.3 CONTENT="Dublin Core">
>
>This approach would help differentiate the different objects in the
>chain of surrogacy, if people think that this level of delineation is
>necessary... thoughts?
>
>Another possible problem: There used to be an assumption that element
>order could not be relied upon as a way of encoding information; is that
>still the case? Would that also apply to stuff between <start> and <end>
>tags?
>
>T.
>
>Ricky Erway wrote:
>
>> We will likely advocate (for people using the Dublin Core for a
>> variety of resources, including non-web resources) describing the
>> original always and if there is a surrogate, also describing the
>> surrogate in the same "record" by repeating the appropriate tags in a
>> second tag set.
>>
>> So, if you have an image of a painting, first describe the painting,
>> then repeat the elements necessary to describe the surrogate. This
>> reflects our thinking that when someone is looking for a painting
>> on the web, they'll call it a painting, even though they may know
>> it's impossible to have a painting on the Web (unless it's created
>> using PC Paint!). The surrogacy is assumed and unspoken.
>>
>> creator: VanGogh
>> title: Starry Night
>> publisher: MOMA
>> date: 1889
>> type: painting
>>
>> creator: Nicolas Pioch
>> title: Image of Starry Night
>> publisher: WebMuseum
>> date: 1996-05-20
>> type: image/jpeg
>>
>> -- and if it's important to describe the photograph that was scanned
>> perhaps a middle set of elements is called for!
>>
>> The point is that users will look for the original thing, so you want
>> to supply that metadata. It could be that the only important aspect
>> of the surrogate is its URL, but some additional info about the
>> surrogate might be useful -- especially for this example, where there
>> are many surrogates on the Web.
>
>
>-- Tony Gill ---------------------- Programme Leader: ADAM & VADS --
> Surrey Institute of Art & Design * Farnham * Surrey * GU9 7DS * UK
> Tel: +44 (0)1252 722441 x2427 * Fax: +44 (0)1252 712925
>-- [log in to unmask] -- http://adam.ac.uk -- http://vads.ahds.ac.uk/ --
John Perkins, Executive Director
CIMI - Consortium for the Computer Interchange of Museum Information
252 Viewmount Dr. RR2 Tantallon, Nova Scotia, B0J 3J0 Canada
voice: 902-826-2824
fax: 902-826-1337
email: [log in to unmask]
cimi info: http://www.cimi.org/cimi
|