| Time |
S |
Nick |
Message |
| 11:55 |
|
hdl |
owen : |
| 11:55 |
|
hdl |
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 |
|
owen |
Paul, I wanted to be sure to have a copy of our discussion of the new not for loan settings. |
| 12:02 |
|
owen |
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 |
|
hdl |
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 |
|
kados |
sorry ... hlt ;-) |
| 12:07 |
|
paul |
hi kados |
| 12:07 |
|
paul |
so they work... |
| 12:07 |
|
paul |
and what do we have to do now ? |
| 12:07 |
|
kados |
I think so ... actually they are very useful for stats ... |
| 12:08 |
|
kados |
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 |
|
owen |
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 |
|
owen |
Homebranch will not be accurate, if the holdingbranch is different. |
| 12:32 |
|
owen |
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 |
|
paul |
QUOTED |
| 13:08 |
|
paul |
for example, enter '700a','701a','702a' |
| 13:08 |
|
paul |
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 |
|
paul |
(10) |
| 13:48 |
|
kados |
I don't quite understand how $date_due is getting passed correctly in SearchMarc.pm |
| 13:49 |
|
kados |
It looks to me like it's set only once per biblinumber ... instead of per itemnumber |
| 13:49 |
|
kados |
(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 |
|
kados |
while (my $item = $sth_itemCN->fetchrow_hashref) { |
| 13:52 |
|
kados |
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 |
|
paul |
sth_issues is : |
| 13:53 |
|
paul |
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 |
|
kados |
I'd like to redesign this section of SearchMarc |
| 13:54 |
|
kados |
for libraries with multiple branches |
| 13:54 |
|
kados |
if an item exists twice in a library |
| 13:54 |
|
kados |
it shows up as: |
| 13:54 |
|
kados |
Nelsonville |
| 13:54 |
|
kados |
Nelsonville |
| 13:55 |
|
kados |
Instead of "Nelsonville (2)" |
| 13:55 |
|
kados |
imagine if we have 7 of an item! |
| 13:55 |
|
kados |
in one branch ... it gets really ugly |
| 13:58 |
|
kados |
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 |
|
paul |
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 |
|
paul |
koha 2.0 ? |
| 13:59 |
|
kados |
because for multi-branch libraries this method does not work |
| 13:59 |
|
kados |
yes ... this was handled differently in Koha 1.x and 2.0 |
| 13:59 |
|
paul |
right. |
| 13:59 |
|
paul |
maybe you could investigate on how katipo did this |
| 14:00 |
|
paul |
and find how to handle it in 2.2 |
| 14:00 |
|
kados |
katipo doesn't use 2.2 |
| 14:00 |
|
kados |
:-) |
| 14:00 |
|
kados |
I spoke with chris about this yesterday |
| 14:00 |
|
kados |
it will need to be fixed before katipo can use it |
| 14:00 |
|
paul |
i knew that. |
| 14:00 |
|
paul |
the solution would be probably to : |
| 14:01 |
|
paul |
* have an array of %lineCN |
| 14:01 |
|
paul |
* add a ùlineCN{numberofitems} |
| 14:02 |
|
paul |
* on each loop step, check if the item exists with same status. If yes, just numberofitems++ |
| 14:02 |
|
paul |
* push @CNresults,@ournewarray outside the loop |
| 14:02 |
|
paul |
(just after) |
| 14:02 |
|
paul |
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 |
|
kados |
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 |
|
kados |
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 |
|
kados |
or inconsistent at least |
| 14:10 |
|
owen |
It depends on what situation you mean |
| 14:10 |
|
owen |
We have plenty of records with correct series entries |
| 14:10 |
|
owen |
Just not all the things people expect |
| 14:11 |
|
owen |
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 |
|
owen |
...biblio.title; |
| 14:11 |
|
kados |
well ... try a different order-by |
| 14:12 |
|
kados |
(so this query works in mysql but not in search.pl? |
| 14:12 |
|
owen |
Not in either place. |
| 14:12 |
|
owen |
But when I query marc_subfield_table for 490a values, this item came up: |
| 14:13 |
|
owen |
490 | a | The world of Snoopy. |
| 14:13 |
|
owen |
So my 'snoopy' search should have brought that up as well, I thought. |
| 14:13 |
|
owen |
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 |
|
kados |
that's in preferences |
| 14:14 |
|
kados |
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 |
|
owen |
No, because 440a is the only thing linked to biblio.subtitle. |
| 14:15 |
|
owen |
Or maybe I'm wrong. |
| 14:15 |
|
kados |
wait ... it's showing up in the query |
| 14:15 |
|
kados |
so it's right ... |
| 14:15 |
|
kados |
must be a query problem |
| 14:15 |
|
kados |
hmmm, there's no % after the words |
| 14:15 |
|
kados |
try it with a % |
| 14:16 |
|
kados |
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 |
|
kados |
select from marc_word where word like 'snoopy%' and tagsubfield like '490a'; |
| 14:18 |
|
kados |
huh ... it's empty |
| 14:18 |
|
kados |
but 440 works |
| 14:19 |
|
kados |
select * from marc_word where word like 'snoopy%' and tagsubfield in('440a', '490a'); |
| 14:19 |
|
kados |
that works too |
| 14:20 |
|
owen |
But they're all from 440a. |
| 14:20 |
|
owen |
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 |
|
kados |
quite a bit actually |
| 14:22 |
|
owen |
...but 'snoopy' just isn't in there. |
| 14:23 |
|
owen |
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 |
|
kados |
this works ... it returns three results in mysql |
| 14:24 |
|
kados |
| 124603 | |
| 14:24 |
|
kados |
| 66832 | |
| 14:24 |
|
kados |
| 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 |
|
kados |
that sounds like a major problem |
| 14:25 |
|
kados |
:-/ |
| 14:25 |
|
owen |
select tag, subfieldcode, subfieldvalue from marc_subfield_table where tag = 490 and subfieldcode = 'a' limit 0,10 |
| 14:25 |
|
owen |
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 |
|
kados |
if that fixes it it means that I need to drop the marc_word table before I do the upgrade |
| 14:27 |
|
kados |
(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 |
|
owen |
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 |
|
owen |
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 |
|
owen |
As far as I know |
| 14:35 |
|
kados |
hmmm |
| 14:36 |
|
kados |
can you point me in the direction of a well-functioning series title search? |
| 14:36 |
|
kados |
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 |
|
owen |
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 |
|
kados |
(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 |
|
owen |
Maybe we could add something like Paul's query of marc notes |
| 14:52 |
|
owen |
## get notes and subjects from MARC record |
| 14:52 |
|
owen |
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 |
|
kados |
if even |
| 14:54 |
|
kados |
and tell the catalogers to start using 440a instead of 490a |
| 14:55 |
|
kados |
(do you know why both are being used?) |
| 14:55 |
|
owen |
Because they're DIFFERENT!!!1 |
| 14:55 |
|
owen |
;) |
| 14:55 |
|
owen |
http://www.loc.gov/marc/biblio[…]hic/ecbdsers.html |
| 14:55 |
|
owen |
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 |
|
owen |
Duh! |
| 14:56 |
|
owen |
:) |
| 14:56 |
|
kados |
god damn it! |
| 14:57 |
|
kados |
so ... we actually want 440a, and 440p |
| 14:57 |
|
kados |
and 490a, p if 440a, p don't exist ... right? |
| 14:58 |
|
kados |
(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 |
|
owen |
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 |
|
kados |
we'll make a new subroutine |
| 15:00 |
|
kados |
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 |
|
kados |
73075 |
| 15:02 |
|
kados |
select count(*) from marc_word where tagsubfield like '490a'; |
| 15:03 |
|
kados |
3481 |
| 15:03 |
|
kados |
select count(*) from marc_word where tagsubfield in('490a', '440a'); |
| 15:03 |
|
kados |
76556 |
| 15:07 |
|
kados |
select count(distinct bibid) from marc_word where tagsubfield in('440a', '490a'); |
| 15:07 |
|
kados |
23590 |
| 15:57 |
|
owen |
Nice to be in The Plains and not have to work through my lunch :) |
| 16:10 |
|
owen |
Something else for the to-do list: http://66.213.78.67/cgi-bin/ko[…]-detail.pl?bib=34 |
| 16:10 |
|
owen |
Multiple series titles getting squished together. Can we build a loop out of these so that each can be linked? |
| 16:10 |
|
owen |
I've added it to the wiki to-do list. |
| 16:10 |
|
owen |
...which is growing rather than shrinking :( |
| 16:25 |
|
kados |
yea :-) |
