Re: [Koha-devel] switching from marc_words to zebra [LONG]

[Thomas D]

7 July 2005


Quoting Paul POULAIN <address@hidden> :
> ---------------- Beginning of the original message ------------------

[snip]

> >>It should really not be a pain to move to zebra with this
> >>structure : 
> >>every call with a MARC::Record (NEWxxxxyyyy subs) manages
> the
> >>storing of 
> >>the MARC::Record in marc_* tables. We could replace this
> code
> >>with a 
> >>zebra insert/update, using biblio.biblionumber as primary
> key.
> >>How to manage biblios and items ? My idea here would be to
> >>store biblio 
> >>+ all items informations in zebra, using a full
> MARC::Record,
> >>that 
> >>contains biblio and items.
> > 
> > 
> > For MARC21, would you use the 852 holdings location and
> other fields in MARC
> > bibliographic?  MARC21 has a MARC holdings format as a
> separate record type
> > from MARC bibliographic,
> http://www.loc.gov/marc/holdings/echdhome.html . 
> > UNIMARC now also has a UNIMARC holdings format as a separate
> record type,
> >
> http://www.ifla.org/VI/8/projects/UNIMARC-HoldingsFormat04.pdf
> .  I would
> > certainly advocate moving towards full use of the available
> formats but
> > perhaps one should approach the question by degrees to
> preserve development
> > resources.
> 
> In UNIMARC, there is also what we called "recommandation 995" 
> (http://www.adbdp.asso.fr/outils/infogestion/r995.htm, in
> french).
> I know no ILS using HoldingsFormat04.pdf description. All uses
> "reco 
> 995", that simpler by far.
> 

I have found a helpful summary of some French UNIMARC issues.  Lahary,
Dominique. UNIMARC as a cataloguing format in France : 64th IFLA General
Conference. IFLA, 1998, http://www.ifla.org/IV/ifla64/111-161e.htm . 
Recommendation 995 is not an IFLA standard but as long as it is supported as
a standard for French public libraries that is fine.  My concern was
adhering to a recognised standard.  Preferably a simple one at first.

Recommendation 995 does not seem to offer a means for machine parsing of
holdings enumeration for serials.  On that account and a few others, it has
strong disadvantages for academic libraries.  Machine parsing of serials
holdings is very important for reducing the administrative burden of OpenURL
link resolvers.  I expect that the UNIMARC holdings format is too new to
have many adopters yet.

Although OCLC will be adopting the MARC21 holdings format this autumn, much
of what is useful in the holdings format already has a place in MARC
bibliographic.  The Koha MARC21 framework is missing some of the most
helpful fields for enumerating serials holdings in a machine parsable
manner.  This is correctable by the user and may be most significantly a
problem for most easily administering OpenURL link resolvers.  There are
other omissions from the default framework such as the leader and the fixed
fields that are much more significant but can also be corrected by the user
and can be addressed by the model change for Zebra.

> > Curiously MARC21 and its predecessors seem to have left this
> out of the
> > format.  Only the thesaurus is given in the MARC21 record. 
> The method of
> > matching a thesaurus control number is left to the system
> implementation. 
> 
> That's exactly what we do in Koha, as we use the $9 (system 
> implementation ;-) )
> This lack makes hard to exchange biblio between libraries.
> 

Why would you need to use $9 in UNIMARC when you have $3 in the UNIMARC
specification?

I have asked on other lists about how standard implementations address this
authority control problem for MARC21 bibliographic and I am awaiting any
answers.  Unfortunately, my recent posts to the MARC list seems to have
fallen into the moderator's black hole.

There is a recent discussion on the MARC list with the usual negative answer
about the recurring question of MARC in relational databases.  A similar
negative view has been expressed about XML really offering a way around the
problem.  There is a mention how existing systems represent MARC data from
the ever well informed and insightful Karen Coyle.  She gives a similar
description to the one Joshua had given me about how this may be
implemented.  Coyle, Karen. Re: Marc in relational databases : MARC. (July
6, 2005).
http://listserv.loc.gov/cgi-bin/wa?A2=ind0507&L=marc&T=0&F=&S=&P=957 .  It
would be fantastic if Karen could be persuaded to take an active interest in
Koha.  She is retired from the California Digital Library but I imagine she
has plenty to keep herself busy.

> -- 
> Paul POULAIN
> Consultant indépendant en logiciels libres
> responsable francophone de koha (SIGB libre
> http://www.koha-fr.org)
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration
> Strategies
> from IBM. Find simple to follow Roadmaps, straightforward
> articles,
> informative Webcasts and more! Get everything you need to get
> up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id?492&op¿ick
> _______________________________________________
> Koha-devel mailing list
> address@hidden
> https://lists.sourceforge.net/lists/listinfo/koha-devel
> 
> ------------------- End of the original message ---------------------


Thomas D

---------------------------------------------
Protect your mails from viruses thanks to Alinto Premium services 
http://www.alinto.com