Subject: [NGC4LIB] After MARC...MODS?

From: Cory Rockliff <[email-masked]>
Date: Mon, 19 Apr 2010 15:54:36 -0400

Karen Coyle's recent(ish) blog post 
<http://kcoyle.blogspot.com/2010/04/after-marc.html> has been occupying 
my thoughts of late-- in particular, her response to Jerome McDonough's 
query as to whether MODS might be a viable alternative to MARC. She writes:

"actually, no. Although MODS improves on some of the problems found in 
MARC, I don't see a real philosophical shift from the basic concepts in 
MARC. It's 'a better MARC XML' but not a web-friendly data format. I'm 
leaning away from the hierarchical view that XML favors to something 
more E-R like."

MARC, as is often pointed out, was conceived of as a data exchange 
format; and while our library systems, bizarrely, continue to provide 
the MARC tags view as the default input mode for catalogers, they almost 
universally store that data internally in an RDBMS. Do we no longer need 
a record-like data exchange format if our systems use, e.g., 
triplestores internally (a prospect which is a ways off, I think)?

Setting aside the question of our cooperative cataloging ecosystem 
(OCLC, mostly, for the time being), which is dependent on the record 
model, isn't it still handy to have an abstraction representing a 
discrete parcel of bibliographic information (e.g., "manifestation 
record" or "work record") rather than always needing to decide, on a 
case-by-case basis, how much and what sort of data to harvest from 
someone else's system?

What I'm wondering is, has the "record" as an abstraction truly outlived 
its usefulness? Is it a good idea to dismiss the many real wins of a 
standard like MODS (which I won't enumerate here, unless someone would 
like me to), a standard which has some traction in the digital library 
world, because it embodies the hierarchical document model of XML?

-- 
Cory Rockliff
Technical Services Librarian
Bard Graduate Center: Decorative Arts, Design History, Material Culture

---
[This E-mail scanned for viruses by Declude Virus]

---

From: Kyle Banerjee <[email-masked]>
Date: Mon, 19 Apr 2010 13:18:58 -0700

>
> MARC, as is often pointed out, was conceived of as a data exchange format;
> and while our library systems, bizarrely, continue to provide the MARC tags
> view as the default input mode for catalogers, they almost universally store
> that data internally in an RDBMS. Do we no longer need a record-like data
> exchange format if our systems use, e.g., triplestores internally (a
> prospect which is a ways off, I think)?
>
> .....What I'm wondering is, has the "record" as an abstraction truly
> outlived its usefulness?

The main question is can you use it to do what you need? Once you reach an
acceptable level of functionality, simply offering a better alternative is
not enough.

If it were, I doubt we'd be typing on QWERTY boards or have mag stripes on
our credit/debit cards (don't even get me started on 4 digit pins which are
somehow acceptable for securing a bank account, but which you can't use for
even crappy internet sites).

kyle

----------------------------------------------------------
Kyle Banerjee
Digital Services Program Manager
Orbis Cascade Alliance
[email-masked] / 503.999.9787

---

From: Jonathan Rochkind <[email-masked]>
Date: Mon, 19 Apr 2010 16:29:31 -0400

> triplestores internally (a prospect which is a ways off, I think)?

We _definitely_ still need to exchange data.  We need to do more, not 
less, sharing of data, cooperative cataloging, etc., and you can't do 
that without a standard exchange format.

We just need an exchange format which _really is_ just an exchange 
format, and does not become our standard element vocabulary schema too, 
or our rules for entering data.  MARC has become all of this.   Which is 
one of the reasons i've thought for a while we desperately need to get 
away from MARC -- not because MARC is not capable of expressing what we 
need (it is capable of expressing MOST but not all of it, although not 
always easily or prettily), but because moving away from MARC is the 
only realistic way to conceptually disintangle our data transmission 
format from our data vocabularly schema(ata), from our rules and 
guidelines for entering data.

What will that standard exchange format look like? Do we need a "record 
model", or can we we just get by with free-floating RDF atomic 
assertions?  I don't know.   I am less confident hitching our boat to 
RDF than some.  And certainly our data practices should not REQUIRE RDF 
among all technologies, but be somewhat agnostic toward semantic web 
technologies, IMO.  If its' well designed data though, it should 
_support_ serialization as RDF.   If we DO end up with RDF-compatible 
data, than the standard transmission format COULD be expressed as RDF, 
and probably other ways too. (Note that it's not enough to simply say 
"RDF" -- to get to a standard exchange format, you'd need to constrain a 
whole bunch more things, including RDF vocabularies used, and RDF 
serialization formats recognized.)

But I agree it's just as likely that we'll want "packages" of metadata 
in the form of "records" for some time to come, not JUST bundles of 
atomic RDF assertions.  

But I'm still not sure MODS is very helpful.  My reasons for not being 
enthused with MODS are NOT, as Cory suggests, "because it embodies the 
hieararchical document model of XML."  I've got nothing against a 
hieararchical document model, and I've got nothing against a "record" 
package based exchange format.   My reasons for being suspicious of MODS 
are because it STILL holds too closely to MARC, it's basically just a 
slightly prettified MARC.   It doesn't allow one to do _very_ much more 
than MARC does, and it still makes it harder for us to conceptually 
seperate our _transmission_ format from our data schemata and rules for 
entering data.

So the key thing here is that our _transmission format_ ought not to 
matter very much.  If we can get down our element schemata in a formal 
and clear and flexible way, and we can provide our guidelines for 
entering data in a transmission-format-independent way.... then the 
transmission format(s) are _easy_ after that.   Those are the hard 
parts.  Get those ducks in a row, and it's no longer a very hard problem 
to create one, two, many transmission/exchange serializations that all 
work fine.

Getting those ducks in a row is (at least from one perspective) the goal 
(or one of the goals) of RDA.  I am not certain how well it has 
succeeded, I have some trepidation.

Thinking that mere exchange/serialization format is _important_, that it 
will determine how we build metadata -- is a symptom of getting confused 
about the role of a serialization format vs the role of a formally 
defined element vocabulary/schema.   It's the latter that's hard, it's 
the latter that needs to be flexible enough to handle the various 
realistic possiblities we see for how we manage metadata.  The 
exchange/serialization format is not so important or hard.  That MARC 
seems so important and central to ALL our metadata management is 
testament to how out-of-control MARC has grown to be WAY more than just 
a data exchange format.

---

From: Peter Schlumpf <[email-masked]>
Date: Mon, 19 Apr 2010 16:33:52 -0500

On 4/19/10, Jonathan Rochkind <[email-masked]> wrote:
> That MARC seems so important and central to ALL our metadata management is
> testament to how out-of-control MARC has grown to be WAY more than just a
> data exchange format.

I have thought for well over a decade that MARC has become a mind prison for
the library community that threatens to choke it into irrelevance.  Time to
come up with a mapping system to transport the data contained in it, throw
that old mess out the window and start over again!

Peter Schlumpf
www.avantilibrarysystems.com

---

From: Alexander Johannesen <[email-masked]>
Date: Tue, 20 Apr 2010 08:13:13 +1000

Hola,

Peter Schlumpf <[email-masked]> wrote:
> Time to

There's some good stuff happening in the RDF world of mapping FRBR
with RDA rules (I think? Karen?) which, if we all got involved in,
would change things for the better.

However, the data exchange format is only a small sliver of a larger
problem, because even though RDF will solve some problems it will
*not* solve the problems of the data itself. Changing the containers
doesn't make the contents turn to gold. There's a lot of work to be
done in cleaning up what you've got, including perhaps the no-go job
of *removing* some stuff, do stuff differently, or not at all. And
most importantly, add something new in.

You need to get information into the "records" about stuff that a) is
relevant to the container, and b) relevant to its contents, and c)
relevant to its surroundings, or, in bibliographic terms, relevant to
the cover, to the contents and its reader.

There's that word again; relevant. And I assert that to understand
what that word truly means, you need to put some heavy thinking caps
on because it does *not* mean "business as usual." An aside thats
really smack on topic is the question; what are you guys doing for
cataloging full-text items? What are you doing for cataloging
knowledge fragments? What are you doing for making relationships
between those items? And how do you and your system identify the
items?

Solve those riddles, and the rest will be easy. :)

Kind regards,

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

---

From: Bernhard Eversberg <[email-masked]>
Date: Tue, 20 Apr 2010 10:00:48 +0200

> that old mess out the window and start over again!
While sympathising with this, I'm at a loss if asked where exactly we
ought to be heading, and how.
MARC is not just a tagging scheme! It is so pervasive and ubiquitous in
librarydom that there is no way to just throw it out the window. Perhaps
the most important but frequently underestimated point is that MARC is
the very language of catalogers. It enables effective communication, it
ensures that catalogers can talk to each other across boundaries, even
natural language barriers because it is numbers and codes they are
talking, not words. To replace it means nothing less than rewiring their
brains for a new way of thinking. Which might work, and will have to,
once, and this is a big "once", this new way of thinking has been
defined. What is the new "mapping system"? MODS? I beg your pardon.
Can you envision catalogers talking MODS to the same effect and
efficiency they are now talking MARC? Efficiency matters.
We have to soberly pin down what the real virtues of MARC are and
not throw these out with the bathwater.

B.Eversberg

---

From: Alexander Johannesen <[email-masked]>
Date: Tue, 20 Apr 2010 19:00:35 +1000

Hello,

> ought to be heading, and how.

It's actually quite simple when you look at it from afar. It is
correct as you say that it's the cataloging language, and I never
called it the culture of MARC for nothing. But first before we leap
into what to do, what is the culprit of this culture of MARC?

Tools.

Library tools suck. If the tools you had were a) smart and b)
collaborating, none of this would have been an issue. Any ILS or
catalog have an internal model to which metadata is converted back and
forth through MARC and its culture (AACR2 and possibly RDA, but who
knows, and then lots of little tricks, tips and cultural magic
intrinsic stuff). If this mechanism had better tools, or should I
rather say smarter, then going from one paradigm to another wouldn't
be so hard.

If you in your old tool put in this and that field with these
sub-fields and values, it should be trivial for any tool to read it
(it's supposed to be machine readable, no?) and parse it and put it
into any back-end model you want.

And that's your answer as well; better tools, fix the ones you've got,
it's the only way to fix this mess without losing all that you've
built up. Write to your tool vendor today and demand progress. I've
seen plenty of librarians being pissed off at their vendors of late
(and not just the OCLC debacle), so perhaps the time is ripe. Perhaps
some smart vendors can see this as an opportunity to save the day and
make oodles of money at the same time.

Whatever happened to that open tools and formats and SOA initiative
from vendors? Why aren't we violently holding them to something like
that? All other industries do. Nudge, nudge.

Regards,

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

---

From: Weinheimer Jim <[email-masked]>
Date: Tue, 20 Apr 2010 11:12:27 +0200

Bernhard Eversberg wrote:

<snip>
We have to soberly pin down what the real virtues of MARC are and not throw these out with the bathwater.
</snip>

I think the fundamental issue is that people want the coding to be "human-readable" and a well-trained cataloger is not considered "human." :-)

So, when we map, e.g. 100,700 = <name type="personal">, this is more understandable to a non-library cataloger; although not that much more. Calling something a "personal name" is exceedingly strange for the uninitiated. But still, others can work with MODS much more easily than MARC and therefore, they may be more tempted to do so and use our records in whatever they create.

But sharing needs to go both ways, and libraries need to ingest whenever possible, too. MARC is very inflexible for this (I still maintain that it's because of its ISO2709 foundation).

In a lot of ways, I think it may be similar to when we switched from MARC-8 to Unicode. Everybody prefers Unicode and it's the real standard now. Maybe the switch from MARC to something else, so long as catalogers could retain their 100, 245 etc. interfaces plus most of their subfields, would be OK and few may even notice a real difference. It could end up being a tempest in a teapot, I don't know.

We need some experimentation on many fronts!

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: Bernhard Eversberg <[email-masked]>
Date: Tue, 20 Apr 2010 11:49:19 +0200

> So, when we map, e.g. 100,700 = <name type="personal">, this is more understandable to a non-library cataloger; although not that much more. Calling something a "personal name" is exceedingly stran…
XML is much too wordy and wasteful, more error-prone, much more work to
write in and write software for, and inefficient to process, inelegant,
and ugly. (I'm aware this is currently a minority position. I regard
XML as something like the emperor's new clothing, only that here the
emperor is buried underneath tons of clothing.)

MARC is very inflexible for this (I still maintain that it's because of 
its ISO2709 foundation).
No!! MARC can very well be represented without the ISO2709 fuss.
MarcEdit, for example, converts losslessly between this representation:

=LDR  00532nam  2200205   45e0
=001  875208
=007  ta
=008  \\991231s1985\\\\n\\\\\\\\\\\\\\0000\ger\d
=010  \\$a
=020  \\$a0521221501
=050  \0$aPR2801. A2
=082  00$a822.3'3
=090  \\$a2650-2692
=100  1\$aShakespeare, William
=245  00$aAll's well that ends well$cWilliam Shakespeare
=260  \\$aCambridge :$bCambridge Univ. Pr.,$c1985
=300  \\$aXIII, 154 S.
=440  \4$aThe New Cambridge Shakespeare
=650  \0$adrama in English
=700  12$aFraser, Russell

and the dreaded ISO2709 contortion. Any OCLC editing screen
represents MARC with no trace of ISO to be seen. It is no requirement at
all, it is just that all those tools being used, including VuFind, fail
miserably if they aren't fed the arcane but technically completely
unnecessary ISO2709.

> 
> Maybe the switch from MARC to something else, so long as catalogers could
> retain their 100, 245 etc. ... plus most of their subfields,
> would be OK and few may even notice a real difference. 
> It could end up being a tempest in a teapot, I don't know.
Agreed. But MARC could well get rid of some historic ballast as well.

B.Eversberg

---

From: Weinheimer Jim <[email-masked]>
Date: Tue, 20 Apr 2010 12:32:04 +0200

<snip>
<

What I meant by inflexible is the trouble MARC has for importing information from other places. For example, if the above record had a lot of analytics, with flexible formats, they could be more easily imported, e.g. (making this up)
=505
<bag1>
<name>Smith, John</name>
<title>Act I of All's well that ends well</title>
<note>Originally presented as a paper at...</note>
</bag1>
<bag2>
<name>Smith, Susan</name>
<title>Act I, scene 2 of All's well that ends well</title>
<note>Originally published in ...</note>
</bag2>

When we add to this scenario information feeding in from all over, such as the example of John Smith's form of name being taken through a URI, or imported links to the conference, or other possibilities such as RSS feed updates, and I can't imagine what else right now, MARC has problems. The above example cannot be done with the current MARC format. 

(I'd better be careful of that! Someone will probably show that it can be done, but I will say that it's not worth spending the time on cobbling together an old format when there are too many other options out there)

I am sure there are many other difficult points in MARC as well. One area where MODS is definitely superior to MARC is in the multiple areas for different kinds of dates, e.g. dateIssued, dateCreated, dateModified, etc.

Still, these are all issues that take place behind the scenes. There would be little or no reason to change anyone's cataloging interface very much at all.

---

From: Ross Singer <[email-masked]>
Date: Tue, 20 Apr 2010 08:19:43 -0400

> So, when we map, e.g. 100,700 = <name type="personal">, this is more understandable to a non-library cataloger; although not that much more. Calling something a "personal name" is exceedingly stran…

Honestly this debate between MARC or MODS is a red herring.  The MARC
structure is not insurmountable and it's easy enough to abstract it
away if need be.  The problem is (as Alexander has pointed out) the
data it's actually transporting.  ISO2709 isn't nearly the problem
that ISBD/AACR2 punctuation brings for a developer (or, anybody but a
librarian, really) trying to make semantic sense of anything but the
most controlled set of records.

Even the punctuation wouldn't be so bad if it wasn't all human
entered, inconsistently used and wildly error-prone.

It doesn't matter what carrier format you want to use (MARC,
MarcXchange, MODS, RDA in RDF, whatever) if you have buckets full of
unparseable string tokens.

-Ross.

---

From: Eric Lease Morgan <[email-masked]>
Date: Tue, 20 Apr 2010 08:26:30 -0400

> most controlled set of records.

IMHO, this is EXACTLY correct. Its is the ISBD/AACR2 sort of stuff that is so field specific and inconsistently applied that it is almost impossible to parse MARC, MARCXML, or MODS without going through a million conditional statements.

-- 
Eric Lease Morgan

---

From: Alexander Johannesen <[email-masked]>
Date: Tue, 20 Apr 2010 22:39:03 +1000

> IMHO, this is EXACTLY correct. Its is the ISBD/AACR2 sort of stuff that is so field specific and inconsistently applied that it is almost impossible to parse MARC, MARCXML, or MODS without going th…

It does surprise me somewhat that all you smart folks don't get
together and create a framework for washing and cleaning up MARC
records (making it convertible to whatever else you want or need). I
know OCLC does it as part of their thing, but this thing should be
open and extendable. Let all geeks use it and fix it. There were some
Perl cleaners back in the days, but surely a better option can be
made. :) Heck, even a RegEx library might prove useful to clean it,
and then some lookups to wash it, and maybe a service or two to match
it (and hence tag it), and maybe someone nice could throw in a
modeller to make it all RDF / Topic Maps friendly as well. Whammo! And
we're back in the driving seat of our own destiny, right? Make it as a
pass-through filter, and people can wash their own dirty laundry to
avoid copyright issues (or ignore this problem, and become copyleft
heros!)

Surely this is worth spending a bit of time on? Surely this is in the
interest of all, including top-brass? Surely there is no better way?
Surely this has all the political clout and librarian chutzpah needed
to get going?

Regards,

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

---

From: Bernhard Eversberg <[email-masked]>
Date: Tue, 20 Apr 2010 14:41:51 +0200

> IMHO, this is EXACTLY correct. Its is the ISBD/AACR2 sort of stuff that is so field specific and inconsistently applied that it is almost impossible to parse MARC, MARCXML, or MODS without going th…

Agreed. Data entry practices and standards have to change regardless of
the formats actually used. More often than not, inconsistencies result
from differences in the ways the ILS's index and display the data, or
what peculiarities a library wanted in the layout of their cards.
Catalogers must become more technically aware of the consequences.

But even so, one doesn't see any agreement at all about what
format to introduce. Internally, systems can use anything they
want, but for exchange a uniformly understood format is
indispensable, and it should be free of oddities in punctuation
and whatever. However, more than one communication format can
be accomodated and offered to the public, as long as tools
for conversion are available.
The recent releases of "open data", BTW, are all non-MARC but differing
widely and wildly from each other...

And Alex wrote:
 > records.
Very odd indeed. What's MARBI thinking?

B.Eversberg

---

From: Alexander Johannesen <[email-masked]>
Date: Tue, 20 Apr 2010 22:55:05 +1000

> Very odd indeed. What's MARBI thinking?

http://www.loc.gov/marc/marbi/marbi.html

According to that page, nothing in the last 8 years. :)

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

---

From: Ross Singer <[email-masked]>
Date: Tue, 20 Apr 2010 08:59:53 -0400

On Tue, Apr 20, 2010 at 8:39 AM, Alexander Johannesen
<[email-masked]> wrote:

> records (making it convertible to whatever else you want or need).

I think there are multiple reasons for this, the big one being the
time and effort of someone(s) who is both technologically adept and
comprehensively familiar with the cataloging rules (and all of the
variants).

Even bigger, honestly, is the fact that "cleansed" data might only be
fractionally better (or a lot, it's hard to know until it's done) and
that our current systems wouldn't work any better even with more
semantically rich data.

And now, if you can identify the resources in your data, it's a whole
lot easier to fill out the gray areas from sources like dbpedia or
freebase than worrying about regexes.

I hope the gravity of that last sentence resonates with somebody.

-Ross.

---

From: "Lundgren,Jimmie Harrell" <[email-masked]>
Date: Tue, 20 Apr 2010 09:02:34 -0400

Oh, please! http://www.loc.gov/marc/ 

Jimmie Lundgren 
Associate Chair & Contributed Cataloging Unit Head 
Cataloging & Metadata Dept. 
Smathers Library 
PO Box 117004 
University of Florida 
Gainesville, FL 32611-7004 
352-273-2725 
352-392-7365 (fax) 
[email-masked] 

-----Original Message-----
From: Next generation catalogs for libraries [mailto:[email-masked]] On Behalf Of Alexander Johannesen
Sent: Tuesday, April 20, 2010 8:55 AM
To: [email-masked]
Subject: Re: [NGC4LIB] After MARC...MODS?

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

---

From: "Dobbs, Aaron" <[email-masked]>
Date: Tue, 20 Apr 2010 09:20:24 -0400

Staying with the MARC / ISO2709 notation does us few favors with personal names. 
The MARC+AACR2 implementation of naming makes it very difficult to distinguish between the various "Smith, John" possibilities without referencing an authority file. If we're referencing an authority file anyway, why not take the next step?

This notation: "<name>Smith, John</name>" from "<bag1>" could be either:

<bag1>
<surnomen>Smith</surnomen>
<praenomen>John</praenomen>
</bag1>

Or

<bag1>
<personalname>
<reference1>Cloud-based Personal Names Authority File1 ID</reference1>
<reference2>Cloud-based Personal Names Authority File2 ID</reference2>
</personalname>
</bag1>

(there may be potential problems with these Anglo-centric naming conventions)

Continuing the theme, each work in a "local" catalog could be referenced to a Cloud-based Works Authority File, expand this out to all the common facts about a work or expression, etc. 

Going beyond that, then, the "local" item record (a.k.a. the inventory record) becomes a bucket of references attached to a local inventory control ID - where the ID is the Primary Key. The ID and its associated Foreign Keys are all the inventory system needs to track/control item circulation, just make the circ client a little smarter & have it pull in any necessary details from the cloud-based authority files (which means we could switch to an inexpensive, by comparison, off-the-shelf inventory system, similar to those used by Wal-Mart or any other retailer with automated checkout).

Discoverability becomes a query against a separate, large, common index (of whatever descriptive components required/desired plus a location identifier), which allows the searcher to learn whether the item is in the local library or must be requested from afar.

Local notes and local subject headings could be incorporated in the common index (perhaps keyed to a location identifier for "special snowflake-ness" if practical/desired) which would enrich the discoverability aspects of the ultimate work/expression/item.

I'm not saying MARC is bad; however, I am suggesting the current Local-ILS implementation of MARC may be an evolutionary dead-end.

-Aaron
:-)'

> From: Next generation catalogs for libraries
> [mailto:[email-masked]] On Behalf Of Weinheimer Jim
> Sent: Tuesday, April 20, 2010 6:32 AM
<snip>
> What I meant by inflexible is the trouble MARC has for importing
> information from other places. For example, if the above record had a
> lot of analytics, with flexible formats, they could be more easily
> imported, e.g. (making this up)
> =505
> <bag1>
> <name>Smith, John</name>
> When we add to this scenario information feeding in from all over, such
> as the example of John Smith's form of name being taken through a URI,
> or imported links to the conference, or other possibilities such as RSS
> feed updates, and I can't imagine what else right now, MARC has
> problems. The above example cannot be done with the current MARC
> format.
</snip>

---

From: MJ Suhonos <[email-masked]>
Date: Tue, 20 Apr 2010 09:39:40 -0400

Thank you, Ross, for the "red herring" comment — I was beginning to get very discouraged by this thread; the MARC-vs-MODS debate, interesting as it is, seems symptomatic of other issues.

Besides, LoC has already summarized (many of) the issues for us:
http://www.loc.gov/standards/mods/mods-overview.html

From my perspective, the conversation seems to go roughly like this:

Cataloguers: We want something better than MARC.
LoC: Okay, did you have anything specific in mind?
Cataloguers: Not really, just.. you know, better.
LoC: Okay, here you go <produces MODS>
Cataloguers: No, no, that's not good enough.  <insert reason du jour>
LoC: … ?!?!

(This is obviously simplified, but in my defence, MARC was conceived before I was, so I'm a bit late to the game.)

A couple of particular statements that I'd like to comment on:

> My reasons for being suspicious of MODS are because it STILL holds too closely to MARC, it's basically just a slightly prettified MARC.   It doesn't allow one to do _very_ much more than MARC does

I disagree — as a programmer/hacker who has almost zero knowledge of MARC (245? 700? 123? XYZ? What?), MODS lets me do some very useful things without having to learn a new language.  Especially for the reasons Eric and Ross mention regarding ISBD/AACR2 and parsing (though, Jonathan, as a hacker you must know this firsthand :-).

And don't take my word for it, just look at some of the CSL and Bibutils work being done by non-librarians with MODS:

http://code.haskell.org/citeproc-hs/
http://www.scripps.edu/~cdputnam/software/bibutils/

> efficiency they are now talking MARC? Efficiency matters.

There's the problem: cataloguers are *forced* to learn how to "talk MARC" and thus become superhuman.  MODS, in contrast, is readable by "mere" humans.  Why do we require cataloguers who aren't doing under-the-hood system maintenance to understand MARC?

For those who think MODS "doesn't go far enough": when I showed the cataloguers in my department a slide of MARCXML, they could generally wrap their heads around it.  When I showed the same record in MODS, their reaction was more mixed, and less temperate.

So, if you mean "go far enough to change many cataloguers' thinking", MODS is pretty radical.  If you mean "go far enough to break from the hierarchical record concept", then no.  But then, I'm not we'd want to use MODS for that anyway.

When I see, eg:  http://www.loc.gov/marc/bibliographic/bd20x24x.html — I see a crosswalk.  A cataloguer with item-in-hand wants to enter metadata for "Uniform Title" based on the rules of practice they have.  Why should they know or even care whether it's coded internally as 240 or <titleInfo type="uniform">?  

> Still, these are all issues that take place behind the scenes. There would be little or no reason to change anyone's cataloging interface very much at all.

I couldn't agree more — a large part of the problem is that the tools are built so poorly that they don't successfully separate "cataloguing rules" from the underlying encoding format.  We saw this as a huge cultural issue when trying to build a cataloguing tool designed for different cultures (libraries, archives, museums) and thus, different descriptive rules, but with an underlying crosswalkable data store.  The librarians insisted on "seeing" MARC; the archivists insisted on "seeing" EAD, and so on.

And lastly:

> records (making it convertible to whatever else you want or need)

I think what you're looking for is this:
http://www.loc.gov/standards/mods/v3/MARC21slim2MODS3-3.xsl

Obviously that's somewhat tongue-in-cheek, but if you look at sheer amount of logic in that stylesheet (and bear in mind that it includes more from the "MARC slim Utils"), you'll see that a significant amount of "clean up" work is involved in crosswalking from MARC to MODS.

Case in point:  I have about 10M MARC21 records that I want to try some "interesting stuff" with.  The very first thing I need to do in order to a) use modern tools and b) make it readable for myself (a programmer and librarian, but not a trained cataloguer) is convert it to MODS.  After struggling for many hours yesterday with MARC::XML and MARC4J (the only tools available to me), I'm still stuck.  The data format sucks and the tools to free it into something modern also suck.

If I was starting with MODS instead, I'd have a much larger set of tools to manipulate the XML, and tinker with ways to break it into linked data, crosswalk into Dublin Core, etc.  (Aside: I'd like to serialize MODS into JSON but unfortunately it's too tied to XML to do this easily; love to hear ideas from anyone who might know how to do this.)

I guess my point after all this ranting is that by our single criterion "better than MARC", MODS succeeds wildly.  It's imperfect, absolutely; and by design it still inherits MARC-like concepts, but we are richer for having it as a tool.  Why aren't we using it?  If it's not "good enough", then we have to be specific about what criteria *would* make it "good enough", and for what purposes.

MJ

---

From: Bernhard Eversberg <[email-masked]>
Date: Tue, 20 Apr 2010 15:40:29 +0200

> Staying with the MARC / ISO2709 notation does us few favors with personal names. 
As I said, forget ISO2709, it can be entirely gotten rid of without any
changes in MARC substance. It is ONLY still around because of all those
tools and interfaces, and it doesn't sit in most ILS's anyway,
internally.

> The MARC+AACR2 implementation of naming makes it very difficult... 
> 
There *will* be these problems. And don't forget terminology changes and
designators that become politically incorrect and all that.
Numeric tags have been and will be the method of choice; there's no
salvation in verbal tagging. This does not preclude exports in all
manner of copiously verbose ways, I'm talking of exchange standards
only which are for content that must be stable for a relative eternity.

> Continuing the theme, each work in a "local" catalog could be referenced to a Cloud-based Works Authority File,
Sure, a nice idea, but don't drive this too far; it creates new
dependencies on infrastructure and will likely be performance critical.

> 
> Discoverability becomes a query against a separate, large, common index 
Yes; this could then also be a switchboard between national standards
for extending queries beyond borders.

> 
> I'm not saying MARC is bad; however, I am suggesting the current
 > Local-ILS implementation of MARC may be an evolutionary dead-end.
> 
Maybe, but this doesn't help as long as there is no new strategy
that does more at lower cost.

B.Eversberg

---

From: Bernhard Eversberg <[email-masked]>
Date: Tue, 20 Apr 2010 15:49:23 +0200

> There's the problem: cataloguers are *forced* to learn how to "talk MARC" and thus become superhuman.  MODS, in contrast, is readable by "mere" humans.  Why do we require cataloguers who aren't doi…
No, to learn MARC does not consist of learning all the numbers and
codes, that's rather trivial. You have to learn the precise meanings and
the concept, and that's the same with verbal tags. You only *think* you
understand something when reading verbal tags, but without the
understanding of the precise semantics you are prone to producing a hell
of a mess. Dublin Core data have proved this point in abundance;
read Roy Tennant's "Metadata's Bitter Harvest":
   http://www.libraryjournal.com/article/CA434443.html

B.Eversberg

---

From: Ross Singer <[email-masked]>
Date: Tue, 20 Apr 2010 09:59:32 -0400

On Tue, Apr 20, 2010 at 9:39 AM, MJ Suhonos <[email-masked]> wrote:

> I guess my point after all this ranting is that by our single criterion "better than MARC", MODS succeeds wildly.

Actually, I'm not sure this exactly the conclusion you should be
drawing from the crux of your email.  The MARC-to-MODS XSLTs are
extremely adept at gleaning the actual data from our legacy MARC
records and putting them into a more semantically rich data structure.
 I would say this is generally good and useful.

That's different than saying that MODS is a a good or useful
destination (and, again, I go back to my point that it's moot once
you've gotten to this stage).

I think it's far more useful to focus on the XSLT (since that's where
the really important stuff is happening for MODS) than the actual
output document.

-Ross.

---

From: "Walker, David" <[email-masked]>
Date: Tue, 20 Apr 2010 06:55:50 -0700

> After struggling for many hours yesterday with MARC::XML 
> and MARC4J (the only tools available to me), I'm still stuck.

MJ, have you tried using yaz-marcdump [1], which comes with the yaz toolkit [2] ?

You can invoke that from the command line to convert your MARC to MARC-XML.  And then use XSLT to get the MARC-XML to MODS.

Easy enough to then put that all in a script in the language of your choice to automate the whole thing.

--Dave

[1] http://www.indexdata.com/yaz/doc/yaz-marcdump.html
[2] http://www.indexdata.com/yaz

==================
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu
________________________________________
From: Next generation catalogs for libraries [[email-masked]] On Behalf Of MJ Suhonos [[email-masked]]
Sent: Tuesday, April 20, 2010 6:39 AM
To: [email-masked]
Subject: Re: [NGC4LIB] After MARC...MODS?

MJ

---

From: MJ Suhonos <[email-masked]>
Date: Tue, 20 Apr 2010 10:04:03 -0400

> codes, that's rather trivial.

Maybe for you!  It's overwhelmingly imposing for me, which is why I do to great lengths to avoid it.

> You have to learn the precise meanings and
> of a mess.

Of course; and this is where having defined semantics for the "metadata elements" (I'm not sure what else to call them) is critical — Dublin Core did a good job of making these vague enough so as to guarantee messy data, but I would contend it was the lack of consistent cataloguing rules (or at least, lack of application) that was the larger contributor.

I agree that simply being able to read MODS as verbal text isn't sufficient for good-quality data; but verbal cues are much easier to mentally map to the semantic definitions than numeric ones — if it's all the same to computers, don't we want to make it easier for mere humans to work with our records?

MJ

---

From: Ed Summers <[email-masked]>
Date: Tue, 20 Apr 2010 10:19:36 -0400

I think the primary tension here is not between document oriented
MARC/MODS and RDF, but between document oriented MARC/MODS and the
models present in FRBR and RDA. To some extent these tensions are
eased, as MARC takes on features that will allow it to be a carrier
for RDA [1]. I haven't personally evaluated these changes, but in
principle it seems like a decent compromise until other serialization
formats for RDA are proposed.

The other tension is that the Future of Bibliographic Control report
[2] really highlighted the need for LC and libraries in general to
integrate their data into the web:

"""
3.1.2 Integrate Library Standards into Web Environment
3.1.2.1 All: Express library standards in machine-readable and
machine-actionable
        formats, in particular those developed for use on the Web.
3.1.2.2 All: Provide access to standards through registries or Web
sites so that the
        standards can be used by any and all Web applications.
3.1.2.3 LC: Begin transitioning LC-managed vocabularies to a platform
that is both
        Web services-friendly and allows files to be downloaded for
incorporation
        into other applications. These vocabularies include the many
lists that are
        used in bibliographic records such as language and geographic
codes, resource
        format codes, etc.
"""

RDF is a data model that is made for (and of) the web [3] -- so I
personally think it is well suited for making library data more a part
of the web. That being said, I think an xml serialization format other
than application/rdf+xml could represent bibliographic data
sufficiently.

But at this stage, I think we need the flexibility to figure out what
vocabularies work, and which don't. Kudos to the Royal Library of
Sweden, the National Library of Hungary, the Deutschen
Nationalbibliothek for kicking the tires, and giving URLs to the
things libraries care about. Hopefully we'll see more library software
companies recognize the business opportunity here.

//Ed

[1] http://www.loc.gov/marc/RDAinMARC29.html
[2] http://www.loc.gov/bibliographic-future/news/lcwg-ontherecord-jan08-final.pdf
[3] http://www.w3.org/1999/11/11-WWWProposal/thenandnow

---

From: Bernhard Eversberg <[email-masked]>
Date: Tue, 20 Apr 2010 16:21:23 +0200

> Maybe for you!  It's overwhelmingly imposing for me, which is why I do to great lengths to avoid it.
No, my reaction when first confronted with MARC was exactly the same.
There's a very good introduction, "Understanding MARC". Very
illuminating and, while it is still around, indispensable reading.
   http://www.loc.gov/marc/umb/
> I agree that simply being able to read MODS as verbal text isn't sufficient for good-quality data; but verbal cues are much easier to mentally map to the semantic definitions than numeric ones — if…
We want to make things easier, right, but that doesn't mean we should
give up presicion. It just means we must be able to produce, for
example, RIS data as well (arguably the most widely known format
because Endnote and others use it).

B.Eversberg

---

From: Deborah Fritz <[email-masked]>
Date: Tue, 20 Apr 2010 10:32:10 -0400

Apologies, I would have sent this to MJ directly, but cannot find an email
address.

MJ,
You could try this utility. Download and install MARC Report. It has a free
30-day trial period (with no restrictons)
http://www.marcofquality.com/soft/mrtdownload-f.html

Once installed, start the program.
Go to the Utilities menu and select 'MARC to XML'.
Click the MARC21 button and select the file you want to convert 
Click the XML button and setup a name for the results
(Hint: if converting a very large file, performance will improve by sending
the output to a different drive) 
Click the Custom tab. 
Click on the sylesheet box; 
	select MARC21slim2MODS3-3r.xml
(Hint: the 'r' stylesheets add one line to the default LC stylesheets that
will improve performance by several orders of magnitude) 
Click Start Conversion.

If converting a large file, it would be a good idea to run the file through
the Verify utility first to make sure there are not any problems that could
trip up the conversion.

Deborah

------
Deborah Fritz
MARC Database Consultant
The MARC of Quality
www.marcofquality.com
Voice/Fax: (321) 676-1904

> [mailto:[email-masked]] On Behalf Of Walker, David
> Sent: Tuesday, April 20, 2010 9:56 AM
> > After struggling for many hours yesterday with MARC::XML and MARC4J 
> > (the only tools available to me), I'm still stuck.
> 
> You can invoke that from the command line to convert your 
> MARC to MARC-XML.  And then use XSLT to get the MARC-XML to MODS.
> 
> Easy enough to then put that all in a script in the language 
> of your choice to automate the whole thing.
> 
> --Dave
> 
> [[email-masked]] On Behalf Of MJ Suhonos [[email-masked]]
[snip]

> Case in point:  I have about 10M MARC21 records that I want 
> to try some "interesting stuff" with.  The very first thing I 
> need to do in order to a) use modern tools and b) make it 
> readable for myself (a programmer and librarian, but not a 
> trained cataloguer) is convert it to MODS.  After struggling 
> for many hours yesterday with MARC::XML and MARC4J (the only 
> tools available to me), I'm still stuck.  The data format 
> sucks and the tools to free it into something modern also suck.
> 
> If I was starting with MODS instead, I'd have a much larger 
> set of tools to manipulate the XML, and tinker with ways to 
> break it into linked data, crosswalk into Dublin Core, etc.  
> (Aside: I'd like to serialize MODS into JSON but 
> unfortunately it's too tied to XML to do this easily; love to 
> hear ideas from anyone who might know how to do this.)
> 
> I guess my point after all this ranting is that by our single 
> criterion "better than MARC", MODS succeeds wildly.  It's 
> imperfect, absolutely; and by design it still inherits 
> MARC-like concepts, but we are richer for having it as a 
> tool.  Why aren't we using it?  If it's not "good enough", 
> then we have to be specific about what criteria *would* make 
> it "good enough", and for what purposes.
> 
> MJ

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 5041 (20100419) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

---

From: Ed Summers <[email-masked]>
Date: Tue, 20 Apr 2010 10:33:25 -0400

In case you haven't seen it already, I meant to add that Hillman,
Dushay and Phipps have a good paper on the operational need we have to
move beyond the Record in our metadata:

Improving Metadata Quality: Augmentation and Recombination
http://ecommons.library.cornell.edu/handle/1813/7897

Digital libraries have, in the main, adopted the traditional library
notion of the metadata 'record' as the basic unit of management and
exchange. Although this simplifies the harvest and re-exposure of
metadata, it limits the ability of metadata aggregators to improve the
quality of metadata and to share specifics of those improvements with
others. The National Science Digital Library (NSDL) is exploring
options for augmenting harvested metadata and re-exposing the
augmented metadata to downstream users with detailed information on
how it was created and by whom. The key to this augmentation process
involves changing the basic metadata unit from 'record' to
'statement.'

//Ed

---

From: "Mitchell, Michael" <[email-masked]>
Date: Tue, 20 Apr 2010 09:38:15 -0500

This little portion of what you wrote is funny to me. You've said previously you  want to change our authorized names to numbers (or URIs) and now our numbers to names/words. 
OK. 

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

-----Original Message-----
From: Next generation catalogs for libraries [mailto:[email-masked]] On Behalf Of MJ Suhonos
Sent: Tuesday, April 20, 2010 8:40 AM
To: [email-masked]
Subject: Re: [NGC4LIB] After MARC...MODS?

<snip>A cataloguer with item-in-hand wants to enter metadata for "Uniform Title" based on the rules of practice they have.  Why should they know or even care whether it's coded internally as 240 or <titleInfo type="uniform">?  <snip>

---

From: MJ Suhonos <[email-masked]>
Date: Tue, 20 Apr 2010 10:44:03 -0400

> This little portion of what you wrote is funny to me. You've said previously you  want to change our authorized names to numbers (or URIs) and now our numbers to names/words. 

Sorry, I never said that.  Maybe you're thinking of someone else?

MJ

---

From: "Mitchell, Michael" <[email-masked]>
Date: Tue, 20 Apr 2010 09:45:38 -0500

MJ,

MarcEdit has several conversion options including MARC to MODS. I don't know how well it works but it does a lot of other things well.
<http://people.oregonstate.edu/~reeset/marcedit/html/index.php>

Michael Mitchell

-----Original Message-----
From: Next generation catalogs for libraries [mailto:[email-masked]] On Behalf Of Walker, David
Sent: Tuesday, April 20, 2010 8:56 AM
To: [email-masked]
Subject: Re: [NGC4LIB] After MARC...MODS?

--Dave

==================
David Walker

---

From: Jonathan Rochkind <[email-masked]>
Date: Tue, 20 Apr 2010 10:46:04 -0400

Bernhard Eversberg wrote:
> the concept, and that's the same with verbal tags. 

So, okay, here's what this means to me:  You are saying that MARC serves 
as our metadata _schema_ or _vocabulary_.  It is NOT just a 
serialization format or an exchange format, it is in fact our schema, it 
defines what elements are available and what they mean.

Now, to me, THAT is in fact the biggest problem with MARC.  We've taken 
what was originally designed as simply a transport format, and turned it 
into a schema.  In the process, by having ONE standard that is BOTH our 
metadata schema and serialization format, by entangling these two 
concepts, it makes any kind of movement or inter-operability much more 
complicated.  It makes it nearly impossible to have a serialization of 
our data in some _other_ serialization format in a 'lossless' way, 
because the serialization format and the schema are so entangled. 

It makes our 'content guidance' like AACR2 _very_ difficult to 
understand in practice, because the only reasonable way to write content 
guidance like AACR2 is to refer to a metadata schema.  AACR2 refers to 
ISBD -- which "officially" was designed as a metadata schema (although 
we/they didn't use that term way back then, that's what it was; library 
people were actually doing 'metadata engineering' FIRST).    But in 
_fact_, in most/all AACR2-using countries, it's MARC21 that BECAME the 
true metadata schema. AACR2 keeping up the fiction that it's ISBD makes 
these various parts of our metadata control regime mesh with "broken 
gears", making everything _much_ harder to understand for both library 
and non-library sector people (who might want to inter-operate with our 
data). 

It makes it insanely complicated to make any changes to ANY of the parts 
of the metadata regime, because the parts inter-relate in ill-defined 
ways. If what you really need is a change in our 'metadata schema', does 
that mean you need a change to ISBD, MARC, or AACR2?  Or all of the above? 

RDA _theoretically_ uses FRBR (rather than ISBD) as the referenced 
'metadata schema'.   This to my mind is actually the _most important_ 
part of RDA, the  The problem is that the RDA effort didn't really 
realize how important and how challenging this was, they didn't really 
realize what it entailed, and didn't take it seriously -- perhaps until 
fairly recently.  FRBR needs/needed some work to do the job, and it 
needs to effect the whole of how RDA is structured. Diane Hillman is 
waging an epic struggle to make RDA take seriously the idea that (a 
further formalization/specification of) the FRBR model is the metadata 
schema which RDA applies guidance to.  If she and RDA are successful, 
that will be the biggest contribution of RDA, and will make possible 
alternate serialization formats that are still "high fidelity".

Jonathan

---

From: Weinheimer Jim <[email-masked]>
Date: Tue, 20 Apr 2010 17:08:32 +0200

A few points.

Here is an example in the mapping from MARC21 to MODS for uniform titles from http://www.loc.gov/standards/mods/mods-mapping.html:
130, 240 $a$d$f$k$l$m$o$r$s
730 $a$d$f$k$l$m$o$r if ind2 is not 2 	
Maps to:
<title> with <titleInfo> type="uniform" and
130, 240, 730 $n (and other subfields following as above) 	
Maps to
<partNumber> 	
130, 240, 730 $p (and other subfields following as above)
Maps to:
<partName> 		
130, 240, 730 $0 	add xlink="contents of $0" (as URI) 	

Now, compare this to the MARC Guidelines for the 240 field:
http://www.loc.gov/marc/bibliographic/bd240.html 

and the LC Rule Interpretations (these are the additions to AACR2, not AACR2 itself) for uniform titles:
http://sites.google.com/site/opencatalogingrules/aacr2-chapter-25 

Here is the Uniform title in UNIMARC:
http://archive.ifla.org/VI/3/p1996-1/uni5.htm 

A non-cataloger will probably ask: What is a uniform title? And that would be the correct response because there are different types of uniform titles for different purposes and they are terribly complex. It should also be accepted that there are legitimate reasons for this complexity. The above rules work together intimately to ensure standards for both the coding and standards for the information. (Except for the UNIMARC, which has different standards)

When you look at the mapping of MARC to MODS, there is a great deal of data loss. Therefore, let us take the version information: 240$s (that I have personally agonized over at times) just gets bunged in together to <titleInfo type="uniform"> along with lots of other information. This is definitely a loss of information. UNIMARC is probably as complex with uniform titles, while all the other formats will probably be very difficult.

Bernhard would have different entry practices for entering the conceptual idea contained in 245$s, but I am sure they have their rules for this. Yet, how do we share that information using MODS? We don't. We can't, since it mushes everything together. Therefore, MODS is not good enough for us to share with, e.g. the Germans even they may code the same information separately as we do in our 245$s. The only way to share is to either forget the separate $s or recode locally.

Still, to calm the working catalogers, they need to be aware that this "loss of data" happens only when another organization harvests your record, and these others can select from different formats, e.g. harvesting from American Memory right now, you can choose Dublin Core, MARCXML or MODS.
http://memory.loc.gov/ammem/oamh/oai_request.html In any case, the information in the local database that the catalogers create still exists and is fine.

How much of this does the computer programmer need to know? I don't know, but the programmer doubtless needs plenty of help and should not expect to do such things on their own. There should be a happy medium somewhere.

---

From: MJ Suhonos <[email-masked]>
Date: Tue, 20 Apr 2010 11:23:42 -0400

Hi all,

Just wanted to say thanks to those who responded with help on tools for MARC-to-MARCXML(-to-MODS) conversion.  Yaz-marcdump did the trick beautifully, and was as easy as I had expected it to be.

Thanks again,
MJ

---

From: "Dobbs, Aaron" <[email-masked]>
Date: Tue, 20 Apr 2010 11:40:38 -0400

To distill down, the model says:

The transport format uses:
1. an integrated schema (which is:
2. populated by guidelines (which are:
3. based upon rules (as:
4. expressed in interpretations (which are:
5. inclusive of punctuation (and:
6. applied in various fashions (which are:
7. subject to local decisions (and:
8. flavored by typographical errors

-Aaron
:-)'

> Sent: Tuesday, April 20, 2010 11:09 AM
> > There's the problem: cataloguers are *forced* to learn how to "talk
> MARC" and thus become superhuman.  MODS, in contrast, is readable by
> "mere" humans.  Why do we require cataloguers who aren't doing under-
> the-hood system maintenance to understand MARC?
> 
> >
> Here is an example in the mapping from MARC21 to MODS for uniform
> titles from http://www.loc.gov/standards/mods/mods-mapping.html:
> A non-cataloger will probably ask: What is a uniform title? And that
> would be the correct response because there are different types of
> uniform titles for different purposes and they are terribly complex. It
> should also be accepted that there are legitimate reasons for this
> complexity. The above rules work together intimately to ensure
> standards for both the coding and standards for the information.
> (Except for the UNIMARC, which has different standards)
> 
> When you look at the mapping of MARC to MODS, there is a great deal of
> data loss. Therefore, let us take the version information: 240$s (that
> I have personally agonized over at times) just gets bunged in together
> to <titleInfo type="uniform"> along with lots of other information.
> This is definitely a loss of information. UNIMARC is probably as
> complex with uniform titles, while all the other formats will probably
> be very difficult.
> 
> Bernhard would have different entry practices for entering the
> conceptual idea contained in 245$s, but I am sure they have their rules
> for this. Yet, how do we share that information using MODS? We don't.
> We can't, since it mushes everything together. Therefore, MODS is not
> good enough for us to share with, e.g. the Germans even they may code
> the same information separately as we do in our 245$s. The only way to
> share is to either forget the separate $s or recode locally.
> 
> Still, to calm the working catalogers, they need to be aware that this
> "loss of data" happens only when another organization harvests your
> record, and these others can select from different formats, e.g.
> harvesting from American Memory right now, you can choose Dublin Core,
> MARCXML or MODS.
> http://memory.loc.gov/ammem/oamh/oai_request.html In any case, the
> information in the local database that the catalogers create still
> exists and is fine.
> 
> How much of this does the computer programmer need to know? I don't
> know, but the programmer doubtless needs plenty of help and should not
> expect to do such things on their own. There should be a happy medium
> somewhere.
>

---

From: "Diane I. Hillmann" <[email-masked]>
Date: Tue, 20 Apr 2010 13:38:19 -0400

Ed:

Interestingly enough this piece of the WG recommendations is exactly the 
stuff I'm working through with my students this week.

> formats for RDA are proposed.
What the MARC changes lack is the rich set of relationships that RDA 
Vocabularies include.  Although for sure we'll be dealing with MARC for 
some time to come, we shouldn't settle for the few relationships that 
have been crammed into MARC.  The RDA Vocabularies seem to me to be 
poised to be the basis of the serializations you're looking for, but I 
may be biased ... :-)
>          used in bibliographic records such as language and geographic
Absolutely, and it's a huge disappointment that this work is going so 
slow in some of the areas that count, like the NAF, for instance.  The 
FRAD element set is going into the Registry even as we speak, so I'm 
hoping that will be a stepping stone.
> companies recognize the business opportunity here.
The DNB is doing some fabulous work with RDA, including entering German 
language translations of the prefLabels and definitions--really some 
good proof that we don't have to settle for English-only anymore.  (See: 
http://metadataregistry.org/schemapropel/list/schema_property_id/112.html and 
the RDF: http://rdvocab.info/roles/cinematographer.rdf -- and yes, we 
know the human display is sub-optimal, but we're working on that).

Diane

---

From: "Diane I. Hillmann" <[email-masked]>
Date: Tue, 20 Apr 2010 13:46:23 -0400

Ed,

Thanks for the plug!  Those who are concerned about how we're going to 
haul our legacy data with us as we move on from MARC should take a look 
at what the eXtensible Catalog Project is doing (some screencasts here: 
http://www.screencast.com/users/eXtensibleCatalog -- I particularly 
recommend #1 & #3).  They've taken much of the work we did for NSDL and 
put it to good use in their metadata management system and their services.

Diane

---

From: Karen Coyle <[email-masked]>
Date: Tue, 20 Apr 2010 12:46:50 -0700

> put it to good use in their metadata management system and their

The difference I see, though, between XC and some of the discussion  
here is that XC is about *use* of data not *creation* of data. In  
other words, XC is about taking metadata and transforming it. I still  
can't quite figure out the level of detail that is retained after the  
transformations, but all of the verbs are things like "harvest" and  
"transform", meaning that metadata has to already exist.

Where I think we have some difficult decisions to make is around data  
creation. MARC has over 500 different variable data elements and a  
hundred or so more fixed elements.  
(http://futurelib.pbworks.com/Data+and+Studies).
RDA has over 300 elements and more than that as relationships (and we  
know that RDA elements have been underspecified in terms of detail  
compared to MARC). (http://metadataregistry.org/rdabrowse.htm) If you  
have highly detailed metadata, you can always reduce it to less detail  
if that's all you need for an application. However, if you don't  
create the metadata at a particular level of detail, you will probably  
not be able to recover greater detail algorithmically.

The analysis that hasn't been done on library cataloging is: "what  
elements and coding are necessary for the desired system  
functionality?" We don't know what level of detail is useful, much  
less cost-effective. The cataloging rules (AACR2, RDA) address some  
functionality (e.g. designing headings for an alphabetical view), but  
ignore most of it (e.g. how to provide searchable values for dates;  
how to code serials numbering for check-in services). I'm fine with  
the system functionality analysis being a second step in the process,  
but it has to be a step, and it has to be part of the same process  
that produces cataloging rules, for two reasons: 1) the rules may have  
to make some compromises in order to have the desired system  
functionality 2) the same catalogers who will be creating the AACR2 or  
RDA cataloging data are the ones who are creating the data that will  
be used by systems, whether added on to the cataloging rules or  
included with them.

I don't think we can go forward unless this step takes place, yet, as  
I've said before, we don't seem to have any organization or entity  
whose task this is. JSC isn't taking it on (and doesn't have the  
skills to); LC took it on for AACR/MARC, but seems unable to play that  
role today; the "publishers" of RDA are just that: publishers, not  
systems folks.

kc

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

---

From: Alexander Johannesen <[email-masked]>
Date: Wed, 21 Apr 2010 15:05:04 +1000

> Oh, please! http://www.loc.gov/marc/

Not sure what to make of that response. MARBI is suppose to pursue the
wonderfulness of MARC, no? Where is the framework I'm talking about?
Or even the idea of a framework rather than a few scruffy scripts? The
mind boggles.

Besides, I've talked about the absolute EVIL of MARC before, a timely
reminder for this discussion ;
   http://shelter.nu/blog/2008/09/marcxml-beast-of-burden.html

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

---

From: Weinheimer Jim <[email-masked]>
Date: Wed, 21 Apr 2010 09:38:42 +0200

Alexander Johannesen wrote:
<snip>
On Tue, Apr 20, 2010 at 23:02, Lundgren,Jimmie Harrell

Thanks for pointing to your blog posting, but I do have some problems. You write:

"<datafield tag="245" ind1="1" ind2="0">
  <subfield code="a">Arithmetic /</subfield>
</datafield>

I'll translate what this does for you;

<title>Arithmetic</title>

The MARC tag 245 means "title statement", and the code "a" means, uh, title. This perticular madness comes from the culture of MARC itself which I'll rant about some other time (and have in the past), so I'll try to stick to the pure XML part of it."

This isn't entirely true. 245$a means "title proper," which is a technical term that catalogers use. You can find the guidelines for it in the ISBD at 1.1 Title Proper:
http://www.ifla.org/files/cataloguing/isbd/isbd-cons_2007-en.pdf#page=37
Where you find several paragraphs defining it, stating what is and is not a title proper, and what is and is not included in it. Certainly non-specialists will find its meaning almost impossible to understand without a lot of additional work, and at difficult moments, catalogers themselves must return to this definition. Practically all parts of the bibliographic record are defined in these extremely precise ways. This is no different from how any other standard works in any endeavor. For example, without a lot of effort I cannot understand the standards for roofing materials or the requirements to be able to label a certain food as "Chocolate" (apparently, the standards for chocolate are more rigorous here in Italy than in other countries).

So, when a non-specialist says "title" it does not mean the same as when a specialist says "title," who immediately differentiates it in many ways and encodes it in the 245 field, one of which is the "title proper" which goes into the 245$a. So, in contrast to the others on this list who say that ISBD is a problem, I will say that the library world in very lucky in this respect because of the tremendous work done by our predecessors to create truly international standards based on the ISBD. Are they followed perfectly by everybody? Of course not.

The non-specialist may justifiably ask why titles are treated in such a seemingly arcane manner, but then would get entangled in a myriad of intricacies, just as would happen if I would ask why a certain standard exists for roofing materials. As a short answer to the title question, in addition to ensuring the correct identification of a specific item, these guidelines exist for some older reasons as well, such as filing order in the card catalog, so that, e.g.:
"War and peace : the definitive edition"
And
"War and peace in the nuclear age" 
Are not interfiled. 

I expect to get tomatoes hurled at me for pointing this out, but nevertheless, it is questionable whether people browse titles today as they did in the old days, and to be honest, every computer catalog I have used interfiles it anyway, along with all kinds of other strange interfiling practices. While this has often driven me crazy, the public has never seemed to notice it. So, perhaps this reason is no longer justified, but there are still plenty of other important reasons for retaining the title proper so it should certainly be retained.

This is why I say that specialist catalogers must be involved in these matters. We can't expect programmers to undertake a deep study of these bibliographic intricacies, just as I mentioned in an earlier post that a specialist cataloger can only become at best a semi-competent programmer. 

While I believe things need to change and simplify (which is not the direction of RDA, IMHO) it must be done with a clear understanding of what we have now, what could be gained and what would be lost. This is beyond the abilities of any one person or even one community of specialists. There is nothing wrong with this; it is just the way the world works.

---

From: Alexander Johannesen <[email-masked]>
Date: Wed, 21 Apr 2010 18:28:59 +1000

> The MARC tag 245 means "title statement", and the code "a" means, uh, title.
> This perticular madness comes from the culture of MARC itself which I'll
> rant about some other time (and have in the past), so I'll try to stick to the
> pure XML part of it."

Weinheimer Jim <[email-masked]> wrote:
> This isn't entirely true. 245$a means "title proper," which is a technical
>  term that catalogers use. You can find the guidelines for it in the ISBD
> at 1.1 Title Proper:

I love your rebuke; it's one of those instances where the layman gets
corrected by the expert in something the layman neither needs nor
cares about and writes extensively on why it is wrong to assume we
need that degree of specificry. I think there is a word for that. :)

However, it's a bit disturbing to be told that that's not entirely
true given I took the terms and definitions from the horse's mouth
(http://www.loc.gov/marc/bibliographic/bd245.html), where MARC21 would
be a given, which states "title statement" for 245 and "title" for
subfield "a". So if you can't even trust loc.gov official MARC
documentation without being corrected by a cataloger / librarian, how
on EARTH do you guys think the rest of the world, me and my laypeople,
will even bother trying to keep up with this madness?

Btw, the point of my post at that point wasn't to dig into the
specifics of that field, but point to the morbid lack of container
mentality found in MARC. And that in itself is odd given the rich
model it is based on, but then understandable given its age and lack
of development with the ages.

I should also decree that my post was more on MARCXML than MARC
itself, so maybe I gave off the wrong impression that I was generally
harping on MARC again when I was specifically harping on the XML
version.

> So, in contrast to the others on this list who say that ISBD is a problem, I
> will say that the library world in very lucky in this respect because of the
> tremendous work done by our predecessors to create truly international
> standards based on the ISBD. Are they followed perfectly by everybody?
> Of course not.

I'd say you've got bigger problems than that. What gives; MARC rules
and definitions, AACR2 rules and definitions, ISBD rules and
definitions. Any more? I know lots of countries have their own
additions, subtractions and completely new ones as well, some minted
on MARC or any other rule set they thought were up to snuff. Surely
this in itself must be seen as a problem? (Not the rules themselves,
but the way they're spread out, not validated, not merged, not easily
accessible, not easily understood)

> The non-specialist may justifiably ask why titles are treated in such a
> seemingly arcane manner, but then would get entangled in a myriad
> of intricacies, just as would happen if I would ask why a certain
> standard exists for roofing materials.

There's not that many sets of rules for roofing materials. There's
more sets of rules for roofing in general, but not for materials.
Maybe you meant the latter. Still doesn't compare, and maybe it's the
non-academic threshold that keeps the material to a mortal level. My
brother is a roofer. :)

> I expect to get tomatoes hurled at me for pointing this out

And deservedly so. Surely when someone points out the insanity and
complexity with the culture of MARC the right thing to do is not to
point out more madness and complexity?

> So, perhaps this reason is no longer justified, but there are still
> plenty of other important reasons for retaining the title proper so
> it should certainly be retained.

Because you say so? :)

> This is why I say that specialist catalogers must be involved in
> these matters.

It's no longer that we need to involve the specialist catalogers in
these matters; they need to involve themselves if these matters are
important. No one will actively involve and embrace costly people
where computers are taking over, it's a dead duck, a dead race, even
if it is wrong and evil and tragic. The only way to add the value of
those specialists back into the loop is by putting them right in the
design of our next gen tools. Get them out of the cellars and into the
IT section, pronto!

> We can't expect programmers to undertake a deep study of
> these bibliographic intricacies, just as I mentioned in an
> earlier post that a specialist cataloger can only become at
> best a semi-competent programmer.

Umm, of course we won't expect them to do so; what's the point? What
is the importance of these bibliographic intricacies, especially in
lieu of smarter software with full-text access? Sorry to be a
pessimist in these matters, but speaking as someone who works with AI,
semantic technology, full-text knowledge management and massive
recursive key-value distributed stores on a daily basis, you guys
don't stand a chance if you think that textual analysis is so
complicated you've got a job for life.

You have to realize that the reason you posses (a word more fitting
than I planned) your specialist knowledge is because you're part of a
community that created a system for finding stuff when all you had
were bits of paper in a filing-cabinet. The world of finding stuff is
turned upside down and inside out, and unless you sit down and try to
work out what you've got that is truly valuable in the new world (a
proper title for a blog post that carries quotations from an online
article that's different from the print version, where the blogger
rambles a bit in the title?), that new world will race past you, your
knowledge will be lost, and if there was any value to be found, it
will get forgotten and overlooked.

> While I believe things need to change and simplify (which is not the direction
> of RDA, IMHO) it must be done with a clear understanding of what we have
> now, what could be gained and what would be lost.

Agree 100%.

> This is beyond the abilities of any one person or even one community of
> specialists. There is nothing wrong with this; it is just the way the world works.

Agree 30%.

Of course a community of specialists can get together and form a
marvelous foundation upon which the future can carry on. It's happened
many times, and it will happen again. Heck, even an individual can
sometimes break down walls and change the future for the better.

Get crackin'!

Regards,

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

---

From: Weinheimer Jim <[email-masked]>
Date: Wed, 21 Apr 2010 11:32:01 +0200

Well, I have certainly been rebuked on this list several times for my lack of programming expertise and I've taken the rebukes to heart and try to learn from them, so I think my reaction was both fair and correct. :-) But on the other hand, when the layman neither "needs nor cares" about it, is that really the correct attitude? After all, a layman, by definition, doesn't know very much about it. I guess it depends on who the layman is. If the layman is just an interested spectator, that may be one thing, but if the layman is helping to build a house or something important, I think they should need and care to know about it.

<snip>

You just looked at the short summary. If you look down to the real definition in the MARC format guidelines (which are *not* the same as the cataloging rules), you will see:
"$a - Title
Title proper and alternative title, excluding the designation of the number or name of a part. Subfield $a also contains the first title of separate works (by the same or different authors/composers) in a collection lacking a collective title."
followed by lots of examples. This is probably almost incomprehensible to the casual observer. But again, these are *not* the cataloging rules.

<snip>
I'd say you've got bigger problems than that. What gives; MARC rules and definitions, AACR2 rules and definitions, ISBD rules and definitions. Any more? I know lots of countries have their own additions, subtractions and completely new ones as well, some minted on MARC or any other rule set they thought were up to snuff. Surely this in itself must be seen as a problem? (Not the rules themselves, but the way they're spread out, not validated, not merged, not easily accessible, not easily understood)
</snip>
And 
<snip>
Surely when someone points out the insanity and complexity with the culture of MARC the right thing to do is not to point out more madness and complexity?
</snip>

There are many more rules than that. When I worked at FAO of the UN, they have their own AGRIS rules, there are EAD rules, zillions and zillions of rules, and then other places that follow very few or no rules at all. Look at the vast majority of sites on Google with no rules whatsoever.

But it isn't the rules that make a simple matter complex, the rules are complex (to the layman, insanely so) because they attempt to do is complex: to describe and impose an order on all types of materials from all times and all places. These rules are to make a tool (a catalog) to be used by other experts, i.e. a library catalog is an expert system and librarians have never really worked to make it more friendly to the layman. Lots of training is needed before someone can use a catalog competently. (I have posted quite a bit about this and a change in librarian attitudes needs to take place, which I think is happening now)

I can say that things are not getting simpler with the web. Certainly there may be promising developments in AI but so far, I haven't seen anything workable and I don't have that kind of faith. To use tools such as Google for serious purposes is a nightmare.

<snip>

Because you say so? :)
</snip>

No, because other cataloger-experts around the world think so by working with ISBD. 

To discuss the other points in your message:

I agree 100% that we must work with full-text access and discover new methods for creating and accessing resources. RDA and FRBR do not do this in any way at all and are completely silent in this regard. So far as I know, RDA mentions ONIX crosswalks, which is a tiny fraction of what needs to be done, while a discussion of full-text access is ignored. 

This should cause no surprise since FRBR (the foundation of RDA) was written in the pre-Google days. It is one of the main reasons why I have been speaking out against implementing RDA. Nobody seems to be asking the obvious question: can a catalog record interoperate with full-text materials to improve access and improve the general understanding of the item(s) available? And if so, how? I don't know; I suspect it can. But if it is shown that a catalog record can improve matters, then we should continue creating them, while if it is shown that it doesn't improve matters, then there will be no value in continuing cataloging since it would add no value. That would be too bad, but we need to face facts, and besides I don't think that would be the result. It seems as if researches in these areas would be very interesting.

But still, description of a resource for reliable access is not and probably will not become an easy thing and I certainly have not seen it done automatically in any kind of satisfactory way yet. 

Concerning:
<snip>

Agree 30%.

And that is one reason why I initiated the Cooperative Cataloging Rules, to try to create a new "community." Still don't know if that one will fly.

Ciao,
Jim

---

From: Peter Schlumpf <[email-masked]>
Date: Wed, 21 Apr 2010 07:34:41 -0500

> sometimes break down walls and change the future for the better.

 Agree 110%

I will add that bringing in views from outside the community of specialists
is a good thing.  They offer something fresh.  The present ugly kludge that
is MARC is a product of inbred thinking and cruft accumulated over decades.
Such finely grained definitions of what a title is looks a little ridiculous
in the real world.  I see little of value in the byzantine complexity.

I would also add that a small group of specialists or an individual are best
suited to putting a real dent in the Universe.  They are more likely to
shake things up with new solutions that are elegant and hang together.  If
an idea is too complicted to wrap your mind around it, something is wrong.
Libraryland on the other hand seems to revel on committees, collectivist
thinking and complexity.  They talk and they talk, rehashing minutae and
picking nits while little gets done.  And what usually results is a
complicated ugly kludge that satisfies no one.

MARC and other tools seem to me to be designed by librarians for librarians,
and so they isolate themselves in an inward looking culture that reinforces
its own views.  Does MARC make it easier and simpler for the end layperson
to locate resources in today's world?  I don't think so.  Libraryland needs
to break out of this MARC mind-prison.  The longer it stays the further
behind it will be relative to the rest of the world.

And let's face it: It's all made up stuff anyway.  We're not dealing with
stone tablets here in any of this.

Peter Schlumpf

---

From: Bernhard Eversberg <[email-masked]>
Date: Wed, 21 Apr 2010 16:13:47 +0200

Peter Schlumpf wrote:
> shake things up with new solutions that are elegant and hang together.
So why did this not happen a long time ago? I remember to have put this
very question to a panel of experts, including Fred Kilgour, in 1976.
They said yes, a very good idea, and we got together about this indeed
and discussed it a lot and you know what? We re-invented MARC. Then in
1987 or so, I met Fred Kilgour again and said that Germany had not yet
adopted AACR and MARC. He said, "They better did". And now, they are
about to do it.

> If an idea is too complicted to wrap your mind around it, something is wrong.
So, quantum theory must be wrong. I beg your pardon. Einstein said, make
your theory as simple as possible, but not any simpler.

I'm absolutely not against new data models, I'd be delighted to see one
that surpasses MARC's usefulness by leaps and bounds. And I confess not
to have been able to find a new and fundamentally different and better
solution myself. So, I'm glad to let others take the lead.

Please, get real and present workable models. Find outside specialists
who can help with it. Rig up a sizable database to demonstrate the
new concepts and functions. Spread this word, everyone is welcome.
Everyone in this forum will be beside themselves with joy to see it.
You seem to be thinking we don't want new approaches. But believe me, I
have seen a few... We cannot, however, throw everything overboard. There
will have to be a migration. On second thoughts, to be free of
all those constraints, we might eventually be better off if we let
legacy data live where they are and start afresh with a new model just
for new data.

B.Eversberg

---

From: MJ Suhonos <[email-masked]>
Date: Wed, 21 Apr 2010 10:33:41 -0400

> legacy data live where they are and start afresh with a new model just

Bringing this back around to the subject (I just now realize how much of a misnomer "subject" is in email practice; but I digress..) of this thread, I'm in full agreement with Bernhard's statements above.

However, *will* everyone be ecstatic to see an approach built on a new model?  *Especially* if it involves throwing some things overboard, like MODS does (and I'm only using MODS to tie back in to our original topic)?  It seems to me that the most common objection I see to "new models" is when they involve a loss of information (usually "less precision") compared to MARC, as though that's some sort of terrible thing to be avoided at all costs.

There are certainly complex issues and use cases involved, and a new approach need not be simple in the sense of being crude.  But whether migration or separation, we *are* going to have to throw some (and perhaps many) things overboard.  The sooner some of us can let go of them, the more quickly we can sail to brighter shores.

MJ

---

From: Weinheimer Jim <[email-masked]>
Date: Wed, 21 Apr 2010 17:02:51 +0200

Peter Schlumpf wrote:

<snip>

While in many senses, I agree with this, bringing in new views must be done with care, otherwise they can also offer naivete. It's always rather easy to see a highly complex practice and proclaim that it should be gotten rid of. So, while it may seem ridiculous to have so many definitions of a title, you need to find out why. In this case, it is because that there really are so many different types of titles. This is one of those things you don't realize until you think about it more closely.

So, while it may seem that it is catalogers who are imposing a "Byzantine complexity" on materials that in themselves are clear, and therefore is just not worth the effort, from another point of view, catalogers state that we are imposing order and clarity upon materials that, in themselves, are essentially chaotic.

Now, once this is understood or at least accepted, the debate can begin. Do we want to lose this kind of control over the different types of titles? If so, what would be the consequences? And the small group cannot answer these questions on their own, since the only people who can know what the consequences would be are those who use your system. I am at least open to the possibility of dropping all of it, although I am skeptical.

Here is a concrete example of what may seem to be a small change can erupt into a huge complexity. One rule in subject cataloging is that you have one heading for one concept. In the 1990s LC decided for various reasons to change this excellent rule for the case of the "Soviet Union" when everything fell apart. Suddenly, there was a choice of three possibilities: Russia, Soviet Union, or Former Soviet republics. Seems small and simple enough--that is, until you had to do it.

Suffice it to say, these were some of the most mind-numbing complexities I have ever worked on in my life. We had some of the most experienced catalogers in the country perplexed. Finally, I made some guidelines myself, gave a workshop and then was asked to put it online in my Slavic Cataloging Manual (which I gave to ACRL and Indiana University) at: http://www.indiana.edu/~libslav/slavcatman/rsufsr.html If you want to see some of the complexities, read it.

Little changes can have huge consequences in a catalog. I agree there may be alternate solutions but care must be taken before introducing them.

---

From: Cory Rockliff <[email-masked]>
Date: Wed, 21 Apr 2010 11:11:51 -0400

On 4/20/2010 10:46 AM, Jonathan Rochkind wrote:
> realize what it entailed, and didn't take it seriously -- perhaps 
> until fairly recently.  FRBR needs/needed some work to do the job, and 
> it needs to effect the whole of how RDA is structured. Diane Hillman 
> is waging an epic struggle to make RDA take seriously the idea that (a 
Pardon my ignorance of efforts already underway, but what form is this 
epic struggle taking? Would FRBR formalization simply result in a model 
which will inform systems design, or is there more to it? And what about 
FRBRoo?

And on the question of schema vs. serialization format more generally: 
several people have voiced the opinion that what Jonathan is calling the 
'metadata schema' (I assume this is roughly synonymous with 'element 
set'?) is the hard part, and serialization should be trivial. But 
wouldn't the ability to generate a common transmission format without 
data loss be the criterion for compatibility between systems? Otherwise, 
how to judge to what extent systems have "implemented" a given 
conceptual model?

Maybe I'm getting caught up on terminology here.

---

---

From: Cory Rockliff <[email-masked]>
Date: Wed, 21 Apr 2010 13:19:23 -0400

In one way, the XC project seems to have come up with a sensible and 
pragmatic approach, perhaps the only one: in order to move forward, 
they've created their own patchwork scheme, incorporating elements from 
others where they exist. It's not meant to be theoretically rigorous, 
it's meant to be ugly, and work. The XC Metadata Services Toolkit is a 
platform for all kinds of transformation, and, crucially, exposes the 
transformed metadata at each stage of transformation.

But as Karen points out, this is all about transformation for use, not 
creation. The position XC is designed to occupy in the library workflow 
means that metadata continues to be created in a legacy format, then 
converted and served up on the fly. But what other choice is there, at 
this point? Here's where my "thought experiment" comes in. Actually, 
it's the situation I find myself in, so there's some self-interest 
here--but I think it's a valid thought experiment, anyway.

You're the technical services / systems librarian at a very small art 
research library (40k records). You can make virtually any decision you 
like as to cataloging policy, and, within certain budget constraints, as 
to systems choice and development. You're willing to roll up your 
sleeves and do some coding, but you're not a seasoned programmer. The 
size of your library means that you can spend some time massaging your 
data, and there aren't any veteran catalogers to yell at you. Even a 
suggestion as radical as abandoning LCSH for Getty vocabularies for 
general collections encounters no opposition.

What sort of a system do you put together, in the next year or so? There 
are things you'd like to do with your data which MARC, in its current 
state, can't do (e.g., record the source or URI of a controlled 
vocabulary term at the subfield level), and most existing tools are 
built around MARC. You're free to do what you like with the data, but 
library business processes must go on, in some fashion: serials need to 
be checked in by support staff, books need to circulate.

Is XC's approach (legacy ILS* > Metadata harvest & transformation > 
decoupled search interface) the only viable one in this scenario, or is 
there another model? Or even variations on the same model?

*And I'm including the open-source ILSes under this rubric, because 
they're not essentially different. Of course, an open-source ILS, unlike 
a proprietary one, could be re-engineered around a new data format, but 
that's probably beyond the abilities of our single librarian.

18 West 86th Street
New York, NY 10024
T: (212) 501-3037
[email-masked]

---

---

From: Alexander Johannesen <[email-masked]>
Date: Thu, 22 Apr 2010 10:26:20 +1000

On Wed, Apr 21, 2010 at 19:32, Weinheimer Jim <[email-masked]> wrote:
> But on the other hand, when the layman neither "needs nor cares" about
> it, is that really the correct attitude? After all, a layman, by definition, doesn't
> know very much about it. I guess it depends on who the layman is. If the
> layman is just an interested spectator, that may be one thing, but if the
>  layman is helping to build a house or something important, I think they
>  should need and care to know about it.

Well, in our case there is no mystery; it's librarians vs. everybody
else. The librarian domain is something that's in the interest of most
people, and as much as most people "needs or cares" about the reason
we have librarians and libraries, they don't give a monkey's bottom
about the minutiae of the twilight-zone between AACR2 and ISBD; that
stuff is only interesting to people who are several steps removed from
both reality and the evolution of information science. It's nonsense,
it's piffle, it's caring about where you put the life-guards flags up
on the beach when the tsunami hits. This stuff is something nobody
needs nor cares about, not anymore, except die-hard catalogers who
find some sadistic pleasure in rules and regulation that don't mean
anything to anyone else. They don't help us find things better;
they're not computer friendly. They don't aid in searching; they don't
aid in textual analysis. They don't help us build collections; they
don't capture knowledge. Why?! Why are you doing these things?!
Aaaaargh!

Yes! Yes, we understand they they perhaps *were* useful. But they no
longer are or are only now for just a few moments more, so if
catalogers value their arcane knowledge and would like to either have
a job or aid the human development of knowledge management (or both,
hopefully) they need to justify their knowledge in light of the
direction of the future, and definitely shape it accordingly. Saying
that some ways of doing meta data capture and markup is important
*doesn't*make*it*so* when it's so easy to point to computerized
alternatives. There's a reason Google and friends aren't employing
librarians en masse, and it's *because* the arcane knowledge within
means nothing when meta data value (as opposed to its content) can be
recreated better through computer analysis.

Yeah, yeah, you're all going to pipe up with how terrible computers
are at meta data harvesting. Get real, or you'll be out of a job. Take
a look at what's happening *right*now* with eBook websites popping up
and the same rate as the hundreds of eReaders. This is no game, this
is no fad, this is no temporary fashion statement; these are the very
real beginnings of what the future will look like. And when the full
texts are available, when publishers and writers of their own
materials gets tools with meta data capabilities, the job of
cataloging stuff will be on par with the level of which we today
catalog blogging; zilch!

What I just don't get is that catalogers and librarians know so darn
well how their knowledge is needed, how the future needs people who
can guide and help us all in through the informolasses, yet there's no
movement towards doing so on a grand scale! You all sit and dick
around with quibbles of whether to use MARC or MODS, and talk about
how FRBR and RDA fits into your world. I'll tell you how it fits into
*our* world;

Not at all.

...

> There are many more rules than that. When I worked at FAO of the
> UN, they have their own AGRIS rules, there are EAD rules, zillions
> and zillions of rules, and then other places that follow very few or
>  no rules at all. Look at the vast majority of sites on Google with
>  no rules whatsoever.

And friggin' frustrating bloody crazy stupid thing is that I find the
books I'm after through Google, not the catalogs! I do tons of
research all the time on all kinds of strange things. I give catalogs
the benefit of doubt *all* the time, I think, they've fixed them up,
they must have made them better, surly if I pop in just the right term
in the right field, I might get to where I want to go. But no, it
doesn't work that way, because the library infra-structure isn't
designed that way. The catalogs are to rigid to give good results on
fuzzy terms (and yes, I'll admit I'm a fallible human being rather
than a fully trained reference librarian!). For me these days, the
only thing the catalog is good for is to find a specific paper or book
that may or may not be found locally. But most of the time I'll find
it online for a could of bucks, or sent to me for keeps for cheap.
*shrug*

...

> And that is one reason why I initiated the Cooperative Cataloging Rules,
> to try to create a new "community." Still don't know if that one will fly.

And I support you all the way, but I wish you good luck because to me
it looks like the people you really need to jump on this are too stuck
their own backsides to notice.

Anyway, sorry to be in a bit of a ranting mood today. This
conversation is the same one I had when I begun my bibliophile life
all those years ago; nothing has really changed, except that OPACs
have been dragged up to a sub-par level with the tools everyone else
is using. We're still talking about MARC and AACR2 and RDA and FRBR
and MODS and all that technological nonsense that won't make a dent in
how people see the library. The internet has already changed
everything, and you're just too slow to keep up with it, to keep up
with technology. People will leave you behind and forget the culture
that shaped humanity and probably made us going into the information
age even possible.

So sorry, but this is depressing. I think I need to take some time off
again from the list. :)

Regards,

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

---

From: Bernhard Eversberg <[email-masked]>
Date: Thu, 22 Apr 2010 10:42:17 +0200

> there another model? Or even variations on the same model?
I understand you mean the XC schema as documented here:
http://www.extensiblecatalog.org/sites/default/files/fulltext/XCSchemaProperties20090107.pdf

Is that something more agreeable than MARC, in all those regards
addressed by the critics of MARC and cataloging?
Might this be a starting point for the radically new approach that is so
obviously and desperately needed?
But is this schema a data model? What are the entities, what
relationships are defined, how are they to be coded? What I see is just
a long list of elements, arranged in WEMI levels - what about the
other FRBR entities? And do the WEMI levels mean there have to be
separate records (or what?) for those 4 entities?
What, in other words, is the XC data model?

B.Eversberg

---

From: Weinheimer Jim <[email-masked]>
Date: Thu, 22 Apr 2010 10:51:18 +0200

<snip>
[...] they [users--JW] don't give a monkey's bottom about the minutiae of the twilight-zone between AACR2 and ISBD; that stuff is only interesting to people who are several steps removed from both reality and the evolution of information science. It's nonsense, it's piffle, it's caring about where you put the life-guards flags up on the beach when the tsunami hits. This stuff is something nobody needs nor cares about, not anymore, except die-hard catalogers who find some sadistic pleasure in rules and regulation that don't mean anything to anyone else.
</snip>

I encounter this type of reaction among non-specialists--which includes many librarians who have never done cataloging by the way--and I find it highly revealing. I would think it would be logical that if there is a general agreement among specialists that certain capabilities within a machine or a system are vital, there would be some level of respect paid to their experience; that although there may be many things that I, as a layman, personally do not understand, I should not conclude that I am in the midst of some type of conspiracy among members of a "modern guild" who are really only trying to retain a dead-hand control over processes and materials. It would be more logical to think that perhaps the knowledge this group has built up over the years and decades and even centuries is a type of collective wisdom that I do not know--and cannot know without a lot of work; that what they know and what they have specialized in over their entire careers should not be dismissed !
 out of hand.

When that specialized group is made up of mechanics, or bakers, or even computer programmers, a certain respect and deference is given to their expertise and experience, but this does not happen with cataloging. Everybody always knows better than a cataloger. To be fair, it has probably always been that way. Witness the scathing attacks Antonio Panizzi had to endure at the British Library in the early 1800s. In my research at Princeton University, I discovered that the creation and maintenance of the library's catalog was at first the responsibility of the university's president, who got tired of it; he delegated it to the faculty, where it deteriorated badly until the entire affair disintegrated altogether in the 1870s with one poor soul literally going insane(!). The faculty finally admitted defeat and inability to deal with it (! although they maintained it was lack of interest), and they hired their first real librarian. I still am in awe of the incredible knowledge and !
 abilities this man displayed, and his boundless ability for hard work. He is probably the greatest practical cataloger I have ever come into contact with.

The Google-type tools today seem to be easy but that is the way they are designed to *appear*. While these tools are incredibly useful and I use them all the time, the cataloger understands that this "easiness" is actually deceptive. So, if you do a search for "mark twain" or "world war i" or the memoirs of a fighter pilot during the invasion of Iraq, or whatever, the search seems to work because you almost always get something that makes you "happy." This is where it ends for the layman, but for the cataloger, it's only the beginning. For the cataloger, it is a very serious issue what people mean when they search something like "world war i" or "blacks" or "Dostoyevsky" and then instead of just making the searcher "happy," to relate that request in a reliable way to what they retrieve. This is not easy.

Research has shown and my 100% experience is that people "trust" the Google result, although it is totally a black box. I cannot know what is really in the "Google collection"; I cannot know the intricacies how Google ranks anything. All that is completely secret, rather like the guilds I mentioned above. Therefore, the Google result cannot be checked for reliability. Things are quite different in a traditional library catalog. The technical issues in this regard are highly involved and I have gone on too long already, but this is a complex matter and cannot be understood in five minutes, I assure you. 

The non-technician has never thought about any of this. When I do a Google search during reference work or in information literacy classes, I pause at the Google result and ask, "What are we looking at?" Nobody I have met has ever thought about what is contained in the Google result or why something is number one. This is an issue of prime importance: the retrieval of information that human beings can rely upon so they are not subject to a torrent of misinformation campaigns, spin and superstition. I think that's important.

Enough said on that, but this is a very sore point with many catalogers. While we are supposed to respect everybody else, everybody else can say we don't know anything at all and dismiss everything we say as backward and useless. Many take offense, although I am more open.

Now,
<snip>
What I just don't get is that catalogers and librarians know so darn well how their knowledge is needed, how the future needs people who can guide and help us all in through the informolasses, yet there's no movement towards doing so on a grand scale! You all sit and dick around with quibbles of whether to use MARC or MODS, and talk about how FRBR and RDA fits into your world. I'll tell you how it fits into *our* world;
</snip>

I think this is very well-said. Do we need change? Of course. Still, at some level we need to discuss nuts and bolts, and this is where I see the MARC-MODS, FRBR-RDA debate. We need deep and substantive changes and the current efforts are in the wrong direction, I completely agree. Still, I think that the foundational basis of cataloging remains as valid as ever and are definitely not supplied by the Googles and Yahoos and Mendeleys out there, although they may desperately try to convince us that people need nothing else. We need them and they need us.

It may take a few decades for people to realize they need specialized-librarian controls, however, much as it took the Princeton faculty quite some time to finally admit they just couldn't handle it. We'll see, but I hope it doesn't take that long.

---

From: Alexander Johannesen <[email-masked]>
Date: Thu, 22 Apr 2010 21:08:41 +1000

On Thu, Apr 22, 2010 at 18:51, Weinheimer Jim <[email-masked]> wrote:
> I encounter this type of reaction among non-specialists--which
> includes many librarians who have never done cataloging by
> the way--and I find it highly revealing.

Ugh, you missed my point entirely. I'm not saying we don't need
specialists. I'm saying what you're specialists in isn't relevant to
what the world wants, and unless that is changed, the world will make
sure those kind of specialists disappear.

> Still, I think that the foundational basis of cataloging remains as valid
> as ever

Why? I guess that's rooted in how you define those foundational things.

> and are definitely not supplied by the Googles and Yahoos and
> Mendeleys out there, although they may desperately try to convince
>  us that people need nothing else. We need them and they need us.

Prove it. With anything. Prove that anyone needs catalogers in any
meaningful or compelling way. Prove that they are relevant to what's
going on in the publishing and academic industries.

> It may take a few decades for people to realize they need
> specialized-librarian controls

James, you don't *have* two decades for this. This needs to happen now!

Regards,

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

---

From: Weinheimer Jim <[email-masked]>
Date: Thu, 22 Apr 2010 13:18:40 +0200

<snip>

How can I prove it?

How about this? Pretend that you are interested in the history of black people in agriculture in the United States. Tell me how you would go about searching and retrieving information in Google or Google Scholar or a related tool using full text. And I'm not even going to consider here the "quality" of the items, which is a related point.

We get questions like this every day.

---

From: Alexander Johannesen <[email-masked]>
Date: Thu, 22 Apr 2010 21:53:44 +1000

> How can I prove it?

I don't know, but the point is that if you can't prove it, you'll
disappear. It doesn't matter if posterity will find that you were
valuable. It doesn't even matter if your knowledge is valuable to
anyone; you must start proving it.

> How about this? Pretend that you are interested in the history
> of black people in agriculture in the United States. Tell me how
> you would go about searching and retrieving information in
> Google or Google Scholar or a related tool using full text.

Well, I pop "black people in agriculture in the United States" and get
back 1.3 million hits of which, one can assume, there is valuable
information. I go through them, and copy and paste into my research
document anything that smacks of gold.

And this satisfy your use case 100%; this is someone with an interest.
I have a better one for you;

I'm interested in beach ecology, but there's no such specific
taxonomical term, so it falls within oceanography, but most of that
deals with the ocean itself, not the edge. I need to find information
in the cross-roads between the Gerringong volcanic period and the
Hawkesbury Sandstone escarpment, and the beach ecology and geology of
the same area. Now *that* is an impossible task which even local
specialist librarians have failed to help me with. I have the
geological surveys of 1974 and 1961 (I think), but no information on
the area after, plus the Illawarra historic booklet of 1986 that has a
brief chapter on generic geological history.

And I'm sorry to say, but Google has found more relevant stuff than
any of the local libraries (and the NLA which I've also tried to
search through ... gets me the 1974 geological survey, but nothing
else)

And the thing is, if there *is* information out there and it gets
digitized, it *will* end up in Google rather than the library. Google
*will* find it, and you will not. Google gives me pictures of the
hexagonal columns on Bombo beach, they give me a map of their
whereabouts, it gives me info on what they are, and how old they are.
Libraries give me nothing. This isn't anymore about books or journals
or articles. It is about knowledge management.

Tell me more specifically why we need catalogers? What is their
purpose? What is their job? And just remember, I'm not some newbie pup
who don't know what catalogers do. I know all too well. I'm asking,
what is their purpose when the meta data record gets less important,
and links and free-texts more? Are you ready for this scenario? Are
you ready for this future?

Regards,

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

---

From: "Lundgren,Jimmie Harrell" <[email-masked]>
Date: Thu, 22 Apr 2010 08:24:15 -0400

Ugh, I'm not sure I accept your view as the ultimate definition of what the world wants. My recent experience in consulting with real world developers of user features of library catalogs is quite different. Examples? 

Users and public services librarians want icons displayed to visually cue users in on what kind of thing is being described such as book, online resource, dvd, map, etc. Assigning these icons automatically relies on details coded in the records. I fervently wish they were recorded more simply to support this function better and keep programmers from pulling their hair out, but at least they are recorded and can form the basis of this ad hoc user-friendly development in the online catalog. 

Facets allow users whose search strategies retrieved more than they want to individually examine to apply suggested limits to zero in on the items that will best serve their needs and desires. Facets are built ad hoc on elements of information recorded by catalogers in specific fields and subfields. 

There isn't anyone actually using true MARC in their systems as far as I know. It is simply a communication format that all the other systems already are able to translate through, right? (Unless you want to start over and personally catalog every item in your library you must import some of your records from somewhere, right?) One major block to replacing MARC is actually the bottom line. The expense of developing that specific translation capability in all those various systems for a new communication format, together with the failure of a professionally accepted replacement to have emerged so far are what has kept MARC in it's unique role in the information world. 

Catalogers have nothing to do with it. We will adapt and work with whatever comes along, as we have continually adapted to change after change in cataloging rules and in MARC formats since the introduction of online cataloging in the 1970's. I don't think we'll keep quiet about portrayals of the bibliographic universe or user needs as simple, however. 

Thanks and have a great day,
Jimmie  

Jimmie Lundgren 

-----Original Message-----
From: Next generation catalogs for libraries [mailto:[email-masked]] On Behalf Of Alexander Johannesen
Sent: Thursday, April 22, 2010 7:09 AM
To: [email-masked]
Subject: Re: [NGC4LIB] After MARC...MODS?

Regards,

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

---

From: Alexander Johannesen <[email-masked]>
Date: Thu, 22 Apr 2010 22:40:32 +1000

On Thu, Apr 22, 2010 at 22:24, Lundgren,Jimmie Harrell
<[email-masked]> wrote:
> Ugh, I'm not sure I accept your view as the ultimate definition of what the world wants.

Good!

> Users and public services librarians want icons displayed to visually cue
> users in on what kind of thing is being described such as book, online
> resource, dvd, map, etc.

This is terribly old hat, is in't? Never mind, the important question
is, how did you find out your users wants this? If the answer is
through some UX testing, then you're testing on the status quo, you're
not testing the future.

> Catalogers have nothing to do with it. We will adapt and work with
> whatever comes along, as we have continually adapted to change
> after change in cataloging rules and in MARC formats since the
> introduction of online cataloging in the 1970's.

Um, how are you going to adapt and work with whatever comes along, if
what comes along is something that eats catalogers for breakfast?

> I don't think we'll keep quiet about portrayals of the bibliographic
> universe or user needs as simple, however.

What do you mean here?

Regards,

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

---

From: "Mitchell, Michael" <[email-masked]>
Date: Thu, 22 Apr 2010 08:11:57 -0500

Ah yes. And if yours are an example of the people skills associated with Information Science then I'm sure you'll have no trouble moving the world into your corner. I think I'll keep this rant of yours to demonstrate the biggest difference between Library Science which is based on people and society and info sci which is basically math. And we know how much everyone loves math.
	You know my posts may sound simple and uninformed to someone outside of librarianship but I don't think the problems are actually too difficult to figure out. Info scientists can make some new digital tools and we librarians will adapt them and apply them to what we do in libraries. Info sci and librarianship are not one and the same and I don't believe they ever will or should be (despite some obvious overlap).

Michael Mitchell

-----Original Message-----
From: Next generation catalogs for libraries [mailto:[email-masked]] On Behalf Of Alexander Johannesen
Sent: Wednesday, April 21, 2010 7:26 PM
To: [email-masked]
Subject: Re: [NGC4LIB] After MARC...MODS?

Not at all.

...

...

Regards,

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

---

From: "Lundgren,Jimmie Harrell" <[email-masked]>
Date: Thu, 22 Apr 2010 09:24:10 -0400

No, the formal testing thing didn't quite happen yet partly because speed of the developments outstripped the capacity of the testing process, (by which I mean by the time the tests were scheduled and implemented the catalog had changed again). Input such as demand for new features and improvements to existing services comes from those people directly helping the users at the service desks and the chat reference services in the libraries at the 11 universities in our consortia, and through them from the users themselves. No, we weren't working from old hat assumptions or abstractions based on the flatly online world of Google. 

Eating catalogers for breakfast? What do you mean by that? Thanks,
Jimmie 

Jimmie Lundgren 

-----Original Message-----
From: Next generation catalogs for libraries [mailto:[email-masked]] On Behalf Of Alexander Johannesen
Sent: Thursday, April 22, 2010 8:41 AM
To: [email-masked]
Subject: Re: [NGC4LIB] After MARC...MODS?

Good!

What do you mean here?

Regards,

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

---

From: Bernhard Eversberg <[email-masked]>
Date: Thu, 22 Apr 2010 15:40:23 +0200

> So sorry, but this is depressing. I think I need to take some time off
Use it to construct a model, an implementation, some rules (hopefully
not necessary) for data entry, rig up a service that slaps all that open
source stuff together, then return to bask in our admiration and 
applause, and our sighs of relief from desperation.

B.Eversberg

---

From: Julie Hankinson <[email-masked]>
Date: Thu, 22 Apr 2010 11:25:09 -0400

There's a reason Google and friends aren't employing
ibrarians en masse, and it's *because* the arcane knowledge within
eans nothing when meta data value (as opposed to its content) can be
ecreated better through computer analysis.

Alex

You do remember the controversy at Google Books a while back, when it was found that books were dated as 1900 that shouldn't have been, that books by Sigmund Freud had someone else in the author field, etc, etc. That's why Google needs catalogers.

Julie Hankinson
Assistant Librarian/Cataloger
Benjamin Franklin Institute of Technology

Alex
You do remember the controversy over at Google Books where it was found that books were dated as 1900 that shouldn't have been, 
books by Freud had someone else in the author field, etc, etc. That's why Google needs librarians, to straighten the whole mess out.

---

From: Shirley Lincicum <[email-masked]>
Date: Thu, 22 Apr 2010 08:42:07 -0700

Recently posted on the code4lib mailing list:

> Also, a couple of people asked if Google is hiring.  Not only are we
> hiring large numbers of software engineers, but we're now seeking a
> librarian / software developer (below).  I'm happy to take questions
> about either.
>
> All the best,
> Will
> brockman@google
>
>
> Metadata Analyst
>
> Google Books is looking for a hybrid librarian/software developer to
> help us organize all the world's books.  This person would work
> closely with software engineers and librarians on a variety of tasks,
> ranging from algorithm evaluation to designing and implementing
> improvements to Google Books.
>
> Candidates should have:
> * An MLS or MLIS degree, ideally with cataloguing experience
> * Programming experience in Python, C++, or Java
> * Project management experience a plus, but not required
>
> This position is full-time and based in Cambridge, MA.

---

From: Julie Hankinson <[email-masked]>
Date: Thu, 22 Apr 2010 11:49:57 -0400

Maybe I should specify: that was Alex's quote--I was responding to it.

Julie

Julie Hankinson

-----Original Message-----
From: Shirley Lincicum <[email-masked]>
To: [email-masked]
Sent: Thu, Apr 22, 2010 11:42 am
Subject: Re: [NGC4LIB] After MARC...MODS?

 All the best,
 Will
 brockman@google

 Metadata Analyst

 Candidates should have:

---

From: Alexander Johannesen <[email-masked]>
Date: Fri, 23 Apr 2010 07:36:45 +1000

Guys,

I'm not impressed. My rant isn't designed to tick people off, nor to
say that you are all worthless and are going to die. Why haven't
anyone picked up the challenges and explained to me in no uncertain
terms why we need catalogers in the future? It's such a simple
question, you shouldn't be avoiding it, and there should be plenty of
easy answers.

Now, Julie's example of bad meta data in Google Books is a better one,
but it only takes us so far ; it exemplifies meta data that's easy for
folks and spot, and easy for Google to fix, just slap a report button
on there, and they'll fix it. This is 245$a stuff, the most used field
and subfield in meta data history.

This is trivial stuff. You don't need a cataloger and definitely not a
cataloging specialists for this sort of stuff. The question is why we
need those meta data / cataloging specialists? What part of the future
do they fit into?

(Btw, just because Google wants to hire one librarian does not mean
they're hiring en mass, which was my assertion)

Regards,

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

---

From: Cory Rockliff <[email-masked]>
Date: Thu, 22 Apr 2010 18:07:35 -0400

If we're talking about the descriptive drudgery that takes up far too 
much of catalogers' time today, I *hope* there's no future. Other skills 
in the cataloger's toolkit (classification, subject analysis, authority 
work) continue to be relevant, I think. "Universal" classification 
schemes such as LCC and Dewey may be approaching the end of their useful 
lives as the problem of ordering books on physical shelves becomes less 
important, but librarians could be well-placed to work on reconciling 
domain-specific vocabularies and weaving together disparate data sets. 
*Could* be.

Surely you have some of your own ideas about how catalogers could make 
themselves useful, though?

---

---

From: Thomas Krichel <[email-masked]>
Date: Fri, 23 Apr 2010 00:49:31 +0200

Cory Rockliff writes

> If we're talking about the descriptive drudgery that takes up far
> too much of catalogers' time today, I *hope* there's no future.
> Other skills in the cataloger's toolkit (classification, subject
> analysis, authority work) continue to be relevant, I think.

  I have done a lot of work in this area, but I don't need the 
  help of catalogers for it. I need subject experts and I need
  a good computer system that the subject experts can use. 

  There are a great many value-added services that can be constructed
  on the web, based on information that is already on the web. Think
  for example, about a system that would archive professional emails
  lists. Such a system could indentify contributions made by
  individuals across lists.  It would try to build threads by real
  subject rather than by email subject. It could visualize the
  relations between lists by topics, words used, contributors. It
  could archive the contents in a re-purposable form etc. This is just
  an example off the top of my head.

  Catalogers can't build such systems unless they know an
  instructional computer language and a bit of system administration.

  Cheers,

  Thomas Krichel                    http://openlib.org/home/krichel
                                http://authorclaim.org/profile/pkr1
                                               skype: thomaskrichel

---

From: Bernhard Eversberg <[email-masked]>
Date: Fri, 23 Apr 2010 08:52:36 +0200

> question, you shouldn't be avoiding it, and there should be plenty of
Easy answers? Obviously not.
This exchange is getting us nowhere, and don't we have to hammer it out
what an NGC will have to be and to do before we should think about
whether or not it will require catalogers to build it, and why and
what for? Who knows, it may require a very different bunch of people,
if any.
So let's finally put the horse before the cart and try to say what
an NGC will have to be and to do. Then, what data model it will
therefore need, and then how to implement it, and finally, what
intellectual input it will then need.

Why not start from a very broad list of the functions of
a catalog. Here is one, for you to pick apart or modify:

Produce reliable results

Clearly display differences

Bring together what belongs together

Present meaningful choices

Locate what users want

B.Eversberg

---

From: Alexander Johannesen <[email-masked]>
Date: Fri, 23 Apr 2010 16:57:09 +1000

> themselves useful, though?

Oh, for sure, plenty of ideas, but if there's one thing I've learned
over the years it is that librarians don't take outside hints nor
suggestions, so I'm desperately trying to at least trigger librarians
to do something themselves, to do their own thinking and reaction.
Creating awareness of what librarians don't really want to know about
seems to be important enough, and hopefully my stupid, over-dramatic
participation here could trigger the smallest trickle of progress.
That would make me happy. I don't have any library job to lose which
also adds to my communique, I can only lose the potential of my
reputation and clout which, realistically, isn't as valuable as what
I'm fighting for.

Anyway. Off to pry fighting kids off each other with a crowbar.

Regards,

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

---

From: Alexander Johannesen <[email-masked]>
Date: Fri, 23 Apr 2010 17:01:46 +1000

Ok, I'll bite, and then I'm going to leave ;

> Easy answers? Obviously not.

And that's a real shame; catalogers are the input to any catalog. If
the input doesn't reflect what we need in the output, then what?

> Produce reliable results

What's reliable?

> Clearly display differences

Differences between what?

> Bring together what belongs together

Based on the notion of what?

> Present meaningful choices

What does meaningful mean?

> Locate what users want

As opposed to what you've got? Or what they want which you *do* got?

This is not going to be easy. :)

Regards,

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

---

From: Bernhard Eversberg <[email-masked]>
Date: Fri, 23 Apr 2010 09:06:06 +0200

> Ok, I'll bite, and then I'm going to leave ;
Alex asked the obvious and necessary questions and at once understood it
ain't gonna be easy. Some progress.

My points were very broad ones, just headlines, and of course they need
substantiation.
Some of it is here:

http://www.biblio.tu-bs.de/allegro-test/formate/gz-1e.htm

B.Eversberg

---

From: Alexander Johannesen <[email-masked]>
Date: Fri, 23 Apr 2010 17:22:16 +1000

> ain't gonna be easy. Some progress.

No, no, that's taking it out of context. Creating your *list* isn't
going to be easy. Not only because of the language used, but because
we've all tried, both here on this list and elsewhere, for years to
create that list. My questions that should have simple answers are
about the profession of catalogers, and perhaps more specifically
specialist catalogers. If they cannot answer in fairly simple terms
what their future might or should be like, don't you think there's a
more serious underlying problem somewhere? I do.

But we can get back to the catalog, the mailing-list's ulterior
guiding light. The trouble is, I think, with a list that you just
gave, and perhaps pretty much most of the discussion we have here, is
that it always start with some reincarnation of a catalog. Why this
obsession about the catalog? Do you wanna know what the next
generation catalog is going to be? It's not going to be a catalog!

Anyway, just a clarification.

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

---

From: Weinheimer Jim <[email-masked]>
Date: Fri, 23 Apr 2010 09:39:48 +0200

Alex,

I think this exchange has been extremely valuable since it illuminates an area of genuine difference in the views of catalogers vs. programmers.

I tried to elicit a real-life example with my request for how someone should go about finding information on a specific topic. This happens thousands of times every day when people ask a reference librarian to help them find specific types of information. If you are only mildly interested in a topic, it's one matter, but if you are trying to write a paper for class, or keep from looking like a fool when talking on topics with others who may be experts, you take a more serious approach. 

Students have tremendous problems with this as they progress in their studies at university. Research has shown that some 80% or more people rate their searching abilities as "very good" or "expert". And they may be, for a mundane task such as finding the height of Mt. Everest, getting somebody's email address, or finding and buying a new Ipod on Amazon.com. (More or less what librarians term "ready reference") But once they are confronted with the task of finding information for a class paper--even on extremely simple topics such as the one I gave you--they discover they are helpless and don't know anything at all. They don't know where to begin; they don't know how to end; they don't know anything except to type different words into a box and it's not working.

This is when they come to the reference librarian for help, and in my experience, they are more or less in a state of shock and totally panicked. This makes the librarian's job *especially difficult* since your number one task is to calm them down. Still, I think a lot of their panic is from suddenly having to face the undeniable fact that in a realm where they believed they were experts, it has become frighteningly obvious that they don't know what they are doing at all.

One thing that traditional librarians always had--and yes, I am bringing up that dreaded *past* again! :-) -- was the control in a library catalog. They knew that within specified limits, and those limits were clearly laid out, they really could find *all books* by Dostoyevsky in the local collection, no matter in what language or how his name appeared in the item. This is something you--let me be very clearly about this--you *absolutely, positively, cannot do* using only full-text tools. 

So, the library catalog has always been arranged conceptually (an error shown in the statements of many non-catalogers who discuss our "textual strings" and ignore their conceptual purpose), and therefore, within known parameters, you can find "everything" about the concept "cats" in a library catalog. See for example, this search in LC's catalog with some very nice suggestions for other searches:
http://catalog.loc.gov/cgi-bin/Pwebrecon.cgi?DB=local&Search_Arg=cats&Search_Code=SUBJ_&CNT=100&hist=1

Browsing in this way shows clearly what is available in the LC catalog on cats and even provokes the searcher at times with the unexpected, e.g. Cats--Caricatures and cartoons, or Cats--Humor, or Cats--Psychic aspects. This is how a catalog is arranged: by concepts, and how it is supposed to work. When I have shown people how it works, they find it quite powerful and extremely fast. Also, with our conceptual controls, we can separate the concept "cats" from other conceptual entities that are not related but use the same text, e.g. Cats & a Fiddle (Musical group), Cats & dogs (Motion picture) Cats & Jammers (Rock group) and so on. Try searching Cats in Google (it would probably be best to turn on the Safe Search, but perhaps not) and compare it to the subject search in LC and with an open mind, consider if the Google result is anything that could be useful or merely chaotic.

Google and other full-text tools do not have this kind of control, and librarians miss those controls a lot, I assure you. This is why experienced librarians often look askance at the new tools.

What I just outlined is becoming lost knowledge, especially so among the public, but also increasingly among younger librarians. But I submit that ignoring these controls that *are not replicated anywhere else* or dismissing them out of hand actually limits our imagination as to what can be done.

The method I sketched above (which becomes far more complex in practice) is hopelessly obsolete in many ways that I won't go into here, and this I readily admit, but the control it provides is not.

The future I foresee that would be best for our users is not to abandon the controls found in a catalog but to adapt them for the current "user needs" (whatever they are determined to be, and not those determined in FRBR), perhaps dumping some things, and working with the additional access provided through ever-improving full-text searching capabilities.

Perhaps someday, the conceptual work done by human catalogers can be done automatically by machines. But nothing I have seen makes me think it will happen anytime soon. If our controls should vanish, and this may be a possibility with the economic crisis and the generalized view of "traditional cataloging = continued obsolescence," it will impoverish us all.

---

From: Peter Schlumpf <[email-masked]>
Date: Fri, 23 Apr 2010 08:08:35 -0500

On 4/23/10, Weinheimer Jim <[email-masked]> wrote:
>
> Alex,
>
> I think this exchange has been extremely valuable since it illuminates an
> area of genuine difference in the views of catalogers vs. programmers.

I agree 100 per cent.  This has been the most valuable discussion I have
seen on here for a long time, perhaps ever.  Valuable not only in
illuminating the differences in the thinking between catalogers and
programmers, but also in asking challenging questions that finally get down
to the meat of what a catalog really is, or could be (I hesitate to use the
word "should" because that implies there's only one correct way).

I think neither view entirely wrong.  Each side is looking at it through
their own lens.  There are advantages and disadvantages to a very
semantically structured system as there are advantages and disadvantages to
full-text searching systems.  I would say a big disadvantage to full-text is
that search results are noisy.  This is because it treats content as dead
data.  Matching patterns in strings basically.  A semantically structured
system deals in concepts and how they relate to eachother -- not just a pile
of bytes.

What could be helpful is to throw off the MARC blinders and the programming
and computer blinders.  Consider what a catalog really is in an abstract
form without MARC or  computers or even books.  Sort of a general theory.
Can we do that?  Has someone ever done that?  Perhaps on that level we can
have an improved discussion.

Bernhard Eversberg issued this challenge:

"Please, get real and present workable models. Find outside specialists
who can help with it. Rig up a sizable database to demonstrate the
new concepts and functions. Spread this word, everyone is welcome.
Everyone in this forum will be beside themselves with joy to see it."

I'm seriously taking him up on that.  I am working on an idea that I have
been kicking around for many years.  It's a generalised semantic mapping
system -- sort of a database of pure relationships between objects.  The
objects in this "database" could be anything:  Books, patrons, indexes,
concepts, URLs, images, whatever; but the objects reference only indirectly
to what they represent.  I am developing this thing without reference to
MARC or even database concepts.  I have a crude prototype.  I hope that
within a month or so I can present to this group a clearer fleshed out
explanation of what this thing is, what it can do, and perhaps even provide
a working example.

Peter Schlumpf

---

From: Bernhard Eversberg <[email-masked]>
Date: Fri, 23 Apr 2010 16:22:19 +0200

Peter Schlumpf wrote:
> ...  asking challenging questions that finally get down
It is not about finding "one correct way", I think.
There are those functions to consider that libraries, and their catalogs
in particular, have fulfilled to this day. Starting with a blank slate
has its appeal, certainly, but then at least we have to say whether or
not this or that heritage functionality is obsolete or not.
The modernized Cutter "objects", with the austere lettering of "FRBR"
on the spine, are certainly running pitifully short of a
comprehensive description of a catalog's duties, but cannot be
dismissed out of hand, or regarded a mere historic footnote either.

Whether we still call the beast a "catalog" at the end of the day
is immaterial. But where do we get if we are not also trying to
reach consensus about a few things we'd definitely want to see in
a library catalog? Why this forum then?

B.Eversberg

---

From: Todd Puccio <[email-masked]>
Date: Fri, 23 Apr 2010 11:06:37 -0400

-----Original Message-----
From: Next generation catalogs for libraries
[mailto:[email-masked]] On Behalf Of Alexander Johannesen
Sent: Thursday, April 22, 2010 5:37 PM
To: [email-masked]
Subject: Re: [NGC4LIB] After MARC...MODS?
Guys,
I'm not impressed. My rant isn't designed to tick people off, nor to
say that you are all worthless and are going to die. Why haven't
anyone picked up the challenges and explained to me in no uncertain
terms why we need catalogers in the future? It's such a simple
question, you shouldn't be avoiding it, and there should be plenty of
easy answers.
...
This is trivial stuff. You don't need a cataloger and definitely not a
cataloging specialists for this sort of stuff. The question is why we need
those meta data / cataloging specialists? What part of the future do they
fit into?
Alex
alexander.johannesen ---

Mr. Johannesen,
What you seem to not realize is that these are the same people that will do
the work in the new environment.  Or more to the point the same "kind" of
people.

Point 1 : The same folks that obsess over ISBD are the same people that have
the minds and experience for the complex subject analysis; that have the
same minds to learn new meta-data schemes.  Yes, they are slow to change
once invested, but we are talking about the same folks.  

Point 2 : Experience has shown that over time any new meta-data scheme will
digress into increasing complexity. There will be calls for standardization
and the creation of entrenched specialists.  I can't seem to find any
experts in Panizzi's "91 Rules" anywhere these days.  They retired, or died,
or learned the new rules and formats.  But, they were still cataloging
specialists; and so are we.  
	We are part of the same line of a proud tradition that is dedicated
to maintaining metadata so that it can be preserved and accessed by users in
a useful way. 

--
Todd Puccio
Director of Technical Services / Librarian
Nova Southeastern University
Health Professions Division Library
3200 S. University Drive
Ft. Lauderdale, FL 33328
(954)262-3114 or ext 2-3114

[email-masked]

---

From: "B.G. Sloan" <[email-masked]>
Date: Fri, 23 Apr 2010 08:10:15 -0700

Jim Weinheimer said:
 
"Students have tremendous problems with this as they progress in their studies at university...once they are confronted with the task of finding information for a class paper...they discover they are helpless and don't know anything at all. They don't know where to begin; they don't know how to end; they don't know anything except to type different words into a box and it's not working...This is when they come to the reference librarian for help."
 
I don't know about that last sentence. I'd bet that a relatively small percentage of students working on papers actually approach a reference librarian for help finding resources when they run into problems. I bet most just keep plugging away, typing different words into a box until they find something that's "good enough" for them.
 
Bernie Sloan

--- On Fri, 4/23/10, Weinheimer Jim <[email-masked]> wrote:

---

From: Todd Puccio <[email-masked]>
Date: Fri, 23 Apr 2010 11:45:52 -0400

Jim Weinheimer said:
 
"Students have tremendous problems with this as they progress in their
studies at university...once they are confronted with the task of finding
information for a class paper...they discover they are helpless and don't
know anything at all. They don't know where to begin; they don't know how to
end; they don't know anything except to type different words into a box and
it's not working...This is when they come to the reference librarian for
help."
 
I don't know about that last sentence. I'd bet that a relatively small
percentage of students working on papers actually approach a reference
librarian for help finding resources when they run into problems. I bet most
just keep plugging away, typing different words into a box until they find
something that's "good enough" for them.
 
Bernie Sloan

Yes, and this is why Librarians are considered Faculty at major
universities.  
They are part of the educational and teaching process. 
University Librarians are not the same as food court counter clerks at the
student union serving up books and information on a plastic tray.

When a student goes to a university for an education, learning how to do
research is part of what they are there for.
There usually isn't a course for it.  It is part of the indirect learning a
student must go through.  
"Learning how to learn."  Gathering the skills that will earn them the
"Rights and Responsibilities" that their degree confers upon them.

Students that use "good enough" resources and not seek the expertise and
instruction of a librarian will have research that withers and dies.  This
will separate the excellent students from others.

It is the same in life & work. We all must learn how and who we must consult
to gain the knowledge, information and expertise that we lack.

---

From: Julie Hankinson <[email-masked]>
Date: Fri, 23 Apr 2010 12:09:17 -0400

Cory

Physical books will never go away completely, even though e-books are catching on more and more. Also, you do need traditional classification schemes for e-books as well as physical books, don't you?

Julie Hankinson

-----Original Message-----
From: Cory Rockliff <[email-masked]>
To: [email-masked]
Sent: Thu, Apr 22, 2010 6:07 pm
Subject: Re: [NGC4LIB] After MARC...MODS?

If we're talking about the descriptive drudgery that takes up far too much of catalogers' time today, I *hope* there's no future. Other skills in the cataloger's toolkit (classification, subject analysis, authority work) continue to be relevant, I think. "Universal" classification schemes such as LCC and Dewey may be approaching the end of their useful lives as the problem of ordering books on physical shelves becomes less important, but librarians could be well-placed to work on reconciling domain-specific vocabularies and weaving together disparate data sets. *Could* be. 
 
Surely you have some of your own ideas about how catalogers could make themselves useful, though? 
 
> they're hiring en mass, which was my assertion) 
-- Cory Rockliff 
 
---

---

From: "B.G. Sloan" <[email-masked]>
Date: Fri, 23 Apr 2010 09:15:27 -0700

Todd Puccio said:
 
"When a student goes to a university for an education, learning how to do research is part of what they are there for. There usually isn't a course for it.  It is part of the indirect learning a student must go through."
 
My youngest son struggled during his first semester at the University of Utah, so he enrolled in an Ed Psych "how to succeed in college" course in the second semester. In one component of the course an instruction librarian from the University's Marriott Library taught the students how to use the library. I don't know who this instruction librarian was, but I think he was a miracle worker. Prior to this class my son relied on me to help him find resources for papers. After this class my son never once asked for help, and would occasionally use phrases like "boolean searching" in casual conversation. :-)
 
Too bad classes like this one aren't required in a student's first semester. It's a shame that colleges and universities force students to learn this through "indirect learning".
 
Bernie Sloan

--- On Fri, 4/23/10, Todd Puccio <[email-masked]> wrote:

From: Todd Puccio <[email-masked]>
Subject: Re: [NGC4LIB] After MARC...MODS?
To: [email-masked]
Date: Friday, April 23, 2010, 11:45 AM

Jim Weinheimer said:

 
Bernie Sloan

---

From: "B.G. Sloan" <[email-masked]>
Date: Fri, 23 Apr 2010 09:32:28 -0700

Todd Puccio said:
 
"Students that use 'good enough' resources and not seek the expertise and instruction of a librarian will have research that withers and dies.  This will separate the excellent students from others."
 
I'm not sure about the "wither and die" part. I was assuming that Jim W was referring to undergrads when he said "This is when they come to the reference librarian for
help." It's my impression that there are a fair number of undergrads who use "good enough" resources to write "good enough" research papers, and get grades "good enough" to graduate and get decent jobs.
 
Bernie Sloan

Jim Weinheimer said:

 
Bernie Sloan

---

From: Thomas Krichel <[email-masked]>
Date: Fri, 23 Apr 2010 21:39:08 +0200

Julie Hankinson writes

> Physical books will never go away completely,

  "There will always be books", is like saying there will always
  be horses. Yes, there are still horses but are they a serious
  means of transport?

  Cheers,

---

From: Janet Hill <[email-masked]>
Date: Fri, 23 Apr 2010 13:49:29 -0600

Actually, your approach is almost guaranteed to cut off conversation and
discussion rather than stimulate it.   Perhaps that's why so few have picked
up your dismissively thrown gauntlet.  It may be that your experience of
librarians not "picking up outside hints" has more to do with you than them.

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-----
Sent: Friday, April 23, 2010 12:57 AM

Regards,

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

---

From: Laval Hunsucker <[email-masked]>
Date: Fri, 23 Apr 2010 12:56:31 -0700

For what it's worth -- classification and subject 
analysis are in my ( long ) experience precisely 
examples of things that cataloguers are *not* 
good at ( as opposed to, e.g., authority work ).
They're the ones who got us into the subject/
classification mess wherein we now often find 
ourselves.

And one should *never* turn librarians loose on 
domain-specific vocabularies -- unless they are, 
of course, real practicing domain specialists 
themselves. And one of the laws of nature is that 
they in that case are more unlibrarians than they 
are librarians -- whoever it is who signs their 
paychecks.

- Laval Hunsucker
   Breukelen, Nederland

----- Original Message ----
From: Cory Rockliff <[email-masked]>
To: [email-masked]
Sent: Fri, April 23, 2010 12:07:35 AM
Subject: Re: [NGC4LIB] After MARC...MODS?

-- Cory Rockliff

---

---

From: Cory Rockliff <[email-masked]>
Date: Fri, 23 Apr 2010 16:01:51 -0400

> Physical books will never go away completely, even though e-books are catching on more and more. Also, you do need traditional classification schemes for e-books as well as physical books, don't yo…

I'll refer you to Clay Shirky's "Ontology is Overrated," if you haven't 
read it--in particular, the bit about library classification schemes: 
<http://www.shirky.com/writings/ontology_overrated.html#of_cards_and_catalogs>

The point is, traditional schemes like LCC continue to be used, despite 
preserving what is now often a laughably out-of-date worldview, because 
the biases of the scheme itself don't matter all that much. Why? The 
reader's interaction with the scheme is generally limited to the 
flattened classification numbers it generates, which serve simply to 
order physical books from left to right on shelves, grouping them in 
such a way as to facilitate browsing.

As soon as the open shelf disappears, through the relocation of physical 
books to remote storage, where there are far more efficient methods for 
automated retrieval than a topical classification scheme, or to the 
digital realm, a scheme like LCC no longer serves the same role. 
Realistically, will we continue to make use of a scheme like LCC, even 
in this scenario? Quite possibly--for all its quaintness, it's still a 
very robust ordering system. In fact, we could be leveraging the 
knowledge encoded in LCC (e.g., the textual captions) to provide a much 
richer search experience *right now.* Do we *need* a traditional, 
shelf-oriented, monohierarchical classification scheme to provide access 
to digital full text? I don't think so. My comment was about the 
relevance of cataloger skills, not the longevity of current cataloging 
practices.

---

---

From: Cory Rockliff <[email-masked]>
Date: Fri, 23 Apr 2010 16:07:22 -0400

Of course, let's not forget the possibility that our infrastructure 
falls apart. Paper books, in the appropriate climate, suffer benign 
neglect far more gracefully than server farms do--it could be that at 
some point in the not-too-distant future, we'll be very glad we still 
have our paper books. And our horses. :)

---

---

From: Laval Hunsucker <[email-masked]>
Date: Fri, 23 Apr 2010 14:13:12 -0700

> Creating awareness of what librarians don't 
> really want to know about seems to be 
> important enough, and hopefully my stupid, 
> over-dramatic participation here could trigger 
> the smallest trickle of progress.

Could -- but I wouldn't recommend betting the 
family silver on it.

- Laval Hunsucker
   Breukelen, Nederland

----- Original Message ----
From: Alexander Johannesen <[email-masked]>
To: [email-masked]
Sent: Fri, April 23, 2010 8:57:09 AM
Subject: Re: [NGC4LIB] After MARC...MODS?

Regards,

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

---

From: Laval Hunsucker <[email-masked]>
Date: Fri, 23 Apr 2010 14:14:36 -0700

> The same folks that obsess over ISBD are 
> the same people [ A ] that have the minds 
> and experience for the complex subject 
> analysis; [ B ] that have the same minds to 
> learn new meta-data schemes.

[ A ] :  Agree 0 %

[ B ] :  Agree +/- 100 %

- Laval Hunsucker
   Breukelen, Nederland

----- Original Message ----
From: Todd Puccio <[email-masked]>
To: [email-masked]
Sent: Fri, April 23, 2010 5:06:37 PM
Subject: Re: [NGC4LIB] After MARC...MODS?

-----Original Message-----

Mr. Johannesen,

[email-masked]

---

From: Alexander Johannesen <[email-masked]>
Date: Sat, 24 Apr 2010 07:15:18 +1000

On Sat, Apr 24, 2010 at 05:49, Janet Hill <[email-masked]> wrote:
> discussion rather than stimulate it.

My approach? Dear Madam, but what exactly is my approach? And how am I
getting worse results than other means? I've been on this list since
its inception, I've been working in the library, I've worked outside
of it. I'm a technologist, and a former wannabe librarian. Some days I
take it nice and easy and enjoy the molasses, other days I've fed up
with no progressiveness. My approach is guaranteed to do absolutely
nothing in particular; *you* only react to and see what happens here,
*I* also get reaction and see what happens in private exchanges with
librarians. There's more than one side to this "approach" you seem to
deem judge so poorly. I suspect the thing you dislike with "my
approach" is being too honest about certain things, and heck, yes, you
and many librarians indeed hate confrontation and strong opinions. And
yes, I know I'm stepping on someone's toes through being so strident.
Tough, but I make no apologizes for being passionate about libraries.

>  It may be that your experience of

Yes, I was expecting "the problem is you" from you. And in your world,
I'm sure you're right.

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

---

From: Laval Hunsucker <[email-masked]>
Date: Fri, 23 Apr 2010 14:16:05 -0700

You don't have to bet, Bernie. This is indeed 
what ( quantitative ) research has shown.

The alternative scenario is in essence our own 
construction ( a.k.a. wishful thinking 
).

Coming to a reference librarian ( physically or 
virtually ) for real substantive help is one of 
the least favored options ( understandably, I 
dare say ).

- Laval Hunsucker
   Breukelen, Nederland

----- Original Message ----
From: B.G. Sloan <[email-masked]>
To: [email-masked]
Sent: Fri, April 23, 2010 5:10:15 PM
Subject: Re: [NGC4LIB] After MARC...MODS?

Jim Weinheimer said:

 
Bernie Sloan

---

From: Alexander Johannesen <[email-masked]>
Date: Sat, 24 Apr 2010 07:19:16 +1000

>> hopefully my stupid,

> Could -- but I wouldn't recommend betting the

That's either / or a call of despair, or a call to go away.

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

---

From: Laval Hunsucker <[email-masked]>
Date: Fri, 23 Apr 2010 14:20:47 -0700

Todd's post is a good example -- but admittedly 
a rather advanced case -- of what I meant just now 
by  wishful thinking. Pretty much out of sync with 
all reality of which I'm aware. ( Though Nova 
Southeastern could theoretically constitute a weird 
exception to the general state of affairs. )

- Laval Hunsucker
   Breukelen, Nederland

----- Original Message ----
From: Todd Puccio <[email-masked]>
To: [email-masked]
Sent: Fri, April 23, 2010 5:45:52 PM
Subject: Re: [NGC4LIB] After MARC...MODS?

Jim Weinheimer said:

 
Bernie Sloan

---

From: Laval Hunsucker <[email-masked]>
Date: Fri, 23 Apr 2010 14:36:30 -0700

> That's either / or a call of despair, or a call 

Oh no -- stick around. And despair ?  We've 
certainly learned to live with that by now.

- Laval Hunsucker

----- Original Message ----
From: Alexander Johannesen <[email-masked]>
To: [email-masked]
Sent: Fri, April 23, 2010 11:19:16 PM
Subject: Re: [NGC4LIB] Again Re: [NGC4LIB] After MARC...MODS?

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

---

From: Alexander Johannesen <[email-masked]>
Date: Sat, 24 Apr 2010 07:45:06 +1000

> the work in the new environment.  Or more to the point the same "kind" of

Huh, I don't realize this? Are you kidding me? I used to create tools
for specialists catalogers, so i have a pretty good idea of who they
are and what they're up to. I eat EADs for breakfast for heavens sake,
a sad skill I can't seem to unlearn!

> once invested, but we are talking about the same folks.

You don't seem to realize that the tools that were needed for
cataloging books and physical objects in no dramatic way will resemble
the tools needed for knowledge management and electronic resources
(into which books in general now are poured). Even classification
schemes works differently, because computers finally give you the
power you needed in the first place to get it right. The trifecta of
current LCSH and similar schemes, the very notion that a hit is a hit,
is not only missing important information, it is wrong in its
conceptual design! Analysis and the concept of "near misses" are
*paramount* in finding information. Making computer systems more in
tune with human fuzzy nature while applying relevance is the key. Any
selection of subject headings on a book by their very nature make sure
some will find it and some will not. Computers now allow people to
find similar items through subject heading analysis, something
catalogers - specialist or not - cannot help with. (Just to pick on
one thing)

> digress into increasing complexity.

Yes, which is why a lot of people are moving away from schemas (in the
rigid sense). Karen Coyle and friends are doing FRBR and RDA in RDF,
and popping your former schema through SKOS with a more abstract
definition *solve* that particular problem. (Yes, a thesaurii can be
used for more than just thesaurii; it can work as a meta schema) Me,
I'd love to see you do serious modeling without field mentality, so
that you can remove the cruft that doesn't seem to work, but
librarians don't think in such fuzzy ways, so I realize that's a dud.

> I can't seem to find any

There once used to be a proud profession of the blacksmith, making
horse-shoes and all sorts of things for pretty much everyone, because
everyone had a horse or more. Today these people work mostly in theme
parks. And there's nothing wrong with it, and it's still a proud
profession. Just not very relevant to society at large.

But what's your point here? Do we *need* the 91 rules, are there still
tons of materials using these rules, were they good rules, would they
be good rules for the future, what? And if there are, then the problem
isn't the rules nor not finding the people involved; the problem is
the deep structure of how cataloging have been done. The point here is
that by looking at all of these rules and schemas together I can
understand some things, while other things are too cryptic ; there are
fundamentals and there are particulars. The specialists are always
specialists in particulars, and to me, all cataloging issues lies in
the twilight zone between the two.

> to maintaining metadata so that it can be preserved and accessed by users in

Yes, absolutely, and no one is saying a single bad word about that.
But I'm specifically talking about the future, about now when meta
data isn't about physical items anymore, when computing power is able
to satisfy your every wet dream, and when society has too much
information to feel comfortable with. In this time when we *need*
experts on meta data we *also* need to recognize that the shape of
what meta data is has changed, that methods for finding has
topsy-turvied, that the purpose of the items have changed, that
society is different. Yes, these things have always changed, I'll
agree with that, but it has changed so fast this time that the library
culture has been rendered somewhat irrellevant. I don't want to see
them rendered completely irellevant, but for the libraries to do that
needs to be committed to these new ways far quicker than they seem to
be doing.

Anyway, I'm picking up just too much negative slag again. Time for a break.

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

---

From: Janet Hill <[email-masked]>
Date: Fri, 23 Apr 2010 16:13:47 -0600

Since you asked -- your approach, through this thread at least, has appeared
to me to be combative and dismissive.  You deem it "honesty".  Others deem
it "condescending".  Passion is good.   Stridency is not helpful.  Strong
opinions are good, but not as weapons.  Radical ideas are good, but not as
dares.  Real progress in a system as laden with inertia as ours demands
cooperation among and participation by many.  Positions stated in a manner
that drives people away from genuine exchange does not engender the
cooperation, participation, thought, and invention and progress that you so
fervently desire.  

Janet Swan Hill, Professor
Associate Director for Technical Services
University of Colorado Libraries, CB184
Boulder, CO 80309
[email-masked]
     *****
"The thing about democracy, beloveds is that it is not neat, orderly, or
quiet.  It requires a certain relish for confusion."  Molly Ivins

-----Original Message-----
Sent: Friday, April 23, 2010 3:15 PM

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

---

From: Alexander Johannesen <[email-masked]>
Date: Sat, 24 Apr 2010 13:19:58 +1000

Oh, my sweet, sweet Janet,

Janet Hill <[email-masked]> wrote:
> Since you asked --

It was a couple of rhetorical questions, but don't let that get in the
way of going for the man rather than the challenges put forth.

> your approach, through this thread at least, has appeared

Let me make something perfectly clear, something that's been on my
mind for a long time and that I feel is probably as important in any
of these discussions as any of the open threads ;

All through my many years of engaging with the library world there is
one strong common phenomena that keeps me coming back for more, and
that is that people like me who voice their opinion in here a bit
louder and harsher than the hushed levels librarians normally enjoy,
we (well, I) get tons and tons of private mails from other librarians
write letters of appreciation and thanking me for saying what
sometimes needs to be said (and sometimes needs to be said in a strong
way). These are in general people who prefer not to engage in voicing
opinions against the library administration, who dare not open their
mouth in fear of people like you, because you're the professor, and
they are not. I'm not merely blabbering about stupid things no one
cares about, or daring people into stuff you deem silly. Lots of
people are worried. Lots of people want change before their jobs gets
cut further. Lots of people want to steer the Titanic of the library
world in a different direction. But they often can't state this out
loud, for many, many reasons, mostly because we're all human, and
humans often do stupid things that the rule books weren't designed to
trigger.

All of your opinions on what is good and bad conduct is simply nothing
more than your opinion, and I doubt you'll be able to back it up once
scrutinized, so asking rhetorical questions should be *easy* to
dispel. Why aren't you?. Again I notice that *your* only contribution
to this discussion has been to attack the person. Well done.

Regards,

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

---

From: Jonathan Rochkind <[email-masked]>
Date: Mon, 26 Apr 2010 11:14:58 -0400

Peter Schlumpf wrote:
> that search results are noisy.  

See, this indicates to me you have an entirely different perspective on 
this conversation than me!

Both 'sides' in this conversation believe in the importance of 
semantically structured metadata.   If the 'programmer side' didn't, we 
wouldn't bother having the conversation, we'd just ignore it!   If we 
didn't need semantically structured metadata, it wouldn't be so 
important to replace the MARC/ISBD/AACR2 jumble with something that 
actually _worked_ to efficiently create semantically structured metadata 
for software systems.

But in fact, we all here agree it is important. (And of course many of 
us agree that full text indexing  is ALSO useful where available, and 
should be made available in as many places as possible. )

Jonathan

---

From: Janet Hill <[email-masked]>
Date: Mon, 26 Apr 2010 10:59:32 -0600

.. It's amusing to hear someone who has never encountered me assume
(apparently) that I habitually speak in hushed tones, shun strong opinions,
and hesitate to challenge authority or established practice.   (most people
would emphatically not describe me as "sweet, sweet janet")

-----Original Message-----
Sent: Friday, April 23, 2010 9:20 PM