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/