Hi everyone.  Once again I apologize for a long, dense posting.  

Stanford is not currently not putting holdings information into a marc bib 9xx field when exporting bib recs from our ILS, which is what everyone else seems to be doing to get holdings info into VuFind.  I'm raising a bunch of questions because I think there might be a better way: in particular, a better way for libraries with complex holdings especially.  Perhaps Stanford should just suck it up -- but right now, I lack a great deal of pertinent information, and I'm looking for the collective wisdom of the community.

Wayne, Jim and I have been having quite the discussion on the vufind-unicorn list about bundling holdings info with bib info for batch loading into vufind, and the best way to express this information. The information I'm talking about is stuff like: the call number, library building, the availability, the date due, the other location (on shelf, checked out, missing, etc.) and anything else we deem useful for users in the discovery phase.  I don't know if this information is considered "holdings" or  "item" info;  I use "holdings" as a generic term below.

Here are some motivations:

1.  facets for library building - larger campuses often have many library buildings, and users presumably want to find out what materials are a long walk away, or which library building has the largest number of relevant resources, etc.

2.  browsing by call number - we can't do this unless the call numbers are batch loaded (all the call numbers in all our current holdings recs!)

3.  having accurate serials holdings information displayed in vufind (not sure how related this is to the other issues) 

4.  having access to both bib and all relevant holdings information at indexing time.

There seem to be two approaches to expressing holdings information.  From a doc at  http://www.oclc.org/support/documentation/localholdings/primer/holdingsprimer.pdf 

"Separate vs. Embedded Holdings. The MARC 21 formats give libraries two options to record their holdings data:
§ Create a separate holdings record linked to the bibliographic record.
§ Embed the holdings data in the bibliographic record. 
Typically, if the library has chosen to embed its holdings data, the data consists of only the data elements needed to locate the item within the library (the locations data Data Area). [...] If the library has chosen to record its holdings separately, and link to the bibliographic record, then it can record more data elements, more holdings locations, and the fact that they hold multiple copies of the item. [....] The “separate but linked” approach also allows the library to implement the multiple options allowed by the Z39.71 standard (see page 6) when dealing with multiple formats."

Here are some important pieces of information I don't have:

1 how holdings records are used for monographs vs. for serials, general practices, Stanford local practices, blah blah.

2.  what  ways can we programmers get the call number, the location (building), the availability, the date due, the other location (on shelf, checked out, etc.) and anything else we deem useful for discovery from our respective ILS?    For example, Unicorn has API commands:  you can get the item rec (with call number info) as xml, but the bib rec is output as marc 21. 

3.  can we, the vufind community, collaborate on a standard approach and common code (as much as possible) to get all this information fed to VuFind, across ILS vendors?   
3a. Would that be a marc 21 holdings record  (see http://www.loc.gov/marc/holdings/echdhome.html ) ?  
3b. Would that be a standard way of embedding the information into a marc bib 9xx field (or other)?  (the same field?  the same use of the same subfields?) 
3c. Would it be both?
3d. Would it be an xml format?

See also DLF's ILS-Discover Interface task force http://project.library.upenn.edu/confluence/download/attachments/5963787/ILS-DI-Snapshot-2008-Feb15.doc

4.  when an ILS stores holdings separately from the bib record, is information lost when the same holdings information is embedded into the bib record?  The oclc holdings primer quoted above implies the answer is yes.  
4a. If information is lost by embedding, which information is lost?   Anything likely to be useful for discovery?
4b. does this have anything to do with why getting serials holdings information into vufind is difficult?

5.  should we care about minimizing differences in methodology for importing monograph holdings vs. serials holdings (vs. other types of holdings)?

Stuffing the holdings info into a marc bib 9xx field *may* be the best approach, but the notion of putting holdings information into a bib rec "smells" to me.  It feels like it's a kludge, and it needs refactoring.  Yes, I want to have the holdings bundled with the bib data ... but not necessarily smushed together.  A salad, not a soup.

 What if we got data to index in bundles that looked something like this:

<record>
   <uniqueId>[blah]</uniqueId>
   <marc>[marcxml of bib rec]</marc>
   <item>[xml representation of holdings info for item rec 1]</item>
   <item>[xml representation of holdings info for item rec 2]</item>
</record>

It would be easy to index the xml above as a solr/lucene document with unique id of [blah], bib information gleaned from the marcxml and holdings info gleaned from the xml for the holdings/item recs.

In order to get these xml records from ILSs, I'm thinking the "drivers" for the different ILS vendors would work as follows.  The driver code that lives with VuFind would always get the same sort of xml bundle.  The code that is more closely tied to the ILS (for Unicorn, the cgi script that lives on the Unicorn box) would, for each bib record, convert it to marcxml, then get the xml for the related item/holds records, and combine all these into the xml above.

Wayne has already expressed concerns about scaling this;  we would hopefully be able to batch up requests for records, which could reduce the problems.

Wayne also pointed us to the OpenSearch service that returns (more complete?) holdings info in marc bib 999 fields - See below

I'm really interested in folk's reactions.

On Jun 25, 2008, at 7:08 AM, Wayne Graham wrote:

Ok, I know this isn't exactly Unicorn, but I was reading through my
code4lib mail and thought it was along the lines of what we've been
discussing. Their OpenSearch service returns results in 15 different
formats, which is pretty impressive (examples below).
When I looked at the MARCXML, I noticed that they were returning  
holding info with their own xmlns (http://open-ils.org) along with
some other information (xhtml links). I think this is really a good
example of what Naomi was talking about in developing a service that
could display the info differently.

Wayne

===========================================

HTML, with links:  
http://dev.gapines.org/opac/extras/opensearch/1.1/-/html-full?searchOrg=PINES&searchTerms=harry+potter&searchClass=keyword

MARCXML (view source): 
http://dev.gapines.org/opac/extras/opensearch/1.1/-/marcxml?searchOrg=PINES&searchTerms=harry+potter&searchClass=keyword

MARCXML with some extensions (view source):
http://dev.gapines.org/opac/extras/opensearch/1.1/-/marcxml-full?searchOrg=PINES&searchTerms=harry+potter&searchClass=keyword

MODS: 
http://dev.gapines.org/opac/extras/opensearch/1.1/-/mods3?searchOrg=PINES&searchTerms=harry+potter&searchClass=keyword

OAI DC: 
http://dev.gapines.org/opac/extras/opensearch/1.1/-/oai_dc?searchOrg=PINES&searchTerms=harry+potter&searchClass=keyword

RSS 2.0: 
http://dev.gapines.org/opac/extras/opensearch/1.1/-/rss2?searchOrg=PINES&searchTerms=harry+potter&searchClass=keyword

and even a catalog card mock-up:
http://dev.gapines.org/opac/extras/opensearch/1.1/-/htmlholdings?searchOrg=PINES&searchTerms=harry+potter&searchClass=keyword

--
/**
* Wayne Graham
* Earl Gregg Swem Library
* PO Box 8794
* Williamsburg, VA 23188
* 757.221.3112
* http://swem.wm.edu/blogs/waynegraham/
*/
Naomi Dushay
ndushay@stanford.edu