← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 11:33 | hdl | ok. |
| 11:43 | kados | hdl: still there? |
| 11:43 | dewey | there is a minor diff in <div>s, that I missed |
| 11:43 | kados | hdl: got a quick question regarding itemization of serials |
| 11:44 | hdl: it seems that barcodes and itemcallnumbers aren't recalled when editing back issues of a serial | |
| 11:44 | hdl | yes |
| 11:44 | kados | hdl: have you seen this behaviour? |
| 11:44 | hdl | this is a problem. |
| 11:44 | This is because there is no "link" between serial and items. | |
| 11:45 | I am striving to solve this on rel_3_0 | |
| 11:45 | kados | hdl: your client won't be adding barcodes to their serials? |
| 11:45 | hdl: or itemcallnumbers? | |
| 11:45 | hdl | Another problem would be for multiple items reception. |
| 11:46 | kados : tey are. | |
| 11:46 | kados : they are. | |
| 11:46 | kados | hdl: but if they receive a serial, with a barcode and itemcallnumber, then next month, repeat, but the barcode and itemcallnumber aren't included for the back issues, it will break their items |
| 11:47 | hdl | No. |
| 11:47 | Becaus serial doesnot have an itemnum field a the moment. | |
| 11:48 | kados | hdl: it will add a new blank item then |
| 11:48 | hdl: blank meaning it will not have barcode or itemcallnumber, but will have serial info | |
| 11:48 | hdl | I should hide the display of items for old elements. |
| 11:48 | would that solve your problem ? | |
| 11:49 | kados | hdl: only partly |
| 11:49 | there doesn't seem to be a way to update the Vol No info in an item record | |
| 11:49 | using serials control | |
| 11:49 | you can only update the serials tables | |
| 11:50 | hdl | for item records, you should use biblios. |
| 11:50 | BUT. | |
| 11:50 | I thought on this problem. | |
| 11:50 | There are many problems to solve. | |
| 11:50 | kados | why not just add itemnumber to serials? |
| 11:50 | it would solve a lot of problems | |
| 11:51 | hdl | only partly. |
| 11:51 | If we receive 4 times an issue number... you are doomed. | |
| 11:51 | kados | why? |
| 11:52 | hdl | Because you want to say : OK I got this number in my library. |
| 11:52 | And not see it 4 times in your statecollection. | |
| 11:53 | What I can propose is to write on the wiki what I thought of to manage this stuff. | |
| 11:53 | kados | ok |
| 11:53 | but I also think that we shouldn't advertise itemization of serials as a new feature | |
| 11:53 | hdl | And how this could be implemented and designed. |
| 11:53 | kados | because it is clearly not ready for production |
| 11:54 | hdl | I have done this on the rush. And couldnot think about linking and updating. |
| 11:54 | kados | I have some cases of duplicated barcodes |
| 11:54 | with the one client I have using this | |
| 11:55 | and items that can't be deleted because they have no itemnumber | |
| 11:55 | but no way for the librarian to fix | |
| 11:55 | (and even for me ... very difficult) | |
| 11:56 | hdl | I could work on this but maybe after authorities management. |
| 11:56 | kados | right |
| 11:57 | hdl | kados : Documentation about bib1.att and record.abs and gils on Indexdata site isOK for use on zebra1.3 ? |
| 11:57 | Is there another Doc source ? | |
| 11:58 | kados | hdl: some of the doc is for 2.0, some is for 1.3 ;-) |
| 11:59 | hdl | kados : How did you manage to build bib1.att and record and usmarc.mar and .chr files ? |
| 12:00 | kados :Error /retry ? | |
| 12:00 | kados | hdl: it took many many months :-) |
| 12:00 | hdl: now you will be happy when I say we need to split the roles of koha developers ;-) | |
| 12:01 | hdl: because I would vote myself as the Search manager :-) | |
| 12:01 | hdl | I would be happy only if you tell us that you cope with UNIMARC too :D |
| 12:01 | which I doubt ;) | |
| 12:01 | kados | hdl: I will |
| 12:02 | hdl: but only after NPL goes live ;-) | |
| 12:02 | hdl | So I shall strive to understand what you did. |
| 12:02 | kados | hdl: and only if we find someone else to do a good job on MARC21 Biblio management |
| 15:27 | owen | kados: have you tested frameworks in dev_week? |
| 15:28 | kados | owen: what part of frameworks? management of them? |
| 15:28 | owen | Yeah. We had problems in previous versions with the process for editing frameworks |
| 15:29 | kados | I don't trust the frameworks editor |
| 15:30 | I rely on carefully constructed sql files ;-) | |
| 15:30 | why, is there something you'd like to change? | |
| 15:30 | owen | We need to set NPL up with a specialized framework for MORE items |
| 15:30 | kados | ahh, right |
| 15:30 | ok, tell me a bit about it | |
| 15:32 | owen | Currently, MORE items are added with minimal information: title, itemtype. |
| 15:32 | kados | just those fields? |
| 15:32 | plus an item I'm guessing | |
| 15:33 | with barcode | |
| 15:33 | owen | Yeah, of course. |
| 15:33 | kados | any other fields? |
| 15:34 | owen | No. The records don't need to be searchable other than by title, since we put the MORE tracking number into the title field |
| 15:34 | kados | why not put it in callnumber field? |
| 15:34 | owen | The issue previously was that the title field seemed to be the best place to put that number in order for it to be searchable |
| 15:35 | kados | that's no longer the case ;-) |
| 15:35 | owen | I'm not sure it makes any more sense to make it a call number than part of the title, since it's a number like '29382103921' |
| 15:37 | kados | right |
| 15:37 | owen | We talked about setting up a MORE item type which wouldn't be searchable through the OPAC |
| 15:37 | kados | yep, that can still be done |
| 15:37 | not sure it will happen before golive though | |
| 15:38 | owen | Lauren approved that, so it can go on the to-do list |
| 15:39 | kados | approved the new itemtype? |
| 15:40 | owen | There had be some question about statistics with the itemtype scheme, but she said it's fine |
| 15:40 | had been, I mean | |
| 15:41 | kados | right |
| 15:42 | owen | You mentioned at the last Liblime meeting that there would be some new requirements for the catalogers to follow in order to get all the right data into records for the purpose of the new searching |
| 15:42 | kados | yes |
| 15:43 | they already know most if them | |
| 15:43 | we've been discussing it | |
| 15:43 | what we're going to need to do | |
| 15:43 | is put together a cataloging manual ;-) | |
| 15:43 | owen | Donna today talked as if she's still concerned about not having all the information she needs |
| 15:43 | kados | ahh, good to know |
| 15:43 | I'll touch base with her | |
| 15:43 | tomorrow | |
| 15:43 | dewey | tomorrow is our national day |
| 15:44 | kados | hehe |
| 15:44 | owen | dewey: forget tomorrow |
| 15:44 | dewey | owen: I forgot tomorrow |
| 15:44 | owen | We talked today about who all would have edit privileges on the catalog |
| 15:45 | That's why I'm thinking about this stuff now | |
| 15:45 | kados | it's tricky |
| 15:45 | because iirc some folks create MORE items | |
| 15:46 | but we wouldn't want them to have access to the regular items, right? | |
| 15:49 | owen | In an ideal world we'd have several levels of cataloging access: Full, "Simple" (for things like MORE items), and deletion-only |
| 15:49 | kados | right |
| 15:49 | owen | Even the deletions can be tricky, although less so now if we've got Koha stopping deletions of items still on issue |
| 15:49 | kados | in an ideal world I'd have a team of 12 programmers to work on koha :-) |
| 15:50 | owen: right | |
| 15:50 | owen | :) My point is that we're fine having only one level of catalog access because we understand we've got to work with what we've got |
| 15:51 | kados | gotcha |
| 15:55 | tumer[A] | owen:you can still delete a bibliographic record (together wit all the items) even if any is on issue , but don't tell them |
| 15:55 | kados | tumer: not in dev_week |
| 15:56 | tumer | have you updated i did not see that |
| 15:56 | kados | tumer: yea, check out the DelBiblio routine |
| 15:56 | tumer | k |
| 15:57 | this new thing that came to head instead of dev_week is it? | |
| 15:57 | kados | don't think so |
| 15:57 | should be just in dev_week | |
| 15:59 | tumer | its in dev week |
| 15:59 | we are all doing the same things differenly allover again | |
| 16:00 | kados | tumer: we are? |
| 16:01 | tumer | yes i have written that just after dev_week to addbiblio.pl but somebody lost it |
| 16:01 | kados | :( |
| 16:01 | tumer | so i have it in head only |
| 16:02 | i think barcode checking of items was lost as well | |
| 16:02 | kados | I recently discovered that in rel_2_2 (and probably elsewhere), rebuildnonmarc completely destroys items data |
| 16:02 | tumer | you can edit a barcode and have duplicate barcodes |
| 16:03 | kados | as in it takes the not-up-to-date marc data for items and puts it in items table, rather than using the authoritative data from the items table itself |
| 16:03 | owen | Another thing to be fixed in 2.2.6b :) |
| 16:03 | kados | tumer: I haven't tested that in dev_week, but in rel_2_2 it's definitely not permitted to have duplicate barcodes |
| 16:03 | owen: really? | |
| 16:04 | tumer | not when creating a new one |
| 16:04 | owen | I mean it /should/ be. |
| 16:04 | tumer | but when editing it does not |
| 16:04 | i have that fixed in head | |
| 16:04 | kados | wow, that's something I didn't know |
| 16:04 | will have to make a note of it | |
| 16:04 | owen | I don't mean it /will/ be |
| 16:04 | kados | is there a bug filed for it? |
| 16:05 | tumer | i dont remember |
| 16:06 | chris | hmm in the olden days, barcode was a unique column in mysql .. so you couldnt have duplicates mysql wouldnt let you .. i think that got ripped out at some point, and no one replaced it with checks in the code |
| 16:06 | tumer | hi chris |
| 16:06 | kados | hey chris |
| 16:06 | chris | hi guys |
| 16:06 | seen this | |
| 16:06 | dewey | I haven't seen 'this', chris |
| 16:07 | chris | www.rangitikeilibrary.org.nz ? |
| 16:07 | kados | what I've seen a lot of recently, is items saved to the marc_subfield_table, but not to items table |
| 16:07 | chris | yikes |
| 16:07 | kados | so you end up with an item you can't use ... and can't edit or delete either |
| 16:07 | yea, it's a disaster | |
| 16:07 | chris | classy |
| 16:08 | kados | chris: looking nice |
| 16:08 | chris | was their launch yesterday |
| 16:08 | kados | w00t |
| 16:08 | gonna do a press release? | |
| 16:09 | chris | there were 3 reporters there yesterday |
| 16:09 | plus the Minister for libraries | |
| 16:10 | kados | we need to be better about updating the news on the koha.org site while I think about it |
| 16:10 | chris: sweet! | |
| 16:10 | chris | so im just seeing what was written about it |
| 16:10 | tumer | nice work chris |
| 16:10 | chris | kados: yes we do |
| 16:10 | kados | I'd submit some stuff but I can't remember how :-) |
| 16:11 | chris | hmmm fire it at russ :) |
| 16:11 | thats how i do it | |
| 16:11 | kados | heh |
| 16:11 | hey russ | |
| 16:11 | russ: can you remind me of how to access the editing interface for koha.org? | |
| 16:12 | russ | how do |
| 16:12 | sure | |
| 16:12 | two secs | |
| 16:12 | http://koha2.edit.katipo.co.nz to browse the edit site | |
| 16:13 | http://koha2.edit.katipo.co.nz/kaka to access the editor | |
| 16:13 | the news editor is at | |
| 16:13 | kados | thx |
| 16:14 | russ | http://koha2.edit.katipo.co.nz/admin/news/ |
| 16:14 | two secs i'll change it | |
| 16:36 | kados you there? | |
| 16:38 | kados | russ: yep |
| 16:39 | russ | when you add a new item for the news, check the homepage box otherwise it will just show up in the news section |
| 16:39 | kados | ahh ... oops :-=) |
| 16:39 | sorry bout that | |
| 03:25 | paul_away | cd koha./nick paul_indispo |
| 07:59 | hdl | kados ? |
| 07:59 | dewey | hmmm... kados is becoming a true Perl Monger... |
| 08:21 | kados | hi hdl |
| 08:27 | hdl | hi how are you ? |
| 08:27 | kados | a bit tired ... but otherwise, well |
| 08:27 | hdl | Still trying to get an authority file into zebra. |
| 08:27 | But *.att and *.abs files are quite a mystery to me. | |
| 08:28 | kados | :-) |
| 08:28 | hdl | and dont know whether there are norms, since bib1 and gils seem to be generalized. |
| 08:29 | or if we can build up our own. | |
| 08:29 | kados | I wrote a quite comprehensive bib1.att ... do you have that one? |
| 08:30 | at the top of the file I have: | |
| 08:30 | # $Id: bib1.att,v 1.1.2.2 2006/09/18 20:02:47 kados Exp $ | |
| 08:30 | it adheres to bib1 as closely as possible, but I did expand on the standard in the 8XXX and 9XXX attribute sets | |
| 08:32 | and my record.abs is likewise, very close to the standard | |
| 08:33 | hdl | yes but bib1 seems to be lacking some ways to question headings. |
| 08:33 | kados | headings? you mean subject headings? |
| 08:33 | hdl | If you want to query only $a heading or whole heading or rejected forms ... |
| 08:34 | You donot have enough distinctions between them. | |
| 08:34 | kados | the ccl.properties file I committed has some explaination of bib1, based on online bib1 syntax documents |
| 08:34 | hdl | Maybe I want to have too much precisions. |
| 08:34 | OK. I shall invest. | |
| 08:35 | I did get my stuf indexed. | |
| 08:35 | kados | cool! |
| 08:35 | hdl | But yaz-client closes connexion before making any search. |
| 08:35 | Target closed connection | |
| 08:35 | Do you know why this can occur ? | |
| 08:35 | kados | hdl: Mike R has already submited a UNIMARC patch :-) |
| 08:35 | hdl: check your email | |
| 08:36 | hmm ... not sure why it closes connection | |
| 08:38 | hdl: I have discovered something very important (a bug) | |
| 08:39 | hdl | kados: got this. I will try. |
| 08:39 | kados | hdl: rebuildnonmarc.pl does not properly re-construct items data |
| 08:39 | hdl: so do not run it on any client data or items will be destroyed! | |
| 08:40 | hdl | what do you mean by "does not properly re-construct items data"? |
| 08:40 | kados | hdl: it seems to assume that the authoritative items data is in the MARC |
| 08:40 | hdl: rather than in the items data | |
| 08:40 | hdl: items table I mean | |
| 08:40 | hdl | It does and it is the way rebuild non marc work. |
| 08:41 | kados | morning owen |
| 08:41 | hdl | It states the fact taht MARC values are more valuable than non-MARC ones. |
| 08:41 | owen | Hi |
| 08:41 | dewey | salut, owen |
| 08:41 | hdl | I see no problem in that. |
| 08:41 | Hi owen. | |
| 08:42 | kados | hdl: but in fact, it's incorrect for all versions of Koha except 2.2.6 |
| 08:42 | hdl: because before one month ago, marc_subfield_table was never updated with new items information if items were edited | |
| 08:43 | hdl: and moreover, marc_subfield_table has no understanding of how to properly order items data ... so if you have items ordered as Vol 1, Vol 2, etc ... it will re-arrange them randomly when you rebuildnonmarc | |
| 08:44 | hdl | Does it ? |
| 08:44 | kados | yep |
| 08:44 | hdl | What about subfieldorder ? |
| 08:44 | or tagorder ? | |
| 08:45 | (tagorder is here for that purpose) | |
| 08:45 | kados | all I know is, I run rebuildnonmarc, and it moves items data around ... and items data is missing |
| 08:45 | hdl | imho |
| 08:45 | kados | I haven't investigated carefully why |
| 08:46 | hdl | I ran rebuild over and over and didnot have such a problem. |
| 08:47 | kados | in 3.0 I think we should make the items table the authoritative source of items data |
| 08:48 | since our MARC management is unreliable | |
| 08:48 | hdl | zebra closes connexion before yaz-client can make any search. Target closed connection |
| 08:48 | kados :Do you know why this can occur ? | |
| 08:49 | kados | sorry, no |
| 09:04 | hdl | have you read what I proposed on wiki.koha.org |
| 09:04 | kados | not yet |
| 09:05 | hdl | how can I analyse what is in db with zebra ? |
| 09:05 | kados | hdl: there are some explainations already on the wiki |
| 09:05 | hdl | To know if indexation didnot failed ? |
| 09:05 | kados | http://wiki.koha.org/doku.php#[…]ramming_resources |
| 09:05 | Zebra Programmer Guide | |
| 09:05 | has some useful tips | |
| 09:09 | hdl | As soon as I type f in a yaz-client connexion with db is closed. |
| 09:13 | It does so only for authorities and not for biblios. | |
| 09:13 | Strange. | |
| 10:03 | kados | hdl: do you understand the MARCmarc2koha sub? |
| 10:03 | hdl | yes. |
| 10:04 | kados | it seems somewhat recursive in a way that I'm not completely comfortable with |
| 10:04 | because I'm not 100% sure of the behavior | |
| 10:04 | for instance: | |
| 10:04 | while (($field)=$sth2->fetchrow) { | |
| 10:04 | $result=&MARCmarc2kohaOneField($sth,"biblio",$field,$record,$result,$frameworkcode); | |
| 10:04 | } | |
| 10:04 | the first time this is called, $result is null | |
| 10:05 | right? | |
| 10:05 | but $field is not | |
| 10:07 | in rebuildnonmarc, MARCmarc2koha is used in a few places | |
| 10:08 | sub localNEWmoditem has: | |
| 10:08 | my $olditem = MARCmarc2koha( $dbh, $record,$frameworkcode ); | |
| 10:08 | C4::Biblio::_koha_modify_item( $dbh, $olditem ); | |
| 10:08 | $record contains only items fields | |
| 10:09 | but if I understand correctly, MARCmarc2koha still stuff to biblio and biblioitems fields | |
| 10:09 | it looks like someone was gonna check to see witch one to do | |
| 10:10 | first line is: | |
| 10:10 | my $sth=$dbh->prepare("select tagfield,tagsubfield from marc_subfield_structure where frameworkcode=? and kohafield=?"); | |
| 10:10 | but that $sth is never eecuted ... | |
| 10:10 | and there is no flag passed to say which of biblio, biblioitems,items is to be pulled out | |
| 10:11 | and it looks also like $result is overwritten every time something is added | |
| 10:13 | hdl | It seems to me that $result could be a ref to a hash. |
| 10:13 | kados | hdl: or is there something magical happening because $result is a ref to hash? |
| 10:13 | hdl: you beat me :-) | |
| 10:13 | hdl | That will be completed over and over. |
| 10:14 | In order to caintain biblio, biblioitem and items information. | |
| 10:14 | caintain stands for contain. | |
| 10:14 | kados | ok |
| 10:14 | I think I understand it now | |
| 10:14 | but I am still confused about whether items table or MARC is authority on items data | |
| 10:15 | here it seems that it's MARC that's authoritative ... but if something in items is unmapped, it is lost? | |
| 10:16 | hdl | If you merely overwrite informations from items table, then yes. |
| 10:17 | But you can be careful, | |
| 10:17 | kados | for instance ... if datelastborrowed is not in framework, it is lost when rebuildnonmarc is run, right? |
| 10:20 | hdl | seems so. |
| 10:21 | because all fields are in OLDmoditem | |
| 10:22 | kados : have you tested work with more than One base on zebra ? Does this work ? | |
| 10:22 | kados | hdl: I haven't tested it |
| 10:22 | hdl: well ... | |
| 10:23 | hdl: I have tested it, but not put data into more than one database on zebra | |
| 10:27 | hdl | the second database seems not receiving queries. |
| 10:27 | tumer around ? | |
| 10:33 | kados | hdl: we almost need a 'rebuildmarc' script to add the stuff in items to MARC |
| 10:33 | hdl: because unless I'm mistaken, the MARC items data shouldn't be authoritative ... | |
| 10:34 | hdl: for one, there aren't enough subfields in a tag to contain all the items mappings | |
| 10:34 | hdl: also, at least in rel_2_2, we don't update the MARC data on circ like we do the items table | |
| 10:35 | hdl: do you know if paul has any opinions on this issue? | |
| 10:35 | hdl | I think that what could be done in not UPDATE ALL the fields in items table but ONLY those who are found in MARC. |
| 10:35 | paul_indispo | |
| 10:36 | kados | perhaps that is what is already done, I'm not patient enough to step through every line of the code ;-) |
| 10:36 | paul_indispo: are you present? | |
| 10:36 | hdl | (he is reading) |
| 10:37 | kados | ok |
| 10:37 | in dev_week, I decided that items table would be the authority on items data | |
| 10:37 | because updating items in MARC is too slow during circulation | |
| 10:40 | so there is a periodic cron job that updates the MARC items data (in biblioitems.marc and in Zebra) | |
| 10:40 | but i wanted to clarify what is done in rel_2_2 and rel_3_0 | |
| 10:43 | hdl: is paul_indispo with you? | |
| 10:45 | hdl | No he is managing a trainig and each time you beep him, client is aware ;) |
| 10:45 | kados | :-) |
← Previous day | Today | Next day → | Search | Index