Ricky,
> The objection many of us have with 1:1 is in requiring 1:1
> description for versions and derivatives. I want to be able to use a
> single DC record to describe a digital image of an Ansel Adams
> photograph. If I am not allowed to say in a single record that the
> photographer is Ansel Adams and that the image is JPEG-compressed,
> then I'll break the rules rather than create a record for the
> negative, for the print, for the copy-photograph of the print, for
> the TIFF image, and for my various JPEG derivatives.
We're all possibly getting confused with hazy terms once more. In this case,
the term at fault is 'record'.
We all, I hope, agree several things;
- that Ansel Adams is NOT the creator of a JPEG image that Ricky creates
in scanning an Ansel Adams photograph
- that, in the majority of cases, a searcher will be after the 'Ansel
Adams picture', and will not really care that someone called Ricky Erway
scanned it... unless, of course, she gives up her day job at RLG to
become a world famous photograph scanner...! ;-)
- that, despite the point above, we would really quite like some
unambiguous way to associate Ansel Adams with his photograph, and Ricky
with the manifestation of that photograph that you and I can look at on
the web... preferably without Ricky getting sued for wrongly claiming to
have created the photograph!
When it comes right down to it, all that 1:1 is really saying is that we
want an unambiguous way to make these links and statements. _ONE_
interpretation of that is that we create one Dublin Core 'record' for
Ansel's photo and one for Ricky's scan, and link them together through the
Relation element.
Another way to do it, which becomes really easy with W3C's Resource
Description Framework (RDF) and is one of the reasons several of us are
working hard to create a friendly explanation of using RDF/XML for Dublin
Core, is to effectively embed these statements within a single 'record'.
Here, 'record' is a 'physical' thing, consisting of a single stream of
metadata (everything in the <HEAD></HEAD> area of an HTML document, for
example).
Another way of considering a 'record' is as an almost conceptual collection
of metadata to describe a resource. Several of these conceptual records can
exist within one physical record, allowing most of the concerns with 1:1 to
be addressed; you're not REALLY typing much more metadata, OR creating loads
and loads of 'physical' records; you're simply being unambiguous about who
did what to which resources. That's got to be a good thing, no?
As for the idea of creating individual records (whether physical or
conceptual) for the mountain which is photographed, the act of
photographing, the negative, the print, the scan, and the digital file on
your screen, well you CAN if it's important to the manner in which you are
describing things. You wouldn't, after all, want to MISLEAD people by
implying that either Ansel or Ricky were the creator of all of these when
they clearly weren't. Where your application or data are not such that any
implication of this kind could be made, and if telling people who did what
at that level of detail doesn't matter, then leave it out.
1:1 is an idea, not a law. It's a way of being unambiguous. It's a way of
saying what we mean. It's a way of demonstrating the relationships between
resources and their surrogates to an appropriate level of detail for any
application of Dublin Core. Finally, it's nothing new. Librarians and other
cataloguing/descriptive communities have adopted many of these ideas for
generations, although not always as explicitly as 1:1 sometimes appears to
state them.
Paul
-- dr. paul miller - interoperability focus - [log in to unmask] --
u. k. office for library and information networking (ukoln)
tel: +44 (0)1482 466890 mobile: +44 (0)410 481812
---------------------------- http://www.ukoln.ac.uk/interop-focus/ --
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|