Subject: [NGC4LIB] Are MARC subfields really useful ?

From: Dan Matei <[email-masked]>
Date: Fri, 4 Jun 2010 08:36:49 +0300

[Desclaimer: I'm a big fan of fine granularity. Thus the TEI scheme is one of my favourite achievments in our domain.]

Beside MARCview, I do not know a user interface which allows searching within MARC subfields. I suppose there are more, 
but I don't see that in WorldCat or LC search interface, for instance.

OK, the UNIMARC subfields are used to generate the ISBD punctuation. But in MARC 21 case, what is the real need for 
marking-up a field with subfield codes ? Does its usefulness justify the effort ?

LibraryThing manages without subfields. Dear Mr. Spalding, do you miss them ?

Thanks,

Dan Matei

-----------------------------------------------------------------------
Dan Matei, director
Institutul de Memorie Culturală - CIMEC
Piata Presei Libere nr. 1, CP 33-90
013701 București [Bucharest], Romania, www.cimec.ro
tel. (+4)021 317 90 72; fax (+4)021 317 90 64
www.cimec.ro

---

From: Ross Singer <[email-masked]>
Date: Fri, 4 Jun 2010 08:19:27 -0400

My problem with this line of thought is that it assumes that the MARC
is immutable -- that other systems won't parse the MARC record and
reconstitute it into its own structure, which may very well use the
granularity of the subfields.

The 260 field comes to mind.  Not that the data entered there is
always really easy to work with, but it would be impossible as a
single lump.

Discovery systems like VuFind and Blacklight (and probably most
others) also make heavy use of the subfields in the 6xxs for faceting.

And if anybody would use $0 for the 1xxs, 240, and 6xxs, that might be
the most helpful of all.

The MARC to MODS XSLT makes heavy use of the subfield data (as well as
fixed field data) which may provide an indication of where it is
useful.

-Ross.

---

From: Demian Katz <[email-masked]>
Date: Fri, 4 Jun 2010 08:26:56 -0400

> others) also make heavy use of the subfields in the 6xxs for faceting.

VuFind also uses subfields to help with relevance ranking -- for example, words within subfield a of a title are given more importance than words in the rest of the field -- extremely valuable if, for example, you're trying to find a book ABOUT an author rather than a book BY that author.

- Demian

---

From: Dan Matei <[email-masked]>
Date: Fri, 4 Jun 2010 16:46:16 +0300

> -----Original Message-----
> From: Next generation catalogs for libraries 
> [mailto:[email-masked]] On Behalf Of Demian Katz
> Sent: 4 iunie 2010 15:27
> 
> 
> VuFind also uses subfields to help with relevance ranking -- 
> for example, words within subfield a of a title are given 
> more importance than words in the rest of the field -- 
> extremely valuable if, for example, you're trying to find a 
> book ABOUT an author rather than a book BY that author.

Right ! But that can be "reduced" to: a) before "/" b) after "/"

Dan Matei

---

From: Karen Coyle <[email-masked]>
Date: Fri, 4 Jun 2010 07:10:59 -0700

> Right ! But that can be "reduced" to: a) before "/" b) after "/"

Dan, what you are saying here is that some MARC subfields are  
redundant with ISBD punctuation, which is true. This is an ongoing  
argument -- why do we do both when one or the other would do that job?

That said, and in the grand tradition of inconsistency that is our  
data legacy, not all fields can be parsed using their punctuation. If  
you remove the subfield codes from:

650 	_7 |a Silk industry |z Asia, Central  |y 1860-1880.

you lose the meaning of the facets (ok, that should be in quotes) of  
the topical v. date subfields. I suspect that if we looked carefully  
through MARC we'd find a lot of instances of this nature.

kc

-- 
Karen Coyle
[email-masked] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

---

From: "McDonald, Stephen" <[email-masked]>
Date: Fri, 4 Jun 2010 10:20:31 -0400

Dan Matei asks:
> Beside MARCview, I do not know a user interface which allows searching
> within MARC subfields. I suppose there are more,
> OK, the UNIMARC subfields are used to generate the ISBD punctuation.
> But in MARC 21 case, what is the real need for

Yes, there are a number of systems that take advantage of MARC subfields.  For instance, many systems allow title searching in subfield t in 7XX fields and 505 formatted contents notes.  Most systems also allow you to display or not display specific subfields.  For instance, it might not display the subfield h of 245, instead replacing it with a graphic.  Some systems allow you to set up "scopes", so that users can automatically select material only in a specific language, or material type, or dates, or many other choices.  In many systems, you could set up a search on the ISSN of a 440 or 490 field.

Even more important, subfields are critical for proper data maintenance.  If a name authority changes, you need to change only the name portion of a name-title field 7xx field.  If you need to create a list of records with a form of Bibliography, you need to search the subfield v of 6xx.  I have created several scripts to aid in cataloging and data maintenance.  They do such things as check whether the item is an electronic resource (245 subfield h), check whether there is accompanying material (300 subfield e), check the publication date (260 subfield c), check whether it should be considered oversize (300 subfield c), and check whether the record was cataloged in English (040 subfield b).  To do this, these pieces of data must be kept separate, in easily identifiable locations.  In other words, in distinct fields.  MARC does this by making them into subfields of larger entities.  There are other ways of organizing it, but it all boils down to distinct fields for distinct t!
 ypes of information.  Even LibraryThing uses distinct fields for distinct types of information.  It just doesn't have as many differentiations of types of information as MARC has.

					Steve McDonald
					[email-masked]

---

From: "Houghton,Andrew" <[email-masked]>
Date: Fri, 4 Jun 2010 10:24:45 -0400

> [mailto:[email-masked]] On Behalf Of Dan Matei
> Sent: Friday, June 04, 2010 09:46 AM
> To: [email-masked]
> Subject: Re: [NGC4LIB] Are MARC subfields really useful ?
> 

Yes it can, but the issue with MARC is that it mixes content and 
presentation and you are suggesting a presentation position rather 
than a content position.  The unfortunate part of MARC is that it 
doesn't use *enough* subfields to describe the content and what 
subfields it does define it includes presentation artifacts that 
have to be striped or replaced depending upon what you want to do 
with the data.

Having been through this issue when the DDC folks decided to add 
some additional fields and subfields to MARC the current thinking 
at LC and MARBI was a presentation position.  They couldn't 
understand why the DDC folks wanted to keep the presentation
artifacts out of the content fields and why there was a need to
use a separate subfield for textual/punctuation information.  In
the end the DDC folks were able to keep the presentation artifacts 
out of the subfields they defined so that *applications* could use 
the data, as is, and *applications* could provide the correct 
presentation that made sense in their local or regional markets, 
rather than pulling the data from the subfield, removing the 
presentation artifacts and replacing them with the appropriate 
local or regional presentation artifacts.

I'm not "Mr. Spalding", but to provide context to your question
directed at him, when full text indexing fields, it really
doesn't matter what presentation artifacts or punctuation you
have in the data since it will be stripped out by the tokenizer
you are using.  However, this is just one use case for the data, 
albeit a common one.  Every time I want to grab an ISBN from a 
MARC record I cringe when I have to remove numerous presentation 
artifacts from the subfield and I cannot just use the data, as 
is...

  020 ## $a 9780446561808 (pbk.)

vs.

  020 ## $a 9780446561808 $i (pbk.)

Yes, subfield-i isn't defined, but maybe it should be since
"(pbk.)" shouldn't be in subfield-a if its defined as the 
*ISBN*.

Andy.

---

From: Dan Matei <[email-masked]>
Date: Fri, 4 Jun 2010 17:30:40 +0300

> [mailto:[email-masked]] On Behalf Of Karen Coyle
> Sent: 4 iunie 2010 17:11
> 
> 
> redundant with ISBD punctuation, which is true. This is an 
> ongoing argument -- why do we do both when one or the other 
> would do that job?
> 
> That said, and in the grand tradition of inconsistency that 
> is our data legacy, not all fields can be parsed using their 
> punctuation.

He, he... I found that back in 1987, when I tried to convert "ISBD records" (i.e. classical cards in WordStar files) ! :-(

Back to my question...

The question in the subject is brutal, in order to attract attention. I know it is a blasphemy :-)

Of course the subfields are useful (as the TEI tags in scholarly texts)... But:

"Does its usefulness justify the effort ?" That was my real question.

And, of course, we can refine it:

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 ?

Dan

---

From: Weinheimer Jim <[email-masked]>
Date: Fri, 4 Jun 2010 16:48:34 +0200

Dan Matei wrote:
<snip>

</snip>

Dan is asking exactly the right question, and one that has long needed answering. Although I wasn't working way back then, when they created MARC format, they obviously could have done it much more simply, without all of the subfields. It seems logical to me that they didn't yet know whether this deeper layers of (what we now call) semantics were necessary, but they didn't want to take a chance, so they decided to code everything within an inch of its life. 

I think it's time to reconsider the usefulness of a lot of it. If some of these fields haven't been used in almost 50 years now, I think we have enough research data to come to some decisions.

We have already seen some of the real bloopers thrown overboard: some of the tags, the old "main entry in the body of the entry" and others. But nobody has asked the bigger questions yet. For example, I have brought up a few times the need to code separately the 245 $a from $b. I understand it had a purpose before (as I wrote to Alex once), primarily to prevent different texts from inter-filing, e.g. my example "War and peace : the definitive edition" and "War and peace in the nuclear age". In the card catalog, it files correctly, but I haven't seen any OPAC do it "right" and it has always been interfiled and therefore, "wrong". 

Still, almost nobody browses titles like this anymore, and I have personally never even heard of a complaint, except from a librarian (like me, who it drives absolutely crazy!). But I ask: if there are no complaints and nobody even notices, is it still "wrong" to interfile different titles proper? I think a case can be made that the 245$b is really outmoded.

If this is accepted, then it is open season on all of the other subfields and fixed fields. Do we really need a separately coded 100$b? or 100$q? Why? Just because it's considered "correct" is not a reason to continue it.

James Weinheimer  [email-masked]
Director of Library and Information Services
The American University of Rome
via Pietro Roselli, 4
00153 Rome, Italy
voice- 011 39 06 58330919 ext. 258
fax-011 39 06 58330992

---

From: "McDonald, Stephen" <[email-masked]>
Date: Fri, 4 Jun 2010 10:44:35 -0400

> "Does its usefulness justify the effort ?" That was my real question.

In short, yes.  Our system could not function without them.

---

From: Karen Coyle <[email-masked]>
Date: Fri, 4 Jun 2010 07:55:19 -0700

> 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

---

From: Karen Coyle <[email-masked]>
Date: Fri, 4 Jun 2010 08:03:59 -0700

Quoting Weinheimer Jim <[email-masked]>:

For example,
> I have brought up a few times the need to code separately the 245 $a  
>  from $b. I understand it had a purpose before (as I wrote to Alex   
> once), primarily to prevent different texts from inter-filing, e.g.   
> my example "War and peace : the definitive edition" and "War and   
> peace in the nuclear age". In the card catalog, it files correctly,   
> but I haven't seen any OPAC do it "right" and it has always been   
> interfiled and therefore, "wrong".

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.

>
> If this is accepted, then it is open season on all of the other   
> subfields and fixed fields. Do we really need a separately coded   
> 100$b? or 100$q? Why? Just because it's considered "correct" is not   
> a reason to continue it.

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.

kc

---

From: Tod Olson <[email-masked]>
Date: Fri, 4 Jun 2010 10:03:58 -0500

> have to be striped or replaced depending upon what you want to do 
[snip]

Further, parsing ISBD correctly without subfields is fairly complicated and error-prone, and in some cases perhaps impossible to do reliably.  And for those of us have a large number pre-ISBD records, something of a sucker's game.  Much easier and more reliable to go from subfields without presentation artifacts to the desired presentation.

One example of the re-use problem that Andrew brings up is reformatting records for citation formats.  Most of the punctuation needs to change, like that extra ISBD space before the colon when designating a subfield, " : " .  (And these details are important our users.)  MODS isn't a radical rethinking of bibliographic records, but gets points for greatly improving the ease of reusing catalog records in non-catalog contexts just by keeping the ISBD punctuation out of the data.

-Tod

Tod Olson <[email-masked]>
Systems Librarian
University of Chicago Library

---

From: Jonathan Rochkind <[email-masked]>
Date: Fri, 4 Jun 2010 11:00:37 -0400

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 [[email-masked]] On Behalf Of Karen Coyle [[email-masked]]
Sent: Friday, June 04, 2010 10:55 AM
To: [email-masked]
Subject: Re: [NGC4LIB] Are MARC subfields really useful ?

kc

---

From: Janet Hill <[email-masked]>
Date: Fri, 4 Jun 2010 09:24:24 -0600

Years (decades) ago, in their infinite wisdom, the directors of the CARL libraries (that is, those libraries that owned and had paid for the development of the CARL system), decided that fixed fields were a waste of storage space (back when storage space was a significant issue), and so they stripped them out of all records as they were added or loaded, and "saved" them offline in case they might ever be needed.    And so they were called "saved fields".

Well, time passed (not much time, really) and it became obvious that the fixed fields contained data that would enable computer programming to enhance retrieval by doing such things as limiting searches by pertinent variables, utilizing short, uniform, predictably located bits of data.   

And so, it was decided that the fixed fields would no longer be stripped, and that the "saved fields" would be re-attached to the records they belonged to.    But, as it turned out, only about half of the saved fields could be matched successfully to the parent records.    And CARL libraries spent lots of money and lots of years adding critical fixed fields BACK onto the records that once had had them.  

It was a nightmare.  And an argument for not letting directors make decisions among themselves when those decisions have to do with integrity or usefulness of data.

Just a little detour down memory lane ......

And Karen, does my memory fail me, or haven't there already been (relatively) recent studies about the utility of MARC fields?   Admittedly it's a moving target, as systems and expectations evolve.

Janet Swan Hill, Professor
Associate Director for Technical Services
University of Colorado Libraries, CB184
Boulder, CO 80309
[email-masked]
     *****
Tradition is the handing-on of Fire, and not the worship of Ashes.
- Gustav Mahler

-----Original Message-----
From: Next generation catalogs for libraries [mailto:[email-masked]] On Behalf Of Karen Coyle
Sent: Friday, June 04, 2010 8:55 AM
To: [email-masked]
Subject: Re: [NGC4LIB] Are MARC subfields really useful ?

kc

---

From: Janet Schrader <[email-masked]>
Date: Fri, 4 Jun 2010 11:57:36 -0400

I would appreciate it if the OPAC displayed the titles using only
subfield 'a' in a title browse list. I'm frequently asked to add an
additional one word title so patrons can easily find the single word
title when no one remembers the subtitle. For example in our catalog, a
search for "The promise :$b President Obama, year one" does not display
in the list of titles that are simply "Promise" but as #158 interfiled
in the list of those with longer 245's or subtitles. The same thing
happened with "The soloist". Not to mention all those discrepancies when
"a novel" is on the title page but not on the audiobook or paperback.

Janet

Janet Schrader
Bibliographic Services Supervisor
C/W MARS Inc.
67 Millbrook Street, Suite 201
Worcester, MA 01606
508-755-3323 ext. 25
fax: 508-757-7801
[email-masked]
 
-----Original Message-----
From: Next generation catalogs for libraries
[mailto:[email-masked]] On Behalf Of Weinheimer Jim
Sent: Friday, June 04, 2010 10:49 AM
To: [email-masked]
Subject: Re: [NGC4LIB] Are MARC subfields really useful ?

Dan Matei wrote:
<snip>
The question in the subject is brutal, in order to attract attention. I
know it is a blasphemy :-)

Of course the subfields are useful (as the TEI tags in scholarly
texts)... But:

Dan is asking exactly the right question, and one that has long needed
answering. Although I wasn't working way back then, when they created
MARC format, they obviously could have done it much more simply, without
all of the subfields. It seems logical to me that they didn't yet know
whether this deeper layers of (what we now call) semantics were
necessary, but they didn't want to take a chance, so they decided to
code everything within an inch of its life. 

I think it's time to reconsider the usefulness of a lot of it. If some
of these fields haven't been used in almost 50 years now, I think we
have enough research data to come to some decisions.

We have already seen some of the real bloopers thrown overboard: some of
the tags, the old "main entry in the body of the entry" and others. But
nobody has asked the bigger questions yet. For example, I have brought
up a few times the need to code separately the 245 $a from $b. I
understand it had a purpose before (as I wrote to Alex once), primarily
to prevent different texts from inter-filing, e.g. my example "War and
peace : the definitive edition" and "War and peace in the nuclear age".
In the card catalog, it files correctly, but I haven't seen any OPAC do
it "right" and it has always been interfiled and therefore, "wrong". 

Still, almost nobody browses titles like this anymore, and I have
personally never even heard of a complaint, except from a librarian
(like me, who it drives absolutely crazy!). But I ask: if there are no
complaints and nobody even notices, is it still "wrong" to interfile
different titles proper? I think a case can be made that the 245$b is
really outmoded.

If this is accepted, then it is open season on all of the other
subfields and fixed fields. Do we really need a separately coded 100$b?
or 100$q? Why? Just because it's considered "correct" is not a reason to
continue it.

---

From: Kyle Banerjee <[email-masked]>
Date: Fri, 4 Jun 2010 09:00:47 -0700

>
> And Karen, does my memory fail me, or haven't there already been
> (relatively) recent studies about the utility of MARC fields?   Admittedly
> it's a moving target, as systems and expectations evolve.
>

The question is when most of this will be moot as a rapidly shrinking
percentage of the stuff people are looking for will ever exist in MARC.

Worrying about whether the subfields are necessary is a lot like wondering
if the indicators are necessary. The real question is whether you can get
the data out that you want. The whole reason MARC is such a mess is that we
have a culture that creates, structures, and keeps data to meet fringe or
even imagined uses while not dedicating attention to real uses. I like to
describe the problem as "measure with micrometer, mark with chalk, cut with
axe" -- describing inconsistent data with a super precise instrument makes
no sense

MARC is just a container. As such, you can normalize the data and structure
to make the data useful for an application. But there is no technical fix
for conceptual problems.

kyle

---

From: Karen Coyle <[email-masked]>
Date: Fri, 4 Jun 2010 10:02:33 -0700

Quoting Janet Hill <[email-masked]>:

> (relatively) recent studies about the utility of MARC fields?     
> Admittedly it's a moving target, as systems and expectations evolve.
>

The only one that I'm aware of is the Moen/Miksa study of how  
frequently fields and subfields appear in OCLC records. I don't know  
that anyone has been able to define "utility" in this context, but  
would love to see if it they did (or even attempted to)

kc

---

From: "McGrath, Kelley C." <[email-masked]>
Date: Fri, 4 Jun 2010 15:14:13 -0400

Although it's useful and interesting to see how the MARC fields have been used and we need to know that to make plans for going forward, I think the really important (and harder) question is what fields and subfields should we be using.

OLAC (Online Audiovisual Catalogers) has been lobbying for some time for additional MARC fields or subfields (or in some cases modifications to the instructions) in order to provide better coded access to aspects of film and video that we think are important. Now if we could just get the data populated and get systems to use the data...

Kelley McGrath
[email-masked]

-----Original Message-----
From: Karen Coyle <[email-masked]>
Date: Fri, Jun 4, 2010 at 1:02 PM
Subject: Re: [NGC4LIB] Are MARC subfields really useful ?
To: [email-masked]

kc

---

From: Dan Matei <[email-masked]>
Date: Sat, 5 Jun 2010 00:35:27 +0300

-----Original Message-----
From: Kyle Banerjee <[email-masked]>
Date: Fri, 4 Jun 2010 09:00:47 -0700

> to make the data useful for an application. But there is no technical fix

My professional bias is toward fine granularity and I'm not really close to apostasy :-)

But looking at how much time my (rare books) catalogers are spending on marking some details only for presentation, with detriment to the subject headings, for instance, I doubt the cost 
effectiveness.

I acknowledge that if a record is to be exposed as MLA or APA or Chicago, subfield codes are much better than ISBD punctuation :-) However, I still wander if the price is right.

Let's look at the granularity from the "linked data" perspective.

Last year I spent some time in order to devise an XML schema more ambitious than MODS, able - for instance - to detect if the parallel sequences are "balanced", i.e. the sequence to the 
right of = is isomorphic to the sequence to the left of =. (For the curious, I added at the end of the post the ridiculously long XML Schema fragment for this).

See two simplified examples (reduced to the title area):

<manifestation pml:guid="8f8d4b0f-161b-4204-b1cd-3571c1529c8b" pml:compilationTime="2010-06-04T22:21:13">
	<titleAndResposibilityArea>
		<titleProper xml:lang="en">Applications of ecological (biophysical) land classification in Canada</titleProper>
		<titleInformation>proceedings of second meeting, 4-7 April 1978, Victoria, British Columbia</titleInformation>
		<parallelTitleProper xml:lang="fr">Applications de la classification ecologique (biophysique) du territoire au Canada</parallelTitleProper>
		<parallelTitleInformation>compte rendu de la deuxième réunion, 4-7 avril 1978, Victoria, British Columbia</parallelTitleInformation>
		<responsibility>Canada Committee on Ecological (Biophysical) Land Classification</responsibility>
		<responsibility>compiled and edited by C.D.A. Rubec</responsibility>
	</titleAndResposibilityArea>
</manifestation>

<manifestation pml:guid="a657df1b-565f-4150-99e1-438d3acc22b5" pml:compilationTime="2010-06-04T22:26:24">
	<titleAndResposibilityArea>
		<titleProper>Contre les valeurs bourgeoises</titleProper>
		<responsibility>par Gilbert Ganne</responsibility>
		<titleProper>Pour les valeurs bourgeoises</titleProper>
		<responsibility>par Georges Hourdin</responsibility>
	</titleAndResposibilityArea>
</manifestation>

Now, imagine that I want to expose the last manifestation as RDF triples (I'm not a fan of RDF, but it's so fashionable these days...:-). How should I do that ?

As one triple ?

subject:  a657df1b-565f-4150-99e1-438d3acc22b5
predicate: title & responsibility area
object: Contre les valeurs bourgeoises / par Gilbert Ganne. Pour les valeurs bourgeoises / par Georges Hourdin

Or each element as a distinct triple ?

subject:  a657df1b-565f-4150-99e1-438d3acc22b5
predicate: title & responsibility area
object: a

subject: a
predicate: title group
object: a1

subject: a
predicate: title group
object: a2

subject: a1
predicate: title proper
object: Contre les valeurs bourgeoises

subject: a1
predicate: responsibility
object:  par Gilbert Ganne

subject: a2
predicate: title proper
object:  Pour les valeurs bourgeoises

subject: a2
predicate: responsibility
object:  par Georges Hourdin

The second solution seems over kill to me. Besides, I loose the order of the two titles within the area !

So, which is the reasonable granularity ?

Dan

====================================================================================
Appendix
<xs:group name="group.title">
	<xs:sequence>
		<xs:element name="avantTitre" type="pml:type.statement" minOccurs="0"/>
		<xs:element name="titleProper" type="pml:type.statement"/>
		<xs:element name="parallelTitleProper" type="pml:type.statement" minOccurs="0" maxOccurs="unbounded"/>
		<xs:sequence minOccurs="0" maxOccurs="unbounded">
			<xs:element name="or" type="pml:type.statement"/>
			<xs:element name="alternativeTitle" type="pml:type.statement"/>
			<xs:sequence minOccurs="0" maxOccurs="unbounded">
				<xs:element name="parallelTitleProper" type="pml:type.statement" minOccurs="0"/>
				<xs:element name="parallelOr" type="pml:type.statement" minOccurs="0"/>
				<xs:element name="parallelAlternativeTitle" type="pml:type.statement" minOccurs="0"/>
			</xs:sequence>
		</xs:sequence>
		<xs:sequence minOccurs="0" maxOccurs="unbounded">
			<xs:element name="subtitle" type="pml:type.statement"/>
			<xs:sequence minOccurs="0" maxOccurs="unbounded">
				<xs:element name="parallelTitleProper" type="pml:type.statement" minOccurs="0"/>
				<xs:element name="parallelSubtitle" type="pml:type.statement"/>
			</xs:sequence>
			<xs:sequence minOccurs="0" maxOccurs="unbounded">
				<xs:element name="or" type="pml:type.statement"/>
				<xs:element name="alternativeTitle" type="pml:type.statement"/>
				<xs:sequence minOccurs="0" maxOccurs="unbounded">
					<xs:element name="parallelTitleProper" type="pml:type.statement" minOccurs="0"/>
					<xs:element name="parallelOr" type="pml:type.statement" minOccurs="0"/>
					<xs:element name="parallelAlternativeTitle" type="pml:type.statement" minOccurs="0"/>
					<xs:element name="parallelSubtitle" type="pml:type.statement" minOccurs="0"/>
				</xs:sequence>
			</xs:sequence>
		</xs:sequence>
		<xs:sequence minOccurs="0">
			<xs:element name="genre" type="pml:type.statement"/>
			<xs:sequence minOccurs="0" maxOccurs="unbounded">
				<xs:element name="parallelTitleProper" type="pml:type.statement" minOccurs="0"/>
				<xs:element name="parallelOr" type="pml:type.statement" minOccurs="0"/>
				<xs:element name="parallelAlternativeTitle" type="pml:type.statement" minOccurs="0"/>
				<xs:element name="parallelSubtitle" type="pml:type.statement" minOccurs="0"/>
				<xs:element name="parallelGenre" type="pml:type.statement" minOccurs="0"/>
			</xs:sequence>
		</xs:sequence>
		<xs:sequence minOccurs="0" maxOccurs="unbounded">
			<xs:element name="titleInformation" type="pml:type.statement"/>
			<xs:sequence minOccurs="0" maxOccurs="unbounded">
				<xs:element name="parallelTitleProper" type="pml:type.statement" minOccurs="0"/>
				<xs:element name="parallelOr" type="pml:type.statement" minOccurs="0"/>
				<xs:element name="parallelAlternativeTitle" type="pml:type.statement" minOccurs="0"/>
				<xs:element name="parallelSubtitle" type="pml:type.statement" minOccurs="0"/>
				<xs:element name="parallelGenre" type="pml:type.statement" minOccurs="0"/>
				<xs:element name="parallelTitleInformation" type="pml:type.statement" minOccurs="0"/>
			</xs:sequence>
		</xs:sequence>
		<xs:sequence minOccurs="0" maxOccurs="unbounded">
			<xs:element name="part">
				<xs:complexType mixed="true">
					<xs:sequence>
						<xs:element name="number" type="pml:type.statement" minOccurs="0"/>
						<xs:group ref="pml:group.title" minOccurs="0"/>
					</xs:sequence>
					<xs:attributeGroup ref="pml:att.elementMetadata"/>
					<xs:attributeGroup ref="pml:att.sortMetadata"/>
				</xs:complexType>
			</xs:element>
			<xs:sequence minOccurs="0" maxOccurs="unbounded">
				<xs:element name="parallelTitleProper" type="pml:type.statement" minOccurs="0"/>
				<xs:element name="parallelOr" type="pml:type.statement" minOccurs="0"/>
				<xs:element name="parallelAlternativeTitle" type="pml:type.statement" minOccurs="0"/>
				<xs:element name="parallelSubtitle" type="pml:type.statement" minOccurs="0"/>
				<xs:element name="parallelGenre" type="pml:type.statement" minOccurs="0"/>
				<xs:element name="parallelTitleInformation" type="pml:type.statement" minOccurs="0"/>
				<xs:element name="parallelPart" minOccurs="0">
					<xs:complexType mixed="true">
						<xs:sequence>
							<xs:element name="number" type="pml:type.statement" minOccurs="0"/>
							<xs:element name="title" type="pml:type.statement" minOccurs="0"/>
							<xs:element name="subtitle" type="pml:type.statement" minOccurs="0"/>
							<xs:element name="genre" type="pml:type.statement" minOccurs="0"/>
							<xs:element name="titleInformation" type="pml:type.statement" minOccurs="0" maxOccurs="unbounded"/>
							<xs:element name="responsibility" type="pml:type.statement" minOccurs="0" maxOccurs="unbounded"/>
						</xs:sequence>
						<xs:attributeGroup ref="pml:att.elementMetadata"/>
						<xs:attributeGroup ref="pml:att.sortMetadata"/>
					</xs:complexType>
				</xs:element>
			</xs:sequence>
		</xs:sequence>
		<xs:sequence minOccurs="0" maxOccurs="unbounded">
			<xs:element name="responsibility" type="pml:type.statement"/>
			<xs:sequence minOccurs="0" maxOccurs="unbounded">
				<xs:element name="parallelTitleProper" type="pml:type.statement" minOccurs="0"/>
				<xs:element name="parallelOr" type="pml:type.statement" minOccurs="0"/>
				<xs:element name="parallelAlternativeTitle" type="pml:type.statement" minOccurs="0"/>
				<xs:element name="parallelSubtitle" type="pml:type.statement" minOccurs="0"/>
				<xs:element name="parallelGenre" type="pml:type.statement" minOccurs="0"/>
				<xs:element name="parallelTitleInformation" type="pml:type.statement" minOccurs="0"/>
				<xs:element name="parallelResponsibility" type="pml:type.statement" minOccurs="0" maxOccurs="unbounded"/>
			</xs:sequence>
		</xs:sequence>
	</xs:sequence>
</xs:group>

---

From: Jonathan Rochkind <[email-masked]>
Date: Fri, 4 Jun 2010 19:01:24 -0400

"My professional bias is toward fine granularity... But looking at how much time my (rare books) catalogers are spending on marking some details only for presentation, with detriment to the subject headings, for instance, I doubt the cost effectiveness."

Part of our general issue is our broken cooperative cataloging infrastructure.

To me, a little bit of human-created metadata, with the appropriate structure and granularity for machine use, is better than a LOT of metadata without that appropriate structure and granularity.

In my utopian cataloging/metadata universe, a record would possibly start out with just a little bit of "description" -- at whatever level the body doing the cataloging thought was appropriate cost/benefit for _their_ needs. But the metadata would be recorded _well_, with the proper structure and granularity (unlike what we have now). Then someone else might come along and add another data element or two or a dozen -- with the proper structure and granularity -- and when they did, everyone else sharing that record would automatically get their additions with little human intervention (because human intervention is cost).  And that "someone" could maybe even be a "patron" or "general public" -- you can get "good enough" data out of the general public if you have the right data model and the right software. Neither of which we have now.  And without that, you don't get good enough data even out of trained professionals.  Even with that, trained professionals might give you _be!
 tter_ data -- and in my ideal world, if a trained professional improves data (because their employing organization thought the improvement was justified by the cost-benefit tot heir orgnanization), those improvements would also immediately be automatically shared with everyone else with little or no human intervention.

This sort of universe is totally feasible from a technical standpoint -- it just takes the will to create it, resources put into it's creation (including skilled people to invent, design, and create it), and coordinated action by the library community toward the goal.  None of which we seem to have, and I'm not sure how optimistic I can be about us having them before it's "too late", and the library cataloging/metadata tradition essentially dies through neglect and the unsustainability of a current system whose cost-benefit is, as Kyle suggests, NOT effective or sustainable.

Jonathan
________________________________________
From: Next generation catalogs for libraries [[email-masked]] On Behalf Of Dan Matei [[email-masked]]
Sent: Friday, June 04, 2010 5:35 PM
To: [email-masked]
Subject: Re: [NGC4LIB] Are MARC subfields really useful ?

-----Original Message-----
From: Kyle Banerjee <[email-masked]>
Date: Fri, 4 Jun 2010 09:00:47 -0700

As one triple ?

subject: a
predicate: title group
object: a1

subject: a
predicate: title group
object: a2

subject: a1
predicate: title proper

subject: a1

subject: a2
predicate: title proper

subject: a2

Dan

---

From: Weinheimer Jim <[email-masked]>
Date: Sat, 5 Jun 2010 14:27:41 +0200

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>

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  [email-masked]
Director of Library and Information Services
The American University of Rome
Rome, Italy

---

From: Laval Hunsucker <[email-masked]>
Date: Sat, 5 Jun 2010 06:38:42 -0700

> The whole reason MARC is such a mess is
> that we have a culture that creates, structures,
> and keeps data to meet fringe or even imagined
> uses while not dedicating attention to real uses.

I'd really be quite fascinated to learn more about 
what lies -- inductively or deductively -- behind 
your firm distinction of  imagined uses from real 
uses ;  what your empirical basis might be for this 
distinction and for the eventual assignment of 
specific instances to the one or to the other 
category. What kind of investigation, using what 
kind of methodology, entails the validity and 
reliability of drawing such a distinction and of 
making such assignments ?

I don't want to be overly ironic -- but you get the 
idea, I guess, that I'm extremely skeptical of the 
offhandedness and ease with which persons ( *any* 
persons, not just you :  there are many who do it ) 
brandish such formulations as "imagined uses" and 
"real uses". In our field, the collective ignorance on 
this matter is monumental ( and here I emphatically 
include myself along with everyone else ). There is 
a stupefying dearth of respectable research results, 
yes even of research efforts or intentions, and alas 
even of useful theorizing or speculation, concerning 
the matter. This is imho the one greatest cause for 
genuine embarrassment for our discipline and our 
profession.

Therefore I have great praise too, may I add, for 
Karen Coyle, for her observation yesterday :  "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." 
Hear, hear !  I can't tell you how gratified I was to 
see that come by :  one of the best contributions, 
and in just two sentences, to this list that I've seen 
in a very long time.

- Laval Hunsucker
   Breukelen, Nederland

----- Original Message ----
From: Kyle Banerjee <[email-masked]>
To: [email-masked]
Sent: Fri, June 4, 2010 6:00:47 PM
Subject: Re: [NGC4LIB] Are MARC subfields really useful ?

kyle

---

From: Laval Hunsucker <[email-masked]>
Date: Sat, 5 Jun 2010 06:56:46 -0700

> Just because it's considered "correct" is 
> not a reason to continue it.

No ?  Why not ? 

Where would we be if we -- as a person, as a 
profession, as a nation, as a civilization, etc. -- 
didn't base the maintenance of behavior on the 
consideration that what we are doing is correct ? 
Think for a moment :  What does "to consider" 
mean ?

One could easily argue that considering something 
"correct" is *always* a reason to continue it.

Or am I missing something ?

- Laval Hunsucker
   Breukelen, Nederland

----- Original Message ----
From: Weinheimer Jim <[email-masked]>
To: [email-masked]
Sent: Fri, June 4, 2010 4:48:34 PM
Subject: Re: [NGC4LIB] Are MARC subfields really useful ?

Dan Matei wrote:
<snip>

---

From: Weinheimer Jim <[email-masked]>
Date: Sat, 5 Jun 2010 17:18:33 +0200

Laval Hunsucker wrote:
<snip>
> Just because it's considered "correct" is not a reason to continue it.

No ?  Why not ?

Where would we be if we -- as a person, as a profession, as a nation, as a civilization, etc. --
didn't base the maintenance of behavior on the consideration that what we are doing is correct ?
Think for a moment :  What does "to consider" mean ?

One could easily argue that considering something "correct" is *always* a reason to continue it.

You need to reference this to what I had written earlier in my message:

<snip>

If the only reason something is considered to be "correct" is for reasons that don't pertain anymore, then we must reconsider what "correct" means. Anybody who has come across a workflow for materials processed in a library that hasn't been reconsidered in 30 years or so will find many things done only because they are "correct" i.e. the old guidelines and rules tell them to do it. Yet, nobody has reconsidered what they are doing or why, but everyone just continues doing what they have always done. When you start talking openly about the reasons for some of the procedures and rules, you are touching on the issue of "change," and some people can get very angry about it. 

Catalogs and cataloging practices are among the worst offenders in this regard. The example I gave was for titles proper to file in a certain order, but nobody browses titles like that anymore. It is an axiom for web designers that when you put a printed document for use online, (not just as a pdf or a document for download and printing) it cannot be used in the same way so therefore, it must be "architected" for the web. (I hate that word, but "architect" can be a verb now) Information architecture does exactly that, but our catalogs have never been looked at in this way before. Only in the last few years are people reconsidering them in a comprehensive way.

---

From: Michele Newberry <[email-masked]>
Date: Sat, 5 Jun 2010 11:43:01 -0400

Jim,
  You might want to look at our Endeca-based library catalog to see an 
example of a title browse within an interface that normally doesn't 
support this type of browsing.  
http://catalog.fcla.edu
Click on the "Search begins with" radio button and after the screen 
refresh, type your title.  You can also select Author and Series.  Lack 
of the Subject option is an indicator that we just couldn't quite work 
out all the issues of those pre-coordinated index entries within this 
technology.

In this instance, I think it aids the user not to have the content from 
the subfield c in the display so that subfield has some value to me.  We 
find some value in the subfield b for relevance ranking purposes when 
we're trying to bring the probably most likely results to the fore.  We 
call it the "on the road" test.  This uses the words be searched as a 
percentage of the words in the title.  Differentiating the subtitle is 
helpful here.

 - Michele

---

From: Laval Hunsucker <[email-masked]>
Date: Sat, 5 Jun 2010 09:12:35 -0700

> . . ., and I'm not sure how optimistic I can be
> about us having them before it's "too late",
> . . . . 

I have, myself, been working for quite a while 
now on the assumption that it already *is* too 
late [ sic : no quotes ], for better or worse. I am 
sure that I can be pretty optimistic that I won't 
be disabused, later on.

Anyway -- that seems, today, a more productive 
( because realistic ) basis on which to prepare 
now for the future.

And can't we, in fact, be grateful that 'total 
feasibility from a technical standpoint' has 
never been an assurance ( or justification ) 
that something will actually get done ?

- Laval Hunsucker
   Breukelen, Nederland

----- Original Message ----
From: Jonathan Rochkind <[email-masked]>
To: [email-masked]
Sent: Sat, June 5, 2010 1:01:24 AM
Subject: Re: [NGC4LIB] Are MARC subfields really useful ?

In my utopian cataloging/metadata universe, a record would possibly start out with just a little bit of "description" -- at whatever level the body doing the cataloging thought was appropriate cost/benefit for _their_ needs. But the metadata would be recorded _well_, with the proper structure and granularity (unlike what we have now). Then someone else might come along and add another data element or two or a dozen -- with the proper structure and granularity -- and when they did, everyone else sharing that record would automatically get their additions with little human intervention (because human intervention is cost).  And that "someone" could maybe even be a "patron" or "general public" -- you can get "good enough" data out of the general public if you have the right data model and the right software. Neither of which we have now.  And without that, you don't get good enough data even out of trained professionals.  Even with that, trained
 professionals might give you _be!
tter_ data -- and in my ideal world, if a trained professional improves data (because their employing organization thought the improvement was justified by the cost-benefit tot heir orgnanization), those improvements would also immediately be automatically shared with everyone else with little or no human intervention.

Jonathan

---

From: Laval Hunsucker <[email-masked]>
Date: Sat, 5 Jun 2010 09:47:24 -0700

I think that we were and are substantively in
agreement.

It wasn't quite clear to me what you *in fact* 
meant with your peroratio, and perhaps I feared 
the worst.  If you'd written "Just because it's 
represented [ or presented, or characterized, or 
described ] as "correct" . . .",  or  "Just because 
it's justified as "correct" . . .",  or even  "Just 
because it was once considered "correct" . . .",  
I would not have been in doubt what you were
driving at.

Anyway, thanks for clarifying.

- Laval Hunsucker
   Breukelen, Nederland

----- Original Message ----
From: Weinheimer Jim <[email-masked]>
To: [email-masked]
Sent: Sat, June 5, 2010 5:18:33 PM
Subject: Re: [NGC4LIB] Are MARC subfields really useful ?

Laval Hunsucker wrote:
<snip>

No ?  Why not ?

<snip>

---

From: Laval Hunsucker <[email-masked]>
Date: Sun, 6 Jun 2010 07:59:37 -0700

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 <[email-masked]>
To: [email-masked]
Sent: Sat, June 5, 2010 2:27:41 PM
Subject: Re: [NGC4LIB] Are MARC subfields really useful ?

Karen Coyle wrote:]
<snip>

<snip>

---

From: Weinheimer Jim <[email-masked]>
Date: Mon, 7 Jun 2010 10:34:12 +0200

Michele Newberry wrote:
<snip>
Jim,

Thanks for sharing this. Certainly, it is a much better display, but if I search for War and Peace, I still find various titles proper filing together. Still, my experience with people is that they almost never know the exact titles of an item they want. Citations are very often incorrect, and the need for browsing titles proper is far more important to librarians and catalogers than to the public. [As an historical aside, from my researches of early catalogs, some *never* made an entry for title, sometimes not even for the Bible. If the cataloger could find no author to enter the record under, they would place these records into an "Anonymous, Pseudonymous Works" or something similar.]

My suspicion is that in the public's mind, much more common is what used to be termed the "catchword title", e.g. they would think "Bury's Later Roman History", and not "History of the later Roman Empire" or "Professor Thompson's book on Alfred Hitchcock" instead of "The moment of Psycho : how Alfred Hitchcock taught America to love murder".

Just to make it clear, I am *not* saying we should stop coding the subtitle separately, primarily because it is codified in ISBD. But its utility does have to be reanalyzed seriously in our new environment, along with *every other part* we do. There are also consequences to consider: if we want to accept metadata from other providers that do not code the subtitles separately, do we continue to edit the subtitles locally? Is that a wise use of our resources? 

Yet, if we just accept these other records without recoding, consistency falls apart and what does that mean for quality? If we do not consider the implications and consequences of all of this, then when higher authorities ask what someone has done in the last week, they certainly will wonder when they hear: "I've added 245$b to 400 records!" and when this higher authority asks why this is so important, we won't be able to point to any adverse consequences, so there will be no other answer than: "it's the correct way to do it." 

Is this the best use of the staff?

---

From: "Gray-Williams, Donna" <[email-masked]>
Date: Mon, 7 Jun 2010 09:01:31 -0400

I've been following all of these discussions about MARC and its limitations, and sometimes it's beyond me because I'm not especially familiar with XMTL and the like--so here's my question:
Why can't MARC be expanded to function like these other formats if the data isn't presented in a ideal way to be extracted?  Why does it have to be totally thrown out to adopt something completely different? Is that so impossible?

Donna Gray-Williams
Technical Services Manager
Lake County Library System
2401 Woodlea Rd.
Tavares, FL  32778
352-253-6161
352-253-6184 (Fax)
                                 "Outside of a dog a book is a man's best friend. Inside of a dog it's too dark to read."
                                                                               Groucho Marx

---

From: Weinheimer Jim <[email-masked]>
Date: Mon, 7 Jun 2010 15:58:47 +0200

Gray-Williams, Donna wrote:
<snip>
I've been following all of these discussions about MARC and its limitations, and sometimes it's beyond me because I'm not especially familiar with XMTL and the like--so here's my question:
Why can't MARC be expanded to function like these other formats if the data isn't presented in a ideal way to be extracted?  Why does it have to be totally thrown out to adopt something completely different? Is that so impossible?
</snip>

I would like to point out the difference between MARC in its different formats: there is MARC21, UNIMARC, etc. Trying to bring these together is one level of complexity. Then there is the point I bring up, its ISO2709 problem, which is at a level deeper.

An example of some basic structural problems with MARC21 is that it is based on a single main entry, i.e. the 1xx field is not repeatable. Therefore, we have in-depth rules for determining a single main entry although there may be many other authors just as important. While the single main entry was absolutely critical in a printed/card catalog, and in fact, the idea of "multiple main entries" in the card catalog was nonsensical, in computerized records, we have the same problem from the opposite point of view: the idea of making the 1xx field non-repeatable is just as nonsensical.

Yet, if we just decide to make the 1xx field repeatable, we have problems in other fields that allow only single main entries, e.g. analytics and subjects. So for example, while you could easily do something like:
100 	1_ |a Masters, William H.
100 	1_ |a Johnson, Virginia E.
100 	1_ |a Kolodny, Robert C. |d 1946- (I made up thie date)
245 	10 |a Masters and Johnson on sex and human loving / |c William H. Masters, Virginia E. Johnson, Robert C. Kolodny.

You run into trouble with another book about this book:
600 	1_ |a Masters, William H. |t Masters and Johnson on sex and human loving.
(how do we add Johnson and Kolodny?)

So, therefore, if we would make 1xx repeatable, it means that we would have to make the related subfields in 6xx, 7xx and 8xx repeatable as well. This is complex and one reason why we remain stuck with figuring out a single main entry, all remnants of the bygone print world. While it may be possible to fix this with our current formats, this would become much more complex and there are better formats to work with.

None of this presents any difficulties in more robust formats like XML, which could easily have something like:
<subject>
<author>Masters, William H. </author>
<author>Johnson, Virginia E. </author>
<author>Kolodny, Robert C. 
	<dateOfBirth>1946-</dateOfBirth></author>
<title>Masters and Johnson on sex and human loving.</title>
</subject>

Each field and subfield can easily be entered. When you begin to play with it, the sky is the limit and you can even create things that look totally weird to an experienced cataloger:
<subject>
<author>Masters, William H. </author>
<author>Johnson, Virginia E. </author>
<author>Kolodny, Robert C. 
	<dateOfBirth>1946-</dateOfBirth></author>
<title>Masters and Johnson on sex and human loving.</title>
<pubInfo>
<place>Boston</place>
<publisher>Little, Brown</publisher>
<dateofPublication>c1986.</dateofPublication>
</pubInfo>
<physicalDetails>
<paging>598 p.</paging>
<illustrations>ill.</illustrations>
<dimensions>25 cm.</dimensions>
</physicalDetails>
<edition>
<statement>Rev. ed. of:</statement>
<title>Human sexuality.</title>
<edition>2nd ed.</edition>
<dateofPublication>c1985.<dateofPublication>
</edition>
<notes>
<bibligraphyNote>Bibliography: p. [565]-580.</bibligraphyNote>
</notes>
</subject>

I'm not saying we should do this, but we could. Instead of entering all of this information manually, it could be imported as well, which is at least some of the idea of FRBR/RDA. (I personally don't think the problems lie with the cataloging rules--RDA even retains single main entry--but with the formats, which are simply worn out and unused by everyone in the world except libraries)

There are lots of other problems with MARC as well, including MARCXML--primarily because it must be "round-trippable" between XML and ISO2709 and as a result, the limitations of ISO2709 are transferred en masse into MARCXML.

So, the idea of reworking ISO2709 seems to me a bizarre, modern example of the old "Horsey Horseless" from 1899. http://tinyurl.com/2ayd3h 

It's time to move on. And when we do, I am pretty sure that we and our users will find it all much more interesting than what we have today.

---

From: Michele Newberry <[email-masked]>
Date: Mon, 7 Jun 2010 09:58:36 -0400

Jim,

1.  I'm not sure what you mean by "various titles proper filing 
together" as though that's a bad thing.  I thought the point of a title 
browse function along the lines of traditional OPACs was the objective?  
BTW, in the "War and peace" search, there is an example of the problem 
if the subfield C isn't encoded properly.  There, sorted alphabetically 
is a clear "remainder of title page" was:
War and peace atlas
War and peace / by Leo Tolstoy ; translated by Constance Garnett.
War and peace : chapter notes and criticism, including Leo Tolstoi's 
Some words about War and peace /

Looking at the full MARC display, we see:
War and peace / |b by Leo Tolstoy ; translated by Constance Garnett.
If the "b" were a "c", then this title would be in its proper place.

2. Our traditional browse function exists because librarians wanted it.  
Keyword wasn't sufficient no matter how much we tuned the relevance 
ranking to make sure that a title keyword search brought the logical 
matches to the top.  They say they were guided by user behavior and 
requests for the function.  I'm sure there is some truth to this.  There 
are users of our tools who were once card catalog users and they bring 
certain expectations to our discovery tools as well.

3. Regarding your historical research in catalogs (presumably pre-AACR2; 
pre-MARC), perhaps its because early bibliographers/catalogers valued 
the authors of the works more that the titles?  In other words, it was 
the creators of the works that had the most value.  On top of this, with 
many fewer users than we have today, perhaps the phenomenon of "its that 
big book with 'peace' in the title, I can't remember the author" wasn't 
as common?

4. Common titles such as "Bury's Later Roman History" are excellent 
candidates for an alternative title field - one that clearly shows this 
to be a made-up title rather than something that existed on the 
publication itself.  Of course, putting that title in the record 
requires thought and time on the part of the cataloger.  Maybe we don't 
have the resources to do that either?  Or is this where tagging comes 
into the picture?  Let the public's contributions make up for what we 
don't want to pay anyone to do anymore?  A keyword search can find the 
work without knowing the proper title too.  Which is why keyword was 
such an incredible addition to our OPACs a couple of decades ago. At the 
time, of course, we say keyword/boolean as an adjunct to the 
traditional, pre-coordinated indexes not as a replacement.

5. In all honesty, my reaction to the lack of detailed coding in other 
sources of metadata is because the creators of those forms chose to not 
understand the value of AACR2 and MARC when those forms of metadata were 
first being proposed.  I heard a presentation on Dublin Core at OCLC 
Users Council when it was first being developed.  I stood up and said 
"it looks like cataloging to me" and was told "Shush, don't tell the 
geeks; they think they invented it."  IMHO, the coding in MARC isn't 
that hard to do or that hard to learn, especially in the main 
description fields (245-3XX).  Maybe the geeks just weren't smart enough 
to figure out tools to help their users do it?

I'm not defending every aspect of either AACR2 or MARC - certainly it 
behooves us to look at the ROI of what we're doing and determine what we 
can afford.  I will remind you that MARC itself is just the method of 
encoding the rules and is not a cataloging standard itself.  The rules 
existed for a 2nd reason - to clearly identify unique bibliographic 
entities for posterity - because it was deemed important to know those 
differences - which is why we don't put any old made-up title in the 245 
and why we transcribe the remainder of the title page and encode verso 
content in proscribed ways.  So that, a century from now, a bibliophile 
can tell whether the work represented by the cataloging data was the 
actual work desired or some other manifestation of it.  If this 
objective is no longer needed, then a lot of specific coding can be 
fuzzified.  There are a lot more complex parts of MARC that are 
candidates for this than the 245 subtitle IMHO.

 - Michele

---

From: Ere Maijala <[email-masked]>
Date: Mon, 7 Jun 2010 17:23:26 +0300

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 [[email-masked]] On Behalf
> Of Karen Coyle [[email-masked]] Sent: Friday, June 04, 2010 10:55
> AM To: [email-masked] Subject: Re: [NGC4LIB] Are MARC
> subfields really useful ?
>
> Quoting Dan Matei<[email-masked]>:
>
>
>>
> 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?
>
> 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 [email-masked] http://kcoyle.net ph:
> 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
>

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

---

From: Anna Headley <[email-masked]>
Date: Mon, 7 Jun 2010 10:42:03 -0400

> user (staff) interfaces don't do a very good job with the data entry.

hear, hear!!!

What was this system?

-anna

-- 
Anna Headley
Swarthmore College Library
610.690.5781
[email-masked]

---

From: Ross Singer <[email-masked]>
Date: Mon, 7 Jun 2010 10:43:42 -0400

On Mon, Jun 7, 2010 at 10:23 AM, Ere Maijala <[email-masked]> wrote:

> This is just to say that most of our

This pretty much sums up my confusion about this thread.  Just like
your CMS doesn't require your content creators to write up the SQL
inserts into the RDBMS, just like MS Word doesn't require the document
author to manually insert formatting codes, the UI for cataloging
should be able abstract away some of what we're talking about here
(/and/ clean things up upon submission, if need be).

The subfields, indicators, fixed fields, etc. are *not* the problem
(well, any more than MARC itself is a problem).  The granularity is
good.  Even if we're talking about things that *shouldn't* take a heap
of time to catalog, the granularity is useful.  If the interface for
adding this data is the bottleneck, then fix the interface, fixing the
container is a completely different issue.

-Ross.

---

From: Ere Maijala <[email-masked]>
Date: Mon, 7 Jun 2010 17:47:02 +0300

>> user (staff) interfaces don't do a very good job with the data entry.

A domestic ILS, ATP Origo. Used in a lot of Finnish public libraries 
that still use FINMARC (which, by the way, also has a lot more structure 
than MARC 21).

--Ere

---

From: Janet Hill <[email-masked]>
Date: Mon, 7 Jun 2010 09:41:23 -0600

I think I'm going to keep this message on file.   It's so eminently
quotable, and full of truth .... especially the observation that "collective
ignorance on this matter is monumental" .... as well as the observation
about the offhandedness with which some will categorize some uses as
"imagined" or "marginal."

Librarians don't have a particularly good record on predicting the future,
either short OR long term, and lack of substantive research is one of the
reasons.  (faith and optimism also contribute) 

-----Original Message-----
From: Next generation catalogs for libraries
[mailto:[email-masked]] On Behalf Of Laval Hunsucker
Sent: Saturday, June 05, 2010 7:39 AM
To: [email-masked]
Subject: Re: [NGC4LIB] Are MARC subfields really useful ?

- Laval Hunsucker
   Breukelen, Nederland

---

From: john g marr <[email-masked]>
Date: Mon, 7 Jun 2010 10:52:08 -0600

On Mon, 7 Jun 2010, Gray-Williams, Donna wrote:

> Why can't MARC be expanded to function like these other formats if the 
> data isn't presented in a ideal way to be extracted?  Why does it have 
> to be totally thrown out to adopt something completely different? Is 
> that so impossible?

   That may be the wrong question.  Try this: why can't format developers 
be encouraged to start with what already works and make modifications, 
instead of reinventing way too many wheels that are not interoperable? 
Did they all start life in the auto industry??   :)

jgm

                                             John G. Marr
                                             Cataloger
                                             CDS, UL
                                             Univ. of New Mexico
                                             Albuquerque, NM 87131
                                             [email-masked]
                                             [email-masked]

     **There are only 2 kinds of thinking: "out of the box" and "outside 
the box."

Opinions belong exclusively to the individuals expressing them, but
sharing is permitted.

---

From: Karen Coyle <[email-masked]>
Date: Mon, 7 Jun 2010 10:06:39 -0700

Quoting john g marr <[email-masked]>:

>   That may be the wrong question.  Try this: why can't format
> developers be encouraged to start with what already works and make
> modifications, instead of reinventing way too many wheels that are not
> interoperable? Did they all start life in the auto industry??   :)

When MARC was developed, there was nothing anywhere near it that  
already worked. Nothing. In 1965 (which is not before MY time :-))  
data was
   - all upper case
   - all of fixed length, and very short fixed lengths at that
   - ASCII only

MARC was a game-changer, and it is unfortunate that it was only used  
in libraries. Variable length fields, upper and lower case plus  
accents, and what seemed like an endless expandability. That it has  
lasted more than 40 years is a tribute to its design. Few data formats  
are used and usable for that length of time. It was absolutely genius  
in its day; but the world has changed in ways that could not have been  
anticipated at that time.

kc

---

From: john g marr <[email-masked]>
Date: Mon, 7 Jun 2010 12:06:33 -0600

On Mon, 7 Jun 2010, Karen Coyle wrote:

> When MARC was developed, there was nothing anywhere near it that already 
> worked.

  Oops, my bad!  I am only referring to those systems developed recently as 
"alternatives" to MARC.

jgm

                                             John G. Marr
                                             Cataloger
                                             CDS, UL
                                             Univ. of New Mexico
                                             Albuquerque, NM 87131
                                             [email-masked]
                                             [email-masked]

---

From: Alexander Johannesen <[email-masked]>
Date: Tue, 8 Jun 2010 16:45:46 +1000

Hiya,

I've deliberately stayed out of this one as the MARC debates usually
gets my blood boiling beyond a useful level. Anyway, a slight comment
;

Karen Coyle <[email-masked]> wrote:
> MARC was a game-changer, and it is unfortunate that it was only used in
> libraries.

I think this true of any library technology ever invented, no matter
how clever it was. (I'll give DC a free pass here, although it's not
really a technology)

> Variable length fields, upper and lower case plus accents, and
> what seemed like an endless expandability. That it has lasted more than 40
> years is a tribute to its design.

Absolutely, but also because of its remarkable design it is also the
very thing that has driven the library world to focus all their might
on MARC technology. It's a bit like clinging to oil when you need to
go electric because it's harmful to your environment, you're going to
run out, and the infra-structure to support it is aging.

> Few data formats are used and usable for
> that length of time. It was absolutely genius in its day; but the world has
> changed in ways that could not have been anticipated at that time.

Yes, it started well, but it was a bit stupid not to have the whole
enchilada move with the flow and change over time. The tower of
rigidness it turned into is now the tower of Babel for the library
community, including the vendors who incorporated the MARC paradigms
at the heart of their systems, making it the model on which all other
sub-models are shaped on. Ugh, and I don't know if this is
salvageable.

Regards,

Alex
-- 
 Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
--- http://shelter.nu/blog/ ----------------------------------------------
------------------ http://www.google.com/profiles/alexander.johannesen ---

---

From: Ere Maijala <[email-masked]>
Date: Tue, 8 Jun 2010 15:27:17 +0300

>> user (staff) interfaces don't do a very good job with the data entry.

I just have to continue on the subject a bit. :)

We also made the direct MARC editing as easy as possible. In practice 
the editor was a long text field. You'd enter tags, indicators, subfield 
codes in form $x and the system would indent it properly, color the 
syntax and mark any problems (e.g. invalid tags, indicators or subfield 
codes) with a red underline. You could move around, copy and paste (in a 
couple of different flavors too) and do all the things without having to 
do things line by line, subfield by subfield. So even if you'd rather 
enter MARC directly, it doesn't have to be a tedious task with a lot of 
mousing around or dozens of keyboard shortcuts. Oh, there would be so 
many ways to make things easier... :)

--Ere

---

From: Bernhard Eversberg <[email-masked]>
Date: Tue, 8 Jun 2010 15:05:52 +0200

Alexander Johannesen wrote:

 > The tower of rigidness it turned into is now the tower of Babel for
 > the library community,

Not sure if this is a fitting metaphor: MARC has become the very
language of catalogers almost the world over, across the barriers of
"natural" language! Any system with verbal tags couldn't achieve that,
and you also couldn't create a verbally coded alternative to beat MARC
because it couldn't beat its short-hand-like brevity as well as its
internationality.

> Ugh, and I don't know if this is
> salvageable.
> 

Has anyone come up with a practicable alternative, together with an
economically viable migration path, including the rewiring of all
those brains?
OTOH, all systems being capable of exporting MARC, a thoroughly
convincing and comprehensive new solution shouldn't have too difficult a
time to penetrate the market. Why hasn't it happened yet? I'm not sure
inertia is the only answer.

B.Eversberg

---

From: Alexander Johannesen <[email-masked]>
Date: Wed, 9 Jun 2010 08:41:29 +1000

Hola,

Bernhard Eversberg <[email-masked]> wrote:
> "natural" language!

Well, in its context it makes sense ; after the tower of Babel people
couldn't talk to *others*, so the library world is cramming itself
into *one* language while the rest of the world extends into a
multitude. But yes, I could have made that more obvious. :)

> Any system with verbal tags couldn't achieve that,

Careful, now; there's plenty of old and new systems and formats that
are comparable to MARCs brevity and internationalization; DIB, SureX,
SGML, mBBS, and probably hundreds of other formats that have their
pro's and con's throughout computing history ...

> economically viable migration path, including the rewiring of all

The things that need to happen ;

 * Vendor products needs more generic models
 * ILS need identity management for the real world
 * ILS needs AARC2 / RDA rules as validation, and tightened for the real world
 * Libraries and their systems around the world needs to KILL
presentation in MARC
 * Libraries need to demand more from their vendors (get guts)
 * Libraries need to work out how their meta data is relevant to the world
 * Libraries and vendors need to come up with (or reuse) a format the
rest of the world wants to learn or is already using

Some of this has bits done, but there's a LOT that needs to happen.

> inertia is the only answer.

Stupidity? Lack of guts? Fear of change? Lack of guts? Paired with
little money and poor support from the real world? So many to choose
from ...

Regards,

Alex
--- http://shelter.nu/blog/ ----------------------------------------------
------------------ http://www.google.com/profiles/alexander.johannesen ---

---

From: Bernhard Eversberg <[email-masked]>
Date: Wed, 9 Jun 2010 08:01:26 +0200

> multitude. But yes, I could have made that more obvious. :)
Well, speaking one language internally and globally is an asset rather
than a predicament. Communicating in other languages to the outside
world is made easier that way because conversion routines, conceptually,
have to be devised only once and for all. If they want something other
than MARC, they can have it without our internal structures changing
a bit. Those may need enhancement and enrichment, but no radical change.

> pro's and con's throughout computing history ...
Suggest one or two, and we can talk.

>  * ILS needs AARC2 / RDA rules as validation, and tightened for the real world
All right.

>  * Libraries and their systems around the world needs to KILL
Who would that help? It's always only an option for those who know what
they want.

>  * Libraries need to work out how their meta data is relevant to the world
All right. Very good.

>    rest of the world wants to learn or is already using
Yes. Which ones?

> Some of this has bits done, but there's a LOT that needs to happen.
Agreed. Only not sure killing MARC is among those things.

> little money and poor support from the real world? So many to choose
All of it, here and there, but first of all: lack of direction, clear
targets, vision. But they (users) only tell us or let us feel what they
*don't* want, not what they need, or not with any precision. There may
be a thousand different needs and wishes, conflicting with each other ...
A new vision might call for a clear dichotomy between legacy and New 
World. But right now, there's no such vision. It would have to include
a migration path, probably the most difficult part.

B.Eversberg

---

From: "Rinne, Nathan (ESC)" <[email-masked]>
Date: Wed, 9 Jun 2010 09:37:18 -0500

***Apologies for cross-posting*** - I post here, knowing that opinions
vary among librarians and developers about the importance of this
functionality.

Hello all,

I recently had a talk with someone about the importance of browse lists.
Thankfully, I had something happen to me just recently that gave me a
good example of their importance.  I'm posting most of what I wrote to
this person here (some edits), although if it provokes comments, I can't
promise that I will have time to jump back in.  : )  If anyone here
would like to try the search out themselves, and see if they can rise up
to my challenge and prove me wrong (I will recant, if need be), I invite
you to so. The catalog mentioned in the message can be located here:
http://library.anoka.lib.mn.us/ 

Enjoy (or not, as the case may be : ) ):

"...sometimes I personally find the browse subject search indispensible.
That doesn't mean I use it all the time, but I find it to be very
helpful at certain times.

For example, about a month ago I wanted to quickly find a non-fiction
children's book about the vocation of detective/criminal investigation
at my local library (Anoka County) for my 5 year old and it took me 10
minutes to do it when it should have taken 1 minute.  I not only used a
regular keyword search for detective (I usually do this, and after
finding a book that is relevant, look at that book's particular subject
headings... and use those to launch into other relevant books), but used
the advanced search functionality to try and pinpoint one good book.  It
was to no avail, because the books it pulled up (hundreds) were almost
all fiction (he's already listened to every "Encyclopedia Brown" in
there!).  It was pretty useless.  

It got worse.  After I had done my advanced search and got my list of
results (again, almost all fiction), I got a glimmer of hope: on the
right side of the screen there was a box that had the following info:

'Try these too...

Crime prevention--Citizen participation. 

Detectives, Children. 

Women detectives 

Animal detectives. 

Private investigators. 

more information: Here are entered works on amateur detectives.'

Not only this, but as I clicked on these options, more of these "Try
these too..." boxes with different terms showed up, with seemingly
useful headings!  The problem was, that if I clicked on, for example,
the "Private investigators" heading seen above, it did not give you all
the titles under this heading only (i.e. Private investigators, period)
but also gave me all the headings that had "private investigators" *as a
part of it*.  In other words, I got all the immense amounts of fiction
again: and this time, not just fiction for the kids (stuff with the call
number J, or, E, or EJ, which often seems to correlate with "juvenile
fiction" and "children's fiction" sub-headings), but fiction in general
as well.  Of course this same kind of thing happened when I clicked on
"Detectives" when that option came up. (and note this: you not only get
all the fiction about "detectives" of course, but stuff like this as
well: "Women detectives--England--Cornwall--Fiction.").  Maybe this
could be easily fixed, but perhaps most libraries these days would not
want this "fixed" (because maybe for most persons who don't know how
these headings can work exactly, vendors and libraries think this is the
best way to help people (but not me : ) ) find stuff).

At this point, it seemed to me that the clear answer was the subject
browse list (which also features prominently the see and see also
headings), but in this case, although their catalog offers browse list
functionality, how much "screen real estate" they give it is debatable
(it was over on the right of the screen, away from the main action my
eyes were fixed on: OK, yes I'm really making excuses for not being as
observant as I should).  So actually, on that day, I did not see the
browse list (I only found it a few days later, after I mentioned the
situation to [a colleague] and said that she was surprised they didn't
have this option [I was not that surprised at the time, and assumed that
they didn't, because I know that [things like] Destiny Quest and some
versions of Aqua Browser do not have it either]) and so, on that day, I
had to slog through hundreds of items that were fiction in until I
finally found something good (and then, I could click on the *relevant*
subject headings I found and find the stuff that I needed).  Again, 10
minutes, when it should have taken 1.    

Actually, maybe my answer in this case did not be the subject browse
list, but in that case, I wonder what the alternative would be.  I can't
think of another good way to have done it (but if you tell me one, I can
check online today) - to have helped me from being unproductive.  : )
Even if I wasn't a cataloger, I'd feel this way. : )"

Regards, 
Nathan Rinne
Media Cataloging Technician
Educational Service Center
11200 93rd Avenue North
Maple Grove MN. 55369
Email: [email-masked]

---

From: Jason Etheridge <[email-masked]>
Date: Wed, 9 Jun 2010 10:57:05 -0400

> Even if I wasn't a cataloger, I'd feel this way. : )"

In the Evergreen instance that Georgia PINES is running, I went to
Advanced Search, entered detective into a keyword field, selected
Non-Fiction from the Literary Form filter, and Juvenile from the
Audience filter.  All the results seemed "relevant".

Browse lists of the sort that librarians like are coming, though.

-- 
Jason Etheridge
 | VP, Tactical Development
 | Equinox Software, Inc. / Your Library's Guide to Open Source
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  [email-masked]
 | web:  http://www.esilibrary.com

Please come by and visit the Equinox team and learn more about
Evergreen, Koha, and open source options
ALA Annual meeting in Washington, DC
June 24-28, 2010
booth # 1303

---

From: "Mitchell, Michael" <[email-masked]>
Date: Wed, 9 Jun 2010 10:19:33 -0500

Several of the titles I got using "detectives NOT fiction" with a child's reading level didn't even have any subject headings at all. I don't think poor cataloging proves much.
Also, I'm not very crazy about this SirsiDynix product which is one reason we are staying on its predecessor, Horizon, until we're forced to move and I expect that will not be to this latest SirsiDynix system.
Essentially seems like a strawman argument to me.

Michael Mitchell
Technical Services Librarian
Brazosport College
Lake Jackson, TX
michael.mitchell at brazosport.edu

---

From: Weinheimer Jim <[email-masked]>
Date: Wed, 9 Jun 2010 18:51:13 +0200

Thanks for sharing this. Actually, I am currently at a conference in Budapest and this precise topic came up, where I confess, I spoke up.

The attitude in the conference meeting was veering toward the idea that library subjects just do not work, and I spoke up and said that, even though it really hurts me to say so, I must say that in my own work, I have seen that people do not understand how a catalog works. Even though some may try very hard to understand, they still don't. But that doesn't mean that we should stop doing subject analysis (and headings in general), it's that the way everything is structured is that we are all still making catalog cards. Everything we make can still be printed out and put into a card catalog of the 19th century, or even in a printed book catalog from the 17th century.

People browsed because they had no other choice; they couldn't even imagine one, and the tools reflected this. When you use the tools correctly, you still see the power of this method (as Nathan's anecdote illustrated, which showed how this person rediscovered the power of the card catalog). At the same time, we simply must confess that people use keyword searching first, last and always. Perhaps in pre-Google times, we could ignore all of this, but today people want to use this other service, which they like. Information literacy classes make little dent in how people search, no matter how much we tell them that they are doing it wrong, or how much we frown at what they do. Our tools must be relevant to people's uses

Nevertheless, our tools provide a type of access that Google *cannot provide* and this is what we need to focus on: not to get rid of the old ways, but to make them relevent in the new world.

I don't know the answer, but I think there are many out there.

---

From: Laval Hunsucker <[email-masked]>
Date: Thu, 10 Jun 2010 07:04:53 -0700

Alexander Johannesen wrote :  

 >> I'm not sure inertia is the only answer.
> . . .
> Paired with little money and poor support
> from the real world? So many to choose
> from ...

Alex isn't making any choices or prioritizing any 
answers . . . -- . . . But, is it reasonable to expect 
even more money, or better support, from the real 
world when we've been wasting so much of its 
money and inherently compromising so much of 
its support for so long ?

No. There has to be a really big ( mental ) sea 
change -- ideally accompanied by an obviously 
and openly ingenuous contrition -- and a whole 
lot of subsequent good PR, *in the discourses 
of that real world*. 

In my opinion.

Have we got it in us, collectively ?  No, I don't 
really think so. Fat chance.

Business as usual is so very much easier. So I'd 
say :  Enjoy it while you can !
( *Why* do images of Nero fiddling keep popping 
into my mind ?? )

But then no gnashing of teeth or lamentations 
later, please, over the rude awakenings which are 
awaiting us down the line.

- Laval Hunsucker
   Breukelen, Nederland

----- Original Message ----
From: Alexander Johannesen <[email-masked]>
To: [email-masked]
Sent: Wed, June 9, 2010 12:41:29 AM
Subject: Re: [NGC4LIB] Are MARC subfields really useful ?

Hola,

Regards,

Alex
--- http://shelter.nu/blog/ ----------------------------------------------
------------------ http://www.google.com/profiles/alexander.johannesen ---

---

From: Frances Dean McNamara <[email-masked]>
Date: Thu, 10 Jun 2010 13:51:14 -0500

Actually in recent projects we are exporting in MARC then running through yaz to make xmlmarc and make it utf8 (since our ILS is not Unicode).  It's actually an extra step that's a waste of time to put it out in MARC.  Newer systems can output in xmlmarc.  Once you have that format you don't really need to continue to use MARC tags although you can if you want to, I think MARC was built for a time when it worked better in processing to use numbers but xml is more verbose.  There are actually other limits to MARC you may not think about, like numbers of characters and tags.  Those are old, unnecessary limits.  In most systems the numerical tags get mapped to display labels anyhow.  It's just that it used to be awkward to try to store those labels with the data but now it makes more sense to do that.  The concepts of author/title etc. become more important than keeping the MARC tags when you use the data in newer systems.  I think MARC will just age out as the data gets moved !
 to newer systems because it's not useful like it used to be.  Changes in the ideas of things like "collation" will be more important than the MARC tags.  The number of pages is important to match a physical book to a description, but for an ebook it's irrelevant.  And even that number of pages may be a lot less relevant than an identifier that can allow you to pull up a scanned image of that whole book.  If you want to make sure what you have in hand is the 13th edition of the volume, the one with the special introduction by so and so, you don't have to rely on matching title page transcription and exactly how the pages were printed.  You can call up an image of the book and verify that's the one you want.

Anyhow, I'm finding MARC sort of awkward already.  It's nice to have the utility already written to output it but then I usually have to pull it apart to use the data in another system.  I think MARC will get mapped to new systems and go away.

Frances McNamara
University of Chicago

---

From: Laval Hunsucker <[email-masked]>
Date: Thu, 10 Jun 2010 12:50:07 -0700

You make several nice points here, Jim.

Among them is :  

> Information literacy classes make little dent in how
> people search, no matter how much we tell them that
> they are doing it wrong, or how much we frown at
> what they do.

Information literacy classes make little dent in *anything*, 
and never have done.

It's not just a problem of pragmatics, but also one of theory.
And that makes it all the more pitiful.

It is a constant source of amazement to me that such a 
gigantic amount of energy and time ( and therefore money ) 
has been, and still is being, invested in this whole messy 
business. Also invested has been a tremendous amount of 
professional honor and self-esteem. And *that*, I'd guess, 
has now become the really big problem.

- Laval Hunsucker
   Breukelen, Nederland

---

From: Weinheimer Jim <[email-masked]>
Date: Thu, 10 Jun 2010 22:53:00 +0200

Laval Hunsucker wrote:
<snip>

My concern with this is that people want to believe that finding reliable information is an easy thing to do, which is really untrue and to say such a thing is a disservice to everyone. Perhaps it will be easy someday--I don't know, but while it is easier than ever today to find information, it may be more difficult than ever to find reliable information.

Now, what does "reliable" mean? Obviously, a positive definition is changing constantly today and loaded with controversy, but the negative defintion (i.e. unreliable information), absolutely nobody wants. This idea of "avoiding unreliable infomation" rings true with many people and they are concerned about it, but everything remains quite abstract for them. This is one area where I have seen people may listen to advice--even from a librarian.

There are many, many opportunities for us, if we take them.

---

From: Laval Hunsucker <[email-masked]>
Date: Thu, 10 Jun 2010 14:03:05 -0700

Reliability ain't what it used to be.

Sorry :  Reliability ain't what it used to seem to be.

( And I'm not sure whether we've lost much of great value in the process. )

- Laval Hunsucker
  Breukelen, Nederland

----- Original Message ----
From: Weinheimer Jim <[email-masked]>
To: [email-masked]
Sent: Thu, June 10, 2010 10:53:00 PM
Subject: Re: [NGC4LIB] On the importance of subject browse lists

Laval Hunsucker wrote:
<snip>

---

From: Alexander Johannesen <[email-masked]>
Date: Fri, 11 Jun 2010 07:14:33 +1000

Hola,

> Who would that help? It's always only an option for those who know what

Huh? You seriously don't see a problem with presentation artifacts in
a meta data format? Remember what the MAR part of MARC stands for. I
don't think they wanted "readable" as a non-sequitur. I've before
whinged hard and long that having something machine *readable* is not
the same as machine *understandable*.

>>   rest of the world wants to learn or is already using

Don't know. Probably RDF as a carrier. What I find odd is that no one
seems to have tried to make a serious XML version of MARC
(http://shelterit.blogspot.com/2008/09/marcxml-beast-of-burden.html).
By now it could have been the way out, but I suspect it's too late.

> Agreed. Only not sure killing MARC is among those things.

Funnily enough, I didn't say that. :)

Alex
--- http://shelter.nu/blog/ ----------------------------------------------
------------------ http://www.google.com/profiles/alexander.johannesen ---

---

From: Bernhard Eversberg <[email-masked]>
Date: Fri, 11 Jun 2010 13:21:06 +0200

Frances Dean McNamara wrote:
   I think MARC will get mapped to new systems and go away.
Yes, it will. It can go away, however, only after there is a new
exchange format that every system understands and can export.
Right now, MARC remains the only such format. For communications
inside and between particular communities, MARC may become
obsolete much earlier. But which other format might LC use
now or in the near future to replace MARC21 for their distribution
services?

B.Eversberg