how we might bundle holdings info with bib info

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

how we might bundle holdings info with bib info

Naomi Dushay
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?


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


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: how we might bundle holdings info with bib info

Alan Rykhus
Hello Naomi,

My take on this is to embed the information in a 9xx field, multiple
fields if there are multiple holdings. As for the information to embed,
I'm looking at(because I have it implemented):

institution (we're a consortia)
sub-library - facet
collection- facet
availability - facet
call number (I have a hard time with anything but display, as a
consortia each institution uses a different type of call number)

In talking to our librarians the information above is enough for display
and searching purposes. Since there is a link to a dynamic view of
holdings in the record(at least using Aleph) the additional information
is available there, due date, itemized serial holdings, status, etc.
that I see no reason to input the data into the Solr/Lucene database.

As for trying to get every vendor to come up with a standard format for
putting the holdings in a standard format. Noble idea, but I've worked
around multiple vendors for too long, its probably not going to happen.
Having the ability to configure for each different system is the best
you are going to do.

I do have the above fields implemented. I'm still loading the last 3
million records on my new schema, so my site is a little slow and is
only returning partial result sets. But you can see an implementation to
start comments with.

http://vufind.mnpals.net

al

On Fri, 2008-06-27 at 12:58 -0500, Naomi Dushay wrote:

> 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&amp;searchTerms=harry+potter&searchClass=keyword
> > > >
> > > > MARCXML (view source):
> > > > http://dev.gapines.org/opac/extras/opensearch/1.1/-/marcxml?searchOrg=PINES&amp;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&amp;searchTerms=harry+potter&searchClass=keyword
> > > >
> > > > OAI DC:
> > > > http://dev.gapines.org/opac/extras/opensearch/1.1/-/oai_dc?searchOrg=PINES&amp;searchTerms=harry+potter&searchClass=keyword
> > > >
> > > > RSS 2.0:
> > > > http://dev.gapines.org/opac/extras/opensearch/1.1/-/rss2?searchOrg=PINES&amp;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
> [hidden email]
>
>
>
>
>
--
Alan Rykhus
PALS, A Program of the Minnesota State Colleges and Universities
(507)389-1975
[hidden email]


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: how we might bundle holdings info with bib info

Steven McPhillips
In reply to this post by Naomi Dushay
Hi Naomi,

This is only a small response to your email, which raises a lot of issues. For stuff like item availability and due dates, I think you need to determine these at real time in some/all cases. That either means real time updates to SOLR, or talking to your ILS circulation module. We've opted for the latter, which works well for us. I don't know too many systems that incorporate realtime SOLR updates effectively, because every commit is going to flush the index caches which take time to re-warm.

A lot of our holdings information is provided from our ILS at runtime, either through the VuFind driver approach (getHolding()) or other dastardly means. We do import holdings callnumbers and embed them in our bib data to create callnumber indexes, but definitely not in a compliant manner. We've extended the getHolding() routine to extract additional information, like stuff in the 852 field and various item-level notes.

I'm not saying this is the best way to do things, but it's been good enough for us to date. I do like the idea of creating a bundled import package though and can see the benefits such a method would bring.

Steve
________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Naomi Dushay [[hidden email]]
Sent: Saturday, 28 June 2008 3:58 AM
To: [hidden email]
Subject: [VuFind-Tech] how we might bundle holdings info with bib info

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
[hidden email]<mailto:[hidden email]>




-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: how we might bundle holdings info with bib info

Andrew Nagy-2
In reply to this post by Naomi Dushay

Wow - this is a really long email.  Let's take 1 bit at a time otherwise we will all get too confused - all really good discussion topics though.  Maybe this would be a great conversation for an Open Source OPAC conference in the September timeframe ;)

 

One thing to keep in the back of your mind when thinking about how this can be done as a collective effort - we need to keep the Jangle OS project community in the loop as this is something that that community will want to tackle as well.

 

I think this can be accomplished from the ILS Driver perspective with the getHolding method.  It can be extended as Steven has done.  I could see a script - similar to the marc importer - that imports marc holdings.  Maybe this could be an extension to SolrMarc?

 

Andrew

 

 

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?

 

 


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: how we might bundle holdings info with bib info

James Farrugia
For MARC holdings per se, if I understand Andrew right, yes this could be done with via getHolding
and a corresponding script on the server end. Has anyone done this yet?

For other, broader questions about holdings more generally and batching things,
would it make sense to contact NC State, which is using Endeca, and see what they
decided to do and how (they're on Unicorn)?

Jim

>>> On 6/30/2008 at 9:58 AM, Andrew Nagy <[hidden email]> wrote:
> Wow - this is a really long email.  Let's take 1 bit at a time otherwise we
> will all get too confused - all really good discussion topics though.  Maybe
> this would be a great conversation for an Open Source OPAC conference in the
> September timeframe ;)
>
> One thing to keep in the back of your mind when thinking about how this can
> be done as a collective effort - we need to keep the Jangle OS project
> community in the loop as this is something that that community will want to
> tackle as well.
>
> I think this can be accomplished from the ILS Driver perspective with the
> getHolding method.  It can be extended as Steven has done.  I could see a
> script - similar to the marc importer - that imports marc holdings.  Maybe this
> could be an extension to SolrMarc?
>
> Andrew
>
>
> 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-D 
> I-Snapshot-2008-Feb15.doc


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech
Reply | Threaded
Open this post in threaded view
|

Re: how we might bundle holdings info with bib info

Naomi Dushay
In reply to this post by Andrew Nagy-2
Andrew,

I'm happy to include jangle in the discussion loop.

Perhaps the ideal would be for a package to be able to batch load bib feeds OR holdings feeds OR bib and holdings combined feeds.  I would love to see solrmarc expanded for this.  *I* may have to expand solrmarc for this, if we don't suck it up with the holdings -> bib rec shoehorn method.

One tricky bit would be getting the single feeds to correctly update the appropriate existing documents (as this would depend on which fields are stored in the index).

The ILS Driver method is great for real time queries to the ILS, but I don't think it's going to be the preferred method for batch.

And Stephen is right to point out that the information we most desire, at this time, via batch is:

call numbers
library building
institution?  (for consortia?)

Extra credit:  what sort of acquisitions information might be valuable for discovery?  ("on order"  "expected 8/2008" )  What about other non-bib information?

- Naomi


On Jun 30, 2008, at 6:58 AM, Andrew Nagy wrote:

Wow - this is a really long email.  Let's take 1 bit at a time otherwise we will all get too confused - all really good discussion topics though.  Maybe this would be a great conversation for an Open Source OPAC conference in the September timeframe ;)
 
One thing to keep in the back of your mind when thinking about how this can be done as a collective effort - we need to keep the Jangle OS project community in the loop as this is something that that community will want to tackle as well.
 
I think this can be accomplished from the ILS Driver perspective with the getHolding method.  It can be extended as Steven has done.  I could see a script - similar to the marc importer - that imports marc holdings.  Maybe this could be an extension to SolrMarc?
 
Andrew
 
 
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?
 
 

Naomi Dushay




-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Vufind-tech mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vufind-tech