← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 12:35 | thd | kados: are you there? |
| 12:36 | kados: I had a functioning system two days ago | |
| 12:37 | kados: so no worries on that account | |
| 12:37 | kados: I could not work on it yesterday | |
| 12:38 | kados | hi thd |
| 12:38 | 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 | ? | |
| 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 | 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 | kados: I assume you are not doing that by hand :) | |
| 12:44 | kados | hehe |
| 12:45 | in fact, we just got our first non-marc client recently | |
| 12:45 | up till now all records we've migrated have been marc->kohamarc | |
| 12:45 | so no, we don't have such a script yes (though we will in a week or two) | |
| 12:45 | but I imagine it's not very hard at all to do | |
| 12:45 | using MARC::Record | |
| 12:46 | use MARC::Batch; | |
| 12:46 | 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 | ADMWorld is the client ;-) | |
| 12:47 | thd | kados: are they in Ohio? |
| 12:48 | kados | no |
| 12:48 | you've never heard of Archer Daniels Midland Company? | |
| 12:48 | 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 | 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 | koha-tmpl dir | |
| 13:31 | since all templates (opac and intranet) have access to that dir | |
| 13:31 | so we could have koha-tmpl/icons or something | |
| 13:32 | koha-tmpl/icons/npl | |
| 13:32 | koha-tmpl/icons/smfpl | |
| 13:32 | 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 | 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 | So "themelang" is coming through as one string | |
| 13:34 | kados | hmmm |
| 13:34 | do we even need it to be linked to a language? | |
| 13:34 | 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 | in fact, it should be a syspref we can turn on and off | |
| 13:36 | and the syspref should also allow us to specify the file extension | |
| 13:36 | so a new syspref: caticons or something | |
| 13:37 | where caticons can equal '', 'gif', 'jpeg','jpg','png', etc. | |
| 13:37 | if it's '', they're not displayed at all | |
| 13:37 | otherwise, they use the appropriate extension | |
| 13:37 | make sense? | |
| 13:39 | owen | Yeah |
| 13:39 | 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 | 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 | 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 | 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 | 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 | 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 | so the whole filename gets stored in the variable | |
| 14:48 | owen | Yeah, I assume so. |
| 14:52 | kados | chris: you around? |
| 14:52 | 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 | 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 | 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 | thd: I think I found a major bug in MARCgetsubjects() | |
| 17:39 | thd: when using authorities | |
| 17:39 | thd: it doesn't properly keep track of which tag a specific authority is associated with | |
| 17:40 | 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 | http://smfplopac.liblime.com/c[…]c-detail.pl?bib=8 | |
| 17:42 | compare the links with the actual MARC | |
| 17:42 | 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 | hehe | |
| 17:43 | 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 | you mean all controlled subjects would be in 600 say? | |
| 17:45 | instead of spread out in 600, 650,651, etc? | |
| 17:45 | like in read data | |
| 17:45 | 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 | 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 | maybe I'm not understanding what's supposed to happen here | |
| 17:49 | Henry VIII, King of England, -- 1491-1547 | |
| 17:49 | is in 600 | |
| 17:50 | but the authorities link points to 6509 | |
| 17:50 | so of course it's not going to find it | |
| 17:50 | 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 | isn't it the marclist? ie, 650 . 9 ? | |
| 17:51 | I'm pretty sure it's not the record number for the authority | |
| 17:51 | especially since there are no subject authorities extant in this db yet | |
| 17:51 | ;-) | |
| 17:52 | 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 | 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 | as far as I can tell | |
| 17:55 | so it's not 'the 090 for authorities' | |
| 17:55 | 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 | both bib tags and auth record have the same $9 | |
| 17:56 | but there is another column in the auth_subfield_table called authid | |
| 17:56 | which is not the same number afaict | |
| 17:57 | 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 | but I don't think that's related to my problem | |
| 17:58 | $subject=~ s/ -- $//; | |
| 17:59 | when would there ver be a $ in there? | |
| 17:59 | 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 | 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 | 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 | I move them to $9 | |
| 18:11 | then use bulkmarcimport and bulkauthimport (which I created) | |
| 18:11 | but I dont' have time to go into specifics right now | |
| 18:11 | I've gotta work on this marcgetsubjects routine | |
| 18:13 | yay, fixed: | |
| 18:13 | http://smfplopac.liblime.com/c[…]c-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 | 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 | 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 | s/vII/VIII/ | |
| 18:18 | kados | hehe |
| 18:19 | for some reason, the summary links aren't populated with the correct link | |
| 18:19 | but if you manually enter the proper link: | |
| 18:19 | http://smfplopac.liblime.com/c[…]or=and&excluding= | |
| 18:19 | it works like a charm | |
| 18:19 | so now I just need to fix that link | |
| 18:20 | and also need to update the scripts and templates to check for | |
| 18:20 | authorties for the author links | |
| 18:20 | as it appears they don't by default | |
| 18:21 | this is quite exciting ;-0 | |
| 18:22 | here's a strange one | |
| 18:22 | http://smfplopac.liblime.com/c[…]etail.pl?bib=2214 | |
| 18:22 | for some reason, the first two subject links don't have links to the authority | |
| 18:22 | but the last one does | |
| 18:23 | maybe I introduced a new bug ;-) | |
| 18:23 | thd | kados:'...' brings up no authorities that I found in http://smfplopac.liblime.com/c[…]ha/opac-search.pl |
| 18:24 | kados | in fact, the dictionary searches seem to be broken in rel_2_2 |
| 18:24 | try the authority headings search | |
| 18:24 | 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 | my aim is to fix it up before paul releasese 2.4 | |
| 18:30 | huh, looks like that record didn't have an authority record in the first place | |
| 18:31 | yep, missing in original data | |
| 18:31 | bummer | |
| 18:33 | interestingly it still works | |
| 18:33 | so that's cool | |
| 18:39 | thd: do you understand how paul's new 'summary' is supposed to work? | |
| 18:50 | thd | kados: sorry, still on phone |
| 19:22 | kados: great, I am still on phone | |
| 21:23 | 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 | kados: when was this 'summary' feature introduced? | |
| 21:25 | kados | thd: no matter, I got my problem resolved |
| 21:26 | thd: http://smfplopac.liblime.com/c[…]thorities-home.pl | |
| 21:26 | thd: personal name: Grafton, Sue | |
| 21:26 | thd: dictionary search working too | |
| 21:27 | thd: well, javascript error :( | |
| 21:27 | 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 | s/this is/Is this/ | |
| 21:39 | 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 | 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 | thd: of where exactly they came from | |
| 21:45 | 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 | 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 | thd: for some strange reason | |
| 21:49 | thd: in any case, there's nothing to be done | |
| 21:49 | thd: as the client isn't willing to pay +11K to get good authority records from LOC | |
| 21:49 | thd: :-) | |
| 21:50 | thd | kados: nothing except building a real authorities system for which other parties would be willing to pay. |
| 21:50 | 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 | thd: cool thing is, now we have the ability to migrate an existing authorities system | |
| 21:51 | thd: someday when I get a client that wants fresh authorities we'll graduate to merging external auth records with our bibs | |
| 21:52 | 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 | thd: cool | |
| 21:53 | 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 | thd: sweet | |
| 21:53 | thd: I'd be interested in getting a brief summary of what you found | |
| 21:53 | 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 | thd: not everything works if they are not | |
| 21:55 | thd: though some things do ;-) | |
| 21:55 | 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 | 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 | thd: they will still import | |
| 21:59 | 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 | 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 | s/we/were/ | |
| 22:08 | 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 | kados: All those issues were described in the partial invoice and there is very little left to be done. | |
| 22:11 | 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 | 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 | thd: just wondering | |
| 23:28 | thd: some of the ids for the dynix auth records are the same | |
| 23:28 | 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 | s/types or/types of/ |
← Previous day | Today | Next day → | Search | Index