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.
"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?
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?
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:
<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>
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.