Hello. I've been slowly building a path to migrate data from various data sources into koha, and am now at the point where I want to improve the translation. My process so far is this: I'm dumping data to MODS format, and converting to MARC XML with some LoC stylesheets. After that, I can convert to binary MARC with the perl MARC::File::XML package, and import into Koha with its bulk import script. I've had to modify the LoC stylesheets somewhat, and will need to modify them more, but otherwise the existing tools have worked okay. I've noticed a bit of data loss going into Koha. For example, I can't find the series title anywhere, even though it's in the marc database as field 440a, and is mapped to biblio.seriestitle. It seems to work during searches, but is never displayed. Is this a template problem? If possible, I'd also like to populate the koha inventory during import. Can I set a 9xx field to indicate the number of items in stock, and create other similar koha-specific data that way? There are also various other data fields I'm not sure where to put. Bibliographic data about authors, short book review blurbs, awards each book has won, text from the back of the book, type of material (novel, screenplay, poem, etc: not the regular MARC types), genre, urls for books/authors/series, author pseudonyms, quotes from books/authors/series, and a few others. Any idea how to fit these into MARC? -- Scott
Sunday, August 1, 2004 20:34 CDT Hi, Scott, I have the answer to at least a few of your questions, and your questions point to something I was trying to understand about how Koha handles MARC, so hopefully I'll end up with an answer to one of my questions, too. ----- Original Message ----- From: "Scott Scriven" <koha-main@toykeeper.net> To: <koha@lists.katipo.co.nz> Sent: Sunday, August 01, 2004 8:26 PM Subject: [Koha] importing, marc mapping, progress
Hello.
I've been slowly building a path to migrate data from various data sources into koha, and am now at the point where I want to improve the translation.
My process so far is this: I'm dumping data to MODS format, and converting to MARC XML with some LoC stylesheets. After that, I can convert to binary MARC with the perl MARC::File::XML package, and import into Koha with its bulk import script. I've had to modify the LoC stylesheets somewhat, and will need to modify them more, but otherwise the existing tools have worked okay.
I've noticed a bit of data loss going into Koha. For example, I can't find the series title anywhere, even though it's in the marc database as field 440a, and is mapped to biblio.seriestitle. It seems to work during searches, but is never displayed. Is this a template problem?
This is one of the things I was concerned about: how Koha handles the data from MARC records. Stephen, Joshua, other cognoscenti: is Scott's problem here because of a mapping error? something that needs to be defined in MARC parameters?
If possible, I'd also like to populate the koha inventory during import. Can I set a 9xx field to indicate the number of items in stock, and create other similar koha-specific data that way?
# From what has been said before in answer to various questions, that should be okay.
There are also various other data fields I'm not sure where to put. Bibliographic data about authors, short book review blurbs, awards each book has won, text from the back of the book, type of material (novel, screenplay, poem, etc: not the regular MARC types), genre, urls for books/authors/series, author pseudonyms, quotes from books/authors/series, and a few others. Any idea how to fit these into MARC?
This is the part I am most familiar with, Scott, so here we go: 1. I'm not 100% certain what you meant by "bibliographic data about authors", Scott. Normally, bibliographic data about authors is covered in the 100 and 700 fields and is limited to the establishedt forms. (N.B.: $g subfield is not normally used for adding publicly available information.) If you mean, however, having additional information -- something I've never seen proposed but I applaud your enthusiasm! -- I should think you could use a 500 General Note or adapt a particular 59x note and establish its function in that way as local usage. Although I was taught that the 545 note, Biographical or Historical Data, was mainly used for archival collections, if you meant offering a bibliography of the author's/authors' works, perhaps you could use that field for it. Its first indicator even allows for the distiniction of Associated (0) and Related (1) materials. 2. "... short book review blurbs ..." That's easily a 520 $a, first indicator "1" (Review). 3. "... awards each book has won ..." Your basic 586. 4. "... text from the back of the book ..." Often provided as (part of) a 520. In what I have experienced, usually there is only a very brief 520 given for works of fiction, often just providing a sketch of the plot or a little added info about the book. 520 is a repeating field, so you could have more than if you want (you keener, you). 5. " type of material (novel, screenplay, poem, etc: not the regular MARC types) ..." In the few cases where I've seen this done -- and I do think it can be very helpful as the GMD and even SMD categories aren't often clear enough for people and the actual coding for these aspects is limited to a near-dozen encoded categories in position 33 of the 008 field (for book materials anyway)-- it was **simply with a 500 note.** Again, you could get fancier and prescribe a local use for one of the 59x notes. I think I've also seen 653 used for this function. You could also probably use the 655 for your added types of materials. 6. "... genre ..." 655 is for Index Term--Genre/Form, so genre should go here. (I don't think I've ever seen it used for Form though). 7. "... urls for books/authors/series ..." On the cataloguing listserv AUTOCAT that I used to follow religiously, there was a significant discussion of this and the end recommendation was to make use of an appropriate 5xx note in addition to the 856 (specifically, at that time, discussion was on using 530 (Additional Physical Form Available Note) and 856 for cases where there was an online version available) to ensure that, if a patron weren't able to follow the link for whatever reason, there was sufficient information displayed for them to be able to track it down. If you choose not to do that, you will probably want to use 856 first indicator 2 (Related Resource), $3, as recommended in the LC MARC-21 tag description, to characterise further "the relationship between the electronic item identified in field 856 and the item represented by the bibliographic record as a whole". You might well make use of the $z Public note subfield as well. Again, the whole idea is to make it crystal clear for the patron what the relationship is. You could hyperlink to pages with whatever additional information you thought useful. On another note (pardon pun), someone was asking me recently whether, if you did a search for a particular work, say by title, whether the author (and other, e.g. subject, possibly title, fields) would come up in Koha as 'hyperlinked', if there were other works by that author. This is something that Voyager does and it is very handy for patrons and staff alike. 8. " ... author pseudonyms ..." Usually, these are handled by authorities, quite often without disclosure to patrons in the OPAC. Some ILS use authorities embedded into 900 tags. NLC seems to make fairly frequent use of 900 for alternate forms of the main author's name. Perhaps that tag would do for you as well. 9. " ... quotes from books/authors/series ..." I can't quite see the point of going this far, Scott, but you could handle it through 500, 520 (if from the book) or 5xx notes, or even by an 856 linking to quotation pages. 10. "and a few others." If you want to write in with the rest, or send them to me off listserv, I'll be glad to tackle them, Scott. Hope the present material helps. Cheers, Steven F. Baljkas library tech at large Koha neophyte Winnipeg, MB, Canada --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.732 / Virus Database: 486 - Release Date: 29/07/2004
* Steven F. Baljkas <baljkas@mb.sympatico.ca> wrote:
Hope the present material helps.
Yes, thank you. Mapping those will keep me busy for a while. :) In general, so far, MARC seems very book-centric. I mean, it seems that information about authors and other related concepts will be repeated and duplicated quite a bit. If I have ten records listing books by Isaac Asimov, I'd end up with ten copies of his bibliographic data too. Is there any way around that? I realize this is probably a side-effect of MARC's age and origins, when data normalization wasn't a big thing. But I also don't know much yet about MARC. :) -- Scott
* Steven F. Baljkas <baljkas@mb.sympatico.ca> wrote:
It seems to work during searches, but is never displayed. Is this a template problem?
This is one of the things I was concerned about: how Koha handles the data from MARC records. Stephen, Joshua, other cognoscenti: is Scott's problem here because of a mapping error? something that needs to be defined in MARC parameters?
I've noticed a few other fields now which are not displayed. Some of them show up in Koha's marc view of a record, but others don't even show there. I can get them to display by going through the marc structure and setting the tab option, though. Most are set to "ignore" by default, but I think I'd prefer to just set each Nxx tag to use tab N. BTW, modifying the template slightly allowed me to display a bit more info, such as the series title. I'm still trying to get the subtitle and additional authors to work, among others. (subtitle doesn't show up, and only the first additional author is shown) I'd like to dump the rest of the marc data onto the book display page, too, but I haven't done so yet.
1. I'm not 100% certain what you meant by "bibliographic data about authors", Scott.
I suppose I'll have to implement an "author detail" page and appropriate database storage for it. The detail I'm looking for is probably not appropriate in a marc record.
2. "... short book review blurbs ..."
That's easily a 520 $a, first indicator "1" (Review).
I see that now, mapped already to biblio.abstract. However, it is marked as non-repeatable. Is it safe to change that?
On another note (pardon pun), someone was asking me recently whether, if you did a search for a particular work, say by title, whether the author (and other, e.g. subject, possibly title, fields) would come up in Koha as 'hyperlinked', if there were other works by that author. This is something that Voyager does and it is very handy for patrons and staff alike.
Koha seems to do this somewhat already, but I hope to extend it to more fields.
9. " ... quotes from books/authors/series ..."
I can't quite see the point of going this far, Scott, but you could handle it through 500, 520 (if from the book) or 5xx notes, or even by an 856 linking to quotation pages.
I see it as similar to why imdb.com includes quotes, reviews, and even discussion about their movie listings. It helps the viewer decide if the data is valuable or interesting. It may be better to just link to external sites for this info, though. I could work out something for amazon or iblist or similar.
10. "and a few others."
If you want to write in with the rest, or send them to me off listserv, I'll be glad to tackle them, Scott.
I'm unsure how to handle subtitles. I'm not sure how Koha's "title" and "unititle" differ. It sounds like one would list the full title, and the other would do the same without "the" and such prepended. Is there a way to map biblio.title to 245a + 245b? Also, part numbers are a bit confusing. If I have book 3 in a series, should that be a 245n field, 440v, 440n, or something else? The series title seems to be 440a. BTW, thank you very much for all the help! It would take me forever to learn all the intricacies of marc's thousand tags. :) -- Scott
Sunday, August 7, 2004 00:59 CDT Greetings, all, from Subject: Re: [Koha] importing, marc mapping, progress
* Steven F. Baljkas <baljkas@mb.sympatico.ca> wrote:
It seems to work during searches, but is never displayed. Is this a template problem?
This is one of the things I was concerned about: how Koha handles the data from MARC records. Stephen, Joshua, other cognoscenti: is Scott's problem here because of a mapping error? something that needs to be defined in MARC parameters?
I've noticed a few other fields now which are not displayed. Some of them show up in Koha's marc view of a record, but others don't even show there. I can get them to display by going through the marc structure and setting the tab option, though. Most are set to "ignore" by default, but I think I'd prefer to just set each Nxx tag to use tab N.
BTW, modifying the template slightly allowed me to display a bit more info, such as the series title. I'm still trying to get the subtitle and additional authors to work, among others. (subtitle doesn't show up, and only the first additional author is shown)
I still have to finish re-reading Stephen Hedge's answer to another e-mail I sent -- it finally made its way back only yestereve (I don't know what the daemon is doing Stephen) -- but the problems are bigger than I'd thought. Apparently, only one subject field can be indexed (in the sense that we mean in the library field) and that is a significant issue.
I'd like to dump the rest of the marc data onto the book display page, too, but I haven't done so yet.
That would be great, Scott.
1. I'm not 100% certain what you meant by "bibliographic data about authors", Scott.
I suppose I'll have to implement an "author detail" page and appropriate database storage for it. The detail I'm looking for is probably not appropriate in a marc record.
I think that's for the best. Otherwise, the record would get pretty big. Having thought more about it since I last wrote you, I think it might be wise to designate a 59x field of your own choice for that data. That way, if/when you eventually share data with other libraries, all that neat information you'd be providing could be easily excluded by more traditionalist cataloguers, without loss of other more standard information (i.e. if you used a 500 or 520 for both the "author detail" and regular notes, a global search and replace would end up killing some data everyone would want).
2. "... short book review blurbs ..."
That's easily a 520 $a, first indicator "1" (Review).
I see that now, mapped already to biblio.abstract. However, it is marked as non-repeatable. Is it safe to change that?
Okay, this is the core of the problem that -- if I understood what Stephen H. wrote me -- is freaking me out. If I did understand correctly, Koha doesn't really understand or make use of the data in repeated fields, only the first instance of the field per record. That is a huge problem for proper subject cataloguing, but it also makes a problem for notes. It isn't necessarily common to have several 520s in a given record, but it certainly is allowed by MARC standards. (If you look at the MARC Concise Bibliographic information on the LC website, Scott, you can see that next to 520 - Summary, Etc. is the R indicating the field can repeat; NR = Not Repeatable). I gather that you can change the value but not what Koha really is doing with the data, which would be to ignore the 2nd or further instances of a 520.
On another note (pardon pun), someone was asking me recently whether, if you did a search for a particular work, say by title, whether the author (and other, e.g. subject, possibly title, fields) would come up in Koha as 'hyperlinked', if there were other works by that author. This is something that Voyager does and it is very handy for patrons and staff alike.
Koha seems to do this somewhat already, but I hope to extend it to more fields.
Perhaps because I am basing my knowledge on the testdrive version available commonly, I could be wrong here, but Koha doesn't actually seem to do what I meant. Then again, even LC doesn't have that feature activated in their Voyager system, although local college and university libraries near me have those linking features available in their Voyager and Dynix systems.
9. " ... quotes from books/authors/series ..."
I can't quite see the point of going this far, Scott, but you could handle it through 500, 520 (if from the book) or 5xx notes, or even by an 856 linking to quotation pages.
I see it as similar to why imdb.com includes quotes, reviews, and even discussion about their movie listings. It helps the viewer decide if the data is valuable or interesting. It may be better to just link to external sites for this info, though. I could work out something for amazon or iblist or similar.
I guess, from my experience, Scott, it wouldn't be the library's job to try to sell a person on a book or movie, like the commercial sites you reference. I can see the value in the information they provide, but given the realities of cataloguing, it is more likely that the technical services staff would continue in a more traditional vein. If you look at the rather detailed records I sent you off listserv for comparison sake, the dna-856 set demonstrate more what tech services staff would be inclined to do if allowed (for everyone else, these records included some embedded authorities, appropriate 856 notes, 246 notes for common misspellings in the titles that could be expected, as well as complete analysis -- 505, 700 name-title and 740 -- of the contents of anthologies present in the sample).
10. "and a few others."
If you want to write in with the rest, or send them to me off listserv, I'll be glad to tackle them, Scott.
I'm unsure how to handle subtitles. I'm not sure how Koha's "title" and "unititle" differ. It sounds like one would list the full title, and the other would do the same without "the" and such prepended. Is there a way to map biblio.title to 245a + 245b?
Again, if I've understood correctly, "title" would equal 245a but "unititle" would stand for Uniform Title and would be a 240. Tag 240 doesn't occur very often, really. The only time I used it was when I had to catalogue a few different versions of the Bible for inclusion in a collection. Otherwise, you'll see it for particularly prolific authors -- like our favourite and archetype, Shakespeare -- where the text per se is more important than the edition. Tag 245 should list the full title of a work as well as its statement of responsibility (authorship, editorship, etc.). The second indicator in both 240 and 245 indicates how many characters the computer should skip in processing the title that follows: initial definite and indefinite articles plus one space (for English anyway) give the value in the second indicator. "The same without 'the'" would be the filing title, and could be coded in the 852l (ell) if one wanted. Normally, the computer should be able to do the calculation from the 245 indicator and delete the appropriate number of characters before producing a title list.
Also, part numbers are a bit confusing. If I have book 3 in a series, should that be a 245n field, 440v, 440n, or something else? The series title seems to be 440a.
You had misunderstood the meaning of 245n in your original go at this, Scott. The number and named parts there are for aspects of the title, things that distinguish it from other works with the same 245a (and possibly 245b). They don't come up very often in most cataloguing of books; more with legal and report type stuff. What you were aiming for is the establishment of a series title, which is in the 440v in your specific case. E.g. 440 /0 $aHitchhiker's guide to the galaxy ;$vv.3. would be an appropriate series entry for the work entitled: Life, the universe, and everything.
BTW, thank you very much for all the help! It would take me forever to learn all the intricacies of marc's thousand tags. :)
No prob. It takes a while to learn them but you're making great progress. And it won't take forever. Don't panic! ;-) Cheers, Steven F. Baljkas library tech at large Koha neophyte Winnipeg, MB, Canada --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.732 / Virus Database: 486 - Release Date: 29/07/2004
Scott Scriven said:
I see that now, mapped already to biblio.abstract. However, it is marked as non-repeatable. Is it safe to change that?
So long as Library of Congress says it's OK to repeat a tag, then you're "officially" OK. However, be aware that Koha -- with the exception of subjects -- will only store the first instance of the tag in the Koha tables. (In other words, all the tags will be stored in the MARC tables, but only one will be stored in the Koha tables.)
On another note (pardon pun), someone was asking me recently whether, if you did a search for a particular work, say by title, whether the author (and other, e.g. subject, possibly title, fields) would come up in Koha as 'hyperlinked', if there were other works by that author. This is something that Voyager does and it is very handy for patrons and staff alike.
Koha seems to do this somewhat already, but I hope to extend it to more fields.
This would just be a matter of creating links in the template, similar to the way the OPAC handles subject links.
I'm unsure how to handle subtitles. I'm not sure how Koha's "title" and "unititle" differ. It sounds like one would list the full title, and the other would do the same without "the" and such prepended. Is there a way to map biblio.title to 245a + 245b?
In the latest "unstable" scripting of Koha that Nelsonville is using for its OPAC, the non-indexed characters (e.g. "the" and "a") as defined by the indicators in the MARC record are used to provide a "true" alphabetical title list -- see http://koha.athenscounty.lib.oh.us. The "unititle" would be a "uniform title" that differed from the title on a particular edition of a work. For instance, the title on the book may be "John Doe's Ward and Piece," but the standard (uniform) title for the book is "Ward and Piece." BTW, notice also that NPL is now listing _all_ of the notes from all of the MARC note fields on the OPAC detail page. Once we get the code a little cleaner and more universal (so it works for UNIMARC or no-MARC libraries), we'll be committing it to CVS. NPL is also looking into doing the same thing with all of the MARC subject tags, thus bypassing the Koha tables to pull information directly from the MARC tables. Stephen -- Stephen Hedges Skemotah Solutions, USA www.skemotah.com -- shedges@skemotah.com
Stephen Hedges wrote:
BTW, notice also that NPL is now listing _all_ of the notes from all of the MARC note fields on the OPAC detail page. Once we get the code a little cleaner and more universal (so it works for UNIMARC or no-MARC libraries), we'll be committing it to CVS. NPL is also looking into doing the same thing with all of the MARC subject tags, thus bypassing the Koha tables to pull information directly from the MARC tables.
Also note that in 2.2, the OPAC as well as the librarian interface will have 3 view for a given biblio : * "simple" (=the OPAC view in 2.0) * MARC (= complete view) * ISBD. The ISBD format is still on the way. There are several rules in ISBD that are not easy to code (more complex when you need something that works with UNIMARC, MARC21, and any MARC flavour). However, the ISBD display will be a systempref parameter & builded from the MARC tables (=complete record) HTH -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
Hello... I was thinking about building a full MARC display today, and then came across some related messages... Anyway, here is how I was thinking of implementing a more complete display. It essentially involves a marc tag list consumable by the template, and a generic CSS-friendly display controlled by a separate CSS file. Details are below: Build a hash of marc data for each relevant record. Perhaps two-layered, to account for both fields and subfields. These will go into a list I'll call "records". Pass this to the display template along with the koha data. While displaying the records, the template should pull out and consume (remove from the hash) whatever fields are desired, then display the rest afterward, in a generic format. To prevent display of a field, the template should consume it without printing it. The template would generate output similar to... (pseudocode, but for clarity, code is in <? ?>'s) <div class="book_overview"> <div class="245a"><h4>Title:</h4> <span class="245a"><? print record["245"]["a"] ?></span> <? delete record["245"]["a"] ?> </div> <div class="100a"><h4>Author:</h4> <span class="100a"><? print record["100"]["a"] ?></span> <? delete record["100"]["a"] ?> </div> </div> ... and below (any info not used above) ... a titled div for each tag, containing a titled div for each subfield and the actual data in a span: Additional MARC Info +------------------------------------------------+ | Additional author (700) | | +--------------------------------------------+ | | | Personal Name (700 $a): Doe, John | | | +--------------------------------------------+ | | +--------------------------------------------+ | | | Description (700 $g): blah blah blah | | | +--------------------------------------------+ | +------------------------------------------------+ <div class="marc"> <? for each tag in record: ?> <div class="<? print tag ?>"> <h3><? print tag_names[tag], (tag) ?>/h3> <? for each field in record[tag]: ?> <div class="<? print tag, field ?>"> <h4><? print tag_names[tag], (tag) ?></h4> <span class="<? print tag, field ?>"> <? print record[tag][field] ?> </span> </div> <? end for ?> </div> <? end for ?> </div> Layout detail would then be implemented with CSS, with generic formatting for most tags and special formatting for any known tags which should stand out. See http://csszengarden.com/ for details of how this sort of layout can work. Anyway, this would require the template to do a little more than just print out variables. It would need to call functions and/or unset hash entries. Is that possible? Does any of this sound reasonable? Should I be posting on the dev list instead? * Paul POULAIN <paul.poulain@free.fr> wrote:
BTW, notice also that NPL is now listing _all_ of the notes from all of the MARC note fields on the OPAC detail page. Once we get the code a little cleaner and more universal (so it works for UNIMARC or no-MARC libraries), we'll be committing it to CVS. NPL is also looking into doing the same thing with all of the MARC subject tags, thus bypassing the Koha tables to pull information directly from the MARC tables.
Also note that in 2.2, the OPAC as well as the librarian interface will have 3 view for a given biblio : * "simple" (=the OPAC view in 2.0) * MARC (= complete view) * ISBD. The ISBD format is still on the way. There are several rules in ISBD that are not easy to code (more complex when you need something that works with UNIMARC, MARC21, and any MARC flavour). However, the ISBD display will be a systempref parameter & builded from the MARC tables (=complete record)
-- Scott
Scott Scriven wrote:
<>Hello...
I was thinking about building a full MARC display today, and then came across some related messages... Anyway, here is how I was thinking of implementing a more complete display. It essentially involves a marc tag list consumable by the template, and a generic CSS-friendly display controlled by a separate CSS file. Details are below:
Build a hash of marc data for each relevant record. Perhaps two-layered, to account for both fields and subfields. These will go into a list I'll call "records". Pass this to the display template along with the koha data.
While displaying the records, the template should pull out and consume (remove from the hash) whatever fields are desired, then display the rest afterward, in a generic format. To prevent display of a field, the template should consume it without printing it.
The template would generate output similar to... (pseudocode, but for clarity, code is in <? ?>'s)
<div class="book_overview"> <div class="245a"><h4>Title:</h4> <span class="245a"><? print record["245"]["a"] ?></span> <? delete record["245"]["a"] ?> </div> <div class="100a"><h4>Author:</h4> <span class="100a"><? print record["100"]["a"] ?></span> <? delete record["100"]["a"] ?> </div> </div>
... and below (any info not used above) ... a titled div for each tag, containing a titled div for each subfield and the actual data in a span:
Additional MARC Info +------------------------------------------------+ | Additional author (700) | | +--------------------------------------------+ | | | Personal Name (700 $a): Doe, John | | | +--------------------------------------------+ | | +--------------------------------------------+ | | | Description (700 $g): blah blah blah | | | +--------------------------------------------+ | +------------------------------------------------+
<div class="marc"> <? for each tag in record: ?> <div class="<? print tag ?>"> <h3><? print tag_names[tag], (tag) ?>/h3> <? for each field in record[tag]: ?> <div class="<? print tag, field ?>"> <h4><? print tag_names[tag], (tag) ?></h4> <span class="<? print tag, field ?>"> <? print record[tag][field] ?> </span> </div> <? end for ?> </div> <? end for ?> </div>
Layout detail would then be implemented with CSS, with generic formatting for most tags and special formatting for any known tags which should stand out. See http://csszengarden.com/ for details of how this sort of layout can work.
Anyway, this would require the template to do a little more than just print out variables. It would need to call functions and/or unset hash entries. Is that possible?
Does any of this sound reasonable?
It's almost what we plan to do for "ISBD view". Not exactly, but near. About css, i must admit i'm not a css-master, so help in actual code is welcomed (note it's better in the coming 2.2, but not yet csszengarden-top-quality ;-) =
<> Should I be posting on the dev list instead?
yes, I cc it. -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
On 2004-08-02 02:26:03 +0100 Scott Scriven <koha-main@toykeeper.net> wrote:
marc database as field 440a, and is mapped to biblio.seriestitle. It seems to work during searches, but is never displayed. Is this a template problem?
Sounds likely. It may even be that the required data isn't passed to the template, so a perl change is also required. If someone files an appropriate bug report on bugs.koha.org against 2.0.x, I'll catch it. A fix would be even better ;-) I'll leave the other questions to librarians to tell us what to do. Sorry. -- MJR/slef My Opinion Only and not of any group I know http://www.ttllp.co.uk/ for creative copyleft computing Please email about: BT alternative for line rental+DSL; Education on SMEs+EU FP6; office filing that works fast
participants (5)
-
MJ Ray -
Paul POULAIN -
Scott Scriven -
Stephen Hedges -
Steven F. Baljkas