Time |
S |
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-bi[…]mple/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. |