Time  Nick      Message
17:39 Destinati I have a book that needs to have a MARC 630 entry
17:39 Destinati but the Add Biblio only shows 650
17:39 Destinati and some others in the 600 range
17:40 Destinati Koha knows about the 630 tag
17:40 Destinati but doesn't show a place where I can edit it
17:40 Destinati how do I add that field to the "add biblio" screen?
18:08 Destinati we can create a new framework
18:08 Destinati based on the default
18:08 Destinati but there seems no way to edit subfields
18:08 Destinati clicking on the double /\ in the lower left gives a server eror
18:08 Destinati error rather
22:51 kados     thd: are you around?
22:51 kados     thd: I want to bounce some ideas off you regarding 001 and 003
22:52 kados     thd: btw: you can add a plugin for the 003 field, I just committed one
22:53 kados     thd: along with a new syspref for organizations' MARC code
22:53 kados     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 kados     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 thd       in MARC 21 at least
22:56 kados     http://www.itsmarc.com/crs/Bib0000.htm
22:56 kados     "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 thd       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 thd       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 thd       kados: not eating was not a plan, just something that happened in the course of working long hours without stopping.
23:05 thd       kados: Then I was actually too tired to eat L)
23:06 kados     heh
23:07 kados     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 thd       kados: I have not checked yet but what have you changed about the leader plugin.  Is it obvious?
23:08 thd       oh
23:09 thd       yes
23:10 thd       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 kados     thd: I assume that's desirable behaviour
23:13 kados     thd: (what beginning are you talking about?)
23:14 thd       kados: autofill should not even require tabbing
23:15 thd       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 kados     sorry, I thought that would be a quick question
23:27 thd       kados: back now
23:28 thd       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 kados     but I'd also like to move the value that exists (along with the 001 I suppose) to the 035
23:33 kados     if that's desirable
23:37 kados     thd: ?
23:37 kados     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 kados     thanks
23:39 thd       kados: the original default should have been fine but I had not looked for months
23:41 thd       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 kados     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 kados     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 thd       actually UTF-8 and MARC-8 and other library encodings are about the same size
23:45 thd       only the ISO-8859 and other non-MARC encodings would be smaller for accented characters
23:47 thd       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 thd       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 kados     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 Fujitsu   *?
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 kados     thd: not at NPL for instance
23:55 thd       kados: From whence does NPL derive its call numbers?
23:55 thd       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 thd       ?
23:56 thd       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 kados     I don't know if it is an official scheme or one they invented
23:57 kados     in any case, it must be dealt with
23:58 kados     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 kados     as far as where in the mARC they store their custom call numbe
23:59 kados     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 thd       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 thd       It may sometimes work but the whole hierarchy is different in LC and cannot be seen from merely inspecting the number.
00:07 thd       range is not merely a set of arithmetical calculations in LCC
00:09 kados     ye
00:09 kados     p
00:09 kados     Tumer's working on a fix for that
00:09 kados     for 3.0
00:09 kados     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 thd       MARC templates only as something different was intended for non-MARC
00:14 thd       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 thd       kados: biblioitems.classification was meant to be the prefix for the call number like juvenile, fiction, or videos.
00:16 thd       JUV, FIC, or VID
00:19 thd       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 thd       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 kados     thd: and that _is_ maintained
00:23 kados     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 kados     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 thd       n unless a one to many mapping is possible
00:36 thd       kados: other default mappings are plainly incorrect but of no consequence if you run rebuildnonmarc.pl after installing a good bibliographic framework
00:38 thd       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 kados     thd: it's possible NBBC set that up incorrectly
00:39 kados     thd: by accident or something
00:39 kados     thd: oh ... it's from the original frameowork?
00:40 kados     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 thd       Yet even I added some French to the MARC 21 bibliographic framework with Recommendation 995 for field 995 without translating the labels :)
00:44 thd       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 kados     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 thd       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 thd       kados: Do you know the meaning of	'pkoi'?
00:52 thd       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 kados     If you read koha-devel lately there are some messages from Tumer
00:54 kados     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 kados     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 thd       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-bin/koha/acqui.simple/addbiblio.pl
01:40 kados     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 kados     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 kados     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 kados     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 thd       ;;0
01:48 thd       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 kados     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 kados     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 kados     thanks for the help
01:53 thd       goodnight kados
01:59 Fujitsu   Hmm.