Subject: [NGC4LIB] ALA Session on MODS and MADS: Current implementations and future directions

From: "B.G. Sloan" <[email-masked]>
Date: Mon, 21 Jun 2010 16:10:09 -0700

FYI....
 
And I'm also wondering what NGC4LIB folks think of MODS and MADS??
 
Bernie Sloan

--- On Mon, 6/21/10, Riley, Jenn <[email-masked]> wrote:

From: Riley, Jenn <[email-masked]>
Subject: [lita-l] ALA Session on MODS and MADS: Current implementations and future directions
To: "'Metadata Object Description Schema List'" <[email-masked]>, "'A listserv for Metadata Librarians'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Code for Libraries'" <[email-masked]>
Date: Monday, June 21, 2010, 6:57 PM

(This message is being sent to multiple lists; please excuse duplication.)

Please join us at the ALA session MODS and MADS: Current implementations and future directions, sponsored by LITA.

10:30-12:00, Sunday June 27
Washington Convention Center, Room 143 B/C

Over the last few years, the use of MODS has increased rapidly. In 2008 the MODS Editorial Committee was established to work with the community to maintain the MODS and MADS standards and to update these so that they work in increasingly complex and linked metadata environments. This program will include examples of current implementations of MODS/MADS, future directions (including how a 4.0 version might work better at the network level), and its relation to other metadata standards. This program is intended to elicit feedback and discussion with the community.

Speakers:

Jenn Riley, Indiana University: MODS 3.4 is to be released in June 2010, the first Schema release guided by an editorial committee. MODS 3.4 makes two primary types of changes: those intended to help the Schema be more flexible and usable by other communities, and those intended to support RDA-compliant metadata. These changes will be discussed, as well as possible new directions that MODS 4.0 might take.

Bill Leonard, Library and Archives Canada: Use of MODS and MADS at Library and Archives Canada. This presentation will describe the use of MODS within LAC's Trusted Digital Repository.  Local extensions were necessary to carry descriptive metadata for electronic government records.  It will also touch on a separate MARCXML-based system launched earlier this year searches Canadiana authorities offering MADS as an export format.

Sally McCallum and Rebecca Guenther, Library of Congress: Using MODS for discovery of LC's rich collections: This presentation will describe the use of MODS as a common format to provide seamless and integrated access to LC's collections from disparate systems and cataloging formats. It will also discuss the Metadata for Digital Content Working Group, which is establishing a master data element set and format specific profiles for bibliographic descriptions based on MODS.

Amanda Harlan, Baylor University: This presentation will focus on Texas Digital Library's ETD MODS Guidelines & their ETD submission system, Vireo.  It will give an overview on why MODS was chosen to describe ETDS, who was in charge of writing the guidelines, why it was a priority for TDL to develop Vireo, and how much of MODS was incorporated into the Vireo System.  Next the presentation will be covering where TDL is right now in relation to the guidelines and Vireo.  It will give an overview of how many institutions are implementing it currently, how those institutions are dealing with exporting the metadata to their local systems, and who is continuing the development of Vireo and troubleshooting of it.  Lastly it will give an overview of future projections for TDL's Vireo and guidelines.  The presentation will give an overview of why the Vireo's Users Group was formed and its charge, the push to review the ETD MODS Guidelines to see if there is
 a need for any editing, and how institutions are working with developers of Vireo for enhancement recommendations for all parties involved: graduate school, library, and students.

Karen Miller, Northwestern University: Northwestern University Library's digital repository stores digital resources and metadata in a variety of formats. Metadata schemas are chosen based on their suitability to the type of materials being described, with MARCXML being used for monographs and serials, EAD for archival materials, VRA Core for visual images, and so on. In order to facilitate cross-collection searching, each of these metadata schemas has been crosswalked to MODS, which functions as a "lingua franca" for indexing and is particularly well suited for web display.  In the case of EAD, crosswalking to MODS is straightforward at the archival description level, but once subordinate components become involved, translating a hierarchical structure into a flat one presents challenges. This presentation describes the obstacles encountered and solutions implemented at NUL.

Jenn Riley
Chair, MODS/MADS Editorial Committee

========================
Jenn Riley
Metadata Librarian
Digital Library Program
Indiana University - Bloomington
Wells Library W501
(812) 856-5759
www.dlib.indiana.edu

Inquiring Librarian blog: www.inquiringlibrarian.blogspot.com

To maximize your use of LITA-L or to unsubscribe, see http://www.lita.org/ala/mgrps/divs/lita/litamembership/litaldisclists/litalotherdiscussion.cfm

---

From: Bernhard Eversberg <[email-masked]>
Date: Tue, 22 Jun 2010 11:49:02 +0200

> And I'm also wondering what NGC4LIB folks think of MODS and MADS??
One would hope for a few large-scale implementations to convince
oneself of MODS' usefulness.

The MODS site has an implementation registry:

http://www.loc.gov/standards/mods/registry.php

The only entry of a really large database is for COPAC:

"Copac is a union catalogue. It provides access to the merged online
catalogues of many major university research libraries in the UK and
Ireland plus the British Library, the National Library of Scotland, the
National Library of Wales ..."

They extended MODS a bit to accomodate holdings data.

What can COPAC do, thanks to MODS, that a MARC-based catalog couldn't?
 From visiting it, I'm at a loss to answer that question, but I may have
failed to look hard enough. (The granularity of MODS, to mention one
point, is by design inferior to MARC's.)

Some of the other projects make use of MODS' better facilities with
handling the parts<->whole relationships, an area where MARC (or rather,
MARC as it is usually implemented) is famously deficient.

B.Eversberg

---

From: Ross Singer <[email-masked]>
Date: Tue, 22 Jun 2010 08:22:25 -0400

> point, is by design inferior to MARC's.)
While I did not come here to praise MODS, I feel this is a little
disingenuous.  I think two questions need to be addressed here:  1) is
any real granularity lost between MARC21 as it's found in the wild and
MODS?  2) if so, is it anything that really, honestly matters?

-Ross.

---

From: Bernhard Eversberg <[email-masked]>
Date: Tue, 22 Jun 2010 14:35:40 +0200

> MODS?  2) if so, is it anything that really, honestly matters?
Both questions are not solvable across the board but need to be
addressed specifically for an application and implementation.
It's the *potential* that matters and the *intentions* to be served.
You are right that more granularity is not automatically beneficial,
but there are always some chances that it turns out that way.

If, OTOH, you could prove that MARC's additional granularity is
not really and honestly of use anywhere, then by all means let's
go ahead and finish MARC off.

My main question was the other way: what can MODS do that MARC can't?
And I provided a partial answer: part<->whole relationships. Which,
however, not many applications on the list do need or provide.
COPAC, as far as I see, doesn't. (No wonder when all the data if
contains is from MARC sources.)

B.Eversberg

---

From: Ross Singer <[email-masked]>
Date: Tue, 22 Jun 2010 09:03:29 -0400

On Tue, Jun 22, 2010 at 8:35 AM, Bernhard Eversberg <[email-masked]> wrote:

> And I provided a partial answer: part<->whole relationships.

Well, there's another perceived benefit, as well.  MODS was *designed*
as an XML schema and, as such, is theoretically more optimally
designed for the sorts of things people want to do with XML (XSLT, of
course, but also XQuery and whatnot).

The point this raises, though, which is the fundamental flaw in any
"MARC must die"/"This impostor must prove itself to be superior to
MARC" argument is that these are really just serializations.  The
problem is, they are serializations that lack any sort of actual
formally defined data model to serialize, so they conflate the two.
The question of "will MODS get us any farther than MARC" misses the
point when it's really just another way to look at, work with and
share the same the data we're looking at, working with and sharing
with MARC (albeit perhaps a better way if you're trying to do
XML-based things).  Just like there is no reason to store MARC-as-MARC
in our local systems (although we do), there is no reason should be
storing MODS, either.

If the data model existed, these serializations would just be
domain-specific views of it, /which is how it's supposed to work/.

-Ross.

---

From: MJ Suhonos <[email-masked]>
Date: Tue, 22 Jun 2010 09:32:25 -0400

> go ahead and finish MARC off.

Anything that exists probably already has _some_ value to _someone_ by virtue of the fact that they felt the need to create it in the first place.  What I agree is disingenuous is requiring proof that something is not valuable.  I could simply say "prove to me that MODS isn't valuable" and we'd have a nice little self-referential argument.  Pointless.

> My main question was the other way: what can MODS do that MARC can't?

I agree this is the better question: what value do these new things bring *compared to the value that is lost in moving to them?*

MARC is primarily a markup format, and MODS is a large (though not flawless) step towards a data storage format.  Put differently, MARC does many things, one of which is hold data.  MODS focuses on holding data rather than doing other things.

Example: for most top-level elements in MODS, order doesn't matter.  Contrast this to, eg. subfields in MARC 245 ($abnp vs $ahbc, etc.) in which the semantics are encoded in a combination of subfield order and ISBD punctuation.  A set of <titleInfo> elements *might* appear in any order (and anywhere within the record), but still preserves _most_ of the semantics using XML syntax.

MARC proponents will argue that there are well-defined rules for decoding the syntax using punctuation and subfield ordering, but in 2010, an XML schema is both far more accessible to more technology (both within and outside of libraries) as well as not bound up in a dusty AACR2 tome on the shelf.

Just to throw some meat to the dogs, I would argue that we should consider cataloguing in MODS (and using crosswalks to MARC when necessary for interoperability) as a step forward, and manage the exceptions.  That is, assuming we could get a reasonably usable cataloguing system which could do so.

MJ

---

From: Bernhard Eversberg <[email-masked]>
Date: Tue, 22 Jun 2010 15:49:32 +0200

> Just to throw some meat to the dogs, I would argue that we should consider cataloguing in MODS (and using crosswalks to MARC when necessary for interoperability) as a step forward, and manage the e…
MODS having been around for a while, has nobody tried it yet?
If yes, any findings? If no, why not?

B.Eversberg

---

From: MJ Suhonos <[email-masked]>
Date: Tue, 22 Jun 2010 10:00:37 -0400

> If yes, any findings? If no, why not?

My guess is he same kind of cultural inertia and lack of conviction that MARC has serious deficiencies that we see every day on this list.  If it isn't broken, don't fix it [1].

MJ

[1]  http://www.invalidcast.com/post/The-if-it-isnt-broken-dont-fix-it-mentality.aspx

---

From: Bernhard Eversberg <[email-masked]>
Date: Tue, 22 Jun 2010 15:58:32 +0200

> course, but also XQuery and whatnot).
So goes the theory.
Where has it been put into practice for library catalog data on a large
scale, not just experimentally or on a limited scope of tasks? I mean,
XML has been around for long enough now, and there are lots of people
who understand it (and some of them are quite committed), to expect
there to be a success story or two in this arena. More specifically,
is MODS a success story, does it confirm the theory in everyday
practice, in heavy-use scenarios?

B.Eversberg

---

From: Ashley Sanders <[email-masked]>
Date: Tue, 22 Jun 2010 15:06:28 +0100

Hi,

>> point, is by design inferior to MARC's.)

First of all let me say that, in my opinion, what Copac can do is
independent of the format we store the data in...

We weren't allowed to store MARC records because of licensing
issue. We needed to store the record in some format and rather than
invent our format own we used MODS (with our extension for local
holdings.)

But, we don't index the MODS. The MODS is only used to drive the
displays (through XSLT) and provide a download format. Other
download formats are created from the MODS with XSLT.

So, MODS is easy to work with through XSLT and it saved us a load of
hassle coming up with our own format.

 >> (The granularity of MODS, to mention one point, is by design 
inferior to MARC's.)

I'm currently working an a new iteration of Copac in which we do
index a bunch of XML. We decided that the granularity of MODS was too 
fine for indexing and so we've come up with our own "simplified MODS" 
with less granularity. (Basically we've removed some tags, simplified
the hierarchy and dropped a load of attributes.) There'll still be a
MODS record in there as well, but again it'll only be used with XSLT
for driving the displays and export formats.

We also run a "MARC" database for cataloguing purposes. It does
store records in a format with a resemblance to MARC exchange, but
again it is only used to drive the displays and download formats.
The indexing is done separately.

(I've just spent a happy day writing code to translate the
coded fields in the Leader, 008 and 007 into human readable
genre keywords. It is far too easy to get that code wrong and
produce the wrong keyword. It is way more complicated that it
needs to be -- for the creator of the data and the poor sop
who has to process it. I guess all these coded fields were
invented when disk space cost real money. There's really no
need nowadays.)

Regards,

Ashley.
-- 
Ashley Sanders               [email-masked]
Copac http://copac.ac.uk A Mimas service funded by JISC

---

From: Bernhard Eversberg <[email-masked]>
Date: Tue, 22 Jun 2010 16:06:09 +0200

> My guess is he same kind of cultural inertia and lack of conviction that MARC has serious deficiencies that we see every day on this list.  If it isn't broken, don't fix it [1].
That's always a factor, true enough. There are, however, many young
and ambitious developers around who have not been raised on MARC but
know everything about XML and how to put it to work. They will want
to make a big splash, some of them. We are eager to see their results,
or approaches.

B.Eversberg

---

From: Weinheimer Jim <[email-masked]>
Date: Tue, 22 Jun 2010 16:46:12 +0200

The way I look at the issue of MODS vs. MARC is since the vast majority of library records are in some type of MARC now, it is a matter of what is lost vs. what is gained with switching to MODS.=

1) the map from MARC to MODS is at: http://www.loc.gov/standards/mods/mods-mapping.html#mapping, and it is clear what semantics are lost. My previous example were the different subfields in 130/240 being lost when mapped to MODS <title type=uniform>, specifically the $s. Again, the information is not lost but the semantics. There is also 111, 711 $a$c$d$e$n$q, but others as well. There are certain concerns I have as well, e.g. 
245 $a$f$g$k  	<title> with no <titleInfo> type attribute and
245 $b 	<subTitle> 

which is rather strange from the logic point of view (e.g. 245 $g is for "bulk dates" which I believe are primarily for archival materials, but as a result would semantically mix together dates of creation with title information). I don't believe I have ever used those fields before, so probably the issue would arise relatively rarely, and yet I may be completely wrong! In any case, this mapping makes clear what would definitely be lost when transferring a record. Whether that would be seen as serious or not needs discussion. MODS could be further modified if some bit were deemed sufficiently important.

At the same time, Ashley decided that MODS granularity was too fine.

It is also important to remember that this information is lost *onlY* when transferring the record from the database.

What we would gain by changing to a more normal type of XML format does not have to be discussed to this group.

At this point, the whole discussion may be moot because of the latest worldcat record policy. I still haven't made up my mind. The section
"WorldCat Data. For purposes of this policy, WorldCat data is metadata for an information object, generally in the form of a record or records encoded in MARC format, whose source is or at one point in time was the WorldCat bibliographic database." seems to claim as Worldcat data a record of 040 $aDLC$cDLC$dMyLibrary, if it was downloaded through Worldcat. If I downloaded it through direct Z39.50, it may be another matter, but I may have to prove that somehow. Again, to me it's like taking my car to the mechanic, I pay him to do some work on my car, and then he claims that I can't sell the car or do anything with it without his approval. And why? Because if I do so without his approval, it may hurt the "local collective" in some way.

It seems to be a done deal however. And I find it amazing that people have gotten so concerned about Google Books!

James L. Weinheimer  [email-masked]
Director of Library and Information Services
The American University of Rome
Rome, Italy

---

From: Ashley Sanders <[email-masked]>
Date: Tue, 22 Jun 2010 18:49:40 +0100

> At the same time, Ashley decided that MODS granularity was too fine.

And in other ways MODS doesn't have enough granularity. I'd like
to see more actual Markup (the type of Markup that the M in
XML once stood for.)

eg: I'd like to be able to do this sort of thing:

<tableOfContents>Part 1. <work><title>My Book</title>, by
   <name type="..." role="...">Ashley Sanders</name></work>.
   <work><title>Another book</title>, by <name>J. Doe</name></work>.
   ...
</tableOfContents>

You'd then actually be able to do stuff with the data.

In fact I think more mixed content and actual markup rather
than a rigidly defined data structure would be altogether better.
(Most schemas seem to have forgotten what the M in XML meant.)

Ashley.

---

From: Ashley Sanders <[email-masked]>
Date: Wed, 23 Jun 2010 13:01:45 +0100

> You'd then actually be able to do stuff with the data.

Warming to my theme, should anyone be remotely interested...

Take the following very minimal record from Copac (slightly
edited to remove uninteresting stuff like the record number, etc.)

<mods>
  <originInfo>
   <dateIssued encoding="marc">1840</dateIssued>
  </originInfo>
  <titleInfo>
   <title>Birmingham and Derby Junction Railway Time Tables.</title>
  </titleInfo>
  <name type="corporate">
   <namePart>BIRMINGHAM AND DERBY JUNCTION RAILWAY COMPANY.</namePart>
   <role>
    <roleTerm type="text">creator</roleTerm>
   </role>
  </name>
  <note>In : Midland Counties’ Railway. The Midland Counties’ Railway 
Companion, etc. 1840. 12º.</note>
</mods>

What would be nice is to be able to encode it something like this:

<mods>
  <originInfo>
   <dateIssued encoding="marc">1840</dateIssued>
  </originInfo>
  <title><name type="corporate">Birmingham and Derby Junction 
Railway</name> Time Tables.</title>
  <name type="corporate">
   BIRMINGHAM AND DERBY JUNCTION RAILWAY COMPANY.
   <role type="text">creator</role>
  </name>
  <note>In : <name type="corporate">Midland Counties’ Railway</name>. 
<work relation="In"><title>The <name type="corporate">Midland Counties’ 
Railway</name> Companion</title>, etc. <dateIssued>1840</dateIssued>. 
<format>12º</format></work>.</note>
</mods>

Ie, if we have mixed content in the XML we can drop the need for
having a <titleInfo> tag as a parent for <title>. Likewise we can
get rid of the <namePart> tag inside the <name> tag; and get
rid of <roleTerm> inside <role>. (Actually I'd prefer to get rid
<role> and replace it with an attribute of <name>.)

We would be able to mark-up names, titles and other interesting info
inside notes -- in fact, inside any other element.

I think what we would end up with is the potential for much richer
records, while simplifying the tag structure.

Regards,

Ashley.

---

From: Bernhard Eversberg <[email-masked]>
Date: Wed, 23 Jun 2010 14:27:14 +0200

> <format>12º</format></work>.</note>
Do you have software to facilitate the input and editing of structures
like this?
And could it be handled with XSLT? (BTW, is it XMSL 1 or 2 you are using?)
Frankly, I can't think of anyone who would like or be able to
input raw XML. In relation to raw MARC, I'd say it is much more
cumbersome, bulky and error-prone. (More tagging than text, sometimes.)
To fully outdo MARC - which would be a requirement eventually - cannot
be very easy with XML, and esp. not with something as you envision here.

Of course, MARC is non-recursive and could not deliver something along
your line of thinking. So, it is inherently not complex enough for
contemporary ideas. OTOH, complexity can be self-defeating: it requires
a complex body of rules and then you may end up with a lack of time to
learn them and to get stuff right.

B.Eversberg

---

From: Ross Singer <[email-masked]>
Date: Wed, 23 Jun 2010 08:35:31 -0400

On Wed, Jun 23, 2010 at 8:01 AM, Ashley Sanders
<[email-masked]> wrote:

Actually, I'll be completely honest here, this looks like a horrible
idea.  If you've ever had to try to parse and deal with formats that
do stuff like this (EAD, for example), they're excruciatingly
difficult to work with, simply because of all of the possible
variables that can appear when you're just, in this example, trying to
get the title string.

I'm also not entirely sure what this level of granularity buys you or
any reasonable way you would actually add data like this.

Trying to write applications to logically pull this data would be make
me want yank my hair out.  We're not confined to 99,999 bytes in XML
-- it makes more sense to model things properly and explicitly and
consistently (the last being possibly the most important).

-Ross.

>  <title><name type="corporate">Birmingham and Derby Junction Railway</name>
> Time Tables.</title>
>  <name type="corporate">
>  <note>In : <name type="corporate">Midland Counties’ Railway</name>. <work
> relation="In"><title>The <name type="corporate">Midland Counties’

---

From: Weinheimer Jim <[email-masked]>
Date: Wed, 23 Jun 2010 15:29:09 +0200

Bernhard Eversberg wrote:

"OTOH, complexity can be self-defeating: it requires a complex body of rules and then you may end up with a lack of time to learn them and to get stuff right."

If this sort of formatting were considered important enough to implement, the inputting screen could be dealt with. Remember lots of people, probably the majority of people in the world, consider the MARC inputting display to be completely incomprehensible. 

To implement Ashley's idea, I would think some kind of drag-and-drop displays may simplify matters. In the new environment, we would be working with templates just as we do today, where our MARC inputting templates automatically create the ISO2709 format of a MARC record, which nobody ever looks at. I think the raw XML coding would be considered similar to the ISO2709 view: something nobody every looks at.

And while it may not be easy to work with nested data in this way, if it is decided that we would need to do it, a way would be found although it may be difficult. Of course, it's the job of the designers and builders of Ferrari's Formula 1 racing team to build what others decide is needed, even if those designers and builders find it really difficult to build. After all, that's the attitude that lets them win races.

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: Thomas Berger <[email-masked]>
Date: Wed, 23 Jun 2010 15:36:52 +0200

If I may second:

> variables that can appear when you're just, in this example, trying to

"tagging" within traditional elements is exactly what one needs
sometimes, not only when one was able to identify personal or
corporate names from words or initials in titles like here

>>  <title><name type="corporate">Birmingham and Derby Junction Railway</name>

but also with respect to works and language escapes like here:

Diderot's shade : the discussion on "Ut pictura poesis" and expression in French
art criticism

Pictura loquens - poesis tacens : Studien zu Titelbildern und
Rahmenkompositionen der erzählenden Literatur des 17. Jahrhunderts von Sidneys
"Arcadia" bis Ziglers "Banise"

as for

>> <format>12º</format></work>.</note>

Here I'm not quite sure: If I recall correctly, MODS via <relatedItem> already
allows more general cross-referencing between titles than MARC, i.e.
you are allowed to include a full MODS citation and not restricted to encode
the gist of the MARC description of the target record into the constricted
area of subfields of one given field of the source record.

The <note> in the above example might be considered as the special case
of a citation / cross reference cum initial wording. In a more general
vein, when it comes to citations in notes (for indicating sources etc.)
it has always stunned me that librarians were all about scientists not doing
their citations properly but in their own data formats never even had
provisions for but the simplest form of citations...

Thus having the means of substructuring contents as needed and when needed
(BTW for me it is the "X" not the "M") is desirable.

> consistently (the last being possibly the most important).

Applications come to mind, which would very happily and easily
operate on this kind of data: Extract all (bibliographic or textual)
citations, all personal names, all works mentioned and do something
with them (present, match, verify, ...). These applications would
be much too stupid to understand the full bibliographic record,
but exactly know where to look for to fulfil their specific tasks.
They would benefit from the additional consistency introduced by
the kind of "orthogonal" markup in the examples above.

Of course, this kind of finer granularity will never be universal:
Neither mandatory for everyone to perform on data entry nor is there
any processing expectation for general systems as to gracefully
fall back to "processing as simple textual data field".

As for "model[ing] things explicitly": I personally do not like
the redundancy enforced by traditonal data formats: "Capture the
parallel title in this 3xx field for indexing and if the rules
furthermore mandate a note, then repeat the same information again
in the appropriate note field 5xx" (at least this is the situation
here with MAB).

Greetings
Thomas Berger

---

From: Ashley Sanders <[email-masked]>
Date: Wed, 23 Jun 2010 14:40:42 +0100

Ross,

> idea.

I thought people would hate it :-)

  If you've ever had to try to parse and deal with formats that
> variables that can appear when you're just, in this example, trying to

But it's easy to get the title string -- it's a simple XPATH: 
/mods/title. It is irrelevant that title contains other tags.

> any reasonable way you would actually add data like this.

a) It is more truthfully encoding the information in the record.
b) You don't loose sight of the fact that the title contains
a name -- important information I'd have thought. When displaying
the record you can provide links from the name within the title.
Links that take the viewer onto other resource about that name, etc.

> consistently (the last being possibly the most important).

I'm not advocating a completely random tag soup. We need structure,
but I think we also need more flexibility within that structure.

Bernard wrote:

 > Do you have software to facilitate the input and editing of 
structures like this?

No. But I would envisage a workflow like this. The cataloguer is
viewing the title on screen. Sees it contains a name, highlights
the name with the mouse, right clicks and a context sensitive menu
pops up. The system has seen that text before as a name, so
the first choice on the menu is to tag the highlighted text as a
name. Other less likely options would occur further down the popup
menu.

 > And could it be handled with XSLT

Yes.

 > (BTW, is it XMSL 1 or 2 you are using?)

This goes back to SGML. XML 1 has always had mixed content.

Ashley.

>>   <note>In :<name type="corporate">Midland Counties’ Railway</name>.<work
>> relation="In"><title>The<name type="corporate">Midland Counties’
>> Railway</name>  Companion</title>, etc.<dateIssued>1840</dateIssued>.
>> having a<titleInfo>  tag as a parent for<title>. Likewise we can
>> get rid of the<namePart>  tag inside the<name>  tag; and get
>> rid of<roleTerm>  inside<role>. (Actually I'd prefer to get rid
>> <role>  and replace it with an attribute of<name>.)
>>

---

From: Bernhard Eversberg <[email-masked]>
Date: Wed, 23 Jun 2010 15:38:30 +0200

> To implement Ashley's idea, I would think some kind of drag-and-drop displays may simplify matters. In the new environment, we would be working with templates just as we do today, where our MARC in…
Oh, I'm pretty sure this was not Ashleys brandnew idea but has occured
to many a bright mind in the XML universe. That's why I asked what
the tools are to get there. Nested data is not something we alone
might consider or want. The vast majority of XML applications, or so
I read elsewhere, are very straightforward, linear, non-hierarchic
and simple to implement and evaluate. And I'm leaning towards the
overkill view Ross has just confessed to...

B.Eversberg

---

From: Thomas Berger <[email-masked]>
Date: Wed, 23 Jun 2010 15:55:58 +0200

Ashley,

> viewing the title on screen. Sees it contains a name, highlights

make "title" = cover scan and you're with me.

Thomas Berger

---

From: Weinheimer Jim <[email-masked]>
Date: Wed, 23 Jun 2010 16:44:27 +0200

<snip> 
</snip>

What I am trying to say is that we should begin with what we, as information professionals and experts, think that people need and only then determine whether the tools can or cannot do what we determine is necessary. If it turns out the present tools cannot do what we think is necessary, we can consider new tools, but the emphasis should be on what is needed.

I am worried that we are limiting what we think is needed by our current perceptions of how weak or powerful our tools are, or how difficult or easy they are to work with, instead of thinking more boldly. Sort of like the ancient Romans looking at the steam engines they would build and thinking they were only toys, never thinking about putting them to serious use. More powerful steam engines would have changed everything when the empire began to disintegrate.

---

From: Mark Huppert <[email-masked]>
Date: Thu, 24 Jun 2010 11:28:05 +1000

Dear Colleagues

re: Metadata Services Coordinator (ANU08)

We have a nice cataloguing job opening up here at the 
Australian National University (ANU) in Canberra. Canberra is 
Australia's capital - a planned city like Washington DC
with about 500,000 in the metro area (including some nearby
towns in New South Wales). It has a lot of assets for a small 
city - museums, embassies, good schools, educated
people with diverse interests. If you are adventurous or 
planning to come anyway for family reasons, this could be a stroke of
luck.

We're looking for a lead cataloguer with good people and project
management skills who likes exploring the latest technology.
That's not the official wording, but it's the kind of person 
we're hoping to get. The closing date is 11 July.

Please refer to this documentation and carefully follow any 
instructions:

 http://jobs.anu.edu.au/PositionDetail.aspx?p=1337

Relocation assistance may be available to the successful
applicant.

regards

Mark

========================================
Mark Huppert
Menzies Precinct Manager (Acting)
Library Systems and Web Coordinator
Division of Information
R.G. Menzies Building (#2)
The Australian National University
ACTON ACT 0200

T: +61 02 6125 2752
F: +61 02 6125 4063
W: http://anulib.anu.edu.au/about/

CRICOS Provider #00120C
========================================

---

From: Ere Maijala <[email-masked]>
Date: Thu, 24 Jun 2010 10:00:17 +0300

> What I am trying to say is that we should begin with what we, as
> information professionals and experts, think that people need and
> only then determine whether the tools can or cannot do what we
> determine is necessary. If it turns out the present tools cannot do
> what we think is necessary, we can consider new tools, but the
> emphasis should be on what is needed.

How about if I put it this way:

We should begin with what we, as information professionals and experts,
think that people need and only then determine whether the formats can
or cannot do what we determine is necessary. If it turns out the present 
formats cannot do what we think is necessary, we can consider new 
formats, but the emphasis should be on what is needed.

I mean, it's quite easy to come up with a beautiful format that's 
practically useless. I've done that, and it was something really simple 
instead of what's been discussed here. It does make a difference how 
easy it is to build data entry tools, and the point Bernhard raised 
regarding XSLT is important too. And it relates to how easy it is to 
display the data in a meaningful way.

--Ere

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

---

From: Bernhard Eversberg <[email-masked]>
Date: Thu, 24 Jun 2010 09:20:19 +0200

> formats, but the emphasis should be on what is needed.
Correct. But exactly "what is needed" is what we still don't know or
can't pin down. And I think there will not be one easy answer but any
community, no, any one person needs something ever so slightly different
and something else the next time. So, our data model needs to support
exports in many flavors and dressings.

But now, the mighty RDA toolkit is out. Go and look if it might get us
closer to solutions, based on the FRBR data model as it is. But don't
forget there are gigatons of legacy data.

B.Eversberg

---

From: Weinheimer Jim <[email-masked]>
Date: Thu, 24 Jun 2010 10:06:31 +0200

This is exactly the problem. We have tons of metadata made over many decades (if not more) that--at least I believe--will definitely prove useful in this new environment, but we don't know exactly *how* it will be useful. We do know however, that in the current format (in various senses of this word), what we have will definitely *not* be useful outside our own library world, and we must assume that fewer people will be visiting our world.

The FRBR data model is already an anachronism and has never been tested. I find it amazing that FRBR makes this incredible statement that people want to "find / identify / select / obtain --> works / expressions / manifestations / items --> by their authors / titles / subjects" which we absolutely *know* is wrong! That describes how the card catalog worked--even in the OPAC, keyword searching quickly became the dominant search. Does anybody really do this anymore? Once in a very great while when I am searching for a specific edition of, e.g. Burton's Anatomy of Melancholy, but in addition to keyword searching, there is this thing called "Google" and "relevance ranking" that has come around in the last 20 years or so...

I certainly cannot imagine that RDA/FRBR changes will interest anybody in our data, and after looking at some of Karen's attempts, I suspect it isn't even a valid data model for our present records. (Is there *really* such a thing as an "expression" or even a "work"? This has turned out to be far more difficult in reality than we thought, or what I thought, anyway! Perhaps the work and expression as simple collating points for a card/printed catalog, are not "entities" with lots of "attributes" but something else entirely)

In any case, one of the most basic business practices of new product development has never been tried, at least not to my knowledge: does our projected product (i.e. FRBR displays) fulfill *our patrons'* needs? Or a significant number of their needs? I haven't seen anything that deals with this. From my own experience with users, and my own searching patterns, I can't imagine that anybody would look at these displays and say, "Yes!! That is what I have always been missing!!"
 
But it seems as if the library world is doomed to continue onward toward spending its limited resources to create an untested product and train staff to create that untested product that, quite probably, nobody wants.

Again, I want to mention that there is a choice: The Cooperative Cataloging Rules at: http://sites.google.com/site/opencatalogingrules/

---

From: Alexander Johannesen <[email-masked]>
Date: Thu, 24 Jun 2010 19:00:07 +1000

Excuse me, coming through, pardon me! *shove* *shove*

Bernhard Eversberg <[email-masked]> wrote:
> But exactly "what is needed" is what we still don't know or
> can't pin down.

No, that's not true. We can pin down a lot of the things we need, and
we have, in all sorts of documents and websites and reports and
whatsnot. We talk about it, talk it to death, write reports about it,
fill websites with it, mailing-lists with miles and miles of prose
about our needs and wants and yearnings.

What you *haven't* done is written it down in such a way that we can use it.

Think about it; all those models, formats, needs, wants and cries for
help, they're all documented, written about, talked to death, and then
we all return to MARC / AACR2 / RDA and keep going because no one has
created The One True Thing That Encompasses All What We Need [TM]. You
people need to get your head out of the format cloud and into the
model cloud! You're *all* talking about a shared platform for
librarianship, for sharing resources, meta data and whatever tickles
your librarian fancy, yes? Well, the truth is that that model doesn't
exist in a *format*, but in a *model*.

Let's go over just a smidgen of our needs, like that of title. How
many ways can we slice and dice the concept of "title"? Let's just
give it an arbitrary number that's not true but will work for this
example; 100. So we've got 100 ways of conceptually capture this
"title" thing. What's the next step? It is *not* to create some XML
for it, nor is it to create any other format record of it, because
that stuff isn't important, it means nothing, it's just binary fluff
and technological smoke and mirrors instead of what you actually need.
You can bitch and argue for the way you build an XML or MARC record to
represent your thing, but no matter how complex we document how that
format shall capture it, there will always be some use case it won't
capture (and we must all wait for the errata, or live with faults, or
hack around it, or ...), or, probably even more correct, there's
always a point at which the formats complexity overshadows its
usefulness. (And I thought we invented the computer to help us out, to
make our lives easier. Hmm)

Let's make it a bit clearer. Instead of doing ;

<format>
   <datafield tag="245" ind1="1" ind2="0">
      <subfield code="a">Arithmetic /</subfield>
      <subfield code="c">Carl Sandburg ; illustrated as an anamorphic
adventure by Ted Rand.</subfield>
    </datafield>
</format>

.... create concepts out of them, document them, and agree to them.
Just write prose; short, concise prose. If special cases are needed,
create them and document them in the same place. Put up a darn Wiki,
for heavens' sake! Join forces, and agree on what the heck you need
right now, and let's create a model out of it, because it's TONS
easier to extend a model than to extend an infra-structure!

But let me dig into that of identifiers a bit more, as they are
terribly important ;

    <controlfield tag="001">   92005291 </controlfield>
    <controlfield tag="003">DLC</controlfield>

I'll be blunt and go straight for the jugular; what about that
identifier? What the heck is that? Some internal identifier, an id
from an OPAC, or external DB, or some serialisation process, what? You
see such numbers being tossed around a lot, and some of them, like LOC
numbers, gets used as persistent identifiers, yet you still got to
hack your systems to give them meaning. And *this* one, the DLC, when
we search for it (although this one we all know by heart) gives us ;

2035	DLC, normalized: dlc, obsolete code: DNLB	
United States, Library of Congress
Variant name(s): Library of Congress, Congressional Library, United
States, Congress, Library

What is this supposed to mean? What does it mean that LOC issues this
item the number "92005291"? It is meaningless at this point! Sure, we
can, through the magic of "done it before", pop that number into any
LOC service and possibly create some direct link to it (because we all
assume it's part of LOCs union catalog, or some such) We still don't
really know what that number is, we can only guess it.

Why?

For organisations that pride themselves on the bucket-loads of
documentation, process and strict rules these *essential* questions
about the meta data are rather absent. What do these numbers mean? How
can we use these identifiers? Where are they applicable? Who can use
them? How can we use them?

Why aren't we coming up with an identity management plan that we all
can use? Even FRBR sucks in this respect (concepts defined in a
document that isn't addressable is not a good basis for persistent
identifiers), and don't get me started on AACR2 / RDA. Why on earth
isn't there better dialog about what concepts can be entities,
enumerated values, or some such? Lots and lots of meta data is
shareable, not as text, but as concepts! And, a crazy thing maybe, is
that concepts are, again, easier to share than infra structure and
formats!

Here's a concept ;

 * book

I'll write up a definition in my Wiki ;

   "A collection of sheets of paper bound together to hinge at one
edge, containing printed or written material, pictures, etc." (And
don't nitpick on this definition; it should be more specific, better,
longer, crafted by more, agreed and discussed, blah, blah, blah ...)

I'll link it to a definition ;

   http://en.wiktionary.org/wiki/book

What happens here is that the concept "Book" has two identifiers ; one
to our Wiki, and one to Wiktionary. The prose of both might and will
change over time, but the two (or more) together make up a thing that
most people would agree is a "Book."

Libraries have a rich language that needs to be formally defined and
identified so that we all can use and reuse them. Why hasn't this
happened? Well, I suspect librarians are happy to talk their language
and don't see the need for writing this stuff down, they're happy to
*use* their language to document *other* things, like processes, meta
data, documentation, systems, and so on, but you've forgotten to
define your language *itself*. The need for this is *huge*, and let me
clarify this with the example I usually give ;

 * Stacks

No one in the whole world can use this concept except librarians.
People read "Stacks", and have no understanding of what it means (do
they mean what is physically sitting in a stack? Is it a synonym to a
shelf? Or is it their stacks of stuff? A collection? Or all their
collections in one?), neither orally from a library nor from a library
system. But look, we can define a new concept ;

 * Collections

Now we can edit the prose of that, and create a link ;

   Stacks
      is_really_another_word_for
   Collections

We need the library world to be mapped. Not extensively, but enough
for us to define, model and define that world, and we need to do that
for ourselves but also for those who wishes to cooperate with us. We
need these definitions to work as translations between systems. Right
now, all we've got now is (mostly) MARC records doing the translations
of computer records between systems, so the *model* we're basing our
systems on are whatever is defined in, probably, MARC21! We cannot
escape MARC through FRBR / RDA if these things don't do a better job
of identifying the stuff they're trying to save us from.

So what I'm really saying is that this discussion shouldn't really be
about formats, but about a collaboration between all librarians to
build up a system of identifiable concepts that can be reused in all
sorts of weird and wonderful formats, systems and applications.

I think Karen Coyle and her posse is doing something lightweight for
the FRBRizing RDF thingie, right? How about we escalate this into a
serious attempt by all to actually save the library world from being
forgotten by the future, like some old ancient language no one speaks
or understands anymore?

Hope I was making sense,

Alexander
-- 
 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: Thu, 24 Jun 2010 12:08:10 +0200

> Again, I want to mention that there is a choice: The Cooperative Cataloging Rules at: http://sites.google.com/site/opencatalogingrules/
Jim, you may be interested to know that you can do a few things
with the RDA tookit, among which to copy or download the entire text, in
chapters, of not only RDA but also AACR. Just click *PrintText* in the 
upper right.

I'm sending you AACR2 Chapter 1 as Word file anyway, just so you can see
if it might be any use for your project.

B.

---

From: Bernhard Eversberg <[email-masked]>
Date: Thu, 24 Jun 2010 12:22:52 +0200

Sorry, my latest posting was meant only for Jim, but I was wrong
anyway: what you get for downloading as PDF is only excerpts...

But you learn that after the complimentary period, ending Aug. 31,
you can purchase a loose-leaf RDA copy as part of your subscription.

B.Eversberg

---

From: "Diane I. Hillmann" <[email-masked]>
Date: Thu, 24 Jun 2010 07:05:06 -0400

Alex:

As always, your posts are a breath of fresh air!

For the record, FRBR is registered as properties here: 
http://metadataregistry.org/schema/show/id/5.html  These are the 
'official' version, under review by IFLA, expected to be approved this 
summer.

RDA is also available here: http://metadataregistry.org/rdabrowse.htm  
These are currently under review as well, but the process is a little 
less clear and the timetable a bit fuzzier.  They are, however, usable 
as is by those who wish to use them.

This IS the 'serious attempt' you spoke about--we're not just playin' 
around.

Diane

On 6/24/10 5:00 AM, Alexander Johannesen wrote:
> Bernhard Eversberg<[email-masked]>  wrote:
>    
>      <controlfield tag="001">    92005291</controlfield>

---

From: Alexander Johannesen <[email-masked]>
Date: Thu, 24 Jun 2010 21:22:56 +1000

Hiya,

Diane I. Hillmann <[email-masked]> wrote:
> http://metadataregistry.org/schema/show/id/5.html  These are the 'official'
> version, under review by IFLA, expected to be approved this summer.
>
> RDA is also available here: http://metadataregistry.org/rdabrowse.htm  These
> are currently under review as well, but the process is a little less clear
> and the timetable a bit fuzzier.  They are, however, usable as is by those
> who wish to use them.

Don't feel very persistent those identifiers? (And self-referential a
number of them) I guess that's a minor nag, though. Is there
collaboration involved? Wiki pages? Anyone can update the records, or
the normal mode of a working group that unleashes their work when done
(or in stages)? Easier navigation? thoughts on easier ways to grasp
the models proposed? It also feels you're mixing up several levels of
ontology here, but I'd have to really dig in to grasp what's going on.

Hmm, over 230 elements and properties (relationships) in the upper RDA
ontology alone. That's supposed to be easier to understand, right? :)
How many elements in total when you add in a few often-used vocabs?
You really need to have some excellent tools that can work with this
level of complexity. Who's doing that part?

> This IS the 'serious attempt' you spoke about--we're not just playin'

Yes, it looks serious, it certainly is good stuff that can be reused,
*provided* the underlying models are good (any good graphs or maps of
those models anywhere?). What efforts are being made to make
catalogers and librarians understand what is going on here?

Regards,

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

---

From: Bernhard Eversberg <[email-masked]>
Date: Thu, 24 Jun 2010 14:13:57 +0200

Alexander Johannesen wrote:
> those models anywhere?).

Fine ER diagrams at

http://www.rdatoolkit.org/background

Some more thoughts:
I agree with Jim that the RDA/FRBR approach at the data model is
an exaggeration. It is much too firmly rooted in the 19th century
traditional craft of bibliography.
For the top level, I think the expression level is not necessary,
and the "scenario 1" data model would be overkill. It will never get
off the ground, given that MARC21 practice to this very day doesn't
use identifiers even for persons, series, multiparts in general although
this could have been done long since.

Translations, I think, should not be "expressions" but make their
own works - linked to the original where useful. That leaves just
Date, Content type, Other distinguishing characteristic, and sometimes
Scale as expression elements. Add them, as far as needed, as subelements
to the Work identifier element in the manifestation! That way, they can
still serve every function intended for them.

Then look upon works much like subject headings. And all of a sudden,
you already have countless "work records" in the LC authority file and
you need to do hardly more for them than now. Neatly link them to
corresponding "work records" in other languages, after the fashion
of WorldCat Identities.

For the manifestation level, I think there's an excess of elements. Look
at all those notes! Mostly they should be added as subelements to the
elements they refer to instead of being a separate ePrelement.

The most valuable part of RDA will be the vocabularies. They should put
an end to the horrible inconsistencies we now have in legacy data.

 > What efforts are being made to make
Without that, indeed, one cannot see where the enormous effort that has
gone into it all will lead to. For in the end, someone's got to do the work.

Presently, it looks like RDA will remain a closed box with no way of
open linking into its content. Leave it that way, and you can forget 
about it.
The LC tests will not result in anything close to a full
implementation anyway, and that will be the end of it.

B.Eversberg

---

From: Alexander Johannesen <[email-masked]>
Date: Thu, 24 Jun 2010 22:43:36 +1000

Hiya,

> http://www.rdatoolkit.org/background

Yes, they don't look bad at all. Well done!

Actually, I do remember seeing some early versions, and especially one
where all of the ERs were together. I think I blogged doom and gloom
about the complexity involved, and indeed there is a great complexity
in RDA that does not come out in these diagrams, but maybe that's a
good thing for getting people onboard.

> traditional craft of bibliography.

Indeed, there's a heavy, heavy bibliographic leaning in there,
probably an attempt to schmooze with AACR/MARC21 and seem somewhat
familiar to the people who'll handle it.

I keep noticing other things that perhaps bug me more, but are more
subtle, for example where an item has "restrictions on access",
"identifier", and "URI" where the web and the future of cataloging
easily mash these into one (not to mention the wording 'restrictions'
rather than, say, 'constraints') and perhaps show an antiquated model
for all three and what they mean. Or we find nagging meta data
hangovers like for manifestations ;

Computer Carriers
   Computer Card, Computer Chip Cartridge, Computer Disc
   Computer Disc Cartridge, Computer Tape Cartridge
   Computer Tape Cassette, Computer Tape Reel, Online Resource

and then we go to ;

Video Carriers
   Videocassette, Videodisc, Videotape Reel

I know this isn't an exhaustive list, mind you, but there's a
disconnect between the physical and online world in the way the model
is being used. It's more like mashed together slightly semantically
ambiguous rather than building a real model in taxonomical form. Hmm.
All of these could be simple Containers that are either Physical or
Virtual, with a name attached instead which would be very easy to use
and reuse in search, but no, with the current model we either have to
pre-process our data into a simple indexed model, or write code that
slows down the search to nip out the semantics of the models we've
got. I can only guess this is legacy stuff, but I reckon you should
seriously look into a more modern approach.

> For the manifestation level, I think there's an excess of elements.

Amen. :)

> an end to the horrible inconsistencies we now have in legacy data.

Only if the RDA model match what people are doing. I suspect it is too
complex to fit in people's heads easily (because the RDA model
semantically ambiguous models it becomes so much more complex).

> open linking into its content. Leave it that way, and you can forget about
> it. The LC tests will not result in anything close to a full

What does RDA people say about this, though? Surely there's a good
plan put in place, a way to sway the masses, a list of vendors that
are ready to jump onboard ... Tim, you've done bits of this, no?

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

---

From: Laval Hunsucker <[email-masked]>
Date: Thu, 24 Jun 2010 09:44:13 -0700

Jim,

I'm not inclined to take issue with what you wrote here
-- except for one part of it, where you could perhaps
better have been less breviloquent and more explicit :

> . . . what we have will definitely *not* be
> useful outside our own library world, and we
> must assume that fewer people will be visiting
> our world.

Let's be frank about it, shall we ?  Instead of "we must
assume that fewer people will be visiting our world",
wouldn't it be more complete and more accurate to say
"we must assume that fewer people will be populating
our world and visiting our world" ?

I.e., until it becomes so few people that we reach the
point at which that world cannot but evaporate
altogether. ( Or, just possibly, has morphed into quite
another kind of world altogether. )

- Laval Hunsucker
  Breukelen, Nederland

---

From: Laval Hunsucker <[email-masked]>
Date: Thu, 24 Jun 2010 12:22:48 -0700

> Hope I was making sense,

Yeah OK, I get what you were saying, if that's what you
mean -- but you did write :

> We need the library world to be mapped. Not
> extensively, but enough for us to define, model
> and define that world, and we need to do that
> for ourselves but also for those who wishes to
> cooperate with us.

Here I couldn't agree with you less. That's the last thing
we need, for "a serious attempt by all to actually save
the library world from being forgotten by the future",
or for anything else, or for any other reason I can imagine
-- except maybe for a nice exhibit in some museum later
on showing people how there once was this funny thing
everybody used to call a "library" and look, this is more
or less how it worked. Otherwise, "modelling the library
world" seems a pretty useless exercise. Why should one
bother to do *that* ?  I don't get the point. Seems like an
imbecilic sort of navel-staring.

If we should be talking about mapping or modelling or
defining *anything*, we should be talking about
mapping or modelling or defining the ( entire ) universe
and ecology of document and information use -- an
ecology within which the library and the "information
profession" used necessarily to occupy an essential place
and to play a vital role ( though not a place and not a
role that we as an information profession really ever well
understood, let's not delude ourselves ). Only through
modelling that *whole* documentary/information/
communication ecology can we imho hope to have any
realistic chance left of determining whether our profession
as we more or less know it today will have a future role to
play within that ecology -- and if so, how.

I'm not even sure it's possible to do something such as
this, in practice. But I'm sure that if it *is* possible to do
it in a meaningful way, it's going to be a very very very
demanding undertaking. I wouldn't myself put any money
on the chances for success. We haven't in the last many
decades shown much collective enthusiasm or competence
to do this kind of job. Why should we think it's going to
happen now ?

Of course we can on the other hand just keep waiting
around and just see what actually happens.

Think I'll just go out and take a walk now. I need some 
fresh air.

- Laval Hunsucker
  Breukelen, Nederland

----- Original Message ----
From: Alexander Johannesen <[email-masked]>
To: [email-masked]
Sent: Thu, June 24, 2010 11:00:07 AM
Subject: Re: [NGC4LIB] ALA Session on MODS and MADS: Current implementations and future directions

<format>

Why?

Here's a concept ;

* book

* Stacks

* Collections

   Stacks

Hope I was making sense,

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

---

From: Alexander Johannesen <[email-masked]>
Date: Fri, 25 Jun 2010 09:57:01 +1000

Hola, Senor!

Laval Hunsucker <[email-masked]> wrote:
> world" seems a pretty useless exercise.

Wow. You obviously have no idea of how this thing called
"communication" works, do you? Now, I assume your native tongue is
Dutch? Good. Now, my native tongue is Norwegian. And under normal
circumstances we wouldn't be able to have a serious talk, as I don't
speak Dutch and no one sane speaks Norwegian. But, living in countries
with good education we both probably learned English at school. And
this is a good thing! It enables you and me - otherwise confined to
mute nodding of assumptive vagueness! - to actually talk, to transmit
meaning and models between us. It looks like we're still a bit rusty,
but at least there's words coming out of my mouth and you seem to hear
them and understand some of them. So far, so good. English is a map
between us.

The library world does not speak Norwegian, Dutch or English, but
Librarynese, with several accents and regional variants thrown in. The
rest of the world has a host of other languages. For cultures and
bodies to talk effectively and well you need to define what you're
saying in an upper layer. Even within one segment of a language you
often need to bridge semantics between the two in order to get it
right. If I say "classical music" out loud, what am I talking about?
The generic broad sweeping (but oh! so stupid notion) "anything with
violins in it" classical, or do I mean a specific time period, a
specific time period that's broader than the Classical period (like
embracing baroque), or a given style of music, or the music of some
composers, or 'classical' in the way of meaning 'safe' music in a
given period / idiom, and on and on and on. The sad truth is that
there's no such thing as "classical music", only more specific
definitions of the notion and often are highly contextual, yet it's an
expression people use often in all sorts of situations.

So why don't you get it? Do I need to go through the basics of
information science, of ontologies, definitions, key/value recursive
taxa models, and so on? Or just the basic limitations on
communication, language, syntax, structures and rules? How in order to
translate between two bodies we look for the bell-curve of semantics
between the models?

> Why should one

You're being insulting on purpose, aren't you? Yeah, I know you are,
otherwise you would be - oh, what's the word? - really stupid. You
know, the "that" in your tirade above could be referring to a number
of things, but mostly the part where you just don't get it. Are you
going to attack things and call them stupid because you yourself don't
get it? That's Teabagger territory, that.

> and ecology of document and information use --

So, in order to make something neat and small work, we need to make it
huge and unsurmountable?

> an
> understood, let's not delude ourselves ).

That place is called "the world." We in the semantic web world have
know about it for a very long time, and we have defined our little
corners and nooks pretty well, and they are everywhere. We're now
waiting for consensus to sort of out the kinks, really. Oh, hang on.
There's one piece missing. Yeah, you guessed it; the library world, a
bunch of people living in isolation from "the world" thinking outside
thinking is suspicious and if you haven't made it yourself, then we
won't have a bar of it, and as a result totally missing from any
serious world modeling goings on. (Oh, get stuffed; I'm writing
sarcastically, of *course* there's exceptions ...)

> Only through

You know, the library world have already done this. It's called MARC
(with added AACR2), and it's the thing we're trying to get away from
because - surprise, surprise! - it's getting too big, too bloated, too
complex, too rigid, too crazy, too expensive to maintain and create,
too limiting, too little, too late.

Focus on what you actually know, and work hard on mapping that to what
the rest of the world is doing (and I'm here giving up on librarians
ever working directly with the rest of the world, and seriously *join*
their efforts [speaking post-DC here]). If you do anything but that,
you will fail.

> this, in practice.

There were a few links in this very thread showing you that it
definitely *can* be done. They just need a slightly more open model of
cooperation, and voila!

> But I'm sure that if it *is* possible to do

Because if you don't, there is no future?

> around and just see what actually happens.

Spoken like a true warrior.

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

---

From: Weinheimer Jim <[email-masked]>
Date: Fri, 25 Jun 2010 09:16:16 +0200

Laval Hunsucker wrote:
<snip>

I can't argue against this, but I also don't see much of a difference. In essence my concern is: what will happen, and is happening now, is that people are beginning their searches for information in other places than the library (that should come as a surprise to no one) and people find so much in these other places that there is little time left for them to use our resources, or to even know about them in the first place. This is the world that we must plan for because it is happening right now, and there is no indication that people will be clamoring for the work of libraries and librarians. The way I look at it, we can either just give up and find jobs in other fields, or actually try to do something about it, and perhaps even look at the present situation as an opportunity.

In this respect, I am mulling over and playing with Alex's idea that (as I read it) one of the main problems is that of gaining a mutual understanding of the differing concepts. As a practical example, there is the bibliographical idea of "title proper" and "other title information" vs. the more popular idea of "title". The first step is briefly to lay out the differences in the concepts, but then the second step would be to actually make decisions, i.e. is it really worthwhile for us to continue the separate coding of 245$a"title proper" and $b"other title information" or is it so important that we should try to get others to code them separately?

Obviously, determining the answer to the second step would be more ominous and traumatic in many ways, not the least is: who will actually make the decision? But no matter what the decision, it will represent change for somebody, somewhere unless we just decide to let everybody do whatever they want.

Still, there is no reason to undertake step 2 until step 1 is made. Actually, this is the *purpose* I have had for the separate section in the Cooperative Cataloging Rules on the "Conceptual Outline" which attempts to bring the different ideas together. I agree that it is very poorly implemented, it is based entirely on ISBD, but it is something, anyway. http://sites.google.com/site/opencatalogingrules/conceptual-outline 

Of course, I am sure there are much better ways of handling this. It could all be deleted and start over again.

---

From: Bernhard Eversberg <[email-masked]>
Date: Fri, 25 Jun 2010 10:08:10 +0200

Weinheimer Jim wrote:
> 
> In this respect, I am mulling over and playing with Alex's idea that
(as I read it) one of the main problems is that of gaining a mutual
understanding of the differing concepts. As a practical example, there
is the bibliographical idea of "title proper" and "other title
information" vs. the more popular idea of "title". The first step is
briefly to lay out the differences in the concepts, but then the second
step would be to actually make decisions, i.e. is it really worthwhile
for us to continue the separate coding of 245$a"title proper" and
$b"other title information" or is it so important that we should try to
get others to code them separately?
More generally, we need to look at how people and services on the
Web use to refer to and talk about books (or "resources" anyway).
The notion of "title" is not used and understood with any degree of
formal consistency, to begin with. It depends on how long and specific
or unspecific it is, if the author's name is more prominent than the
title itself ("read the new Dan Brown yet?"). And if the "title proper"
is significant, why bother with the rest of the verbiage on the
title page when refering to the book? For Non-book stuff, titles
are difficult to pin down more often than not, and for online resources,
they can get changed any minute - but then, they are referred to by URL.
Automated communication, therefore, can presently depend only on
identifiers. And it does with GBS, for "Find in a library" uses OCLC
numbers. But what happens after that? Do they get to see anything that
resembles what they saw on GBS (or wherever) as representation of the book?

So, when and if people, by whatever happenstance, stumble into libraries
and use their services by whatever automated means, how do we present
results to them? With what language and textual form do we confront them
and offer stuff for downloading or copying or transfer into their
software so they can do something useful with it? That's the question.

Obviously, we cannot use the refined terms concocted for RDA (or AACR
for that matter) at the user interface. OPAC labels, up until now,
and download formats for public use, are differing widely in their
layout, extent and wording. To do something about this is overdue,
but there is no format or even way of talking (see above) about books
that is generally understood and used in all those places where
book information can be found. And RDA, other than AACR (where it
relates to cards), does not bother with the user interface, it deals
just with data elements at the utmost level of abstraction. It does,
however, have a list of core elements, more or less coinciding with
elements that are found most often in our records and that are the
most useful and relevant for talking about the objects they
describe. We should, I think, start from this list of core elements
and turn it into a list of plain language terms to be used as OPAC
labels and such, and implement this widely so it gradually gains
some level of recognition and eventually improve communication
between persons and software, beyond the plain clickable linking by
identifier.
Always, however, readers are not after bibliographic descriptions
but the objects. In FRBR terms, the "obtain" function is what really
matters, and if it takes more than a mouseclick...

B.Eversberg

---

From: Weinheimer Jim <[email-masked]>
Date: Fri, 25 Jun 2010 11:31:40 +0200

title page when refering to the book? 
</snip>

Wow! And I thought I was radical! You are absolutely right, and now that people have a genuine choice on search tools other than the ones we create, we must deal with these situations, otherwise people won't use our tools at all.

This reminds me of something I read recently in an absolutely fabulous, scholarly, weighty tome by Elizabeth Eisenstein, "The printing press as an agent of change." (http://tinyurl.com/3yzwfgn It is taking me forever to get through because I pause and think after every few sentences!) It is startling that there are so many parallels from the period of the late 1400s to the 1500s and our own time. One thing I read recently in it was that as the Bible was translated into the vernaculars, the Catholic Church naturally tried to stop them all by forbidding vernacular translations. The problem was, they couldn't stop them everywhere, but this meant that when lay people were interested in some of Biblical teachings, the only materials available were Protestant translations. Many Catholic monks in Protestant regions saw this happening and wanted people to have a choice, so some went ahead and translated the Bible into various vernaculars even at the risk of being labeled heretics.

If libraries do not give the public what it wants, the public will easily do without libraries, while certain people bemoan what is happening, all the while predicting the end of civilization.

Yet, I feel that there is--or should be--a certain level of dumbing down that we should not transgress. Titles?! Still, many students that I have worked with do not understand searching by "author" or "title" or "subject". This is what we get with Google.

It's a difficult moment, but I think Alex is right: the first step is to come to some kind of mutual understanding--not agreement--over these different concepts.

---

From: Bernhard Eversberg <[email-masked]>
Date: Fri, 25 Jun 2010 13:15:20 +0200

> Yet, I feel that there is--or should be--a certain level of dumbing down that we should not transgress. Titles?! Still, many students that I have worked with do not understand searching by "author"…
Well, are we to present data in an entirely amorphic way, no labels
tacked on at all, just some presumably relevant chunks of text? Sounds a 
bit close to ISBD though as well as a Google result list.

> It's a difficult moment, but I think Alex is right: the first step is to come to some kind of mutual understanding--not agreement--over these different concepts. 

As I said, one might look at the list of RDA Core Elements
for a start and try to twist it into something the average
person may perhaps warm to. If that turns out impossible, then what?
(This is not to say we should store data that way, of course)

B.Eversberg

---

From: Laval Hunsucker <[email-masked]>
Date: Fri, 25 Jun 2010 05:36:02 -0700

The ( need for the ) coding of 245$a and 245$b 
was just brought up.

I'm no cataloguer, and probably know infinitely 
less about that whole Byzantine business than 
most of you here. But, I know for sure that I 
have seen cases of books whose title pages were 
( given the design, positioning of the elements, 
fonts used and so on ) of such a sort that what 
the one cataloguer had put respectively in 245$a 
and 245$b, had by another cataloguer elsewhere, 
who was presumably following the same rules, 
actually been put respectively in 245$b and 
245$a. ( Sorry -- I can't dig out any specific 
examples right now, but they're there. )

No big deal ?

- Laval Hunsucker
   Breukelen, Nederland

---

From: Weinheimer Jim <[email-masked]>
Date: Fri, 25 Jun 2010 14:38:16 +0200

Another possibility, and possibly more understandable since it avoids all the FRBR concepts, would be to use the current BIBCO standards http://www.loc.gov/catdir/pcc/bibco/core2002.html and translate these into everyday language, eliminating some of the more bizarre fields, e.g. the fixed fields.

---

From: Bernhard Eversberg <[email-masked]>
Date: Fri, 25 Jun 2010 14:48:00 +0200

Laval Hunsucker schrieb:

  ... But, I know for sure that I
> examples right now, but they're there. )
Publishers' revenge, I guess. They are always ahead of us
with their tricks, to lead catalogers astray so their
books will be harder to find - for readers ought to buy them...

> No big deal ?
Depends. In a browsable title index, an annoyance, in
a keyword search, hardly, in record displays, mildly
irritating.

B.E.

---

From: Laval Hunsucker <[email-masked]>
Date: Fri, 25 Jun 2010 05:57:49 -0700

James Weinheimer  wrote :

> Yet, I feel that there is--or should be--a certain
> level of dumbing down that we should not
> transgress.

Sure, pragmatically you're bound to be right. But by
whom and on what basis should that level be
determined, I'm wondering ?

Dumbing down seems to me to be in fact something
we all do need, and have needed for a long time.
Only we presumably shouldn't call it "dumbing down",
because that's not what it is -- except in an arbitrary
sense, from *our* traditional perspective, here inside
our own cozy hortus inclusus, as long as it exists.

To many -- most ? -- in the rest of the world, what
*we* do and how we do it can and probably does look
really really dumb. ( Maybe even pathetic. )  To them,
what we might call dumbing down, they would
probably call smartening up. And why not ?  Who are
we to protest ?  Whose point of view matters more,
and whose less ?  Whence and how do we derive the
legitimization for labelling anything as dumb ?

Shouldn't we think long and hard what we mean, and
should mean, by terms like "dumb" and "smart" ?
( While always thinking all along  in the background
why it is we are doing what we are doing in the first
place. )

- Laval Hunsucker
  Breukelen, Nederland