James L. Weinheimer wrote :
> In this case, if the *only reason* to code the $q
> is to provide punctuation such as parentheses,
> that single reason is not worth the training and
> general hassle of working with the coding. if we
> can find other reasons, such as you have
> mentioned with 245$a and $b, then it is another
> matter.
OK. Reasons to do this ? One reason of course, not
yet mentioned but certainly not to be overlooked, is
to ( greatly help ) give cataloguers -- and by extension
most other librarians, I believe -- the feeling that they
are something special, that they are specialists, that
they have special competencies and understanding,
that they *are needed*, resulting in self-esteem
( and of course a salary -- and therefore costs for
other parties -- but that's not my point here ).
Depending on how you look at it, and who you are,
it's even possible to consider [ there's that word
again ! ] this to be in effect the *most important*
reason. Less the most important reason for getting
into such a regimen in the first place, I suppose
you'd have to say, than the most important reason
for disinclination ( unconscious or otherwise ) and
failure to abandon it.
Let's be realistic, after all, and keep this factor, for
pragmatic reasons, squarely in the equation, until
no longer necessary.
And what you say about patrons "car[ing] about the
parentheses [ and suchlike ] one way or the other,
or even really notic[ing]"
them, rings quite true to
me -- as it probably does to a great many others.
Our problem is sometimes that we tend pathologi-
cally to think that they do care, and usually at least
to think that they *ought to* care. ( Horsefeathers,
need I add ? )
- Laval Hunsucker
Breukelen, Nederland
----- Original Message ----
From: Weinheimer Jim <j.weinheimer_at_AUR.EDU>
To: NGC4LIB_at_LISTSERV.ND.EDU
Sent: Sat, June 5, 2010 2:27:41 PM
Subject: Re: [NGC4LIB] Are MARC subfields really useful ?
Karen Coyle wrote:]
<snip>
Actually, when doing large scale, automated record matching, the $a $b difference has been useful. Not everyone agrees on what is and isn't a
subtitle, but more agree on what is the title (although of course it can go either way). In matching, we weighted matches on 245 $a high,
and a lack of 245 $b on one of them was given a lesser penalty. This is different from just allowing a match on partial strings, many could
match partially (left-anchored) and yet be different works.
</snip>
This is one example of how a new use for an older, obsolete purpose of the coding could become useful. But it still needs to be demonstrated that it is worth the labor of manually coding each subfield. To do it takes extra coding and transformations from the beginning to the end, plus the additional training. Also, if we accept information from other agencies, e.g. Dublin Core or Scholarly Works AP, they don't encode a separate subtitle. Would it be worthwhile to spend local resources editing these records?
Do I like this? Absolutely not. But we must begin to have a sense of proportion in these matters. While I can see that the principle of an exact transcription of the title page is very important, perhaps weighing the title proper vs. the "other title information" is less important. Therefore, Dan's question is still valid: is it worth it? My experience suggests that it may not be worth it. Only research can provide any real answer.
<snip>
I would hate to see this all run together:
Tolkien, J. R. R. John Ronald Reuel
Unless you are advocating for keeping the punctuation -- but then we get back to the question of why we are doing both and not just one. I
personally would rather use subfielding than punctuation. As mentioned here, punctuation is display, and is less specific than subfielding. A
"(" is not as meaningful as 245 $q, because it can mean so many things in different contexts.
</snip>
i don't think most of my patrons would care about the parentheses one way or the other, or even really notice it. We have to compare this with what our patrons see on the rest of the web. Is the lack of parentheses really so dire and results in true incomprehensibility? I think it's OK. In any case, where does this idea of "no punctuation" end? In this example, there is a lot of punctuation anyway: a comma (between the surname and forename, which are separate subfields in UNIMARC), plus the periods at the end of each abbreviation of the forename, plus the spaces that separate them. Is the underlying purpose of the coding to keep from providing punctuation--which I think we can all agree is the simplest part of any record? I think not.
The purpose of coding should be much more positive, in my opinion. To go to the trouble of coding something separately, which results in additional labor and complexity all the way down, you should want either to search or to display the "bit of information" in a unique way. In other words, you should want to manipulate it separately in some way. If the "bit of information" is not being manipulated or displayed in a unique way, then there is little purpose in coding it separately. In this case, if the *only reason* to code the $q is to provide punctuation such as parentheses, that single reason is not worth the training and general hassle of working with the coding. if we can find other reasons, such as you have mentioned with 245$a and $b, then it is another matter.
James L. Weinheimer j.weinheimer_at_aur.edu
Director of Library and Information Services
The American University of Rome
Rome, Italy
Received on Sun Jun 06 2010 - 11:00:08 EDT