On Sat, 22 Dec 2012 12:38:27 -0700, Laurence S. Creider
<[log in to unmask]> wrote:
>Dead horse, yes. MARC is simply not capable of doing all the things that
>we want and/or need our metadata to do. It has been a wonderful tool that
> has outlived a number of proposed replacements, and an increased
>granularity could probably be introduced into the system in a major
>reworking that would solve some of the issues you mention below. Even a
>non-systems person like myself, however, can see that no amount of
>tweaking will provide the degree of relatedness amongst data that we need.
>Of course, the other side of the issue is that any proposed replacement
>for MARC will be DOA UNLESS it can adequately and usefully translate all
>those millions of MARC records into the new format without human
>intervention on each record.
Yes; or offer a default which at least shows the kind of data that can't be
connected in terms of the relationships.
All in all, I am a bit bemused by this thread: the 740 tag in question is
dubious at best, because the same title string is already included in an
added name-title access term which is already coded as analytic, i.e. that
tag represents a distinct piece of content included in the resource
described. Such redundancy is required by some ILSs for indexing, but a
straightforward string-matching routine will surely reveal it, and the
cognate status of XXX -2 $t with 740 (or with part of a contents statement
in 505 with full subfielding) shows the way towards applying appropriate
matching algorithms -- in this instance, to discarding that 740.
Data not distinctively coded in MARC can't be assigned a distinctive label
in a new system, without at least some reprocessing. If the Bibframe
project is to come to grips with existing MARC data, which already isn't
perfectly consistent, some clever correction routines will be called for.
At the outset, I rather think, this is a different task from developing and
testing a new framework (of a new kind); but seeing what's been achieved
(still imperfectly) with name authority data in VIAF, I expect that a great
many of the non-straightforward MARC records which inhabit our catalogues
and shared databases can, in the long term, be whittled away; indeed,
looking at OCLC, to take the outstanding example, it seems likely that a
fair proportion of them will be found to be duplicates and able to be
discarded anyway -- or, if done under different cataloguing codes, linked as
a kind of parallel data.
[log in to unmask]
>On Sat, December 22, 2012 7:38 am, Karen Coyle wrote:
>> On 12/21/12 4:51 PM, J. McRee Elrod wrote:
>>> MARC is a very rich and informative coding system, which has been under
>utilized by ILS.
>> It's rich, informative, and often highly ambiguous. For example, in this
>case where there is more than one work but only one 740, to which work
>does the 740 pertain? Who is the creator related to this title? MARC does
>allow those relationships to be coded ($3) but that is rarely included.
>Ditto the other 7xx's in this record, which do not designate which work
>they relate to. Systems can only work with data that has all of its
>meaning expressed in a codified way in the metadata. In MARC records, (as
>in pre-MARC cataloging) there is an assumption that a human will be
>reading the data and making the right connections. That doesn't translate
>to the machine world. Thus, there is little that one can do with the 7xx's
>in this record if you wish to show that there are two separate works
>included in the package:
>> 245 10 |a Missa solemnis / |c Ludwig van Beethoven. Messa di Requiem
>/ Giuseppe Verdi |h [sound recording].
>> 700 1_ |a Milanov, Zinka. |4 prf
>> 700 1_ |a Castagna, Bruna. |4 prf
>> 700 1_ |a Björling, Jussi, |d 1911-1960. |4 prf
>> 700 1_ |a Kipnis, Alexander, |d 1891-1978. |4 prf
>> 700 1_ |a Moscona, Nicola. |4 prf
>> 700 1_ |a Toscanini, Arturo, |d 1867-1957. |4 cnd
>> 700 12 |a Verdi, Giuseppe, |d 1813-1901. |t Messa da Requiem. |f
>> 710 2_ |a Westminster Choir. |4 prf
>> 710 2_ |a NBC Symphony Orchestra. |4 prf
>> 740 0_ |a Messa di Requiem.
>> Once again (as I continue to beat this dead horse) basing a future
>bibliographic model on MARC can't move us very far forward. I liked Mark's
>opening statement that our goal here is "Seeing how the end results match
>the "intention" of the bib record." I think that the intention, in many
>cases, may be richer than the MARC encoding.