← 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