← Previous day | Today | Search | Index
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 11:55 | hdl | owen : |
| 11:55 | I can mail you the log if you like. | |
| 12:02 | owen | thanks! |
| 12:02 | paul | you also can ask Paul owen, he's awake ;-) |
| 12:02 | owen | That worked really well. I've never tried a transfer like that before. |
| 12:02 | Paul, I wanted to be sure to have a copy of our discussion of the new not for loan settings. | |
| 12:02 | Because I knew I wouldn't be able to look at that stuff again in a little while | |
| 12:03 | hdl | owen : you're welcome. first try on DCC transfer ;) |
| 12:06 | Direct connection client to client | |
| 12:06 | kados | hi all |
| 12:06 | hdl | Paul : formes rejetées et associées, ca a a voir avec les authorités. kados : hi |
| 12:06 | kados | paul I talked to chris yesterday: htl does use transfers |
| 12:07 | sorry ... hlt ;-) | |
| 12:07 | paul | hi kados |
| 12:07 | so they work... | |
| 12:07 | and what do we have to do now ? | |
| 12:07 | kados | I think so ... actually they are very useful for stats ... |
| 12:08 | someday NPL should consider switching ... but Chris would like to expand the functionality a bit | |
| 12:08 | owen | It was an interesting discussion--they use transfers instead of returns to change the holdingbranch because they want to retain correct statistics regarding returns and transfers. |
| 12:08 | kados | right |
| 12:09 | owen | However, I don't think NPL needs to have those statistics "clean" at the moment. |
| 12:10 | I also know that the staff appreciates not having to take the extra step to transfer something every time it goes into a cargo bag. | |
| 12:12 | paul | and, about our 1st question (search limit on homebranch instead of holdingbranch), do you think it's OK ? |
| 12:13 | owen | I think it's okay for now, but ultimately we need to figure out a way to update the holdingbranch when a book is returned or transfered. |
| 12:14 | Homebranch will not be accurate, if the holdingbranch is different. | |
| 12:32 | Can more than one MARC subfield be mapped to the same koha field? | |
| 12:34 | paul | it may work. (But would be a surprise ;-) ) |
| 12:34 | owen | Perhaps it would only work if the two MARC subfields were never in the same MARC record at the same time? |
| 12:37 | paul | not sure. |
| 12:45 | owen | Or perhaps I should tell the catalogers to stop using both 440 and 490 and pick one! :) |
| 12:48 | paul | highly more secure ! |
| 13:07 | hdl | re |
| 13:08 | owen | paul, do the 'see also' values in marc_subfields_structure determine which other tags are searched at the same time? |
| 13:08 | paul | yes |
| 13:08 | QUOTED | |
| 13:08 | for example, enter '700a','701a','702a' | |
| 13:08 | WITH the quotes. Otherwise, all searches will fail (sql error) | |
| 13:08 | owen | So if biblio.subtitle is linked to 440a, but I want a series search to also retrieve 490a, then I could add a see also '490a'? |
| 13:22 | paul | owen => right. |
| 13:22 | sylvain | time for the week end, bye all ! |
| 13:48 | kados | paul around? |
| 13:48 | paul | yes, but only for a few miunts |
| 13:48 | (10) | |
| 13:48 | kados | I don't quite understand how $date_due is getting passed correctly in SearchMarc.pm |
| 13:49 | It looks to me like it's set only once per biblinumber ... instead of per itemnumber | |
| 13:49 | (it works, I'm just not sure how ;-) | |
| 13:50 | paul | mmm... which line ? |
| 13:50 | kados | in my SearchMarc (with some modifs) it's about 420 or so |
| 13:52 | while (my $item = $sth_itemCN->fetchrow_hashref) { | |
| 13:52 | right after this line ^^ | |
| 13:52 | paul | i don't understand your problem : date_due is retrieved from $sth_issue, that is related to issues |
| 13:52 | sth_issues is : | |
| 13:53 | my $sth_issue = $dbh->prepare("select date_due,returndate from issues where itemnumber=?"); | |
| 13:53 | kados | so it's only called once then (in that iteration) |
| 13:54 | I'd like to redesign this section of SearchMarc | |
| 13:54 | for libraries with multiple branches | |
| 13:54 | if an item exists twice in a library | |
| 13:54 | it shows up as: | |
| 13:54 | Nelsonville | |
| 13:54 | Nelsonville | |
| 13:55 | Instead of "Nelsonville (2)" | |
| 13:55 | imagine if we have 7 of an item! | |
| 13:55 | in one branch ... it gets really ugly | |
| 13:58 | paul do you have any suggestions on how to best acomplish that? | |
| 13:58 | paul | not really. I think it won't be easy |
| 13:58 | because you have not to merge items with differents status. | |
| 13:58 | kados | yea ... I discovered that yesterday |
| 13:58 | paul | (on issue, not forloan...) |
| 13:58 | kados | yea ... |
| 13:58 | paul | that's why i ignore this case :-( |
| 13:58 | kados | well can we roll back to Koha 2.0 then |
| 13:59 | paul | (ignored) |
| 13:59 | koha 2.0 ? | |
| 13:59 | kados | because for multi-branch libraries this method does not work |
| 13:59 | yes ... this was handled differently in Koha 1.x and 2.0 | |
| 13:59 | paul | right. |
| 13:59 | maybe you could investigate on how katipo did this | |
| 14:00 | and find how to handle it in 2.2 | |
| 14:00 | kados | katipo doesn't use 2.2 |
| 14:00 | :-) | |
| 14:00 | I spoke with chris about this yesterday | |
| 14:00 | it will need to be fixed before katipo can use it | |
| 14:00 | paul | i knew that. |
| 14:00 | the solution would be probably to : | |
| 14:01 | * have an array of %lineCN | |
| 14:01 | * add a ùlineCN{numberofitems} | |
| 14:02 | * on each loop step, check if the item exists with same status. If yes, just numberofitems++ | |
| 14:02 | * push @CNresults,@ournewarray outside the loop | |
| 14:02 | (just after) | |
| 14:02 | should not be so hard finally... | |
| 14:06 | owen | kados, you know how the error log shows the sql statement from searches? |
| 14:07 | kados | yep |
| 14:07 | what about it? | |
| 14:07 | owen | I was going to ask why it wasn't returning anything when I paste it to the mysql prompt, but I may be pasting the wrong query... |
| 14:08 | kados | I'm also not sure how the "AS" statements work diretly in the prompt |
| 14:09 | iirc I've used those queries directly before | |
| 14:09 | owen | I'm trying to figure out why these series searches aren't working. |
| 14:10 | kados | huh ... I thought it was due to incorrect marc records |
| 14:10 | or inconsistent at least | |
| 14:10 | owen | It depends on what situation you mean |
| 14:10 | We have plenty of records with correct series entries | |
| 14:10 | Just not all the things people expect | |
| 14:11 | I can't seem to bring up any results from the 490 tag, though, even though it looks like it's querying it. | |
| 14:11 | kados | huh ... |
| 14:11 | owen | select distinct m1.bibid from biblio,biblioitems,marc_biblio,marc_word as m1,marc_word as m2 where biblio.biblionumber=marc_biblio.biblionumber and biblio.biblionumber=biblioitems.biblionumber and m1.bibid=marc_biblio.bibid and (m1.bibid=m2.bibid) and ((m1.word like 'world' and m1.tagsubfield in ('440a','490a'))and (m2.word like 'snoopy' and m2.tagsubfield in('440a','490a'))) order by... |
| 14:11 | ...biblio.title; | |
| 14:11 | kados | well ... try a different order-by |
| 14:12 | (so this query works in mysql but not in search.pl? | |
| 14:12 | owen | Not in either place. |
| 14:12 | But when I query marc_subfield_table for 490a values, this item came up: | |
| 14:13 | 490 | a | The world of Snoopy. | |
| 14:13 | So my 'snoopy' search should have brought that up as well, I thought. | |
| 14:13 | It's as if it's not really searching 490a, just 440a. | |
| 14:14 | kados | do we have 490a as a 'see also' for 440a? |
| 14:14 | that's in preferences | |
| 14:14 | iirc | |
| 14:14 | owen | Yes. |
| 14:14 | kados | strange ... |
| 14:14 | owen | I wonder if the reverse needs to be the case as well? |
| 14:15 | No, because 440a is the only thing linked to biblio.subtitle. | |
| 14:15 | Or maybe I'm wrong. | |
| 14:15 | kados | wait ... it's showing up in the query |
| 14:15 | so it's right ... | |
| 14:15 | must be a query problem | |
| 14:15 | hmmm, there's no % after the words | |
| 14:15 | try it with a % | |
| 14:16 | also not sure if caps matter ... I suspect not | |
| 14:16 | owen | No luck with the % |
| 14:16 | kados | ok ... let's take a look at marc_word |
| 14:17 | select from marc_word where word like 'snoopy%' and tagsubfield like '490a'; | |
| 14:18 | huh ... it's empty | |
| 14:18 | but 440 works | |
| 14:19 | select * from marc_word where word like 'snoopy%' and tagsubfield in('440a', '490a'); | |
| 14:19 | that works too | |
| 14:20 | owen | But they're all from 440a. |
| 14:20 | Is marc_word not indexing 490a? | |
| 14:20 | kados | maybe not |
| 14:20 | owen | No, because some things are there. |
| 14:21 | kados | yep |
| 14:21 | quite a bit actually | |
| 14:22 | owen | ...but 'snoopy' just isn't in there. |
| 14:23 | Sketch, Skye, softly, Soho | |
| 14:23 | kados | select distinct m1.bibid from biblio,biblioitems,marc_biblio,marc_word as m1 where biblio.biblionumber=marc_biblio.biblionumber and biblio.biblionumber=biblioitems.biblionumber and m1.bibid=marc_biblio.bibid and (m1.word like 'snoopy' and m1.tagsubfield in ('440a','490a')) order by biblio.title; |
| 14:23 | this works ... it returns three results in mysql | |
| 14:24 | | 124603 | | |
| 14:24 | | 66832 | | |
| 14:24 | | 74531 | | |
| 14:24 | owen | Right, and those results are all in 440a tags |
| 14:24 | kados | what's the difference? |
| 14:24 | owen | But if you query marc_subfield_table for 490a tags, you get results with the word 'snoopy' in them |
| 14:24 | kados | ahh |
| 14:25 | that sounds like a major problem | |
| 14:25 | :-/ | |
| 14:25 | owen | select tag, subfieldcode, subfieldvalue from marc_subfield_table where tag = 490 and subfieldcode = 'a' limit 0,10 |
| 14:25 | That's the query that got me looking for snoopy in the first place. | |
| 14:25 | kados | wait ... I might know why |
| 14:25 | owen | I was trying to find a record with a 490 tag in it. |
| 14:26 | kados | I could try to rebuild marc_word with updatedatabase tonight |
| 14:26 | if that fixes it it means that I need to drop the marc_word table before I do the upgrade | |
| 14:27 | (something I was planning for anyway ... this would just be the first legitimate reason to do it) | |
| 14:29 | owen | Of course even if that fixes it, we still don't see 490 tags in opac-detail. That's a problem too. :( |
| 14:33 | kados | why's that? |
| 14:33 | owen | Why is it a problem? Or why is it that we don't see the 490 tag? |
| 14:34 | It's a problem because if a series search turns up an item with a 490 tag, opac-detail should show the series title so that it can be linked back to another series search. | |
| 14:35 | I think we don't see the 490 tag because only 440 is linked to biblio.seriestitle, and opac-detail grabs from there. | |
| 14:35 | As far as I know | |
| 14:35 | kados | hmmm |
| 14:36 | can you point me in the direction of a well-functioning series title search? | |
| 14:36 | it might help if I understood what we're attempting here ;-) | |
| 14:36 | owen | http://66.213.78.67/cgi-bin/ko[…]ail.pl?bib=125040 |
| 14:36 | See how you can click the linked series title and get others in the series? | |
| 14:37 | kados | ooh that's nice |
| 14:37 | owen | I added that this morning |
| 14:38 | kados | so are there any examples where the title exists in 490 (in marc_word) but doesnt' display? |
| 14:38 | (in opac-detail) | |
| 14:39 | owen | http://66.213.78.67/cgi-bin/ko[…]detail.pl?bib=242 |
| 14:45 | kados | SimpleMarc.pm: '490'=>{'a'=>{name=> 'seriestitle', rpt=>0, striptrail=>',:; |
| 14:46 | owen | ? |
| 14:52 | Maybe we could add something like Paul's query of marc notes | |
| 14:52 | ## get notes and subjects from MARC record | |
| 14:52 | at line 49 of opac-detail.pl | |
| 14:52 | kados | is that where 440a comes from? |
| 14:53 | owen | No, that's a place where Paul has added a query to the MARC tables because the koha tables don't have the information we want |
| 14:53 | kados | ahh ... so 440a comes from koha tables |
| 14:53 | owen | the 440 tag comes from my $dat = &bibdata($biblionumber); |
| 14:54 | kados | maybe the easiest solution is to write a script to populate koha tables with 490a is 490a exists |
| 14:54 | if even | |
| 14:54 | and tell the catalogers to start using 440a instead of 490a | |
| 14:55 | (do you know why both are being used?) | |
| 14:55 | owen | Because they're DIFFERENT!!!1 |
| 14:55 | ;) | |
| 14:55 | http://www.loc.gov/marc/biblio[…]hic/ecbdsers.html | |
| 14:55 | 490 is a series statement for which no series added entry is traced or for which the added entry is traced in one of the 800-830 fields in a form different from the form contained in field 490. | |
| 14:55 | Duh! | |
| 14:56 | :) | |
| 14:56 | kados | god damn it! |
| 14:57 | so ... we actually want 440a, and 440p | |
| 14:57 | and 490a, p if 440a, p don't exist ... right? | |
| 14:58 | (maybe n and v while we're at it eh?) | |
| 14:58 | owen | I don't think $p is used enough to worry about it |
| 14:58 | How would we query to see if there are any records with both 440 and 490? | |
| 14:59 | kados | well ... do you mean just to check? |
| 14:59 | owen | Yeah. I'm curious whether they're mutually exclusive. |
| 15:00 | kados | ok ... hmmm |
| 15:00 | owen | Of course the catalogers will say that to convert 490 to 440 would be WRONG |
| 15:00 | kados | well let's just do your suggestion then |
| 15:00 | we'll make a new subroutine | |
| 15:00 | to grab the series title | |
| 15:02 | owen | I'm going to go get some lunch. I'll be back in a bit. |
| 15:02 | kados | select count(*) from marc_word where tagsubfield like '440a'; |
| 15:02 | 73075 | |
| 15:02 | select count(*) from marc_word where tagsubfield like '490a'; | |
| 15:03 | 3481 | |
| 15:03 | select count(*) from marc_word where tagsubfield in('490a', '440a'); | |
| 15:03 | 76556 | |
| 15:07 | select count(distinct bibid) from marc_word where tagsubfield in('440a', '490a'); | |
| 15:07 | 23590 | |
| 15:57 | owen | Nice to be in The Plains and not have to work through my lunch :) |
| 16:10 | Something else for the to-do list: http://66.213.78.67/cgi-bin/ko[…]-detail.pl?bib=34 | |
| 16:10 | Multiple series titles getting squished together. Can we build a loop out of these so that each can be linked? | |
| 16:10 | I've added it to the wiki to-do list. | |
| 16:10 | ...which is growing rather than shrinking :( | |
| 16:25 | kados | yea :-) |
← Previous day | Today | Search | Index