On May 3, 2010, at 2:47 PM, Aaron Rubinstein wrote:
>> 1. MARC the data format -- too rigid, needs to go away
>> 2. MARC21 bib data -- very detailed, well over 1,000 different data
>> elements, some well-coded data (not all); unfortunately trapped in #1
>
> For the sake of my own understanding, I would love an explanation of the
> distinction between #1 and #2...
Item #1
The first item (#1) is MARC, the data structure -- a container for holding
various types of bibliographic information. From one of my older publications
[1]:
...the MARC record is a highly structured piece of information.
It is like a sentence with a subject, predicate, objects,
separated with commas, semicolons, and one period. In data
structure language, the MARC record is a hybrid sequential/random
access record.
The MARC record is made up of three parts: the leader, the
directory, the bibliographic data. The leader (or subject in our
analogy) is always represented by the first 24 characters of each
record. The numbers and letters within the leader describe the
record's characteristics. For example, the length of the record
is in positions 1 to 5. The type of material the record
represents (authority, bibliographic, holdings, et cetera) is
signified by the character at position 7. More importantly, the
characters from positions 13 to 17 represent the base. The base
is a number pointing to the position in the record where the
bibliographic information begins.
The directory is the second part of a MARC record. (It is the
predicate in our analogy.) The directory describes the record's
bibliographic information with directory entries. Each entry
lists the types of bibliographic information (items called
"tags"), how long the bibliographic information is, and where the
information is stored in relation to the base. The end of the
directory and all variable length fields are marked with a
special character, the ASCII character 30.
The last part of a MARC record is the bibliographic information.
(It is the object in our sentence analogy.) It is simply all the
information (and more) on a catalog card. Each part of the
bibliographic information is separated from the rest with the
ASCII character 30. Within most of the bibliographic fields are
indicators and subfields describing in more detail the fields
themselves. The subfields are delimited from the rest of the
field with the ASCII character 31.
The end of a MARC record is punctuated with an end-of-record
mark, ASCII character 29. The ASCII characters 31, 30, and 29
represent our commas, semicolons, and periods, respectively.
At the time, MARC -- the data structure -- was really cool. Consider the
environment in 1965. No hard disks. Tape drives instead. Data storage was
expensive. The medium had to be read from beginning to end. No (or rarely any)
sequential data access. Thus, the record and field lengths were relatively
short. (No MARC record can be longer 99,999 characters, and no MARC field can
be longer than 999 characters.) Remember too the purpose of MARC -- to transmit
the content of catalog cards. Given the leader, the directory, and the
bibliographic sections of a MARC record all preceded by pseudo checksums and
delimited by non-printable ASCII characters, the MARC record -- the data
structure comes with a plethora of check and balances. Very nice.
Fast forward to the present day. Disk space is cheap. Tapes are not the norm.
More importantly the wider computing environment uses XML as their data
structure of choice. If libraries are about sharing information, then we need
to communicate to them in their language. The language of the Net is XML not
MARC. Not only is MARC -- the data structure -- stuck on 50 year-old
technology, but more importantly it is not the language of the people to whom
we want to share.
Item #2
Our bibliographic data (item #2) is the metadata of the Web. While it is
important, and it adds a great deal of value, it is not as important as it used
to be. It too needs to change. Remember, MARC was originally designed to print
catalog cards. Author. Title. Pagination. Series. Notes. Subject headings.
Added entries. Looking back, these were relatively simple data elements, but
what about system numbers? ISBN numbers? Holdings information? Tables of
contents? Abstracts? Ratings? We have stuffed these things into MARC every
which way and we call MARC flexible.
More importantly, and as many have said previously, string values in MARC
records lead to maintenance nightmares. Instead, like a relational database
model, values need to be described using keys -- pointers -- to the canonical
values. This makes find/replace operations painless, enables for the use of
different languages, as well as numerous other advantages.
ISBD is also a pain. Take the following string:
Kilgour, Frederick Gridley (1914–2006)
There is way too much punctuation going on here. Yes, as a human you can figure
it out, but a computer is stupid and needs to have things made explicit. Do all
values in all fields inside parentheses denote dates? No. Are all names
presented in last-name, first-name order? No. Something like this would be much
better:
<author>
<first_name>Frederick</firstname>
<last_name>Kilgour</last_name>
<birth_year>1914</birth_year>
<death_year>2006</death_year>
</author>
The example above is unambiguous.
MARCXML removes no punctuation. It retains all of the ISBD "encoding" as well
as the archaic field codes (110, 245, 650, etc.). MODS goes a step beyond this.
It replaces the field codes with human readable labels/words. It also breaks
out some of the sub-fields denoted by ISBD into explicitly labeled fields.
MARCXML is a step in the right direction. MODS goes even further. Neither
really go far enough.
Why isn't this metadata as necessary as it used to be? Because with the advent
of full text indexing it is possible to use computers to determine the
"aboutness" of a document as well as how a document relates to other documents.
Controlled vocabularies are not useless, just less useful and less necessary
than previously.
Well, that is enough for now. Dinner time.
[1] http://infomotions.com/musings/marc-reader/
--
Eric Lease Morgan
