I agree wholeheartedly with Karen (as usual ;-) ) and am also as usual
grateful to her for cutting straight to the real issue here.
I've been increasingly frustrated listening to some of the comments that
are coming across from libraryland, from folks who wish that DC were more
like MARC, so we could be more comfortable with it. I do understand how
that is, but the fact is that the world is changing, and we must learn to
handle lots of different kinds of data, not just MARC, or we will be
marginalized before we know it, both as regards DC development and in
libraries, where data from all kinds of sources (at all levels of
conformance with MARC), is already a way of life.
We cannot afford to sound like "Chicken Little," and predict dire results
if DCMI does not follow our lead. Yes, we have much to offer--experience
with large data files, with managing names, coping with changes over
time. That cannot and should not be forgotten. But we also have much to
"forget," if we are to disengage enough from our experience to be able to
see clearly the road ahead, and separate the very important from the merely
desirable.
Karen has managed to do that here. It is very important that we know what
rules or schemes were used to create or express a name, if there were
any. If there is no information given, we can handle that, too, though
with less predictable results.
Diane
At 08:53 AM 12/10/99 -0800, Karen Coyle wrote:
>At 12:10 PM 12/10/99 +0000, Berthold Weiss wrote:
> >We are strongly support the necessity of a structured form of
> >personal names. Astrid Schoger and Simon Cox are absolutely right.
>
>I think I would word this differently. I would say that we need to know the
>structure of personal names that we receive in metadata. I don't think that
>there is any one single structure that we can require, and I don't think
>that we can expect that everyone will follow a structuring rule. However,
>when a rule is used we need to know what it is.
>
>Structures for names can be very complex (i.e. AACR2) so simply saying
>"family name, forename" will not suffice. I'd rather there be a mechanism
>by which creators of metadata can indicate when they have used structure
>and what that structure is. This would also leave room for unstructured
>names (which will be part of our information space). While less precise,
>unstructured names, when you know that they are, can still be parsed
>simplistically in ways that enhance retrieval. So we want to take advantage
>of structure when it is present and work knowingly with unstructured data
>when that's what we've received.
>
>I'll give an example. If we have an un-qualified name data element and
>qualifiers for that element that indicate structure, we could get:
>
>Name 1:
>
><name>John Smith, Jr.</name> --> this is simple and unqualified
>
>Name 2:
>
><name> --> this one has structure
><name.schema>schemaname</name.schema>
><name.given>John</name.given>
><name.family>Smith</name.family>
><name.enumeration>Jr.</name.enumeration>
><name.display>John Smith, Jr.</name.display>
><name.sort>smith john jr</name.sort>
></name>
>
>Can a system handle both? Sure it can. What's essential is for everything
>to be labelled correctly, even when the label says: take your best guess.
>
>
>
>----------------------------------------------
>Karen Coyle [log in to unmask]
> University of California Digital Library
> http://www.kcoyle.net 510/987-0567
>----------------------------------------------
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|