On 12/22/12 9:31 PM, Hal Cain wrote
> 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.
700 12 |a Verdi, Giuseppe, |d 1813-1901. |t Messa da Requiem. |f 1980.
740 0_ |a
Messa di Requiem.
"di" "da" ? Not gonna string match. Here it is necessary to say that we
go into the future with the MARC records we have, not the ones we wish
we had.
kc
>
> 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.
>
> Hal Cain
> Melbourne, Australia
> [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
>> 1980.
>>> 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.
--
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
|