Print

Print


While the 240, 130, etc. are subfield coded--most of the library systems
that I've dealt with pretty much ignore those subfield codes.  One of the
design goals in defining MODS was to simplify coding over MARC when
possible--this was judged (rightly or wrongly) to be one of these cases.

When you start talking about changing the "Spanish" to "spa" and having to
reconstruct the u.t. string from bits and pieces of subelements,
attributes, etc. I don't see any usefulness in that.  The language info is
adequately coded in other places in the MARC and MODS record.  It's only
included as a filing device in the u.t.

Dick Thaxter




On Fri, 28 Jan 2005, Mike Rylander wrote:

> On Fri, 28 Jan 2005 14:54:31 -0500, Dick Thaxter <[log in to unmask]> wrote:
> > MODS folks,
> >
> >   What I think is missing from this conversation is an understanding of
> > what a uniform title is designed to do in catalogs that follow AACR or
> > similar rules.  It is a device that tacks on any number of elements in
> > order to coerce an unchaotic arrangement in what can be very long listings
> > of similar and derivative works.  My own feeling is that it's unwise to
> > pick out language as one of these elements and treat it as not part of
> > that human-readable string that comprises the u.t.
>
> I don't want to treat $l as "not part of that human-readable string",
> I just want it to stay in it's own tag, just like in MARC.  MARC has
> the language-of-work in a subfield apart from the title text.  This
> allows you to use just the title text when appropriate, and to combine
> it with the language-of-work when needed.  MODS does not allow you to
> make the distinction.  In my book that is an example (albeit very
> small) of baby-with-the-bathwater.  I don't want to force anyone to
> forget $l, I just want to retain a little more information (the fact
> that $l is NOT embedded in $a) from MARC.
>
> >
> > Consider all of the MARC 240 subfields:
> >
> > # $a - Uniform title (NR)
> > # $d - Date of treaty signing (R)
> > # $f - Date of a work (NR)
> > # $g - Miscellaneous information (NR)
> > A data element not more appropriately contained in another defined
> > subfield.
> > # $h - Medium (NR)A media qualifier.
> > # $k - Form subheading (R)
> > # $l - Language of a work (NR)
> > # $m - Medium of performance for music (R)
> > # $n - Number of part/section of a work (R)
> > # $o - Arranged statement for music (NR)
> > # $p - Name of part/section of a work (R)
> > # $r - Key for music (NR)
> > # $s - Version (NR)
> >
> > Once you pick these apart and treat some as attributes, some as other
> > tags, etc. you really don't have a uniform title anymore.  It could be
> > argued that many of these different u.t. constituent parts might be better
> > coded separately from the main title string.  But if you do that it will
> > be a huge chore in order to put a u.t. back together in a useful form for
> > browsing a large number of hits.
>
> That's a bit strawmannish.  You have the same data separation in the
> original format, so where's the issue.  They will all still live under
> one tag, mods:titleInfo[@type="uniform"], just like the live in 240 in
> MARC.
>
> >
> > I suggest that anyone who doubts the usefulness of the uniform title as a
> > cataloger-constructed string might want to browse through one of the
> > following sequences in any large catalog:  any major work by any major
> > composer; any Bible translation; any U.S. Treaty heading; any author whose
> > works have been heavily adapted, translated, criticized, etc.
> > Shakespeare would be an obvious choice.
>
> I don't doubt it at all! I just want to use a more relaxed matching
> for other groups of records.
>
> >
> > It also seems to me that anyone creating a MODS record with a Titleinfo
> > tag of the type "uniform title" is probably doing AACR cataloging or
> > converting MARC AACR records.  It's not a tag that a non-catalog MODS user
> > is likely to misuse.
> >
> > I'm generally unapologetic about the AACR and MARCisms in MODS. It's not
> > that AACR and MARC got it right, but for MODS to work for my needs it
> > needs to support certain cataloging conventions at least until we've
> > gotten rid of our millions and millions of MARC records.
>
> Well, getting rid of MARC records will be a big job ;) , but in the
> mean time I don't see the problem with mirroring AACR fields from MARC
> a little more closely, especially if LoC is willing to revisit parsing
> out the <extent> text.  Since fields like <languageOfWork> as subnodes
> to <titleInfo> will only show up when AACR is used they shouldn't
> confuse anyone.  And all I'm lobbying for is to have the same
> information about the AACR fields from MARC put in MODS the way they
> were originally designed.
>
> I understand the slippery slope problem that this road leads to, but
> here is how I look at MODS:  MODS, in relation to MARC, is meant to
> provide a structured view of the *displayable data* for use as
> metadata.  To that end, each displayable subfield should get it's own
> tag, and each tag's name should map the the human readable name for
> the subfield from which the data is taken, or at the very least have
> an attribute to tell us which subfield it is from.  This means that
> parsing of things like <extent> do not need to be in MODS (even though
> it would be handy...) but things like the individual uniform title
> subfields *should*.  As another example, take the <name> tag.  Now,
> 100$a and $d (in the simplest compound case) both have there own
> encoding, <namePart> and <namePart type="date">, but are to be
> displayed together.  It is up the the programmer to make that happen,
> since MODS splits them up.
>
> Am I missing something really big here?
>
> --
> Mike Rylander
> [log in to unmask]
> GPLS -- PINES Development
> Database Developer
> http://open-ils.org
>


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*==*=*=*=*=*=*=*=*=*=*=*=*=*=*
*    Dick Thaxter  [log in to unmask] 202 707-7208                   *
*    Automation Specialist                                     *
*    Motion Picture, Broadcasting & Recorded Sound Division    *
*    Library of Congress                                       *
*                             The usual disclaimers apply      *
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=