On Sat, 29 Jan 2005 09:10:20 -0500, Dick Thaxter <[log in to unmask]> wrote:
> On Fri, 28 Jan 2005, Bruce D'Arcus wrote:
>
> > On Jan 28, 2005, at 2:54 PM, Dick Thaxter wrote:
> >
> > > 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.
> >
> > None of us want to rehash the argument I've made here a few times, but
> > I'll just mention it:
> >
> > I think library catalogs are in general NOT easy to search, and that a
> > big part of the reason is the metadata of exactly this sort.
> >
> > So, yes, you've got legacy and you've got the AAR2, but there are still
> > better ways to do human-friendly searching.
> >
> > Bruce
> >
>
> I wasn't talking about searching.  The elements of the u.t. are not
> designed primarily to assist in searching or limiting searches. Every MARC
> OPAC that I know of uses the language codes in 008 or 041 in searching.
> The language in the u.t. is just for arrangement of a browse list in a
> potentially huge set of records.  Although there are other uses for
> u.t.'s--that's best rationale for their use in library catalogs.

In a MARC context I agree completely.  In a MODS context there are
other uses for uniform titles as long as they are not so lossy as to
make them useless, which they are now.  My goal is to create a MODS
OPAC precisely because MARC is not a good format for searching, at
least not compared to MODS.

I jumped into this thread precisely because of searching.  For the
PINES Evergreen project we see MODS as the "searchable version" of
MARC.  If we need to deal with the original MARC format to provide a
portion of searching precalculation, such as FRBR-like grouping, we
will, but it makes sense to me to have enough information in MODS to
do this.

>
> And I'm not arguing that the library catalog is the best or most intuitive
> way to search.  I'm trying to state some reasons why the construct of the
> u.t. evolved and what it is still useful for.
>

I won't argue for changing MARC, or against how it is useful to
catalogers.  I have no desire to change the world that much.  ;)

> In a MODS context, as I said before, anyone using a TitleInfo tag with the
> type "uniform title" is probably dealing in a MARC/AACR context.
>

But since MODS is a generalized format, why not let other contexts exist?

> And I notice you don't address the main argument I make--which is if you
> treat the language element of a u.t. this way, why  not the other dozen
> u.t. elements?

I would argue that we should treat the dozen other u.t. elements that
way.  Displayable data in elements and structural data in attributes.
I am not a cataloger, so I'm not the best person to make that
particular distinction for most subfields in MARC, but I do understand
240$l and that is why I've been using that as the example.  The point
of the discussion, as stated earlier, is to keep the <title> "clean".
MODS already does that for 245 with <title> and <subtitle> elements.

So, we agree that bibliographic standards should evolve (MODS exists),
and stay backward-compatible at the same time (the preponderance of
MARC data used by non-catalogers exists in MODS).  We have a huge
resource available in the form of millions of MARC records, and as
library software evolves we are finding new ways to correlate parts of
these data that were not in the original design.  MODS is an enormous
boon to anyone creating end-user software because it simplifies and
standardizes the interpretation of MARC records.  These new
correlations could be done in MARC, but MODS simplifies the problem
for non-catalogers such as myself.  That is why we (my project) are
using it.  However, in this particular instance MODS is a little too
lossy to be used for research into advanced record matching.  I just
want the evolution to continue.  MODS is not complete enough to
recreate an entire MARC record, so I see no benefit in assuming that
since AARC catalogers ignore the separation of subfields that MODS
should do the same.  MODS is there to help the programmer and if data
can be repurposed without loosing useful information I consider that
evolution.

Again, am I missing something big here?  This isn't really about MARC.
 I don't want MARC to equal MODS, I understand that this is not the
reason for MODS.  I just don't want to lose useful information in the
translation.  But, like I said before, I see the slippery slope.  I
don't think that is the ultimate end of adding u.t. subfield
separation, though, since  u.t.s can be used for initially unintended
purposes even in MARC, and libraries are just starting to learn that.
MODS seems like the natural place to work with these new techniques if
for no other reason than to avoid abusing MARC.

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