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