Re: [VuFind-General] Holdings in Multiple Libraries

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Hi

I have a similar problem to John, and this is something I have been meaning to look at also, but I don't have the location data in the MARC record.  I can extract them by location but I have separate MARC files to load for each building, so the same MARC record  can end up in two separate loads.  There are some MARC records that represent items in multiple buildings, so the last batch of records I load ends up with the one and only building value.  Is there any way to tell the loader to append to field across subsequent loads? Or merge fields as the loads progress??  Any ideas or pointers would be appreciated.

Steve

Steve Bischof
Systems/Discovery Librarian
Wesleyan University
CTW Library Consortium
Middletown, CT

-----Original Message-----
From: John Houser [mailto:ho...@hs...] 
Sent: Thursday, March 04, 2010 9:15 AM
To: Till Kinstler
Cc: vuf...@li...
Subject: Re: [VuFind-General] Holdings in Multiple Libraries

Till,
I have one bib with holdings in a 9xx field. This is very helpful!  

J

On Mar 4, 2010, at 9:03 AM, Till Kinstler wrote:

> Hi,
> 
> what's you original data like? Do you have one MARC record having multiple holding entries for multiple locations? If so, you don't need to split the MARC records by location. Instead extract the multiple locations from the record using a beanshell script and put all these values into the building field.
> 
> I just did something similar. In my data, holding information is in MARC field 900, the location is in 900 $d. Here is my beanshell script, I think you may easily adopt it (eg. if your location data is in some other field than 900 $d simply change the 900 and d values in getVariableFields and getSubfield calls below):
> 
> import org.marc4j.marc.Record;
> import org.marc4j.marc.ControlField;
> import org.marc4j.marc.Subfield;
> import org.marc4j.marc.DataField;
> import org.solrmarc.tools.Utils;
> import java.util.regex.*;
> 
> org.solrmarc.index.SolrIndexer indexer = null;
> 
> Set getLocation(Record record, String standortmap) {
> 
>  Set result = new LinkedHashSet();
> 
>  List signatures = record.getVariableFields("900");
>  Iterator i = signatures.iterator();
>  while (i.hasNext()) {
> 
>    DataField signature = (DataField)i.next();
> 
>    Subfield sig = signature.getSubfield('d');
>    if(sig != null && sig.getData() != null) {
>      result.add(sig.getData());
>    }
>    else {
>    // default value if there is no 900 $d
>      result.add("unknown");
>    }
>  }
>  return result;
> 
> }
> 
> Take that script save it as getLocation.bsh in import/scripts/ and add a line
> building = script(getLocation.bsh), getLocation
> to import/marc_local.properties.
> If there are multiple locations, it returns multiple values and solrmarc puts them into multiple building fields in the index.
> If you need to do more with the location data you get out of the record (I need to expand them using a translation map), that's easy top add to this script. If unsure, just ask.
> 
> Till
> 
> John Houser schrieb:
>> Hi!
>> I'm working on an installation that will serve a number of libraries with overlapping holdings. It's not clear to me how to tell Solr that a given record is held by more than one institution or building. I would very much like the overlapping holdings to
> be reflected in the Institution and Building facets. Right now, I have written a utility to split my data into files for each institution and building combination. But the order loaded determines who ends up with the record. Any pointers to where I need to be looking or what approaches might work would be much appreciated. 
>> My second issue is that we would like patrons to be able to select a library up front. I see that Minnesota and Michigan have done this. Anyone have any code or templates they'd be willing to share? I'm running a recent build of RC2 in order to get the D
> ewey support, and would be happy to integrate changes with the new release.
>> Because our initial group is all public libraries, we'll also be supporting Dewey call numbers. I'd welcome any discussion of issues/solutions with regard to Dewey support.
>> Thanks!
>> J
>> --
>> John Houser
>> Technology Coordinator
>> HSLC
>> 215-534-6820
>> ho...@hs...
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> VuFind-General mailing list
>> VuF...@li...
>> https://lists.sourceforge.net/lists/listinfo/vufind-general
> 
> 
> -- 
> Till Kinstler
> Verbundzentrale des Gemeinsamen Bibliotheksverbundes (VZG)
> Platz der Göttinger Sieben 1, D 37073 Göttingen
> kin...@gb..., +49 (0) 551 39-13431, http://www.gbv.de

--
John Houser
Technology Coordinator
HSLC
215-534-6820
ho...@hs...

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
VuFind-General mailing list
VuF...@li...
https://lists.sourceforge.net/lists/listinfo/vufind-general