Wednesday, January 26, 2005 17:56 CST Hi, Rachel, Thank you very much for the detailed answer. I think I actually understand the KohaDB-MARCDB relationship now! (Of course, the roof will probably fall in on me any second now.)
So would you want the ability to restrict your search based on language as a default search field as well?
Yes, that would be one useful result of using language encoding within MARC records. I would guess that your take on having the ability to search by language is right on; it would be a useful limiter for larger library settings, but ignored by most other library types. Nevertheless, I would say that *language is a must have.* It can be safely ignored by those who do not need it, but it is a very useful perq for those who do. Would it be practicable to have language as a category but something that smaller libraries could set to the default language once and then not have to worry about it? That would be comparable to what Voyager (what LC uses) and other ILS do: the default is English, but you can change that with any given advanced search.
[there are usually at least 2 sides to such a question] - what is in the koha DB, what is in MARC, how can that data be searched on, and how will that affect the display....
I don't know if there would be a simple answer regarding the display, but I would assume most people would recognise a language if they read it, so other than languages with non-Roman scripts (a whole other world of fun that I believe Gerry Arthus and others are dealing with in the Asian arena) there would be no need to complicate Koha's OPAC display. In other words, just sidestep it for now. ;-)
Sooo, while you can assume that pretty much any field is in the MARC record I think (with 900 odd fields it seems a safe bet :-),
Oh yeah! ;-)
depending on what you then want to do with the data, you might need a field for it in the koha db as well - and to map the two together. [snip: passage on language data coding locations: MARC21 tag 041, MARC21 tag 008, positions 35-37 inclusive]
I believe (and someone else might want to jump in and correct me here) that the answer is "both" or possibly "either".
If "either" or "both" are the answers, then I should think it would be best to create a field in the KohaDB for language information, whether for MARC-on or MARC-off.
When you set up your Koha you can choose to have it running in "marc mode" or not - if you choose "not" then I believe it doesn't "show" the MARC and pretty much runs off the Koha db.
If it were, MARC-off, the library would set language, I'd suppose, once or individually with each record in non-MARC fashion (as a note? I am sorry, I really don't know: my training was MARC-based and I only vaguely remember ever seeing language noted on catalogue cards way-back-when). If it were MARC-on flavour, then Koha should look first to those fixed positions in tag 008 (35-37) to determine the language of the material (a series of standardised 2-3 abbreviations which, I imagine could be set up as a table so that Koha would convert the info into human-friendly words), and then, check if there is a 041 tag that provides additional information (same abbreviations). For many records there probably would not be a 041, but it would be nice to check anyway.
[snip] So an item needs a language field that is more like subjects, where you can have more than one.
Yes, that would be the case. BTW, this is a whole separate issue from the language in which the OPAC displays. That should be set separately. It is quite likely, for example, that a French library benefitting from Paul's work, would have a Koha OPAC display in French, and yet have English, German, etc. works that would be available in the library. A typical university library would have the display set in the language of its student/staff-base but have records for items in dozens of languages. Those are my main thoughts on the language matter. I've got a few PS's below on a few other points less germaine but perhaps of interest to some. Thanks again, Rachel, for the great answer e'mail, and please record my vote, along with the UNIDO staff, for having a language identifier as a must have feature. Cheers, your slightly less confused, still frozen Koha enthusiast in ice-cold Winnipeg, MB, Canada Steven F. Baljkas P.S. Re:
There are usually 2 sides (at least :-) to a question like this
Oh, I hear you. In library tech training, the most common answer we got from our instructors was "it depends"! :-)
I think that you can search either the koha db (smaller and faster) or the MARC db (bigger and slower). The koha db is I think a subset of the MARC db - and is basically automatically "joined" to the marc db, so that the two are kept in sync.
Thank you, thank you, thank you, Rachel! I was never completely clear on this before. I think it falls under the category of stuff that is completely clear to programmers but less so for the rest of us. I remember there were a dozen or so messages in a row a few years ago on these issues and I never quite understood what they were talking about with speed as Koha seems to me quite fast.
Additional info about an item is added to the Koha part - about it's life since entering the library, which MARC isn't interested in.
Actually, that bit is not true, Rachel. Most libraries ignore stuff like that, but there is actually a 583 tag, Action Note, that libraries (including 3 that I've worked in) use to record various information about what's happened to the book since it started it's library life. Formally, 583 is for "processing, reference and preservation actions", but given the broader meaning of the first term, that can be used to justify almost anything. And, if a library wanted to keep other info on hand in MARC format there are always 59x notes. In my experience, these aren't set to display in the default non-MARC-view of the OPAC, but library staff could see them by selecting MARC-view.
There is a fair amount of info in a MARC record which lots of libraries have no real use for, and give volunteer cataloguers the willies. [snip]
Certainly, one can understand that. Years ago now, Pate pointed me to the MARC-Lite resources, which are basically just that. Then again, the core minimum standards, which have been around for a long time, are pretty much the same.