IRC log for #koha, 2006-03-20

← Previous day | Today | Next day → | Search | Index

All times shown according to UTC.

Time Nick Message
17:39 Destinati I have a book that needs to have a MARC 630 entry
17:39 but the Add Biblio only shows 650
17:39 and some others in the 600 range
17:40 Koha knows about the 630 tag
17:40 but doesn't show a place where I can edit it
17:40 how do I add that field to the "add biblio" screen?
18:08 we can create a new framework
18:08 based on the default
18:08 but there seems no way to edit subfields
18:08 clicking on the double /\ in the lower left gives a server eror
18:08 error rather
22:51 kados thd: are you around?
22:51 thd: I want to bounce some ideas off you regarding 001 and 003
22:52 thd: btw: you can add a plugin for the 003 field, I just committed one
22:53 thd: along with a new syspref for organizations' MARC code
22:53 thd: I'm hoping to do even more
22:53 thd what is the function of the new system preference?
22:53 kados thd: for instance, I understand that 003 and 001 can be moved to other locations
22:53 thd: the new syspref stores a libraries MARC code
22:54 thd 035 do you mean?
22:54 kados thd: or 010 or 016
22:55 thd the system preference is for the library ID assigned by LC?
22:55 kados thd: correct
22:55 thd kados: 010 is always LCCN
22:56 in MARC 21 at least
22:56 kados http://www.itsmarc.com/crs/Bib0000.htm
22:56 "An organization using a record of another organization may move the incoming control number from field 001 (and the control number identifier from field 003) to field 035 (System Control Number) , 010 (Library of Congress Control Number) , or 016 (National Bibliographic Agency Control Number) , as appropriate, and place its own system control number in field 001 and its control number identifier in field 003."
22:57 thd kados: if the record is from the LC system 010 and 001 are the same on LCs own system or a record originating directly from them
23:00 kados: yes moving those values is useful and formed an important part of the email that I had never finished from months ago and recently decided to send you when the default Koha MARC 21 bibliographic framework was completely finished.
23:01 kados thd: I think I could move them if I knew what the behaviour should be
23:02 thd kados: I did not do much Friday because I had a headache all day from not enough food or sleep.  Today I repaid my sleep dept.
23:02 kados (btw: should the default leader be '     nam a22     7a  4500' or '|||||nam|a22|||||7a||4500'?
23:02 thd kados: I would send you the draft form of that message now but I would have to look for it.
23:03 kados hope you're feeling better
23:03 thd kados: I am fine now.
23:04 kados: I did not eat because I was working to hard and a side effect of not eating is that it is easier to stay awake.
23:04 kados: not eating was not a plan, just something that happened in the course of working long hours without stopping.
23:05 kados: Then I was actually too tired to eat L)
23:06 kados heh
23:07 thd: try the new leader behavior on liblime's demo
23:07 thd That is a bad plan for accomplishing useful work by the week but it allows much to be done in a few days followed by a period of recovery.
23:08 kados: I have not checked yet but what have you changed about the leader plugin.  Is it obvious?
23:08 oh
23:09 yes
23:10 the beginning should not have '|' as that is not defined for all places
23:13 kados thd: i made it so that clicking the mouse in the leader field, or 'tabbing' to it will auto-fill the default value
23:13 thd: I assume that's desirable behaviour
23:13 thd: (what beginning are you talking about?)
23:14 thd kados: autofill should not even require tabbing
23:15 kados: by beginning I meant the record size positions which are presumable filled by MARC::Record
23:15 kados thd: you mean the 'size of record'?
23:15 thd yes
23:16 kados thd: but every other blank should be represented by | ?
23:20 sorry, I thought that would be a quick question
23:27 thd kados: back now
23:28 that document has no values for the bibliographic leader yet
23:32 kados I added a simple 003 plugin that auto-fills the value with that specified in the syspref
23:33 but I'd also like to move the value that exists (along with the 001 I suppose) to the 035
23:33 if that's desirable
23:37 thd: ?
23:37 thd: are you still here?
23:38 thd kados: yes, sorry checking the documentation I see that '|' is not defined as a value for the leader only for some control field positions
23:39 kados ok
23:39 thanks
23:39 thd kados: the original default should have been fine but I had not looked for months
23:41 when I suggested the values to paul for a few places when he was writing a leader plugin for MARC 21 as well as UNIMARC
23:41 kados gotcha
23:41 thd: what is the logical record length?
23:41 thd kados: I noticed some oddities in your Koha to MARC mapping
23:41 kados thd: is it number of characters? or the size of the record in bytes?
23:42 thd: or some other measurement?
23:42 thd I believe that paul had determined that it was the the size in bytes
23:43 kados ok ... that makes sense considering encodings in unicode
23:43 thd therefore UTF-8 records would be larger if they have any accented characters
23:44 actually UTF-8 and MARC-8 and other library encodings are about the same size
23:45 only the ISO-8859 and other non-MARC encodings would be smaller for accented characters
23:47 kados: I noticed some oddities in your Koha to MARC mapping especially concerning the use of classification numbers in the biblioitemstable
23:48 kados thd: do tell
23:49 thd kados: may we commit a template change to substitute items.itemcallnumber instead of biblioitems classification number columns?
23:49 kados: paul had thought that this was a good idea long ago
23:51 Fujitsu Hi everyone.
23:51 kados thd: sure, but can you explain why?
23:51 Fujitsu: hi there
23:51 thd kados: then you would not have to worry about the classification values in the biblioitems table because they would have no real function outside of non-MARC Koha
23:52 kados thd: but call number is different than classification
23:52 Fujitsu I'm from a secondary school in Melbourne, Australia, and we're currently using Softlink's Alice. Is there an easy import mechanism, or will I have to write something to read in the data files and add the records (they are in a dBase format)
23:52 *?
23:53 kados Fujitsu: can you export as MARC?
23:53 thd kados: Your mapping shows the biblioitems class numbers mapped incorrectly.  Actually MARC does not support a mapping that chris had originally intended.
23:53 Fujitsu Yes, kados.
23:53 kados Fujitsu: than you can import your records using the bulkmarcimport.pl script
23:53 Fujitsu Aha. Thanks.
23:54 kados np
23:54 thd kadosL: the call number is derived from the classification number with an additional prefix and suffix
23:54 kados thd: not always
23:54 thd: not at NPL for instance
23:55 thd kados: From whence does NPL derive its call numbers?
23:55 kados: NPL uses DDC
23:55 kados thd: the non-fiction is just the dewey number, the fiction follows a different scheme
23:56 thd I saw that in the logs what is that scheme
23:56 ?
23:56 Cutter classification derived from the name?
23:56 kados thd: (the scheme for fiction is a two-letter code for type of fiction (AF (adult fiction), SF (Science Fiction), M (mystery), etc.) followed by the author's last name
23:57 I don't know if it is an official scheme or one they invented
23:57 in any case, it must be dealt with
23:58 we can't adopt standards to the exclusion of non-standard libraries
23:58 thd kados: so they need to use 082 or something so that searching fiction works in DDC?
23:59 kados I'm not sure what their current cataloging practice is
23:59 as far as where in the mARC they store their custom call numbe
23:59 r
00:00 thd kados: They put them in 952 $k do they not?
00:00 kados probably
00:00 thd kados: and 952 $k is mapped to items.itemcallnumber
00:02 kados: Searches could work in parallel for DDC fiction by adding 082a 082b to the seealso
00:03 kados true
00:04 thd kados: only searching a range of class numbers may not function correctly at NPL for fiction if they are not using DDC call numbers.
00:04 kados right
00:05 thd kados: searching a range of call numbers will not work hardly at all for LC numbers with the current Koha range algorithm.
00:06 It may sometimes work but the whole hierarchy is different in LC and cannot be seen from merely inspecting the number.
00:07 range is not merely a set of arithmetical calculations in LCC
00:09 kados ye
00:09 p
00:09 Tumer's working on a fix for that
00:09 for 3.0
00:09 anyway, we've digressed
00:09 thd so back to my original suggestion I propose that we change the templates to show items.itemcallnumber instead of biblioitems.classification dewey subclass or whatever they are using now.
00:10 MARC templates only as something different was intended for non-MARC
00:14 kados: biblioitems.dewey was intended to be the part before the decimal in DDC while biblioitems.subclass was intended to be the part after the decimal in DDC.  Each are contained withing 082 $a so they cannot be mapped correctly without code to split 082 $a at the decimal point.
00:15 kados: biblioitems.classification was meant to be the prefix for the call number like juvenile, fiction, or videos.
00:16 JUV, FIC, or VID
00:19 kados: biblioitems.classification maps to 852 $k but 852 is no longer maintained in Koha unless the library maintains it in addition to 952 or whatever field is mapped to the items table..
00:22 kados: Therefore those biblioitems classification/call number fields cannot have the proper meaning in MARC Koha that had been intended in non-MARC Koha without unnecessary additional work.
00:23 kados thd: my clients map biblioitems.classification to 952$k I think
00:23 thd: and that _is_ maintained
00:23 thd: IIRC
00:25 thd kados: Do they map 952$k to both items.itemcallnumber and biblioitems.classification?
00:25 kados thd: no
00:25 thd: I think they map biblioitems.classification to a 942 and items.itemcallnumber to 952 ... check the file I gave you
00:32 thd kados: the file you gave me shows 050 $a mapped to biblioitems.classification and 050 $b to biblioitems.subclass which is not semantically correct as chris had intended and could be expected to have unusual searching results but maybe biblioitems.dewey should be mapped alternately to 082 $a or 050 $a for searching with the search templates as they are and then items.itemcallnumber should be what is displayed instead of biblioitems.classificatio
00:34 n unless a one to many mapping is possible
00:36 kados: other default mappings are plainly incorrect but of no consequence if you run rebuildnonmarc.pl after installing a good bibliographic framework
00:38 kados: the winner from the original Koha bibliographic framework is for a subfield that never existed in MARC 21 or US MARC.: biblio.notes 306 k Pkoi besoin de 2 champs?
00:39 kados thd: yea, no idea why that's there
00:39 thd: it's possible NBBC set that up incorrectly
00:39 thd: by accident or something
00:39 thd: oh ... it's from the original frameowork?
00:40 strange ...
00:40 thd When I noticed that some years ago on the koha.org demo I imagined that was from some experimental edit in the demo.
00:43 Yet even I added some French to the MARC 21 bibliographic framework with Recommendation 995 for field 995 without translating the labels :)
00:44 No one would ever see that unless 995 were populated and then it is only visible collapsed in the editor.
00:45 kados thd: it's not collapsed in the editor anymore :-)
00:45 thd: if there is a value it is expanded now :-)
00:47 thd kados: well it is not editor I assume that not editor has the same behaviour as before does it not?
00:48 kados: Or did you merely reverse the behaviour globally?
00:49 kados I did what you told me to
00:50 thd I am sure that I told you something good :)
00:51 kados: Do you know the meaning of'pkoi'?
00:52 no Franglais people around?
00:53 kados no idea
00:53 thd kados: who is Tumer?
00:54 kados I've got to get to bed
00:54 If you read koha-devel lately there are some messages from Tumer
00:54 night thd
00:54 thd kados: I slept most of the day
00:54 kados read you tomorrow :-)
00:55 thd good night kados
00:55 kados thd: if you could finish a proper holdings scenerio for the MARC Framework that would be a great help (with mappings, etc.)
00:56 thd kados: I had been working on exactly that since I awoke again this afternoon
00:56 kados thd: excellent!
00:56 thd: I'll defer to your judgment and make any template modifications you suggest
00:57 thd kados: I ask so that I do not break anything
00:58 kados: I do not know the range of user configurations but I have been recommending that change for many months on the koha list and users seems very happy with it.
01:40 kados thd: http://koha.liblime.com/cgi-bi[…]mple/addbiblio.pl
01:40 thd: tab through the fields and type characters in the fields and watch the leader change
01:41 thd I do not understand the instruction well
01:41 kados there are performance issues I'm afraid
01:41 otherwise, it's a cool feature
01:41 thd kados: Is this meant to dynamically change the leader?
01:42 kados thd: go to the page; tab to the leader or put your cursor in the leader field
01:42 thd: yes, is it working for you?
01:42 thd kados: are you calculating the number of bytes in the record?
01:42 kados thd: it's just a demo, it's not 100% accurate yet, but yes, that's the idea
01:43 thd: is it working?
01:43 thd kados: yes it is working.
01:44 kados thd: what do you think? :-)
01:44 thd kados: Does MARC::Record not do that when the record is finished?
01:44 kados thd: yea :-) but i thought it woudl be a cool thing to demo :-)
01:44 thd It is a very cool demo
01:45 ;;0
01:48 kdaos: your 003 plugin can be adapted for 040 and used as is on 040 $c which is supposedly mandatory for copy catalogued records.
01:49 kados ok
01:49 what else should appear in 040?
01:50 thd kados: if the record is a new original record then 040 $a would be the  same as 003
01:50 kados ok
01:52 thd: I really do need to go to bed now
01:52 thd kados: if the record is edited then an additional non-redundant 040 $d should be added.
01:52 kados thd: after you finish the framework we can discuss creating more plugins
01:52 thd ok
01:53 kados g'night
01:53 thanks for the help
01:53 thd goodnight kados
01:59 Fujitsu Hmm.

← Previous day | Today | Next day → | Search | Index

koha1