Date:         Tue, 3 Dec 2002 12:05:36 -0500
Reply-To:     [log in to unmask]
Sender:       Metadata Object Description Schema List <[log in to unmask]>
From:         Marc Truitt <[log in to unmask]>
Organization: University of Notre Dame Libraries
Subject:      Re: Title element and subtitles
Comments: To: Metadata Object Description Schema List <[log in to unmask]>
Content-Type: text/plain; charset=us-ascii; format=flowed

Karen,

I think you've hit on the real issue here ('that we haven't really
settled on what the purpose of MODS is') and agree with most of what you
say below, with the exception of the following...

 > I also think that it isn't the richness of MARC that people object
to, > it's the parts of it that are detailed but not useful.

Isn't this a proof of the truism that 'one man's trash is another man's
treasure'?  What is 'not useful'?  And to whom?  I think that the very
richness of MARC records lies in the many encoded elements that some
might view as obscure and irrelevant.  A quick example :

A few months ago, I attended a meeting wherein an attendee attempted to
illustrate her point that much of the MARC record was really of marginal
value by rhetorically asking 'Who would wish to extract a listing of all
of the records for festschriften reflected in a library catalogue?'

Of the fifteen or so people present, I'd guess that perhaps half
immediately answered in the affirmative.

- mt

--
**************************************************************************
Marc Truitt
Head
Library Systems Department
213 Hesburgh Library
University of Notre Dame
Notre Dame, IN 46556-5629

Voice  : 574-631-3409
Fax    : 574-631-6772
e-mail : [log in to unmask]
cell   : 574-276-8726

"Librarians are different.  You just have to get over it, and move on..."
                          -- James Steenbergen
**************************************************************************


Karen Coyle wrote:
> At 04:46 PM 12/2/2002 -0500, you wrote:
>
>> Why does this seem like we're reinventing the wheel?  We know there was a
>> good reason for defining a MARC subelement for subtitle
>> information.  The same reasoning was applied when developing the
>> ISBDs.  It's not surprising that this argument is coming up again in a
>> MODS context, but it's making me wonder why we bothered with MODS if
>> people are going to enhance it to the point where it is as rich (and
>> complex) as MARC.  It's a somewhat backhanded compliment to MARC
>> really.  Maybe MARC's richness isn't such a bad thing, eh?
>
>
> Randy,
>
> I suspect that part of our "groping in the dark" here has to do with the
> fact that we haven't really settled on what the purpose of MODS is. I also
> think that it isn't the richness of MARC that people object to, it's the
> parts of it that are detailed but not useful.
>
> MARC and MODS are just data structures. What should be determining those
> structures is the data that we intend to carry. There's a big difference if
> we are carrying data that results from library cataloging, or if we are
> carrying data that has some other origins. Library cataloging data will
> have a certain level of detail, some amount of which is deemed useful in
> our environment. If instead MODS will be used to carry data that, for
> example, originates in the HTML of bookstore pages, then it will have less
> of that richness and the data structure will not need some of the features
> of the library cataloging record.
>
> What I am beginning to see here, mainly arising out of the postings by Yves
> (thank you, Yves!), is that MODS may be a good format to unite varieties of
> library cataloging that have considerable similarities but enough
> differences that they cannot reside in the same systems. It may also be
> able to carry bibliographic data that is somewhat less rich than library
> cataloging but considerably more rich than something like Dublin Core. For
> the moment, however, I think we will achieve more if we have a clear goal
> for MODS (i.e. carrier for library cataloging) than if we simply throw it
> out there and say "whatever."
>
> ----------------------------------------------
> Karen Coyle                    [log in to unmask]
>       http://www.kcoyle.net
>
> ----------------------------------------------