THanks for this message, Diane.
I'd like to follow it up with the comment that I have, over the
last year or so, had the uneasy feeling that DC was in effect
recreating MARC - qualifiers, schemas, trying to plan for
every eventuality ....
Which we for sure don't need to have happen.
Mary
>X-Sender: [log in to unmask]
>X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
>Date: Fri, 10 Dec 1999 14:54:35 -0500
>Subject: Re: Antw: Re: Qualifier Proposal - DC Agents - Update WD
>From: "Diane I. Hillmann" <[log in to unmask]>
>To: [log in to unmask], [log in to unmask]
>X-Unsub: To leave, send text 'leave dc-libraries' to [log in to unmask]
>Reply-To: [log in to unmask]
>Sender: [log in to unmask]
>
>
>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
>>----------------------------------------------
>
______________________________________
Mary Lynette Larsgaard
Assistant Head, Map and Imagery Laboratory
Davidson Library
University of California, Santa Barbara
Santa Barbara CA 93106
telephone: 805/893-4049
fax: 805/893-8799
email: [log in to unmask]
______________________________________
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
