Re: [Koha-devel] switching from marc_words to zebra [LONG]
7 July 2005 Quoting Paul POULAIN <paul.poulain@free.fr> :
---------------- 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,
certainly advocate moving towards full use of the available
perhaps one should approach the question by degrees to
http://www.ifla.org/VI/8/projects/UNIMARC-HoldingsFormat04.pdf . I would formats but 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 Koha-devel@lists.sourceforge.net 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
Thomas D a écrit :
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? (back from vacations)
For 2 reasons : - because $3 is unimarc-specific & we want to be marc-flavour independant - if we want to use $3 only, then we have to use either an internally number or an external one, depending on wether we use a local authority entry or a public one (like Rameau thesaurus, for example, where $3 is FRBN045646897987...) that's more complex to developp ( & the less i do the better i feel, shame on me ;-) ) -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
participants (2)
-
Paul POULAIN -
Thomas D