Time Nick Message 12:35 thd kados: are you there? 12:36 thd kados: I had a functioning system two days ago 12:37 thd kados: so no worries on that account 12:37 thd kados: I could not work on it yesterday 12:38 kados hi thd 12:38 kados great news! 12:38 thd kados: today I have automated selection of record quality 12:38 kados exellent! 12:39 thd kados: do you have some Perl script that I could use for adding extra data to the record using MARC::Record 12:39 thd ? 12:39 kados what extra data? 12:40 thd kados: things like the original classification scheme and price paid for the material 12:40 kados hmmm ... 12:41 kados wouldn't you have to enter that in by hand? 12:41 thd kados: something similar to whatever you do when you have a migration of 100,000 records and the holdings data is not in MARC 12:42 thd kados: I assume you are not doing that by hand :) 12:44 kados hehe 12:45 kados in fact, we just got our first non-marc client recently 12:45 kados up till now all records we've migrated have been marc->kohamarc 12:45 kados so no, we don't have such a script yes (though we will in a week or two) 12:45 kados but I imagine it's not very hard at all to do 12:45 kados using MARC::Record 12:46 kados use MARC::Batch; 12:46 kados well, use MARC::Record anyway 12:46 thd kados: and I assume you do not mean the client who's records I am working on? 12:46 kados correct 12:46 kados ADMWorld is the client ;-) 12:47 thd kados: are they in Ohio? 12:48 kados no 12:48 kados you've never heard of Archer Daniels Midland Company? 12:48 kados http://www.admworld.com/ 12:49 thd yes I just did not know where there world headquarters is 12:49 kados IL maybe? 12:57 thd kados: so you do have a script for mapping 050 $a $b to 952 13:29 owen kados: I saw pierrick committed some stuff relating to item type images 13:30 kados was that in rel_2_2 or head? 13:30 owen Must be head 13:30 owen In his notes he says "you must copy or symlink the itemtypeimg directory from the opac template into the intranet template" 13:30 kados ahh ... right, I remember that 13:31 owen to me that sounds like too much for the person installing. I wonder if there's a simpler way to handle that? Duplicate the item type images in CVS in both places? 13:31 kados hmmm 13:31 owen What do you think? 13:31 kados well, unless I'm mistaken, we should move it to the base 13:31 kados koha-tmpl dir 13:31 kados since all templates (opac and intranet) have access to that dir 13:31 kados so we could have koha-tmpl/icons or something 13:32 kados koha-tmpl/icons/npl 13:32 kados koha-tmpl/icons/smfpl 13:32 kados etc. 13:32 owen Yeah, that sounds like an excellent idea 13:32 kados you wanna write a mail to koha-devel suggesting that? 13:32 kados s/you wanna/could you/ :-) 13:32 owen I wonder how you handle the linking, though? 13:32 kados the linking? 13:33 owen right now the NPL templates link to the images this way: "<!-- TMPL_VAR NAME="themelang" -->/images/<!-- TMPL_VAR NAME="itemtype" -->.gif" 13:34 owen So "themelang" is coming through as one string 13:34 kados hmmm 13:34 kados do we even need it to be linked to a language? 13:34 kados seems like that's just a lot of reduplication of images 13:35 owen Unless someone creates images that have text as part of the image, I suppose 13:35 kados I'd say we change that to /icons/<!-- TMPL_VAR NAME="template" -->/TMPL_VAR NAME="itemtype" -->.<!-- TMPL_VAR NAME="icons" --> 13:36 kados in fact, it should be a syspref we can turn on and off 13:36 kados and the syspref should also allow us to specify the file extension 13:36 kados so a new syspref: caticons or something 13:37 kados where caticons can equal '', 'gif', 'jpeg','jpg','png', etc. 13:37 kados if it's '', they're not displayed at all 13:37 kados otherwise, they use the appropriate extension 13:37 kados make sense? 13:39 owen Yeah 13:39 owen I like the idea that folks can turn it off if they don't specify an extension 13:40 kados cool 13:41 owen Okay, so yes, I can write to koha-devel about that 13:41 kados sweet, thanks 13:42 thd kados: I think having PHP save the first row of the array to file after sorting hits by quality and capturing extra original values from the get request; and then having a completely separate Perl script process the data will be the easiest to implement and safest for debugging. 13:43 thd kados: Some time after the job is done we can have the grand unified Perl script. 13:46 kados thd: sounds good 13:50 thd kados: my Perl script also needs to use URI which I used to overcome whatever problem that I never solved with building the get request in a manner that had worked fine in the past. The issue may have been a query key that needed advanced URI encoding. 13:51 thd s/advanced/prior/ 14:26 owen Joshua, I'm going to hold off on that email until I can talk to Paul on Monday...I'm wondering now if he has some itemtype image stuff that he hasn't committed. Some more extensive management options... Sound familiar? 14:29 kados owen: yea, though I thought he had committed it to head 14:31 owen Hmm.. I'll tinker with it some more. 14:36 owen Oh yeah, it is working... I was just missing the itemtypeimg directory 14:37 kados cool 14:38 owen Okay, yeah, that's what I thought he had talked about. An interface for chooseing images for each item type. it seems to work great 14:38 kados nice 14:38 kados too bad it's not in rel_2_2 14:44 owen I don't know if you've seen what Paul has put together. It does a directory listing of the itemtypeimg directory (which in the current script it looks for in intranet-tmpl/template-name) 14:45 owen So it probably doesn't matter what the file type extension is, it lists them all 14:48 kados cool, ok so that's better then 14:48 kados so the whole filename gets stored in the variable 14:48 owen Yeah, I assume so. 14:52 kados chris: you around? 14:52 kados chris: in rel_2_2, does MARC=OFF mean marc-* tables aren't used? or does it just mean that the user doesn't see the marc tags subfields? 14:55 owen I'm pretty sure it's the latter 14:55 owen I always thought that it just /hid/ the MARC stuff 16:24 kados thd: do you happen to know: is 005 the timestamp for the 'last time item was circulated'? or 'last time item was modified'? or both? 17:24 kados thd: do you happen to know: is 005 the timestamp for the 'last time item was circulated'? or 'last time item was modified'? or both? 17:37 thd kados:005 has nothing to do with items :) 17:37 kados thd: when is is supposed to be updated? 17:38 thd kados: 005 is for the last time the bibliographic record was modified and if the bibliographic record has items then it might be about items. 17:38 kados k, that's what I thought 17:38 kados thd: I think I found a major bug in MARCgetsubjects() 17:39 kados thd: when using authorities 17:39 kados thd: it doesn't properly keep track of which tag a specific authority is associated with 17:40 kados thd: did you do some work on MARCgetsubjects()? 17:40 thd kados: 005 is certainly independent of circulation unless a local use field is being used to store circulation status. 17:40 kados thd: k, got it 17:41 thd kados: yes I did but I did not create any problems that were there before me :) 17:41 kados seems like the 'link' isn't getting updated properly 17:42 thd kados: under what circumstances? 17:42 kados have a look: 17:42 kados http://smfplopac.liblime.com/cgi-bin/koha/opac-detail.pl?bib=8 17:42 kados compare the links with the actual MARC 17:42 kados first one should be 6009 17:42 thd kados: that is a beautiful routine with at least one helpful comment :) 17:43 kados second 650, third 651 17:43 kados hehe 17:43 kados it might be beautiful if it worked ;-) 17:44 thd kados: I suspect that the presumption elsewhere had been that the controlled subject was really in only one field. 17:45 kados not sure I understand 17:45 kados you mean all controlled subjects would be in 600 say? 17:45 kados instead of spread out in 600, 650,651, etc? 17:45 kados like in read data 17:45 kados s/read/real/ 17:46 thd kados: I suspect that paul had assumed elsewhere that one and only one field number was being used for subject control. That is I do not believe that any present bug was not a bug that had always been there. 17:46 kados right 17:47 kados I'll try to fix it 17:49 thd kados: there are distinct $9 numbers in the example that you showed me. 17:49 kados so? 17:49 kados maybe I'm not understanding what's supposed to happen here 17:49 kados Henry VIII, King of England, -- 1491-1547 17:49 kados is in 600 17:50 kados but the authorities link points to 6509 17:50 kados so of course it's not going to find it 17:50 kados when I change the link (in the nav bar) to 6009, it works spendidly 17:50 thd kados: 6509 is the record number for the authority. 17:50 kados hmmm 17:51 kados isn't it the marclist? ie, 650 . 9 ? 17:51 kados I'm pretty sure it's not the record number for the authority 17:51 kados especially since there are no subject authorities extant in this db yet 17:51 kados ;-) 17:52 kados as far as I can tell, authid is distinct from what's stored in $9 17:53 thd kados: Of course I never looked at how authority records were numbered in Koha but I assumed that the numbering had nothing to do with the bibliographic field to which they were associated as there is no necessary unique relationship between proper authorities and a single bibliographic field. 17:54 thd kados: that information should be specified in the bibliographic framework not in the bibliographic record. 17:54 kados what I mean is that the value in $9 is not the same as the authid 17:55 kados as far as I can tell 17:55 kados so it's not 'the 090 for authorities' 17:55 kados s/it's/$9's/ 17:55 thd kados: $9 is for storing the authority record ID unless I missed something very important it is the equivalent of $3 in standard UNIMARC. 17:56 kados well, there is a $9 which stores the linking id between the bib and the auth 17:56 kados both bib tags and auth record have the same $9 17:56 kados but there is another column in the auth_subfield_table called authid 17:56 kados which is not the same number afaict 17:57 kados or at least it shouldn't be 17:57 thd kados: maybe there is the issue that paul used at least 3 keys for the bibliographic record when only one would have been needed. 17:58 kados yea, could be 17:58 kados but I don't think that's related to my problem 17:58 kados $subject=~ s/ -- $//; 17:59 kados when would there ver be a $ in there? 17:59 kados s/ver/ever/ 18:01 thd kados: That is because this is being used by MARC detail for not only the search string where -- is ignored but also for the display sting where subject subdivisions are joined by '--' in display. 18:03 thd kados: the line you are looking at chops the trailing '--' off the end of the previous subject where it had already been appended 18:03 kados yep 18:07 thd kados: I am curious about your looking at authorities when you have six migrations this month just before you leave the country. I did want to prose to you that we create a proper buikautimport.pl if you had funding :) 18:07 kados thd: already done ;-0 18:08 thd kados: Is that why your $9s have values? 18:08 kados thd: the $9s were populated from Dynix values in $@ 18:09 kados thd: so it's not a proper bulkauth as you'd like ... it relies on existing links 18:10 thd kados: so it cannot work for newly created records but how do you get the authority records into Koha then? 18:11 kados thd: dynix records have authority ids in $@ in both the bib and auth record 18:11 kados I move them to $9 18:11 kados then use bulkmarcimport and bulkauthimport (which I created) 18:11 kados but I dont' have time to go into specifics right now 18:11 kados I've gotta work on this marcgetsubjects routine 18:13 kados yay, fixed: 18:13 kados http://smfplopac.liblime.com/cgi-bin/koha/opac-detail.pl?bib=8 18:13 thd kados: ok, so presume that bulkauth import.pl is merely the equivalent to bulkathimport.pl without matching to unknown records. 18:14 thd s/bulkauth importl/bulkmarcimport/ 18:16 kados thd: you can see the fruits of the bulkauthimport script by doing authorties searches on the opac 18:16 kados thd: you'll have the best luck with personal names 18:17 thd kados: so if I search for the merry widower I can find Henry VII :) 18:18 thd s/vII/VIII/ 18:18 kados hehe 18:19 kados for some reason, the summary links aren't populated with the correct link 18:19 kados but if you manually enter the proper link: 18:19 kados http://smfplopac.liblime.com/cgi-bin/koha/opac-search.pl?type=opac&op=do_search&marclist=1009&operator==&value=787721&and_or=and&excluding= 18:19 kados it works like a charm 18:19 kados so now I just need to fix that link 18:20 kados and also need to update the scripts and templates to check for 18:20 kados authorties for the author links 18:20 kados as it appears they don't by default 18:21 kados this is quite exciting ;-0 18:22 kados here's a strange one 18:22 kados http://smfplopac.liblime.com/cgi-bin/koha/opac-detail.pl?bib=2214 18:22 kados for some reason, the first two subject links don't have links to the authority 18:22 kados but the last one does 18:23 kados maybe I introduced a new bug ;-) 18:23 thd kados:'...' brings up no authorities that I found in http://smfplopac.liblime.com/cgi-bin/koha/opac-search.pl 18:24 kados in fact, the dictionary searches seem to be broken in rel_2_2 18:24 kados try the authority headings search 18:24 kados if you want to view the auth records as imported by bulkauthimport.pl 18:25 thd :( 18:25 kados authorities in Koha are as broken as MARC was a few months ago 18:25 kados my aim is to fix it up before paul releasese 2.4 18:30 kados huh, looks like that record didn't have an authority record in the first place 18:31 kados yep, missing in original data 18:31 kados bummer 18:33 kados interestingly it still works 18:33 kados so that's cool 18:39 kados thd: do you understand how paul's new 'summary' is supposed to work? 18:50 thd kados: sorry, still on phone 19:22 thd kados: great, I am still on phone 21:23 thd kados: I am off phone now are you still there? 21:23 kados thd: yep 21:24 thd kados: so I do not know about paul's new summary feature. I actually have not been reading the list for a while. 21:25 thd kados: when was this 'summary' feature introduced? 21:25 kados thd: no matter, I got my problem resolved 21:26 kados thd: http://smfplopac.liblime.com/cgi-bin/koha/opac-authorities-home.pl 21:26 kados thd: personal name: Grafton, Sue 21:26 kados thd: dictionary search working too 21:27 kados thd: well, javascript error :( 21:27 kados thd: but it's finding stuff 21:29 thd kados: this is using the preexisting authorities records that you have with the preexisting links from the bibliographic records? 21:30 thd s/this is/Is this/ 21:39 thd kados: Sue Grafton has a very brief authority record. Where do these authority records originate? There is no 040. 21:39 kados thd: they come from dynix 21:39 kados I'm reloading because I just discovered a bug in my import 21:40 thd kados: not from the the software but actually from the company? 21:45 kados thd: I don't know the full history 21:45 kados thd: of where exactly they came from 21:45 kados thd: but that's all that's in my client's dynix system 21:46 thd kados: I am curios to look at some subject authorities when the data is reloaded 21:46 kados thd: they only have 1XX headings 21:46 kados thd: leader + 1XX 21:48 thd kados: that is what I had observed in what I had seen. That seems as if they were built automatically from the data in bibliographic records. 21:48 kados thd: in fact, they are coming from oclc authority records, but I believe dynix only imported the headings 21:48 kados thd: for some strange reason 21:49 kados thd: in any case, there's nothing to be done 21:49 kados thd: as the client isn't willing to pay +11K to get good authority records from LOC 21:49 kados thd: :-) 21:50 thd kados: nothing except building a real authorities system for which other parties would be willing to pay. 21:50 thd kados: I can get the authority records for much less. 21:50 kados thd: perhaps, but a moot point for now since we don't have funding 21:51 kados thd: cool thing is, now we have the ability to migrate an existing authorities system 21:51 kados thd: someday when I get a client that wants fresh authorities we'll graduate to merging external auth records with our bibs 21:52 kados thd: but this'll do for now 21:52 thd kados: I found the company that acquired the data from Laser Quest for low cost records which come from LC indirectly with the addition of many contributed records. 21:52 kados thd: and we can already create auths from existing bibs in Koha to a greater or lesser extent 21:52 kados thd: cool 21:53 kados thd: I think eventually one of the things tha tthe Koha foundataion could do is manage authority records for the koha community 21:53 thd kados: As I said most of my effort for the cataloguing job was investigating what other services can provide. 21:53 kados thd: we could even subscribe to LOC or an indirect LOC 21:53 kados thd: sweet 21:53 kados thd: I'd be interested in getting a brief summary of what you found 21:53 kados thd: after the cataloging job is finished of course ;-) 21:53 thd kados: yes you could subscribe for a fraction of the cost 21:54 kados thd: and btw: I was wrong before, paul intended that authid be identical to $9 21:55 kados thd: not everything works if they are not 21:55 kados thd: though some things do ;-) 21:55 kados thd: so it's hard to spot 21:55 thd kados: I even found out who has a copy of the PREMARC database that CDS will not release until every record has been sanitised for racist subject headings. 21:56 kados hehe 21:58 thd kados: There are some controlled fields in the bibliographic framework that are missing $9 because I had not finished that part of the bibliographic framework and you had asked me to stop working on it until we had the payment basis resolved. 21:59 thd kados: All $9 subfields are from RLIN but RLIN does not have authority control over some less commonly used controlled fields 21:59 kados thd: that's good to know ;-) 21:59 kados thd: they will still import 21:59 kados thd: just won't be able to edit them 22:00 thd kados: I had included that information in the comments and in the extra long invoice but exactly they will still import but editing might loose a little data. 22:01 thd kados: It is trivial to fix that but I assumed it was no immediate issue since you we not working with authorities for any client yet :) 22:04 thd s/we/were/ 22:08 thd kados: there was also going through everything and verifying every obscure subfield, etc. There are bound to be some errors in anything that large even if I went over the core data enough times to have reasonable confidence in the core fields and subfields. 22:09 thd kados: All those issues were described in the partial invoice and there is very little left to be done. 22:11 thd kados: It mostly required a state of wakefulness which was absent at the conclusion of my previous work :) 23:19 kados thd: would authority records ever contain subject + author + subject in the same record, all of which link up to the same biblio? 23:22 thd kados: do you have an example? 23:28 thd kados: I can think of personal name subject records which might be something like 600 $Shakespeare, William$tComedies$vCommentary not that that would be exactly correct but something like that. 23:28 kados thd: no example 23:28 kados thd: just wondering 23:28 kados thd: some of the ids for the dynix auth records are the same 23:28 kados thd: for different types of records 23:32 thd kados: what do you mean by different types or records in that context? Do you mean that you have authority records which do not have unique IDs as if personal name subjects and topical subjects would have to be stored differently so that their IDs did not conflict? 23:34 thd s/types or/types of/