← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 12:47 | pierrick | kados, are you there ? did you see Tumer proposal to solve Zebra/UTF-8 issue ? |
| 12:47 | kados | pierrick: yes, reading it now |
| 12:50 | wow, that's interesting | |
| 12:50 | so we definitely need to add utf-8 instructions to our zebra files | |
| 13:07 | pierrick | see you tomorrow, good afternoon to USA, good morning to kiwis, good night to France :-) |
| 14:12 | kados | hi cindy |
| 14:13 | cm | hi! I finally made it. |
| 14:13 | kados | cool :-) |
| 14:13 | firewall keep you out? | |
| 14:13 | so here's a snip from your log: | |
| 14:13 | QUERY : MPL at /usr/local/koha/intranet/modules/C4/SearchMarc.pm line 249. | |
| 14:13 | no records found | |
| 14:13 | cm | no, me figuring out how to log in did. :/ |
| 14:13 | kados | sorted at /usr/local/koha/intranet/modules/C4/SearchMarc.pm line 265. |
| 14:13 | hehe | |
| 14:14 | so it looks to me like zebra's not finding any records | |
| 14:14 | did you run bulkmarcimport.pl from HEAD or from rel_2_2? | |
| 14:14 | cm | I already had records in there. So do I need to dump the db and do it again? |
| 14:15 | kados | in that case you can run rebuild_zebra.pl |
| 14:15 | cm | ah...I'll try that. :D |
| 14:15 | kados | with zebra, every change you make to the configuration files requires a reindexing |
| 14:16 | we're still working on making that less painful | |
| 14:16 | under normal circumstances (ie over the command line) zebra can index 200K records in about 10 minutes | |
| 14:16 | but when we do it one at a time with perl-zoom it takes much much longer | |
| 14:17 | cm | um, it died on line 28. I'll try it a different way. |
| 14:17 | kados | make sure the C4 for HEAD (not 2.2) is in your perl path |
| 14:18 | easiest way to do ensure that is to navigate to /path/to/cvs/head/koha | |
| 14:18 | cm | that would do it. :) |
| 14:18 | kados | and run it from there |
| 14:18 | or you can go perl -I /path/to/cvs/head/koha /path/to/rebuild_zebra.pl | |
| 14:19 | cm | I'll try it that way. |
| 14:21 | it <I>still</I> did it. | |
| 14:22 | kados | huh |
| 14:22 | what's the exact error? | |
| 14:23 | cm | Died at /usr/local/koha-cvs-repository/HEAD/koha/misc/migration_tools/rebuild_zebra.pl line 28. |
| 14:23 | kados | right ... |
| 14:23 | it didn't print anything about needint to specify 'confirm'? | |
| 14:23 | perl -I /path/to/cvs/head/koha /path/to/rebuild_zebra.pl -c | |
| 14:23 | try that | |
| 14:23 | cm | ok. |
| 14:24 | kados | I see, someone forgot to print the options out when the script is run without -c |
| 14:24 | cm | it said "Syntax OK" |
| 14:24 | kados | cool, is it running? |
| 14:25 | cm | how long should it take? it went back to the command prompt immediately. |
| 14:25 | kados | hmmm ... |
| 14:26 | try rebuild_zebra_idx.pl | |
| 14:26 | same options | |
| 14:26 | cm | ok |
| 14:26 | kados | wait, nevermind |
| 14:26 | cm | same thing. |
| 14:26 | kados | yea |
| 14:27 | we've been mainly testing with bulkmarcimport | |
| 14:27 | systems that don't have records yet | |
| 14:27 | cm | i have 98,000 (so far) :) |
| 14:27 | kados | well, I mean don't have records in Koha |
| 14:28 | cm | silly ;) |
| 14:28 | kados | :-) |
| 14:28 | hdl: are you around? | |
| 14:31 | cm: looking through the code it looks like rebuild_zebra.pl needs some updating to use our new modules | |
| 14:31 | cm: lots of hard-coded stuff in there | |
| 14:31 | cm | oh, boy... |
| 14:31 | kados | cm: I had assumed you'd be using bulkmarcimport.pl to get your data in to the plugin |
| 14:32 | cm: updating rebuild_zebra.pl should'nt take much more than an hour or so | |
| 14:32 | cm: I'll see if I can fit it in tonight | |
| 14:32 | cm | cool! we have all of mpl's circ data in there. |
| 14:32 | kados | gotcha |
| 14:33 | cm | thanks! |
| 14:33 | kados | there's another procedure that Tumer's been testing that involves dumping out your records and then indexing manually |
| 14:33 | since you've already got your records in rel_2_2 that might make the most sense here | |
| 14:33 | cm | yeah, I saw his post. |
| 14:34 | possibly | |
| 14:34 | kados | it would certainly be the fastest route to take |
| 14:34 | cm | maybe I'll try it this afternoon. |
| 14:37 | kados | cm: make sure you back up your rel_2_2 database before you do anything :-) |
| 14:37 | rel_2_2 is very stable, but the plugin hasn't been fully tested | |
| 14:40 | cm | i am the queen of backups! We're not using it in production yet anyway. later! |
| 14:43 | kados | heh |
| 14:43 | ciao | |
| 14:44 | cm: I'll email you as soon as the rebuild_zebra.pl script's up to date | |
| 14:44 | cm | excellent! |
| 17:03 | shedges | hi Fujitsu |
| 17:04 | Fujitsu | Hi. |
| 19:29 | thd | hdl: If you are still awake kados gave you a good answer to your question but I can amplify. |
| 19:31 | hdl: I had been working overnight yesterday so I needed to sleep and did not see your question until late this afternoon New York time. | |
| 19:32 | hdl: If you are not about presently, I expect to be awake during your time zone tomorrow. | |
| 19:44 | chris: are you about I have a simple question? | |
| 19:44 | chris | yep |
| 19:46 | thd | chris: a value list called branches or something is automatically created when a user starts to fill branch information. |
| 19:46 | chris | huh? |
| 19:46 | whats the context? | |
| 19:46 | a user filling in branch information where? | |
| 19:47 | thd | chris: What is the name of the corresponding value list for items.booksellerid? |
| 19:47 | chris | im sorry i dont know what you are asking me |
| 19:48 | is this in the marc editor? | |
| 19:48 | adding items? | |
| 19:48 | if so, i dont know, i didnt write that code | |
| 19:48 | thd | chris: In the admin module if I add a branch name in the form of BRANCH that name fills a value list which I can call from the MARC editor |
| 19:48 | chris | right |
| 19:48 | thats pulled from the database | |
| 19:48 | from the branches table | |
| 19:49 | there is a table in koha called aqbooksellers | |
| 19:50 | which stores supplier information, its used by the full acquisitions module (with does ordering and receiving) | |
| 19:50 | you can add suppliers to it from full acquisitions | |
| 19:50 | BUT afaik the MARC editor doesnt touch it | |
| 19:50 | thd | chris: I have identified that value list in the MARC framework for branches that can Identify the branch name |
| 19:50 | chris this is read only | |
| 19:51 | chris | yes |
| 19:51 | but, the marc editor doesnt look at that table to get the list of suppliers | |
| 19:51 | it looks at the branches table to get the list of branches | |
| 19:51 | thd | chris: The editor can use a selection box to read branch names. |
| 19:51 | chris | yes |
| 19:51 | it gets those names from the branches table | |
| 19:51 | in the koha database | |
| 19:52 | thd | chris: so maybe if I called the aqbooksellers table I would get booksellers that had been entered? |
| 19:53 | chris | yep |
| 19:53 | but there wont be any entered, unless you had gone to full acquisitions and entered some | |
| 19:53 | heres how it gets the branches | |
| 19:53 | my $sth=$dbh->prepare("select branchcode,branchname from branches order by branchname"); | |
| 19:54 | thd | chris: for branches the curious thing is that the value list does not specify a column from the branches table just the table name in the bibliographic framework. |
| 19:55 | chris | yep |
| 19:55 | cos the query is coded in additem.pl | |
| 19:56 | additem.pl would have to be edited to know about aqbooksellers | |
| 19:56 | and to fetch the data from it | |
| 19:56 | thd | chris: but not coded for aqbooksellers so adding the table name would not magically query the table without adding similar supporting code to additem.pl |
| 19:57 | chris | exactly |
| 19:58 | unfortunately | |
| 19:59 | thd | thank you chris so it is as I would have expected. The behaviour seemed magical when only examining the bibliographic framework code. |
| 19:59 | chris: It is good to know that there is code working hard to support the apparent magic | |
| 20:00 | and where it could be changed to create more apparent magic | |
| 20:02 | chris | :) |
| 05:14 | hdl | thd: are you there ? |
| 05:14 | thd | yes |
| 05:14 | hdl | about kados response ? |
| 05:15 | thd | hdl: Did you have a specific question about it? |
| 05:15 | hdl: let me review it again in logbot | |
| 05:16 | hdl | my custommer agree to make 100$a linked with biblio.author. |
| 05:17 | Is this what you usually do ? | |
| 05:19 | kados ? you rtried to catch me for rebuild zebra ? | |
| 05:20 | When you wake up, I'll be there. | |
| 05:20 | The fact is that usually, it lacks the db parameter. | |
| 05:21 | to the erbraidx commands. | |
| 05:21 | s/erbaidx/zebraidx/ | |
| 05:21 | thd | hdl: yes that would be the most correct |
| 05:22 | hdl: 200 $f should not be the main entry for author in UNIMARC. That is the nonstandard practise of one of your libraries. | |
| 05:23 | hdl | Is it ? |
| 05:24 | thd | hdl: 100 is the main entry for personal author in MARC 21 which is equivalent to 700 in UNIMARC. |
| 05:24 | hdl | thd: Pb : UNIMARC splits firstname and surname into two fields. |
| 05:24 | thd: How would we gather information then ? | |
| 05:24 | thd | hdl: yes the UNIMARC framework may need correcting on that point |
| 05:25 | hdl | And how would we be sure that ppl enter both 200$f and 700 field information. Since you know the more ppl are used to a tool, the more they are lazy. |
| 05:25 | thd | hdl: kados fixed the record editor so that plugins can fill several subfields in the same field. |
| 05:25 | hdl | :) |
| 05:25 | DID he ? | |
| 05:26 | It is for 3.0 or is it backported ? | |
| 05:26 | thd | hdl: yes there have been very many bug fixes |
| 05:26 | hdl | Great ! |
| 05:27 | thd | hdl: he fixed it in rel_2_2. I do not know if all the fixes have been applied to 3.0 yet |
| 05:27 | hdl | Great... again :) |
| 05:27 | thd | hdl: I have been too busy with 2.2 matters to actually set up 3.0 for testing yet |
| 05:28 | hdl | about 008 marc-21 plugin. |
| 05:28 | thd | hdl: we have a new MARC 21 default framework which has yet to be committed I think |
| 05:28 | hdl | kados pointed a file in Attic directory. But I cannot find it on CVS. |
| 05:29 | where is it ? | |
| 05:29 | thd | hdl: I can email it to you as an SQL script it is not perfectly perfected but is much better than the previous one |
| 05:31 | hdl | thd: can you explain how it works in your email ? henridamien at koha-fr dot org |
| 05:31 | thd | hdl: it is well commented |
| 05:33 | hdl: I intend it to be still updated further and there were a few elements left of last but it should be perfectly functional | |
| 05:33 | hdl it is 3 times the former size. | |
| 05:34 | hdl | good. |
| 05:34 | Thx! | |
| 05:40 | thd | hdl: you should have it now |
| 05:42 | hdl: you do need a current rel_2_2 for it to work properly | |
| 05:45 | hdl: aside from the few things left to do within the framework itself there are yet no subsequent frameworks for different media and the work on authorities support for MARC 21 is not yet complete or even working yet for building authorities. | |
| 05:46 | hdl | thd: Did you have a look at the build_authorities I sent you ? |
| 05:47 | thd: It is usefull for a first import. | |
| 05:47 | s/import/creation/ | |
| 05:47 | thd | hdl: yes but we did something wrong |
| 05:48 | hdl: is there something special about the first authority building? | |
| 05:49 | hdl: how is first authority building different from subsequent authority building? | |
| 05:51 | hdl | thd: I said first import, because ppl could ask for an authority building "on-the-fly" (which is BAD and could not get implemented simply) When inputing for instance a 100 field, seeking in authorities automatically for the value, and if not seen, creating a new authority. |
| 05:52 | thd | hdl: so the script is different for building authorities the first time? |
| 05:57 | hdl: or do you mean to say simply that authorities must be built from a script before they can be useful which I understand to be necessarily true? At least, as long as we do not yet have the importation of a complete set of authorities records from BNF or LC. | |
| 05:59 | hdl | authorities can be built from biblio data (that is the build_authorities script aim) |
| 05:59 | Or from a list that is provided. For instance MSC, on which I worked. | |
| 06:00 | But for each new authority list, things have to be designed. | |
| 06:00 | thd | hdl: yes I understand the building need currently. |
| 06:00 | hdl | s/MSC/MSC2000/ |
| 06:00 | thd | hdl: what is MSC? |
| 06:00 | hdl | It is AMS (American Mathematical Society) thesaurus |
| 06:01 | thd | hdl: very nice |
| 06:01 | hdl | in extenso : Mathematical Science Classification |
| 06:03 | thd | hdl: really we need to import the as complete files with tracings and references for them to be more useful for finding the correct authorised form from searching an unauthorised form |
| 06:05 | hdl | thd: I miss one word. |
| 06:05 | thd | hdl: building from the biblios does not obtain the references and tracings when the biblios have only the authorised form |
| 06:05 | which one? | |
| 06:05 | hdl | thd: the as complete files, the what ? |
| 06:06 | thd | hdl: I did not say that well but i meant the complete file of authority records from BNF, LC, etc. |
| 06:07 | If true authority importing were working | |
| 06:07 | hdl | Then it is not Zebra but google that hsould be used to dig into authorities :)))) |
| 06:07 | thd | as in bulkauthimport.pl |
| 06:08 | hdl | Usually, ppl only need a very little part of these huge authorities. |
| 06:09 | thd | hdl: the authorities concept is more intelligent than Google. Google does not understand bibliographic records or even fielded search well. |
| 06:09 | hdl | Then we should provide a service that allow them to import authorities notice, as Z3950 biblios. |
| 06:09 | thd | hdl: yes |
| 06:10 | hdl | maybe that with a zebra authority base, there could be a way for such things. Don't you think so ? |
| 06:12 | thd | hdl: I helped kados: run a test for MARC 21 authorities building and it built the authorities but for some reason the links to the biblios did not function. We made better progress with a previous test so I am not certain what had gone wrong. |
| 06:13 | hdl: we could get authorities import to work fine in rel_2_2 even but we needed to understand building first. | |
| 06:14 | hdl | sometimes, links fails because authoritise are not reinitalised first. |
| 06:15 | did you remove all authorities in your base? | |
| 06:15 | thd | hdl: what is reinitialised? |
| 06:16 | hdl: I do not know if kados deleted the old ones. | |
| 06:16 | hdl | both authorities and links in biblios to authorities. |
| 06:17 | I happened to get some link problem when rebuilding without removieng properly all authority link. | |
| 06:17 | thd | hdl: that is an option for the building script? |
| 06:17 | hdl | -d normally. |
| 06:18 | thd | hdl: maybe kados had not noticed the option or forgot it as he was the one doing the execution |
| 06:19 | hdl: he had decided to concentrate on the record editor problems which he had more confidence about fixing in time for release 2.2.6 | |
| 06:23 | hdl: UNIMARC 200 and MARC 21 245 are not authority controlled including not 200 $f and 245 $c respectively. | |
| 06:25 | hdl: UNIMARC 200 and MARC 21 245 are for the title exactly as it appears on the book | |
| 06:26 | hdl: UNIMARC 200 $f and MARC 21 245 $c are for the author's name exactly as printed on the title page | |
| 06:26 | hdl | thd: yes, but it can be a base for author authorities. |
| 06:26 | thd | s/on the book/ion the title page/ |
| 06:28 | hdl: the complete authorised form of the names is supposed to be in UNIMARC 7XX and MARC 21 1XX and 7XX | |
| 06:31 | hdl: UNIMARC 200 $f and MARC 21 245 $c is for the unauthorised form exactly as it appears in the title page and may be different from the authorised form which is the most complete name obtained from copyright registration records and should usually include the authors dates to distinguish authors with the same name | |
| 06:32 | hdl: nothing should stop you from building authorities from 200 $f if you want to but it is not standard practise | |
| 06:33 | hdl: I understand that you have libraries which are not using 7XX | |
| 06:35 | hdl | thd: And we have libraries that donot use 7XX and then wnat to change to get 7XX work. |
| 06:35 | thd | hdl: they may think that it is double work to put the name twice but there is supposed to be a difference in how the name appears between the authorised and unauthorised form |
| 06:35 | hdl | thd: that's why we build authorities form what they input. |
| 06:36 | thd | hdl: you have matched their records from BNF for upgrading when they wanted to use 7XX later have you not? |
| 06:37 | hdl | thd: No. |
| 06:37 | thd | hdl: you have upgraded records for other purposes? |
| 06:37 | hdl | Sometimes, use of BNF file is more confusing than helping. |
| 06:38 | thd | hdl: if Koha knows what to do with all the information well then it will be more helping :) |
| 06:38 | hdl | thd: When I migrate data, we donot (unless required) propose to get data from BNF. |
| 06:39 | thd | hdl: we will fix the confusion for all the data elements in bibliographic files for 3.X |
| 06:40 | hdl: why does osmoze want MARC 21 records in France? | |
| 06:41 | hdl: Is it for his library that you have been asking about MARC 21 systems yesterday? | |
| 06:43 | hdl | Why do you think it is osmoze demand ? |
| 06:44 | thd: It is for a library in New Caledonia. | |
| 06:44 | thd | hdl: did he not ask about converting records from UNIMARC to MARC 21? |
| 06:45 | hdl | Not that I reckon. |
| 06:46 | or maybe becaus of a data conversion from a Z3950 server that served MARC21 instead of UNIMARC. | |
| 06:47 | Oh yes, but not yesterday, was it last week or the week before. | |
| 06:48 | thd | hdl: New Caledonia has too much English influence to use UNIMARC? |
| 06:49 | hdl | they use Reference Manager, which should be MARC-21. |
| 06:50 | or I am mistaken. | |
| 06:50 | and most of their titles are english. | |
| 06:52 | thd | hdl: What is the prevalent language in New Caledonia? |
| 06:53 | hdl | Normally French, since it is TOM |
| 06:54 | thd | TOM? |
| 06:55 | hdl | TOM : Territoire d'Outre Mer. Far away territories. |
| 06:55 | osmoze | hello |
| 06:56 | thd | yes I almost guessed with a little thought |
| 06:56 | hdl | Two kinds of foreign countries are considered french : DOM and TOM DOM stands for Department, T for Territories. |
| 06:56 | thd | hello osmoze |
| 06:56 | hdl | hi osmoze. |
| 06:57 | DOM are considered as part of France. | |
| 06:57 | TOM as possibily independant. | |
| 06:57 | osmoze | and TOM ? |
| 06:57 | ok | |
| 06:58 | hdl | Their relationship with France is weaker than DOM |
| 06:58 | kados : I cannot see value_builder/marc21_008.tmpl file. | |
| 06:59 | Could I get it from somewhere ? | |
| 06:59 | thd | hdl: that should be in rel_2_2 unless I misspelt it |
| 07:03 | hdl: I have it on my system from maybe two weeks ago on CVS | |
| 07:04 | hdl: It should be in the same directory as other plugins for rel_2_2 | |
| 07:09 | hdl: I see that you asked about the template. Not the plugin. | |
| 07:13 | hdl: /koha-tmpl/intranet-tmpl/npl/en/value_builder/marc21_field_008.tmpl | |
| 07:14 | hdl: you should use the NPL intranet templates as not all of the changes have been incorporated to default | |
| 07:16 | hdl: and the things which are broken like auto-filling the call number in the item are broken in all templates now :) | |
| 07:38 | hdl: I sent you the values for marc_subfield_structure_hidden | |
| 07:39 | s/_hidden/.hidden/ | |
| 08:22 | pierrick | hi #koha :-) |
| 08:34 | hello thd | |
| 09:30 | hdl | hi pierrick |
| 09:31 | pierrick | hello hdl |
← Previous day | Today | Next day → | Search | Index