Posting to Autocat
On Tue, 1 Jun 2010 08:38:55 +1000, Tessa Piagno wrote:
I agree with everyone in this thread.
>Apart from the capatilization issue do we really have to have these new fields 336,337,338?
I would like to ask the same question in a slightly different form: while there are some definite advantages to these fields, are they worth the effort? But before we can decide whether they are worth it, we must figure out how difficult it will be to repurpose our existing records to be useful with any new records we create. Therefore, in concrete terms, can the 336 be generated from Leader/06, the 337 from 007/00 and 338 from 007/01?
Have there been any research or practical attempts in this direction? We should be able to, but if we cannot generate these fields automatically, I would say it would not be worth the effort, since we would be making the millions of current records obsolete in this regard, and the advantages from the new fields are a rather paltry return.
But if they can be generated automatically, it would be another matter. There is a lot of useful information in our fixed fields, such as this, but if it is our goal to make our records more useful in the new information universe, we must confess that information buried in the fixed fields based on position(!) is just too antiquated to work with. The new formats work on different principles. If this information can be extracted into the new fields, such as here into the 336 etc. fields, it could be very good.
Here is a specific example of what I mean:
This is one of the ways that I maintain that MARC format in its ISO2709 format is obsolete. Digging the fixed field information out of this record is not easy. In this example, Leader/06 is the first “a”. Determining where the 007 information can be even more complicated, would take more time for me to figure out, and it is far too much for a non-librarian type. (Remember
there is a position 0):
01142cam 2200301 a
92005291 DLC 19930521155141.9 920219s1993 caua j 000 0 eng a 92005291 a0152038655 : c$15.95 aDLC cDLC dDLC alcac 00 aPS3537.A618 bA88 1993 00 a811/.52 220 1 aSandburg,
Carl, d1878-1967. 10 aArithmetic / cCarl Sandburg ; illustrated as an anamorphic adventure by Ted Rand. a1st ed. aSan Diego : bHarcourt Brace Jovanovich, cc1993. a1 v. (unpaged) : bill. (some col.) ; c26 cm. aOne Mylar sheet included in pocket. aA poem about numbers and their characteristics. Features anamorphic, or distorted, drawings which can be restored to normal by viewing from a particular angle or by viewing the image’s reflection in the provided Mylar cone. 0 aArithmetic xJuvenile
poetry. 0 aChildren’s poetry, American. 1 aArithmetic xPoetry. 1 aAmerican poetry. 1 aVisual perception. 1 aRand, Ted, eill.
ISO2709 is actually more confining than only this. There are a hundred little areas where you cannot expand here. XML provides a much better format.
Still, digging this same information out of a MARCXML record is only slightly easier:
Only slightly easier because you *still* have to dig it all out based on position, e.g. in this example MARCXML record, we see
<marc:leader>00925njm 22002777a 4500</marc:leader>
<marc:controlfield tag=”008″>910926s1957 nyuuun eng
and in the leader and field 007, there are still the separate values in leader/06 and 007 positions 1 and 2 to dig out. This is totally obsolete. There is no reason to do this anymore and it is unrealistic to expect normal webmasters, such as those at Google, to even begin to understand or implement this. Therefore, opting for separate 336 etc. fields would be a step in the right direction so long as the *rules for input* do not change, or at least not much. The more the rules for input change, the more obsolete become our earlier records. This must be considered with great care, especially in these times where there will probably not be too many new catalogers hired.
The natural question, as you point out, is: should this demand more work from the cataloger? The answer is: of course not. And a related question: to create these 336 etc. fields, do we even need any retraining? Or could catalogers simply continue creating records as they always have, and these new fields would be made automatically with no one the wiser? Each catalog–and today, this should not be limited to library catalogs–could then take this information and display/search it however they want.
While the future for “catalogers” may be rather uncertain (I don’t know), the situation may be brighter for “metadata creators” i.e. people who can work easily in a more universal bibliographic environment including that outside of traditional libraries.