← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
Time | Nick | Message |
---|---|---|
15:22 | kados | morning owen |
15:23 | well ... afternoon I guess | |
15:23 | thd | good afternoon kados |
15:28 | kados: are you awake now? | |
15:42 | kados | thd: yep |
15:44 | thd | kados: I have supplied you with a more complete and accurate ISBD setting at http://kohatest.liblime.com/cg[…].pl?tab=Catalogue You should use that one with your customers. |
15:47 | kados | thd: yes I noticed thanks! |
15:47 | thd | kados: Although, maybe few care about ISBD in the webified world. |
15:47 | kados | actually, I've had some folks very interested in it |
15:47 | especially since it is so easy to change the way it displays on the page | |
15:47 | so they can easily edit the OPAC display (if ISBD was the default) | |
15:50 | thd | kados: There are still some problems with repeated subfields in the 2.X design that prevent correct operation of the ISBD rules when repeated subfields are present. Also, ISBD has nothing specified for holdings so that is not present in what I supplied. |
15:50 | kados | thd: ooh, I didn't realize that |
15:51 | thd: I just read over your SQL email in more detail | |
15:52 | thd: I'm going to wait a few days, to see if anyone else has comments | |
15:52 | thd: and then I'm going to recommend adoption for version 3.0 | |
15:52 | thd | kados: The repeated subfields problem is seen where for example there are multiple publishers for the same book. |
15:52 | kados | right |
15:53 | thd: did you notice that some of the subjects aren't searchable in the new opac | |
15:53 | thd | kados: There have been a couple of comments on koha-devel that I have not had time to reply to yet. |
15:53 | kados | http://opactest.liblime.com/cg[…]tail.pl?bib=22762 |
15:54 | neither of those subject links work | |
15:54 | I think I need to change the default MARC21 settings to fix this | |
15:56 | thd | kados: yes, a bibliographic framework change is required for searching all the relevant fields subfields that may appear in 6XX |
15:58 | kados: Also, I never committed the code that I had suggested to correct the problem you had where the indicator had been insufficient to define the thesaurus used in 6XX | |
15:58 | as in the case of Sears. | |
16:23 | kados | thd: could you at least send it to me? |
16:23 | thd: and do you happen to know what subfields should be included in the framework? | |
16:23 | thd: I could commit them right away so they will be in 2.2.6 | |
16:25 | thd | kados: I would need to search for the code. I had a better revised form that I posted on #koha after you had lost attention. I would need to search for that. I will commit it when I find it so that t can appear in 2.2.6 |
16:29 | kados: I am working now to extract all the needed field subfield pairs for use in the bibliographic framework 6XX. My present setting only covers the 650 subfields. | |
16:43 | kados | thd: thanks |
16:59 | thd: should I commit your ISBD modifs to cvs? | |
16:59 | thd: as the default ISBD settings? | |
17:00 | thd: or are those usmarc specific? | |
17:05 | thd | kados: yes, I was thinking of doing many things like that. There are UNIMARC defaults that set many bibliographic framework settings and other preferences. There should be some MARC21 defaults starting with a more complete bibliographic framework that includes 000 - 008. I had been working on setting something up to do that for USMARC but had only been studying how it was done with UNIMARC and became overwhelmed by the nonsense in Newark Mun |
17:08 | kados: looks like my last post was truncated at "Newark Municipal Court". | |
17:12 | kados: but the answer is that my ISBD encoding is MARC21 specific and takes some small readability liberties with the ISBD format for newlines where multiple subject fields are present. | |
17:12 | kados | ahh |
17:13 | thd | kados: There should, however, be MARC 21 defaults just as there are UNIMARC defaults. |
17:13 | kados | yep |
17:14 | thd | kados: There is no default UNIMARC ISBD encoding. It took me a day's work to make the one for MARC 21 thoroughly. |
17:43 | kados: I have updated the bibliographic framework at http://kohatest.liblime.com/cg[…]50&frameworkcode= . | |
17:44 | kados: However, the example that you gave for subject matching still has no matches. Do you have another example? | |
17:45 | kados: Do you have another example record with subject subdivisions? | |
18:12 | kados | I don't off hand |
18:25 | thd | kados: what data set do you use to stock a demo? |
18:29 | kados | thd: in this case, the bib data is a subset of some public library data from one of our clients |
18:32 | thd | kados: what general subject area do they have with a large quantity of material? |
18:33 | kados: maybe something regional realating to there location. Where are they? | |
18:34 | s/there/their/ | |
18:38 | kados | thd: you should be able to tell by looking at the MARC view |
18:52 | thd | kados: The special Liblime template you have has a problem that was fixed for the NPL templates after I told owen to change the search method. Your template needs updating. |
18:53 | kados | thd: could you be more specific? |
18:59 | thd | kados: actually, that was a guess and it seems I guessed wrongly. I will try changing the OPAC template to CSS just to be certain. |
19:06 | kados | k |
19:17 | thd | kados: run rubuildnonmarc.pl . The indexing is not working correctly on you test demo. |
19:18 | kados | k ... |
19:20 | thd | kados: If I am correct you did not run rebuildnonmarc.pl after setting 650a to be the values stored for subjects in koha SQL. |
19:20 | kados | right |
19:20 | don't remember setting that actually | |
19:22 | thd: running now | |
19:22 | thd: it's taking forever | |
19:22 | about 5 per second | |
19:23 | prob about 50K items in this db | |
19:23 | :-) | |
19:24 | thd | kados: maybe 650 linked with bibliosubject.subject is the default for MARC 21. |
19:24 | if you had not changed that value. | |
19:25 | s/650/650a/ | |
19:25 | kados | I'm not sure I touched the default values |
19:25 | don't remember doing that for this collection | |
19:27 | thd | kados: did you import the records before checking that the MARC Check was OK? |
19:27 | kados | thd: don't remember :-) |
19:27 | thd: why? | |
19:28 | thd | kados: I believe there maybe unknown problems with the system if you import records without having a validated MARC check. |
19:30 | kados: Whenever I discovered that I had done that I always used bulkmarkimport.pl to purge and reload my records :) | |
19:45 | kados: Is this the same library that you were having trouble with for some of its usage of Sears subject headings? | |
19:46 | kados | probably |
19:46 | we fixed that right? | |
19:46 | thd | kados: I mean the same records :) |
19:46 | kados | yea |
19:46 | same records | |
19:47 | thd | kados: We fixed that with code that was neve committed. I will search for that fix but that is not the problem at the moment. |
19:48 | kados: Has reuildnonmarc.pl finished running? | |
19:48 | kados | thd: not even close :-) |
19:48 | about 1/5 done | |
19:49 | thd | kados: what is the specification of your server. I use such small sets of records I cannot see what a real load might be. |
19:50 | kados | it's a pIII 2.4 Ghz with 2 gigs of ram |
19:51 | thd | kados: how many records are in this data set? |
19:52 | kados | 50K |
19:54 | thd | If rebuildnonmarc.pl reports a running time, please let me know what that actually is when it is finished. |
19:54 | kados | sure |
19:57 | thd | kados: presently, all subject searches fail, even the simplest of them directly from the search form. I hope rebuildnonmarc.pl cures that problem. |
20:32 | kados | thd: 23722 MARC record done in 3609.88483405113 seconds |
20:32 | still failing | |
20:33 | I'm guessing Owen didn'g commit the opac subject search changes | |
20:33 | owen | Or else I overwrote them by mistake |
20:39 | kados | hmmm, templates are identical |
20:39 | very strange | |
20:41 | thd | kados: owen committed the changes within a couple of days after I had told him about them. |
20:41 | kados | ahha |
20:41 | they're not identical | |
20:41 | thd | kados: what is not identical? |
20:42 | kados | hmmm |
20:42 | didn't make a difference | |
20:42 | operator=starts vs operator=contains | |
20:44 | thd | kados: that what I had guessed but that seemed OK when I had actually checked earlier |
20:46 | kados | didn't seem to make a difference |
20:47 | in my test case | |
20:47 | did we strip out the - or something ? | |
20:47 | thd | kados: a simple subject search for a single term appearing in 650 $a such as history or whatever fails from the advanced search. |
20:48 | kados: As, I said, I have not installed 2.2.5 yet myself. | |
20:49 | kados: I had been too busy looking for a lawyer to keep myself out of gaol. | |
20:50 | kados: Do you know of any installation using 2.2.5 successfully. Could there be a big bug? | |
20:53 | kados: If you query the database directly do you find valid data in bibliosubjects.subjects? | |
20:55 | kados | I can check |
20:59 | thd | kados: I have to help a friend move shortly. I want to help you solve this quickly but I may not have more time when we are both awake today. |
20:59 | kados | I'm working on this until I fix it :-) |
20:59 | it's a major problem :-) | |
21:00 | first I'm copying the known-good koha filesystem over to the test box | |
21:00 | to test if it's in the files or the db | |
21:00 | thd | kados: other suggestions of mine will include purging the records and reloading with bulkmarcimport.pl. |
21:02 | kados | yep, though I use mysqldump to load this data |
21:02 | so I'd be surprised if that wias it | |
21:02 | unless you changed something in the marc framework? | |
21:02 | before I ran rebuildnonmarc? | |
21:02 | thd | kados: If that were to fail and lacking any other obvious reason, I would suggest droping the whole database and starting over in case there is some corruption. |
21:05 | kados: I only changed the search also for 650 $a, management in tab 3 for all 650 subfields, and repeatability for the repeatable 650 subfields. | |
21:07 | kados: I could try a more conservative search also setting using only fields from 650. | |
21:08 | kados: my comprehensive search also value for 650 $a had been newly created today and was untested. | |
21:14 | kados | must be that then |
21:14 | :-) | |
21:15 | thd | kados: I just noticed that biblioitems.dewey had been set to 650b |
21:16 | kados | er? |
21:16 | did you do that? | |
21:24 | thd: I'm going to change things back to the way they were | |
21:27 | thd | kados: I fixed them already |
21:27 | kados | um ... really? |
21:27 | when? | |
21:27 | thd | yes |
21:27 | just now | |
21:27 | kados | not really :-) |
21:28 | thd | sorry, I had been on telephone. |
21:29 | kados | now, they should be fixed |
21:31 | thd | kados: a least basic searches are working now |
21:33 | kados | I see the problem |
21:33 | I'll fix it so you can see it too | |
21:33 | don't do anything on the marc framework till I'm done ok? | |
21:34 | thd | kados: is it the template issue for contains instead of stars? |
21:34 | kados: I actually need to go and help move my friend very shortly. | |
21:35 | kados | ok |
21:36 | thd | kados: what did you find was the problem? |
21:46 | kados | thd: template problem |
21:46 | I committed the change and it's working now | |
05:59 | |hdl| | hello world |
10:54 | kados | morning #koha |
← Previous day | Today | Next day → | Search | Index