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