James Weinheimer wrote:
> I can immediately imagine three sorts of titles that are different:
> those that do not appear on the item, but are created by the
> *cataloger*.
> 1) Uniform title (whatever form it takes). e.g. my example of Thomas a
> Kempis' Imitation of Christ. The original title is Imitatio Christi.
Well... in DC we have DC.Title and DC.Language. I am not a believer in
the synthesised "Uniform Title", though if an Authority Record already
exists, I'll follow its guidance.
<META NAME="DC.Title" LANG="la" CONTENT="Imitatio Christi">
<META NAME="DC.Title" LANG="en" CONTENT="Imitation of Christ">
etc
<META NAME="DC.Language" CONTENT="en">
Add on as many language variants as makes sense to do so. The one
metadata record will still only be referring to the one version of a
work (whether that be the Latin version or the English version). The
DC.Language field indicates what language the specific resource is
actually written in (as opposed to the copious fields present in
multiple languages in the metadata set).
> 2) The title of the larger item it belongs to. In my example, it is a
> part of the Christian Classics Ethereal Library.
The collection is an item by itself, with its own DC metadata set. The
items in that collection will have something like:
DC.Relation = IsPartOf "Christian Classics Ethereal Libarary"
The collection might have:
DC.Relation = HasPart "Imitatio Christo" <-- for the Latin version
DC.Relation = HasPart "Imitation of Christ" <-- for the English version
> 3) For non-roman alphabet items, there could be a transliterated title.
Isn't that what the language attribute is for? No reason for different
title-type fields. Just use the DC.Title field with the language
attribute indicating which language the title is presented in.
> All of these titles certainly help the user to find what they are
> looking for, but they may/may not appear on the item, itself. They
> should all be searched through a single "title" search, however.
They are all the same field - DC.Title. Q.E.D.
> > The special case of DC.Source.Creator ...
>
> There are examples of personal names as corporate bodies. A quick
> example from our catalog (I'm sure there are better ones)
> ------------
> AUTHOR: Adam and Charles Black (Firm)
> Adam and Charles Black are serving as a corporate body here, not "Black,
> Adam" and "Black, Charles", and the cataloger dealt with it
> appropriately.
As long as there is a company registered as "Adam and Charles Black",
I'll accept that. If Adam and Charles Black were acting as a team for
the production of this work, I'd list them as
DC.Creator = "Black, Adam"
DC.Creator = "Black, Charles"
There's no reason to add complexity. If the subtleties of the means of
collaboration are important, turn to a specialist database like MARC,
which has many different ways of encoding special information like "Adam
and Charles worked together on this as a team, rather than as two
individuals or as a company".
> Do we need these distinctions for documents on the web? Perhaps. But in
> any case, there needs to be some sort of guideline for dealing with
> items like this, even if it says "A person can never be a corporate
> body" (Not my opinion).
Well... a person can't be a corporate body. A person can (in Australia
at least) be a sole trader (in which case, they trade as John Doe, Sole
Trader). Maybe I've missed something?
Alex
--
Alex Satrapa
tSA Consulting Group Pty Ltd.
Canberra, Australia
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|