← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 14:15 | hdl | rch around ? |
| 15:02 | ryan | hi hdl |
| 15:02 | hdl | hi. |
| 15:03 | I posted you a message on your latest patch | |
| 15:08 | ryan | ah, ok, I see that I understand even less now what this was doing. |
| 15:09 | why do we store authtypecode as frameworkcode for a given subfield ? | |
| 15:09 | what does it do ? | |
| 15:15 | hdl: can you give an example of how it may be used ? | |
| 15:16 | I see also that we are storing an authtypecode as frameworkcode, so there's a big bug here if it should stay, as well: | |
| 15:16 | frameworkcode | varchar(8) | | |
| 15:16 | authtypecode | varchar(10) | |
| 15:16 | hdl | OK. |
| 15:16 | (on phone) | |
| 15:18 | OK there is a bug should be varchar(10) | |
| 15:21 | exemple : | |
| 15:21 | if you want to make kind of hierarchy. | |
| 15:22 | Europe France Paris | |
| 15:22 | you can either make on authority | |
| 15:22 | OR | |
| 15:22 | have authorities | |
| 15:22 | Europe | |
| 15:22 | France | |
| 15:22 | Paris | |
| 15:23 | gmcharlt | hdl, ryan - in other words, this is a UNIMARCism that doesn't apply to MARC21 |
| 15:23 | hdl | And link tag 505 of France with Paris and Europe. |
| 15:23 | Don't you have any relations between authorities in MARC21 ?? | |
| 15:24 | BT and NT ? | |
| 15:24 | gmcharlt | yep, but not something that would be implemented by having authtypecode in the authorities frameworks |
| 15:25 | ryan | hdl: so unimarc 505 is link to bt or nt ? |
| 15:26 | hdl | gmcharlt: how would you do it ? |
| 15:26 | it is quite the same as linking authorities in biblios. | |
| 15:26 | Should be the same process. | |
| 15:27 | ryan: was just an example but yes. | |
| 15:28 | gmcharlt | hdl: well, for one thing, doing links between whole headings, not specifying that an individual subfield has a reference type while ignoring the subdivisions |
| 15:28 | hdl | you would have 505$5g$9numauthority$aEurope 505$5h$9numauthority$aParis |
| 15:29 | gmcharlt: can you give example ? | |
| 15:29 | our system with authorities linking is not accurate enough for UNIMARC. | |
| 15:30 | one should/could link one subfield to an authority heading to allow composition. | |
| 15:30 | But still, Nowadays system is better than nothing. | |
| 15:31 | gmcharlt | hdl: I think we've sufficiently determined that rch's patch should not be applied, as it supports functionaility needed for UNIMARC. I agree that the $9 mechanism is not sufficient, but MARC21 authorities do not allow arbitrarily linking a subfiield to another authority - it would have to be a subdivsion authority records, and subdivions authority records can code for more than one subdivision at a time |
| 15:32 | in other words, at some time we'll need to rework authority and headings support to dig it out of its mountain of ad-hocness | |
| 15:33 | hdl | could you send authorities records sample for me to better take the git of what you say ? |
| 15:34 | Is there one in git atm ? | |
| 15:35 | gmcharlt | hdl; sorry, I really don't have time today to delve into this - maybe next week |
| 15:35 | hdl | It is not so urgent. |
| 15:36 | koha30 is really much more important. | |
| 15:36 | gmcharlt | hdl: agreed |
| 15:36 | hdl | But I just wanted to work this out with you. |
| 15:36 | If you want and can. | |
| 15:36 | ryan | hdl: i'll retract patch, and send a replacement to update database |
| 15:36 | to fix varchar(8). | |
| 15:37 | hdl | I have performance problems with page loading. |
| 15:37 | I think it is owed to all the css stuff and jquery... | |
| 15:38 | ryan | all pages? or marc structure editor? |
| 15:38 | hdl | quite all pages |
| 15:38 | But subscription and circulation and so on. | |
| 15:38 | especially those. | |
| 15:38 | Is there a way to fix it ? | |
| 15:39 | Is there a way to improve performances ? | |
| 15:39 | gmcharlt | hdl: if you're running FireFox (2, not 3), try the yslow plugin and see if you can get more information (otherwise, it's a little hard to characterize the performance problem) |
| 15:40 | hdl | I + tried to add some getJSON and ajax on subscriptionadd |
| 15:41 | But it is disappointing how slow this is | |
| 15:41 | 1s to load the result of a simple query on localhost. | |
| 16:01 | atz | hdl: yeah, it still will take a long time if you have to do the usual auth/context stuff on the back end |
| 16:02 | hdl | Is there a way to make it faster ? |
| 16:03 | atz | I use check_cookie_auth and my own "ajax_auth_cgi" |
| 16:04 | on the opac side | |
| 16:05 | actually, same kind of thing on the staff side too | |
| 16:17 | Man, I love the message I just read on the list.... | |
| 16:17 | "A National Workshop on Koha ILS was held at AIO University Islamabad last week, organized by PAKLAG..." | |
| 16:25 | gmcharlt | atz: yes; that was nice to see. they also did something similar for OpenBiblio |
| 16:35 | atz | wish they would use linux instead of windows though. |
| 16:55 | acmoore | glad to hear I wasn't the only one surprised (but happy) about that. |
| 17:56 | nengard | can someone tell me what the difference is between the two options for the SubscriptionHistory sys pref? |
| 20:16 | dkg | hey folks-- i'm finally getting around to running the bulk import that gmcharlt advised me about a couple days ago -- it's pretty slow going, but i figure i'll just let it run in a backgrounded screen session. |
| 20:16 | in the meantime, i want to smooth out other bits of infrastructure. | |
| 20:16 | the library i'm working with gets downloadable records from Follett Library Resources, who advertise that they support many different ILS formats for their exported data. | |
| 20:17 | i'd like to get them exporting data that will align with the default koha MARC rules | |
| 20:17 | where should i extract the koha-specific MARC field definitions to send to them? | |
| 20:17 | gmcharlt | dkg: here's a start: koha |
| 20:18 | dkg: oops - http://wiki.koha.org/doku.php?[…]for_vendors&s=952 | |
| 20:19 | dkg | that's great! thank you gmcharlt. |
| 20:19 | does that cover everything that's koha-specific? | |
| 20:20 | (until a couple months ago, i didn't realize that folks used different fields within MARC for the same purpose, so i'm learning here) | |
| 20:20 | gmcharlt | dkg: it covers the essentially item fields - if there are any more that you need to migrate, you can get the values by going to the Adminsitraiton menu and looking at the restuls of the Koha to MARC mapping page |
| 20:22 | dkg | ok, i understand how to retrieve specific mappings -- i guess i'm wondering if the other mappings are standardized or not. |
| 20:22 | also, i'm a little concerned about 952‡y, which is marked as required for circulation. | |
| 20:22 | how are vendors going to know what to put there? | |
| 20:23 | gmcharlt | dkg: 952$y would be the item type - vendors typically get told what values to put in for things like locaiton and item type |
| 20:24 | dkg | gmcharlt: is there a default set of base item types that koha uses? |
| 20:24 | gmcharlt | dkg: no, it's up to the library to define - there are sample item types available when you install, but those are just examples |
| 20:26 | dkg | item type is used to distinguish (for example) a book from a CD, right? |
| 20:26 | gmcharlt | that's one way of viewing |
| 20:26 | dkg | I'm a little bit surprised that there are no official standards in the MARC world for how to do that. |
| 20:26 | can you give me another way to think about item type? | |
| 20:26 | gmcharlt | another way is regular loan vs. journal loan vs. reference loan vs. not for loan |
| 20:27 | i.e., not in terms of the item's physical format, but how it circulates | |
| 20:27 | dkg | ah. i see. |
| 20:27 | and the physical format might be stored elsewhere. | |
| 20:28 | thanks for answering all these newbie questions. | |
| 20:29 | gmcharlt | no problem (and yes, it is amazing that item record handling was never adequately standardized in MARC) |
| 20:32 | dkg | should i be getting a ton of output from my misc/migration_tools/bulkmarcimport.pl ? like one line per MARC field or subfield? |
| 20:32 | e.g.: | |
| 20:32 | INDEXING :GRO at /home/dkg/src/koha/C4/Biblio.pm line 2303, <GEN201> line 463. | |
| 20:36 | and to be clear: 952$y style "item types" have to match an entry in the "itemtypes" table, right? | |
| 20:37 | gmcharlt | dkg: you're using NoZebra, right? yeah, those are expected and benign, though I ought write a patch to quell them |
| 20:37 | and yes, 952$y item types have to match the codes defined in the itemtypes table | |
| 20:38 | dkg | i'm pretty sure i'm using nozebra, though i only seem to get to work on this project in fits and starts, and it was a while ago. |
| 20:38 | how would i check? | |
| 20:39 | i do actually have a zebrasrv running, fwiw. | |
| 20:40 | gmcharlt | dkg: check the value of the NoZebra syspref - if it's ON, you're not using zebra |
| 20:43 | dkg | mysql> select variable,value from systempreferences WHERE variable = 'NoZebra'; |
| 20:43 | +----------+-------+ | |
| 20:43 | | variable | value | | |
| 20:43 | +----------+-------+ | |
| 20:43 | | NoZebra | 1 | | |
| 20:43 | +----------+-------+ | |
| 20:43 | 1 row in set (1.24 sec) | |
| 20:43 | so i guess i'm not. | |
| 20:43 | if i was using zebra, would those messages go away? | |
| 20:44 | gmcharlt | yes; indexing would be more sophisticated, too |
| 20:47 | dkg | Do you have a recommendation for when it's worthwhile to use zebra? can you point me toward docs? |
| 20:48 | gmcharlt | dkg: I recommend Zebra pretty to anybody who doesn't mind dealing with a couple daemon processes |
| 20:49 | dkg: but especially worthwhile if you have over 20,000 bibs or so | |
| 20:50 | dkg | ok. i think we'll be counting at about 10K bibs, but i certainly don't mind a couple daemon processes. |
| 20:51 | i suppose that puts me on the cusp. I'll try to sort it out and probably be back here asking more annoying questions. | |
| 20:51 | gmcharlt | ok |
| 20:51 | (and no, they're not annoying) | |
| 20:51 | dkg | should i expect any change in speed with zebra? (thanks for the reassurance about the questions) |
| 20:52 | gmcharlt | searching and indexing should be faster |
| 20:52 | dkg | OK, that's a good thing. |
| 20:52 | which daemon process do i need to read up on other than zebrasrv? | |
| 20:53 | (or was "couple" a figure of speech?) | |
| 20:53 | gmcharlt | dkg: it would be either zebraqueue_daemon.pl or running rebuild_zebra.pl -a -b -z as a cronjob every couple minutes |
| 20:53 | the latter is probably better | |
| 20:54 | dkg | OK. i'll read up and report back. thanks for the help, as always. |
| 20:55 | gmcharlt | you're welcome |
← Previous day | Today | Next day → | Search | Index