As a library web developer with practical experience processing MARC data, I believe the first indicator of the 856 field is useless. It is useless for two reasons. First, the access method for a given URI is usually built into the URI itself. The vast majority of the URIs found in subfield $u of an 856 field will tell you the access method is, for example, based on the File Transfer Protocol (FTP) or the Hyper Text Transfer Protocol (HTTP). That is why our URIs have prefixes like ftp:// or http://. The second reason it is useless is because there is already a subfield $2 that can be used if you need to be explicit about what the access method is.

When I have MARC data that looks like the following (in pretty-print form, of course):

856 40 $u http://digital.library.wisc.edu/1711.dl/AldoLeopold $z Available through UW Digital Collections

That first indicator is redundant. I know that the access method is HTTP by the URI itself. Furthermore, if it was absolutely necessary, it could be coded like this:

856 40 $2 HTTP $u http://digital.library.wisc.edu/1711.dl/AldoLeopold $z Available through UW Digital Collections

This would free up a valuable indicator to be used to say whether the electronic location is for a resource with open access. A value of 0 could indicate not open access and a value of 1 could indicate open access. This could be taken a step further in the case where the resource is not open access. There could be a recommendation for local copies of the catalog record to use a subfield which says for whom access is restricted, such as, “Faculty, Staff and Students.”

At present I am working on a project that we have given the code name UW · Forward. Forward is a union index over the library collections within the UW System. Currently the UW System Libraries has 14 different ILS Catalogs, one for each of the 13 four year campuses and another one for all of the two year campuses. Forward searches the data across all libraries.

We deduplicate all of our MARC records so that we can have a single record for items held at multiple locations. As part of the process of deduplication, for certain MARC fields, we add all instances of a given field into the combined record. We do this for holdings represented in 852 fields and for URLs in 856 fields.

The Problem

MARC capture of URL description has proven to be inadequate in our context. We simply do not have the kinds of information coded in 856 fields to clearly present access to online representations of library items.

Licensed Content

When a particular campus has access to a licensed online resource, the local version of the URL used is incredibly important. The library in question usually needs to proxy the URL through a campus authentication & authorization mechanism to provide off campus access to databases and e-journals. These are arguably the most important online resources in our catalogs – they are not only carefully selected, like all online resources, they are also some of our patron’s preferred library resources and the ones taking up greater and greater percentages of the library budget.

This is where the first problem lies: the MARC 856 field does not provide any indication that a given URL is for a licensed resource that has restricted access. This problem is complicated by the fact that sometimes a UW System campus catalogs a URL in its proxied form and other campuses insert a proxy string at runtime. In this case the cataloged form of the URL is not proxied but the OPAC software inserts the proxy prefix when it outputs a web page. A “restricted access” or “deep web” indicator would be great here. Alas, the indicators are already reserved.

What makes this more complex here at the UW System is the fact that the Forward project is a union index and provides a single view for all campuses. So we have the added problem of not just telling the end user what the correct URL is, but for whom that URL is valid. Traditionally this kind of information is coded into the free text public note subfields (usually $z). As a free text field, the way any given library indicates that a URL is available only to certain users is all over the place. There is nothing consistent enough in our MARC records that come from multiple sources that I can address in code.

Free Online Resources

The free online resources that have been cataloged in our OPACs are also extremely problematic when introduced into a consortial/union context. The following scenario represents a huge missed opportunity. There are certain resources that have been cataloged by one or a few of the campuses within the UW System. A great example would be our own UW Digital Collection Center’s site for The Aldo Leopold Archives. Forward currently has a record for this archival collection, for which the data comes from a few schools within the UW System. A close inspection of the MARC data in question the staff view raises a few problems:

There are two URLs, each cataloged 6 times by different schools. However the digital collection that has been cataloged should clearly indicate that it is available to the entire patron base of faculty, staff & students from the entire UW System, not just the six schools who contributed records. We are missing an opportunity to let the other schools who did not catalog the resource themselves benefit from the cataloging provided by the 6 schools that did catalog this digital collection. Again, it would be nice to have an indicator which states this is an “unrestricted free online resource”. The same indicator but opposite value as what is needed for licensed online resources.

Furthermore, there is no agreement among the schools who did catalog the resource as to whether the URLs in question are for the thing itself or a related resource. Notice the way that the second MARC indicator is applied inconsistently in the 856 fields. Some campuses consider both URLs to be related to this resource, while one school thinks one of the URLs is for the resource itself and another thinks that both URLs are the resource itself. The inconsistencies here make it impossible to write code that efficiently displays to an end user how to use the resource in question, which is to say that the descriptive function of the cataloging in question is failing in our unified context.

Steel cage grudge match!

In this corner we have Licensed Resources, weighing in at a hulking 60% of your library budget. In the opposite corner are Free Resources, nimble, agile and known to fell a giant or two. Get your tickets. The fight will be phenomenal and sensational.

Finding solutions that make sense for free online resources are proving to be the opposite solutions that work for licensed content. For example, for free content, the best thing to do is drop any affiliation with the school who cataloged the resource in question, deduplicate the set of URLs and display a small set of links to everyone. However, for licensed content the affiliation between school and URL is important so that the end user can authenticate and prove she has the credentials to use the resource in question. And all the while there is nothing in the MARC data that tells me a given URL is restricted to a particular subset of the population for whom we intend will use our union catalog.

This is a keen insight in my view since it really begins to get at the fun stuff that the Googles, Amazons, etc are doing with data that libraries long to do with bibliographic data. Coyle starts to articulate something here that I have not been able to put my finger on: the way that FRBR is a huge step forward but still only has an eye toward an implementation rooted in the way libraries have traditionally done things.

My library right now has been in discussions about subject guides and how to best build and provide access to them. I have felt for some time now that it would be great to get out of a next-generation catalog a system that imparts the kind of knowledge our librarians and subject liaisons put into these projects. Coyle’s post renewed this thought by framing the new catalog model in terms of a “Knowledge Management system,” which to my mind is the true aim of a discovery system.

In the past when I have tried to express a hybrid of a next-generation catalog and a subject discovery tool, I have always framed it in terms of applying graph theory to bibliographic data. I think Coyle’s post helps me to understand this. It seems obvious to use subject terms and call number ranges as one type of edge/vertex for nodes which are bibliographic items. However, her discussion raises the possibility of a new set of different kinds of edge types: translations, abridgements, extensions, etc.

More on this later…

It’s easy to get all Web 2.0 starry-eyed about this, perhaps partly because our catalog has been so ghastly for so long. People talk about social recommendations, comments, tags, structured blogging, and so on. There are a few problems with going down this road, though:

1. Other people are alerady doing this, well, and for free.
2. The Information Superhighway is littered with the charred-out husks of failed social networks. (Did you know Amazon added tagging a year ago? Have you ever used it?)
3. Library catalogs, by definition, contain only your library’s stuff.

The first two points might be surmountable (and are really the same thing anyhow), but the third is the killing blow to any idea of catalog-as-research-tool. Amazon has more data than you. Google Books has more data than you. Worldcat has more data than you. The thing you need to do your research may be at someone else’s library; this is why we have ILL, after all. Using the OPAC to do research means you’ll miss out on everything that’s not local. We can’t fix that. All of the social networking, “More about this book,” “More books like this,” and so on are all based on using the OPAC as a research tool. We just shouldn’t do that.

The place where our catalog can excel, the place where no one can compete, is in finding things already in our collection. Try using your Voyager-based catalog to find out where a particular book (or journal volume) is. Want extra credit? Try finding a NASA technical report. For some stuff, it’s nearly impossible to do, even for librarians. The number of times I’ve heard a librarian say “Well, I just know this is probably over here…” makes me want to scream. We’re using a catalog that indexes all of our millions of things so badly that our librarians often need to ask other librarians to help find things that are sitting on a shelf or in a file drawer.

It’s shameful.

So… I’m happy to wait on all of the Web 2.0 goodness until we’ve mastered the Web 1.0 thing.

Elaine Svenonius in The Intellectual Foundation of Information Organization traces the timeline of what I would call major missteps that we are only now beginning to recover from in library land. It goes something like this:

1. Cutter stated his cataloging objectives which importantly included what Svenonius calls the collocating objective
2. Lubetzky states his objectives and formally introduces the work/document distinction. His formulation was essentially adopted as the Paris principles.
3. IFLA only corrects this mistake of omission 36 years later

Cutter’s original collocating principle is ignored in favor of a conceptualization that places a heavy emphasis on books/bibliographic items as uniquely identifiable things. It is only later in 1997 that IFLA reformulates and modernizes the objectives, which leads us to the current state of debate over FRBR and the new (old) world of facets. This is the point at which Svenonius hits the nail right on the head:

The traditional finding objective specifies that what is to be found is a particular known document, while the traditional collocating objective specifies that what is to be found is a set of documents, defined by criteria such as author, work, and subject. The first IFLA objective integrates these into a single finding objective. While this is logical and introduces a certain elegance of expression, at the same time it diminishes the importance of the concept of collocation. This concept is well entrenched in bibliographic discourse. It is particularly useful for the emphasis it gives to what in the first instance is the primary act of information organization — bringing like things together. Both for its set-forming connotations and its ties to tradition it is too valuable to lose.

- Chapter 2, section on traditional objectives

The final emphasis is mine. While uniquely identifying an item is important this is going to happen whether we like it or not since it is an inherent feature of any system that functions at the most simplistic level. Now for an incredibly long time leading up to the current era cataloging was rooted in identification of bibliographic items at the expense of collocation of bibliographic items. Adding to the significance of this, during the era of mass digitization of bibliographic records (we can call it the Gorman era), this is the model that was used: identify.

In the past few years we have seen library land, with more tradition, history and rich data than anyone else in the world, get trounced by corporations and mashups who understand that you can get miles farther with vastly simpler description of the physical item if you give people something more important: collocation. People who bought this also bought this.

It boggles my mind why more librarians don’t seem understand this: we will never have to make the sales pitch to other bibliophiles, those people already understand the value of a book or other bibliographic entity. Anyone who obsesses over the edition of a book and who it was that wrote the introduction or preface is probably already sold on the value of libraries. It is the people who don’t understand how rich a library collection is that we need to spend our efforts seducing. We can do that by weaving the web: description should be base on 21st century collocation, not that old sixties issue, identity.

Karen Coyle has is right and Renear/Choi are confused in there concept of FRBR Group 1 entities. Coyle states, “I tend to consider all aspects of metadata to be abstract in nature, since it is a representation of something else.” Renear/Choi state

The argument is simple: FRBR describes works as abstract and items as concrete. If all properties of “higher” entities are inherited by “lower” entities then items inherit the property of being abstract, and therefore items will be both abstract and concrete. But nothing is both abstract and concrete – therefore there is no unlimited general property inheritance in FRBR.

They mistakenly seem to think that because works model something abstract that the model has some kind of “is-abstract” attribute or property while items, which model concrete things have an attribute on par with “is-concrete”.

There is no “is-abstract” attribute for works, expressions or manifestations and there is no “is-concrete” attribute for items. The attributes of an item might be things like “copy number” or “location code.” The attributes of works might include a unique identifier that serves as a reference to collocate related expressions. However, that ID is still a concrete thing (likely an integer, see below). Or a work might have an attribute like “uniform title”. Expressions might add an attribute like “transcribed title” or “language”. Manifestations … well, you get the point. (See, for example, page 32 of the FRBR document.)

There is nothing abstract about an implementation of FRBR. Even if the Work was represented as nothing more than an arbitrary identifier in a system, it is still a concrete thing. Works may be no more concrete than integers, but it is important to remember that in a modern system integers are the thread that binds together the cloth of the fabric of content in a RDBMS. The work entity is simply the thread that binds together the more substantial entities one level down: the cloth-like expressions.

The hierarchy of the inherritance relationship still works because there is no logical conflict between any attributes of a work and any of an item. Renear/Choi come close to acknowledging this in their paper:

It may be objected that this argument is sound but irrelevant as the only properties ever at issue were the attributes (or attribute values, or attribute/value pairs) explicitly specified in FRBR. So for the work entity the only relevant properties are ones such as title, form, context, and so on; but not the property of being abstract. On this account only specified attributes (and/or attribute values) are inherited and the argument given does not apply as “abstract” and “concrete” are neither attributes nor attribute pairs. We believe that even this limited version of inheritance is misconceived, but before presenting our arguments against it we explore it further.

But what I think they miss is that works do not have a property of abstraction at all. I am not sure that Romeo and Julliet the work has any property of abstractness. As Meriam Webster points out “the word poem is concrete, poetry is abstract.” However, investigating the properties of poetry (being the productions of a poet, being poetic) we do not find a property corresponding to abstractness. It is the same with FRBR entities. “A work is an abstract entity” (FRBR document), but that does not mean that Romeo and Julliet the work has the property of abstractness.

Is this moot anyway?

The conflict they raise may actually be desirable. I think there is a bit of a tension between a theoretical model here and a practical model. I live in a practical realm and think about ways to implement a FRBR-based application. In the practical world there is at least one important solution to the conflict of interest that Renear/Choi raise: overriding an attribute (or behavior).

Take a programming language like Java as an example. In Java it is possible to override the behavior or attributes of an inherrited class in a subclass. In implementing a system and working in one of the prominent object-oriented programming languages you might be able to define works as abstract and items as concrete. This could then have useful implications in the display of items in your collection. A user interface could browse works and items differently. When just looking at lists of items you see things that you do not when merely taking a look at the work-view of a bibliographic entity (such as a shelf location).

• Gimme Shelter a hook
• What I wouldn’t give, for just one f!#$ hook

The bane of my existence for the past couple of weeks has been the lack of a universal identifier for electronic resources like databases and full text aggregators. When trying to match records between one system and another, e.g., a link resolver and catalog, an ISSN is a blessed thing. Why, oh, why can’t I have one for my database resources? Sure, there are OCLC numbers, but there is no incentive to add such a thing to a system that does not participate in cooperative cataloging.

-Sad Librarian

So I stumbled upon something that left me a little bit shocked: unless I am missing something, the iTunes music program does not provide a display for the record label of a given song. Does it strike anyone else as odd that this little bit of bibliographic description does not make the cut for the popular music catalog of the iPod era? Am I just a librarian for thinking this is odd or is “record label” beyond the 4/4 time signature of what is needed to identify and browse a music collection?

(I did check and it turns out that the Gracenote CDDB that provides the service for the getting track names into iTunes does contain a much richer bit of metadata for an album than Apple uses in its program. So it appears to be a conscious decision to use a weak set of descriptive elements.)