On Sat, 29 Jan 2005 09:17:48 -0500 (EST), Dick Thaxter <[log in to unmask]> wrote:
>
> 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.

I think we're talking past each other on this one.  I don't want to
turn "Spanish" into "spa", I just want "Spanish" to be in a seperate
element under titleInfo in MODS so that I can ignore it.  Since I only
want to do that for research into using MODS for FRBR-like grouping
(at this point), I have a local solution for the time being.

>
> 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      *
> *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
>
>


--
Mike Rylander
[log in to unmask]
GPLS -- PINES Development
Database Developer
http://open-ils.org