Re: Are MARC subfields really useful ?

I'm with Jonathan here.

To add to it, I take it that MARC here really means MARC 21. When we
moved from MARC21-Fin to MARC 21, we lost a lot of the structure in some
important places, such as 773g. It's very unfortunate to have all these
pieces of information stuffed in a single subfield when you try to e.g.
construct useful OpenURL's.

If using subfields is too difficult, it's got a lot to do with the tools
we use. Who said, for instance, that you need to enter all the data
directly to a MARC record? I used to work on a system that allowed the
cataloguer to enter most of the metadata in a form and see the MARC
record be constructed by the system simultaneously. You didn't lose any
flexibility or the heart of the data, but you could tab through the
fields and fill them very quickly. This is just to say that most of our
user (staff) interfaces don't do a very good job with the data entry.

--Ere

On 4.6.2010 18:00, Jonathan Rochkind wrote:
> 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
>


-- 
Ere Maijala (Mr.)
The National Library of Finland