So, from the standpoint of working with computer systems trying to make use of Marc data, the biggest frustration in Marc is that the data is not sufficiently structured for actual machine processing/recognition/decision making.
If you were _just_ to get rid of sub-fields, and have everything in a field just as one 'narrative' string -- this would make the problem worse. The sub-fields are almost the only thing we've got that lets software pull out the data it wants. Why not take the hypothesis further, and say, why not get rid of marc _fields_ too, why not just have the whole cataloging record in one big string, perhaps delimited by ISBD punctuation, or perhaps even that is 'unneeded expense', just one big string, why not? Well, obviously becuase it would make our data nearly uselsess for machine processing.
Now that said, if we're spending lots of time (which is money) creating Marc records -- and they STILL aren't adequately machine processable, obviously something is wrong. I don't think the answer is that we need to spend MORE time, the answer is that we are spending time _improperly_. The answer isn't giving up on structuring our metadata or just "structuring it less" (OR just un-thinkingly "structuring it more"), the answer is on figuring out how to structure it _right_, so the time spent on it actually _pays off_ in metadata that can actually be used effectively by software.
Figuring out how to do this right isn't neccesarily easy, there isn't an easy magic bullet answer, but it's work we ought to be doing. Some of the people who are trying to figure it out include Hillman/Coyle/et al's work on RDA vocabulary, and Jenn Riley's work on FRBR metadata.
Jonathan
________________________________________
From: Next generation catalogs for libraries [NGC4LIB_at_LISTSERV.ND.EDU] On Behalf Of Karen Coyle [lists_at_kcoyle.net]
Sent: Friday, June 04, 2010 10:55 AM
To: NGC4LIB_at_LISTSERV.ND.EDU
Subject: Re: [NGC4LIB] Are MARC subfields really useful ?
Quoting Dan Matei <dan_at_CIMEC.RO>:
>
> All subfields are useful enough to justify the effort to delimit them ?
>
> I thought we are looking for reducing the cost of cataloguing. Or not ?
I don't think we know what "subfielding" costs us. Is it more than
adding notes like "Includes bibliographic references" even though
there is also a coded element for that in the fixed fields? (Which is
up there with the idiocy of the 020 field, frustration that I share
with Andrew.) And even if something costs, don't we also have to look
at the value? Adding subject headings is very costly, from what I
hear, as is doing authority control. I suspect that those cost much
more than adding in subfielding. But what are they worth?
I've been sitting in on a group that will send a report this ALA (I
believe) to bigheads on ROI for cataloging -- not a study, but ideas
on what needs to be studied. It's a very difficult task. We don't know
what elements of our data lead to "user success" (however that is
defined). Without that information, it's darned hard to know what you
can and cannot eliminate from the cataloging task.
kc
--
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
Received on Fri Jun 04 2010 - 11:07:14 EDT