On 04/08/2011 09:59, J. McRee Elrod wrote:
<snip>
Bernhard said:
But seriously, XML is certainly inadequate as a medium for data input
and editing. A software interface will have to shield the raw XML
entirely from the view of catalogers.
Exactly. MARC is a shorthand - so much easier to say 130 and 240 than
to give them verbal names.
XML has the ability to "play with others", but we can produce XML from
MARC more easily than we can create it directly.
</snip>
Of course, catalogers never see the raw MARC format either. The problem
with producing XML from MARC is that much of the internal structures of
MARC is transferred into the XML. This is primarily why so many have
said that MARCXML is not one bit better than MARC as it is now. (I
disagree and emphasize that it is a very important, and inexpensive
*single step* in the right direction compared to what we have now) In my
own opinion, I agree that retaining numbers instead of the names (in
English) *would be* much better, but so many have been so vehement about
this, I just gave up--because in the end, it's all just computer codes
and to the computer, it makes no difference whether something is coded
"100a" or "personalNameMainEntry" or anything else you can come up with.
The way the code is then displayed to the searchers or to the inputters
(catalogers) is entirely up to the system designers, so that "100a" or
"personalNameMainEntry" can display to them this way, or in Russian,
Chinese, UNIMARC codes or pictures of Elvis Presley during different
periods of his life! :-) They can display any way at all. Plus, one
person on a computer can have one rendering, while a person on the
computer sitting right next to it, looking at exactly the same record,
can have it in a completely different rendering.
One of the real practical advantages to users, (at least I think) of XML
comes with being able to create web services that can do all kinds of
things. So for example, if I am interested in the archaeology of Rome, I
could download an app to my Iphone, or an API to place on my website,
that would automatically query the LC catalog for the 10 latest books on
Roman archaeology and retrieve *only the titles*, which would have links
to the complete records in the LC catalog so that if I am interested in
something, I could get more information. Or the same could work with
catalogs in Italy (non-MARC21) or the Blackwells catalog (perhaps in
ONIX) or some websites I may have selected personally on Roman
archaeology that provide reviews or something, plus some other full-text
databases on Roman archaeology (who knows what any of these formats
would be?).
Or better yet, as is very possible today, to search *all of this at once
automatically* and bring them all together into a single page for me to
peruse and to further sort and work with in all kinds of ways. There are
thousands of variations on this but ISO2709/MARC21 breaks down in this
kind of environment since its purpose is to transfer complete catalog
cards from one library catalog to another. It is also very probable that
in such an application, MARC21 (i.e. library data) would *not* be the
most utilized format, and if there were no handy and relatively
easy-to-use XML format, developers would think it wasn't worth their
time and not include it, resulting in the disaster that our data would
end up being ignored completely by the vast majority of people who are
interested in the archaeology of Rome. (This refers to my comments in
the first paragraph about why I changed from mind about changing from
the MARC numbers to entire words)
What role does, and should, the cataloger, with unique skills, play in
such an environment? The cataloger should play a very, very big role, I
think, but we must first consider what a cataloger does in ways that are
different from the traditional roles.
--
James Weinheimer weinheimer.ji...@gmail.com
First Thus: http://catalogingmatters.blogspot.com/
Cooperative Cataloging Rules: http://sites.google.com/site/opencatalogingrules/
