Nabble - Koha - Zebra

[Koha-translate] Why contribute to Koha?

2008-12-02T07:48:52Z

Hello,

I am a Ph.D. candidate in Instructional Technology at the University of Tennessee. My dissertation focuses on what motivates people to contribute to F/OSS projects. Though it may seem obvious to you, many non-programmers are still suspicious of OSS and think there must be a catch. Can you help me to demonstrate why talented programmers are willing to work for free? My survey should take no more than 15 minutes and asks for no identifying information.

Please click on the following link to take the survey. If you are interested in the results of the survey, please send me a message. This is my second request for participation; if you responded already, please ignore this request.

http://ubiquity.utk.edu/limesurvey/index.php?sid=45871&lang=en

Your help is highly appreciated.

Thanks,

Hoda Baytiyeh.

hodabn@...

_______________________________________________
Koha-translate mailing list
Koha-translate@...
http://lists.koha.org/mailman/listinfo/koha-translate

Koha3.0 beta + Zebra can not search.

2008-03-30T18:49:20Z

Hi all,

I just installed koha3.0 beta and zebra 2.0.26. Everything works fine except opac search.
I can not find any biblio i add and on zebra terminal, i got this message:

10:42:11-06/03 zebrasrv(1) [session] Session - OK 1
unix:/var/run/koha/zebradb/bibliosocket 29767
10:42:11-06/03 zebrasrv(1) [request] Auth idPass kohauser -
10:42:11-06/03 zebrasrv(1) [request] Init OK - ID:81/81
Name:ZOOM-C/YAZ Version:1.154/3.0.24
10:42:11-06/03 zebrasrv(1) [request] Search biblios ERROR 109 1 1+0
RPN @attrset Bib-1 @or @or @or @or @or @attr 1=36 @attr 4=1 @attr 6=3
@attr 9=32 @attr 2=102 Duen @attr 1=4 @attr 4=1 @attr 6=3 @attr 9=28
@attr 2=102 Duen @attr 1=4 @attr 4=1 @attr 9=26 @attr 2=102 Duen @attr
4=6 @attr 5=103 @attr 9=16 @attr 2=102 Duen @attr 4=6 @attr 5=1 @attr
9=14 @attr 2=102 "duen? " @attr 4=6 @attr 9=14 @attr 2=102 Duen
10:42:11-06/03 zebrasrv(1) [session] Connection closed by client

My question is What is "Search biblios ERROR 109 "?

I follow the installation guide to install koha and everything is default setting:

1. perl Makefile.PL
(you will be prompted to answer a number of questions)
2. make
3.(optional) make test
4. sudo make install
5. sudo ln -s /etc/koha/koha-httpd.conf /etc/apache2/sites-available/koha
(note that the path to koha-httpd.conf may be different depending on your
installation choices)
6. sudo a2enmod rewrite
7. sudo a2ensite koha && /etc/init.d/apache2 reload
8. sudo zebrasrv -f /etc/koha/koha-conf.xml
(note that you will want to run Zebra in daemon mode for a production
system)
9. Browse to http://servername:8080/ and answer the questions

Is that enough? Any additional settings on zebra?

Anyone got koha3-zebra work?

Thanks alot for anybody help...

new lists.koha.org mailing list system for Koha

2008-03-25T06:09:31Z

A new list server is up now check :
http://lists.koha.org/mailmain/listinfo/koha-zebra

--
Henri-Damien LAURENT
_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.koha.org/mailman/listinfo/koha-zebra

Re: Scan problem.

2007-11-02T10:56:48Z

Henri-Damien LAURENT wrote:

> Mike Taylor a écrit :
>> Henri-Damien LAURENT writes:
>> > the latest question I found a workaround :
>> > my $scan= $conn->scan_pqf('@attr 1=21 @attr 6=3 @attr 5=102 @attr 8=1
>> > "[A-z0-9]"');
>> > That way, I can get all the publishers.
>>
>> Hmm. But if you start your scan from the just "a" that will yield the
>> same start-point. Remember that the term in a scan "query" is not
>> searched for, just used as a start-point within the list of all
>> terms. If you want to start from the very beginning, you should
>> probably use the empty search-term "", which sorts to the start.
>>
>> > This query was wrong because no search parameter. I corrected it.
>>
>> And is it working?
>>
> empty search term is not working.
> What works best is "0".
>
>> > >From perldoc ZOOM :
>> > number [default: 10]
>> > Indicates how many terms should be returned in the ScanSet.
>> > The number actually returned may be less, if the start-point is near the
>> > end of the index, but will not be greater.
>> > I tried to set number to 100 this way
>> > $conn->option(preferredRecordSyntax => "usmarc",number=>100);
>> >
>> > And got only 10 results.
>> > Am I doing wrong ?
>>
>> For some reason, you can't set multiple options in a single call like
>> this: the second and subsequent are ignored. Use:
>> $conn->option(preferredRecordSyntax => "usmarc");
>> $conn->option(number=>100);
>>
> Thanks for this very valuable information.
> It works now.
>> > Is there a way to order "scanned" term on hit count ?
>>
>> Not that I know of. If there is a way, it's Zebra-specific, and Adam
>> will be the one who knows about it.
>>
> Let us wait his advice on that then.
>

The order of scan terms are ordered in lex. order. Not by frequency. We
are, however, working on this . The solution will still be "scan" but an
attribute will signal "order by frequency". AKA faceted search.

/ Adam

_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.nongnu.org/mailman/listinfo/koha-zebra

Re: Scan problem.

2007-10-29T13:38:02Z

Henri-Damien LAURENT writes:
> > > the latest question I found a workaround :
> > > my $scan= $conn->scan_pqf('@attr 1=21 @attr 6=3 @attr 5=102 @attr 8=1
> > > "[A-z0-9]"');
> > > That way, I can get all the publishers.
> >
> > Hmm. But if you start your scan from the just "a" that will yield the
> > same start-point. Remember that the term in a scan "query" is not
> > searched for, just used as a start-point within the list of all
> > terms. If you want to start from the very beginning, you should
> > probably use the empty search-term "", which sorts to the start.
> >
> > > This query was wrong because no search parameter. I corrected it.
> >
> > And is it working?
> >
> empty search term is not working.
> What works best is "0".

Strange that "" doesn't work. What is the diagnostic?

Terms beginning with character that precedes "0" in ASCII order will
not be found using "0", of course. I suggest trying " " (space),
which IIRC is the lowest-numbered printing character in the ASCII set.

> > For some reason, you can't set multiple options in a single call like
> > this: the second and subsequent are ignored. Use:
> > $conn->option(preferredRecordSyntax => "usmarc");
> > $conn->option(number=>100);
> >
> Thanks for this very valuable information.
> It works now.

Excellent.

_/|_ ___________________________________________________________________
/o ) \/ Mike Taylor <mike@...> http://www.miketaylor.org.uk
)_v__/\ "Troodontids are almost certainly deinonychosaurs. I was wrong
about troodontids in 1994, but don't care" -- Thomas R. Holtz, Jr.

_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.nongnu.org/mailman/listinfo/koha-zebra

Re: order by date of publication ?

2007-10-29T13:17:05Z

Hello Henri-Damien,

I just found your message about sorting by date; I thought I had
resolved this in the CCFLS catalog, but maybe it's cropped up again
since I updated zebra. Originally the sort-by-publication date was set
to use the date in 008, but in our records that is not always accurate,
so we changed it to use the date in 260c. However, we have the same
problem as you do, with "c" being used for copyright, etc. I removed
the c's from that field before I imported, but that is probably not the
best thing to do, since records added since we migrated could have them
there. It really should be able to remove extraneous letters before
sorting. That's not what's happening here, though, because I did the
same search as you and looked at the MARC view, and there are no c's in
260c for the ones I looked at.

Cindy Murdock
CCFLS

Henri-Damien LAURENT wrote:

> Hi,
> I think I have a problem of sorting with zebra.
> Indeed,
> here is a list which comes from ccfls
> I asked for walt whitman and walt as author, and asked for order by
> date-of-Publication newest to oldest.
> 1997 comes First
> then 1999 then 1997 again, and 1994
>
> here comes the list
>
> To the soul : Thomas Hampson sings the poetry of Walt Whitman / by
> Hampson, Thomas.
>
> - 1997 - EMI Classics, ; New York : - 1 compact disc (74:49 min)
>
> Copies available at: Meadville Public Library (1),
> CDCD B Hampson
> Walt Whitman : selected poems, 1855-1892 : a new edition / by
> Whitman, Walt,
>
> - 1999 - St. Martin's Press, ; New York : - xxviii, 530 p. : ; 25 cm.
>
> Copies available at: Meadville Public Library (1),
> NF811.3 Whitman
> Walt Whitman / by Whitman, Walt,
>
> - 1997 - Sterling Pub., ; New York : - 48 p. : : Includes index. ; 26 cm.
>
> Copies available at: Meadville Public Library (1),
> JNFJUV 811 Whitman
> Walt Whitman / by Whitman, Walt,
>
> - 1997 - Sterling Pub., ; New York : - 48 p. : : Includes index. ; 26 cm.
>
> Copies available at: Meadville Public Library (1),
> YANFYA 811.3 Whitman
> Walt Whitman / by Loewen, Nancy,
>
> - 1994 - Creative Editions, ; Mankato, Minn. : - 45, [1] p. : ; 29 cm.
>
> Copies available at: Meadville Public Library (1),
> NF811 Loewen
>
>
>
> I took ccfls to show that it was not a frenchy problem, but a global one.
>
> On a french catalogue equiped with rel_30, with date of publication
> Newest to oldest, we have :
> 2006, 2004,2003,1999,1857 !!, 1985, 1980, 1980
> and date of publication is indexed as !:y
>
> Titre
>
> Paul de Tarse en Méditerranée
> <https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=53331>
> , recherches autour de la navigation dans l'Antiquité | Ac 27-28, 16
>
> Chantal Reynier
> <https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/search.pl?q=au:Chantal%20Reynier>
> - 2006 - les Éd. du Cerf Description : - 288 p. ; 22 cm
>
> Histoire de Paul de Tarse
> <https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=54103>
> , le voyageur du Christ
>
> Jerôme Murphy-O'Connor
> <https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/search.pl?q=au:Jer%C3%B4me%20Murphy-O%27Connor>
> - 2004 - Ed. du Cerf Description : - 315 p. ; 22 cm
>
> Tarse et Jerusalem
> <https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=54360>
> , la double culture de l'apôtre Paul en Galates 3,6-4,7
>
> Marc Rastoin,...
> <https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/search.pl?q=au:Marc%20Rastoin%2C...>
> - 2003 - Ed. Pontificio Istituto Biblico Description : - 1 vol. (376 p.)
> ; 24 cm
>
> Jacob Taubes et Paul de Tarse
> <https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=54033>
> , Notes de lecture
>
> Simon C. Mimouni
> <https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/search.pl?q=au:Simon%20C.%20Mimouni>
> - 1999 - Peeters Description : - [10] p. ; 25 cm
>
> Opera
> <https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=3230>
>
>
> Diodore de Tarse
> <https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/search.pl?q=au:Diodore%20de%20%3Cspan%20class%3Dterm%3ETarse%3C%2Fspan%3E>
> - 1857 Description :
>
> Jésus de Nazareth et Paul de Tarse
> <https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=6359>
>
>
> Christophe Senft
> <https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/search.pl?q=au:Christophe%20Senft>
> - 1985 - Labor et Fides Description :
>
> Paul de Tarse
> <https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=11540>
> , Apôtre du notre temps
>
> contributions de G. Benelli ... [et al.]
> <https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/search.pl?q=au:contributions%20de%20G.%20Benelli%20...%20%5Bet%20al.%5D>
> - 1979 - Abbaye de S. Paul h.l.m Description : - 806 p. ; 24 cm
>
> Commentarii in Psalmos I-L [1-50]
> <https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=11890>
>
>
> Diodore de Tarse
> <https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/search.pl?q=au:Diodore%20de%20%3Cspan%20class%3Dterm%3ETarse%3C%2Fspan%3E>
> - 1980 - Brepols Description : - CXX-328p. ; 25cm
>
> Paul de Tarse
> <https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=13309>
> , congrès
>
> [organisé par ] l' ACFEB, Strasbourg, 1995
> <https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/search.pl?q=au:%5Borganis%C3%A9%20par%20%5D%20l%27%20ACFEB%2C%20Strasbourg%2C%201995>
> - 1996 - Ed. du Cerf Description : - 373p. ; 22cm
>
> Les Fragments de Tarse au Louvre
> <https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=22023>
>
>
> Léon Alexandre Heuzey
> <https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/search.pl?q=au:L%C3%A9on%20Alexandre%20%20Heuzey>
> - 1876 Description :
>
> Paul de Tarse
> <https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=22920>
>
>
> Joseph Holzner
> <https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/search.pl?q=au:Joseph%20%20Holzner>
> - 1950 - Alsatia Description : - 577p. ; 24cm
>
> Saul de Tarse
> <https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=27766>
> , Lettres à une jeune église
>
> Jean Paul Benoit
> <https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/search.pl?q=au:Jean%20Paul%20%20Benoit>
> Description : - 214p.
>
> Paul de Tarse
> <https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=42201>
>
>
> Michel A. Hubaut
> <https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/search.pl?q=au:Michel%20A.%20Hubaut>
> - 1989 - Desclée Description : - 143 p. ; 22 cm
>
> Le Psautier chez les Pères
> <https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=48415>
>
>
> - 1994 - Centre d'analyse et de documentation patristiques Description
> : - 310p. ; 21cm
>
> Le Psautier chez les Pères
> <https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=48417>
>
>
> - 1994 - Centre d'analyse et de documentation patristiques Description
> : - 310p. ; 21cm
>
> Paul de Tarse
> <https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=48697>
> , un homme aux prises avec Dieu
>
> Daniel Marguerat
> <https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/search.pl?q=au:Daniel%20%20Marguerat>
> - 1999 - Ed. du Moulin Description : - 109p. ; 18cm
>
>
>
> Moreover, I have to state that :
> in France, 210$d is supposed to have publication date but also sometimes
> some information such as c for copyright, and other terms...
> Maybe it could be overcome by using null words for sorting dates (I hope
> so). Is this true ?
> Hoping to have an answer soon.
>

_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.nongnu.org/mailman/listinfo/koha-zebra

Re: Scan problem.

2007-10-29T12:08:40Z

Mike Taylor a écrit :

> Henri-Damien LAURENT writes:
> > the latest question I found a workaround :
> > my $scan= $conn->scan_pqf('@attr 1=21 @attr 6=3 @attr 5=102 @attr 8=1
> > "[A-z0-9]"');
> > That way, I can get all the publishers.
>
> Hmm. But if you start your scan from the just "a" that will yield the
> same start-point. Remember that the term in a scan "query" is not
> searched for, just used as a start-point within the list of all
> terms. If you want to start from the very beginning, you should
> probably use the empty search-term "", which sorts to the start.
>
> > This query was wrong because no search parameter. I corrected it.
>
> And is it working?
>

empty search term is not working.
What works best is "0".

> > >From perldoc ZOOM :
> > number [default: 10]
> > Indicates how many terms should be returned in the ScanSet.
> > The number actually returned may be less, if the start-point is near the
> > end of the index, but will not be greater.
> > I tried to set number to 100 this way
> > $conn->option(preferredRecordSyntax => "usmarc",number=>100);
> >
> > And got only 10 results.
> > Am I doing wrong ?
>
> For some reason, you can't set multiple options in a single call like
> this: the second and subsequent are ignored. Use:
> $conn->option(preferredRecordSyntax => "usmarc");
> $conn->option(number=>100);
>

Thanks for this very valuable information.
It works now.
> > Is there a way to order "scanned" term on hit count ?
>
> Not that I know of. If there is a way, it's Zebra-specific, and Adam
> will be the one who knows about it.
>
Let us wait his advice on that then.

--
Henri Damien LAURENT et Paul POULAIN
Consultants indépendants
en logiciels libres et bibliothéconomie (http://www.koha-fr.org)

_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.nongnu.org/mailman/listinfo/koha-zebra

Re: Scan problem.

2007-10-29T09:47:50Z

Henri-Damien LAURENT writes:
> the latest question I found a workaround :
> my $scan= $conn->scan_pqf('@attr 1=21 @attr 6=3 @attr 5=102 @attr 8=1
> "[A-z0-9]"');
> That way, I can get all the publishers.

Hmm. But if you start your scan from the just "a" that will yield the
same start-point. Remember that the term in a scan "query" is not
searched for, just used as a start-point within the list of all
terms. If you want to start from the very beginning, you should
probably use the empty search-term "", which sorts to the start.

> >From perldoc ZOOM :
> number [default: 10]
> Indicates how many terms should be returned in the ScanSet.
> The number actually returned may be less, if the start-point is near the
> end of the index, but will not be greater.
> I tried to set number to 100 this way
> $conn->option(preferredRecordSyntax => "usmarc",number=>100);
>
> And got only 10 results.
> Am I doing wrong ?

For some reason, you can't set multiple options in a single call like
this: the second and subsequent are ignored. Use:
$conn->option(preferredRecordSyntax => "usmarc");
$conn->option(number=>100);

> Is there a way to order "scanned" term on hit count ?

Not that I know of. If there is a way, it's Zebra-specific, and Adam
will be the one who knows about it.

> > > My last question would be : What if I want to get all the distinct
> > > values stored for authors. Can I get them via a scan ?
> > > something like scan_pqf("@attr 1=1 @attr 8=1 @attr 6=3") which would
> > > return all authors, complete subfields, for resultset 1, assuming names
> > > and surnames would be in the same subfield.
> >
> > That looks about right. Adam can comment on this from a more informed
> > perspective than I can.
> >
> This query was wrong because no search parameter. I corrected it.

And is it working?

_/|_ ___________________________________________________________________
/o ) \/ Mike Taylor <mike@...> http://www.miketaylor.org.uk
)_v__/\ "Historically, Taunton is part of Minehead already" -- Monty
Python's Flying Circus.

_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.nongnu.org/mailman/listinfo/koha-zebra

Re: Scan problem.

2007-10-29T08:54:12Z

Mike Taylor a écrit :

> Henri-Damien LAURENT writes:
> > Hi,
> > I am exploring a bit further scanning feature.
> > It is really great and the fact that we can use @attr 8 with resultset
> > number would be of great value to display facets in my opinion.
> > But I am facing some problems :
> > ZOOM::Resultsets and ZOOM::Scansets are linked to connexions.
> > If I want to use scan_pqf() with @attr 8= number, to limit facet to the
> > previous resultset, I have to get or to guess resultset Number.
> > But how can I since resultsets donot have any id property,
> > and users are likely to refine or do multiple searchs ?
>
> You can retrieve the result-set ID using:
> $rs->option("resultSetId");
>
> (Make sure you have an up-to-date YAZ for this to work.)
>
> > One solution I see would be to create and destroy connections right
> > before and right after each search. Would kohagang agree on that ?
>
> I don't see that this is either necessary or sufficient.
>
> > That way, ResultSet number would always be 1.
>
> Not necessarily.
>
> > But it seems to me that getting resultset number as a property of
> > ZOOM::ResultSets OR making ScanSets depend not only on connections but
> > also on ResultSets could be a solution and could be interesting.
>
> Changing the model to make ScanSet dependent on ResultSet would have
> dramatic consequences and would violate the ZOOM Abstract API. But I
> guess that you don't need this if you can fetch resultSetId.
>
> > Another question is :
> > number [default: 10]
> > Indicates how many terms should be returned in the ScanSet.
> > The number actually returned may be less, if the start-point is near the
> > end of the index, but will not be greater.
> > Is there really no way to get More results ?
>
> Well, sure: set "number" to a higher number.
>
> > What If I wanted only the 10 most relevant results but not the 10
> > first ? Would there be a solution ?
>
> No, there is no relevance support in scan: it is a very literal-minded
> browse of the index.
>
>
>
> > (But would work for Callnumbers, simple subjects, branches and
> > Publihser names). Of course, we could get some by entering a
> > one-letter word a b c d.... But if we could avoid...
>
> Sorry, I don't understand that question.
>

Hi
thanks for your answer.
resulsetId is really great.
the latest question I found a workaround :
my $scan= $conn->scan_pqf('@attr 1=21 @attr 6=3 @attr 5=102 @attr 8=1
"[A-z0-9]"');
That way, I can get all the publishers.

From perldoc ZOOM :
number [default: 10]
Indicates how many terms should be returned in the ScanSet.
The number actually returned may be less, if the start-point is near the
end of the index, but will not be greater.
I tried to set number to 100 this way
$conn->option(preferredRecordSyntax => "usmarc",number=>100);

And got only 10 results.
Am I doing wrong ?

Is there a way to order "scanned" term on hit count ?
> > My last question would be : What if I want to get all the distinct
> > values stored for authors. Can I get them via a scan ?
> > something like scan_pqf("@attr 1=1 @attr 8=1 @attr 6=3") which would
> > return all authors, complete subfields, for resultset 1, assuming names
> > and surnames would be in the same subfield.
>
> That looks about right. Adam can comment on this from a more informed
> perspective than I can.
>
This query was wrong because no search parameter. I corrected it.

--
Henri Damien LAURENT et Paul POULAIN
Consultants indépendants
en logiciels libres et bibliothéconomie (http://www.koha-fr.org)

_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.nongnu.org/mailman/listinfo/koha-zebra

Scan problem.

2007-10-29T08:15:55Z

Henri-Damien LAURENT writes:
> Hi,
> I am exploring a bit further scanning feature.
> It is really great and the fact that we can use @attr 8 with resultset
> number would be of great value to display facets in my opinion.
> But I am facing some problems :
> ZOOM::Resultsets and ZOOM::Scansets are linked to connexions.
> If I want to use scan_pqf() with @attr 8= number, to limit facet to the
> previous resultset, I have to get or to guess resultset Number.
> But how can I since resultsets donot have any id property,
> and users are likely to refine or do multiple searchs ?

You can retrieve the result-set ID using:
$rs->option("resultSetId");

(Make sure you have an up-to-date YAZ for this to work.)

> One solution I see would be to create and destroy connections right
> before and right after each search. Would kohagang agree on that ?

I don't see that this is either necessary or sufficient.

> That way, ResultSet number would always be 1.

Not necessarily.

> But it seems to me that getting resultset number as a property of
> ZOOM::ResultSets OR making ScanSets depend not only on connections but
> also on ResultSets could be a solution and could be interesting.

Changing the model to make ScanSet dependent on ResultSet would have
dramatic consequences and would violate the ZOOM Abstract API. But I
guess that you don't need this if you can fetch resultSetId.

> Another question is :
> number [default: 10]
> Indicates how many terms should be returned in the ScanSet.
> The number actually returned may be less, if the start-point is near the
> end of the index, but will not be greater.
> Is there really no way to get More results ?

Well, sure: set "number" to a higher number.

> What If I wanted only the 10 most relevant results but not the 10
> first ? Would there be a solution ?

No, there is no relevance support in scan: it is a very literal-minded
browse of the index.

> My last question would be : What if I want to get all the distinct
> values stored for authors. Can I get them via a scan ?
> something like scan_pqf("@attr 1=1 @attr 8=1 @attr 6=3") which would
> return all authors, complete subfields, for resultset 1, assuming names
> and surnames would be in the same subfield.

That looks about right. Adam can comment on this from a more informed
perspective than I can.

> (But would work for Callnumbers, simple subjects, branches and
> Publihser names). Of course, we could get some by entering a
> one-letter word a b c d.... But if we could avoid...

Sorry, I don't understand that question.

_/|_ ___________________________________________________________________
/o ) \/ Mike Taylor <mike@...> http://www.miketaylor.org.uk
)_v__/\ ... but Doctor, surely the odds against that happening are
astronomical!

_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.nongnu.org/mailman/listinfo/koha-zebra

Scan problem.

2007-10-27T08:43:43Z

Hi,
I am exploring a bit further scanning feature.
It is really great and the fact that we can use @attr 8 with resultset
number would be of great value to display facets in my opinion.
But I am facing some problems :
ZOOM::Resultsets and ZOOM::Scansets are linked to connexions.
If I want to use scan_pqf() with @attr 8= number, to limit facet to the
previous resultset, I have to get or to guess resultset Number.
But how can I since resultsets donot have any id property,
and users are likely to refine or do multiple searchs ?

One solution I see would be to create and destroy connections right
before and right after each search. Would kohagang agree on that ?
That way, ResultSet number would always be 1.
But it seems to me that getting resultset number as a property of
ZOOM::ResultSets OR making ScanSets depend not only on connections but
also on ResultSets could be a solution and could be interesting.
ResultSets seems there in Zebra, so there should be a solution to play
with them via zoom.

Another question is :
number [default: 10]
Indicates how many terms should be returned in the ScanSet.
The number actually returned may be less, if the start-point is near the
end of the index, but will not be greater.
Is there really no way to get More results ? What If I wanted only the
10 most relevant results but not the 10 first ? Would there be a solution ?

My last question would be : What if I want to get all the distinct
values stored for authors. Can I get them via a scan ?
something like scan_pqf("@attr 1=1 @attr 8=1 @attr 6=3") which would
return all authors, complete subfields, for resultset 1, assuming names
and surnames would be in the same subfield. (But would work for
Callnumbers, simple subjects, branches and Publihser names). Of course,
we could get some by entering a one-letter word a b c d.... But if we
could avoid...

Does Anyone has answers ?
Is anyone interested ?
What do Koha gang think about that ?

--
Henri Damien LAURENT et Paul POULAIN
Consultants indépendants
en logiciels libres et bibliothéconomie (http://www.koha-fr.org)

_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.nongnu.org/mailman/listinfo/koha-zebra

Re: Zebra Sorting Problems

2007-10-26T09:41:40Z

Hi
I have the same issue on Date-Of-Publication.
I think this may be because some information in 100$a is not fully detailed for dates of publication.
But I want also to check whether those issues are fixed. (For Titles and authors, I know it is.)

Joshua M. Ferraro wrote:

Hi all,

Chris and I have been trying to get ZOOM's sort() or sort_as() methods
working ... hoping ID guys can shed some light on why they're not.

So ... right after a search we're doing:

# sort result set
# in theory this should sort by title
if ($rs->sort("yaz", "1=4 <i") < 0) {
warn "sort failed";
}
else {
warn "sorted";
}

The Apache log shows:
[Thu Mar 16 10:24:24 2006] [error] [client 70.106.173.65] sorted at /home/koha/testing/koha/intranet/modules/C4/SearchMarc.pm line 265., referer: http://opactest.liblime.com/cgi-bin/koha/opac-search.pl

However, Zebra's log shows:

10:24:24-16/03 zebrasrv(3) [request] Sort ERROR 207 (1)->1

and the results are clearly not sorted ...

Here's a short sample of our 'collection.abs' file:
melm 090$c identifier-standard,identifier-standard:p
melm 020$a isbn:w,!:s
melm 100 author,author:p,!:s
melm 110 author
melm 111 author
melm 130 title
melm 240 title,title:p
melm 242 title,title:p
melm 243 title,title:p
melm 245$c author
melm 245 title,title:p
melm 245/?/a title !:w,!:p,!:s

Any suggestions for this problem? Also, we're interested in the
relevance ranking options ... how would we set that up?

Cheers,

--
Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE
President, Technology migration, training, maintenance, support
LibLime Featuring Koha Open-Source ILS
jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS

_______________________________________________
Koha-zebra mailing list
Koha-zebra@nongnu.org
http://lists.nongnu.org/mailman/listinfo/koha-zebra

order by date of publication ?

2007-09-26T06:59:18Z

Hi,
I think I have a problem of sorting with zebra.
Indeed,
here is a list which comes from ccfls
I asked for walt whitman and walt as author, and asked for order by
date-of-Publication newest to oldest.
1997 comes First
then 1999 then 1997 again, and 1994

here comes the list

To the soul : Thomas Hampson sings the poetry of Walt Whitman / by
Hampson, Thomas.

- 1997 - EMI Classics, ; New York : - 1 compact disc (74:49 min)

Copies available at: Meadville Public Library (1),
CDCD B Hampson
Walt Whitman : selected poems, 1855-1892 : a new edition / by
Whitman, Walt,

- 1999 - St. Martin's Press, ; New York : - xxviii, 530 p. : ; 25 cm.

Copies available at: Meadville Public Library (1),
NF811.3 Whitman
Walt Whitman / by Whitman, Walt,

- 1997 - Sterling Pub., ; New York : - 48 p. : : Includes index. ; 26 cm.

Copies available at: Meadville Public Library (1),
JNFJUV 811 Whitman
Walt Whitman / by Whitman, Walt,

- 1997 - Sterling Pub., ; New York : - 48 p. : : Includes index. ; 26 cm.

Copies available at: Meadville Public Library (1),
YANFYA 811.3 Whitman
Walt Whitman / by Loewen, Nancy,

- 1994 - Creative Editions, ; Mankato, Minn. : - 45, [1] p. : ; 29 cm.

Copies available at: Meadville Public Library (1),
NF811 Loewen

I took ccfls to show that it was not a frenchy problem, but a global one.

On a french catalogue equiped with rel_30, with date of publication
Newest to oldest, we have :
2006, 2004,2003,1999,1857 !!, 1985, 1980, 1980
and date of publication is indexed as !:y

Titre

Paul de Tarse en Méditerranée
<https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=53331>
, recherches autour de la navigation dans l'Antiquité | Ac 27-28, 16

Chantal Reynier
<https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/search.pl?q=au:Chantal%20Reynier>
- 2006 - les Éd. du Cerf Description : - 288 p. ; 22 cm

Histoire de Paul de Tarse
<https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=54103>
, le voyageur du Christ

Jerôme Murphy-O'Connor
<https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/search.pl?q=au:Jer%C3%B4me%20Murphy-O%27Connor>
- 2004 - Ed. du Cerf Description : - 315 p. ; 22 cm

Tarse et Jerusalem
<https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=54360>
, la double culture de l'apôtre Paul en Galates 3,6-4,7

Marc Rastoin,...
<https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/search.pl?q=au:Marc%20Rastoin%2C...>
- 2003 - Ed. Pontificio Istituto Biblico Description : - 1 vol. (376 p.)
; 24 cm

Jacob Taubes et Paul de Tarse
<https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=54033>
, Notes de lecture

Simon C. Mimouni
<https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/search.pl?q=au:Simon%20C.%20Mimouni>
- 1999 - Peeters Description : - [10] p. ; 25 cm

Opera
<https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=3230>

Diodore de Tarse
<https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/search.pl?q=au:Diodore%20de%20%3Cspan%20class%3Dterm%3ETarse%3C%2Fspan%3E>
- 1857 Description :

Jésus de Nazareth et Paul de Tarse
<https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=6359>

Christophe Senft
<https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/search.pl?q=au:Christophe%20Senft>
- 1985 - Labor et Fides Description :

Paul de Tarse
<https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=11540>
, Apôtre du notre temps

contributions de G. Benelli ... [et al.]
<https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/search.pl?q=au:contributions%20de%20G.%20Benelli%20...%20%5Bet%20al.%5D>
- 1979 - Abbaye de S. Paul h.l.m Description : - 806 p. ; 24 cm

Commentarii in Psalmos I-L [1-50]
<https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=11890>

Diodore de Tarse
<https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/search.pl?q=au:Diodore%20de%20%3Cspan%20class%3Dterm%3ETarse%3C%2Fspan%3E>
- 1980 - Brepols Description : - CXX-328p. ; 25cm

Paul de Tarse
<https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=13309>
, congrès

[organisé par ] l' ACFEB, Strasbourg, 1995
<https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/search.pl?q=au:%5Borganis%C3%A9%20par%20%5D%20l%27%20ACFEB%2C%20Strasbourg%2C%201995>
- 1996 - Ed. du Cerf Description : - 373p. ; 22cm

Les Fragments de Tarse au Louvre
<https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=22023>

Léon Alexandre Heuzey
<https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/search.pl?q=au:L%C3%A9on%20Alexandre%20%20Heuzey>
- 1876 Description :

Paul de Tarse
<https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=22920>

Joseph Holzner
<https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/search.pl?q=au:Joseph%20%20Holzner>
- 1950 - Alsatia Description : - 577p. ; 24cm

Saul de Tarse
<https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=27766>
, Lettres à une jeune église

Jean Paul Benoit
<https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/search.pl?q=au:Jean%20Paul%20%20Benoit>
Description : - 214p.

Paul de Tarse
<https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=42201>

Michel A. Hubaut
<https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/search.pl?q=au:Michel%20A.%20Hubaut>
- 1989 - Desclée Description : - 143 p. ; 22 cm

Le Psautier chez les Pères
<https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=48415>

- 1994 - Centre d'analyse et de documentation patristiques Description
: - 310p. ; 21cm

Le Psautier chez les Pères
<https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=48417>

- 1994 - Centre d'analyse et de documentation patristiques Description
: - 310p. ; 21cm

Paul de Tarse
<https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/detail.pl?biblionumber=48697>
, un homme aux prises avec Dieu

Daniel Marguerat
<https://admin-catalogue.iptheologie.fr/cgi-bin/koha/catalogue/search.pl?q=au:Daniel%20%20Marguerat>
- 1999 - Ed. du Moulin Description : - 109p. ; 18cm

Moreover, I have to state that :
in France, 210$d is supposed to have publication date but also sometimes
some information such as c for copyright, and other terms...
Maybe it could be overcome by using null words for sorting dates (I hope
so). Is this true ?
Hoping to have an answer soon.
--
Henri-Damien LAURENT

_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.nongnu.org/mailman/listinfo/koha-zebra

Re: Net::Z3950::ZOOM Tests

2007-09-08T08:33:05Z

Hi
I tried with:
perl -MCPAN -e 'install Bundle::CPAN'

and all error will resolve!!

Please, sorry I'm latin
Hola:
Yo intenté con:
perl -MCPAN -e 'install Bundle::CPAN'
y todos los errores se resolvieron. En mi caso todos los tests con make test fallaron. Ninguna opción de ZOOM funcionó y no logré culminar la instalación de KOHA. Entonces decidí verificar mi instalación de perl. Con Bundle se instalaron una serie de paquetes que faltaron.

Luego volví a reiniciar y compilé nuevamente ZOOM y todo funcionó a la perfección.

También es buena idea verificar el funcionamiento de yaz. Para ello hice:
yaz-client -x
open http:mi IP
status
list_all
quit
con los resultados de conexión y demás confirmé que yaz funciona. Luego procedí a instalar ZOOM.

Re: No Unicode support

2007-07-23T17:44:01Z

Reply inline:

On Wed, July 18, 2007 3:31 pm, MJ Ray wrote:
> Mike Taylor <mike@...> wrote:
>> Correct. We are as keen to fix this as you are, and would very much
>> appreciate any funding you can scare up from your customers.
>
>> > http://lists.indexdata.dk/pipermail/zebralist/2007-May/001522.html
>

In case there is any lack of clarity, this issue is about indexing and
related Unicode support in Zebra. Unicode data storage and record display
in Koha works and is unaffected by this problem. Indexing romanised
fields is sufficient for some libraries to work around this problem but
unacceptable to others.

I answer below based on information which I was obtaining directly from
Index Data prior to MJ Ray's message to which I am now replying. I
suggested to Mike Taylor later that he should try to answer on the
koha-zebra list and perhaps he would have but he was leaving on holiday.

I continue from my off-list message encouraging interested parties to
pursue this matter.

> What is the target amount?

A large sum would be required, except that only US$ 11,000 remains
unfunded at this time.

Mike Taylor informed me last week that one significant source of funding
was nearing the end of a funding cycle so that a commitment of funding
within the next week or so would be helpful for starting work now as
opposed to some unspecified later time. The work required is substantial
and might take a little under six months.

I interpreted a later message from David Dorman to imply that work was
liable to start soon but that a commitment for any funding would be
appreciated. I understood that a commitment for any amount would be
helpful.

> Would each interested customer conclude a
> contract with indexdata or should it be gathered under one company?

I suspect that Index Data is indifferent to the source of commitments as
long as they can expect that the commitments will be honoured. Any party
may have some preferences for how to manage the relationship but those are
likely independent of the actual goal.

> Can it be structred as payment-on-delivery or payment-per-milestone?
>

Mike Taylor informed me that Index Data is seeking commitments of funding
while payment could be made at a later date, even some period after
completion of the work. I communicated with him about the prospect of
having funds in 6 to 9 months. Everyone prefers payment in advance but
that is not necessary in this case.

> Koha people - semi-related, when will kohala be able to be a
> gathering-place for funding?

Someone who knows about Kohala should answer. Does anyone from France
have a response?

> Should we apply to associate with
> Software in the Public Interest, Inc, or similar, even if only for
> development topics?
>

I suggest that Koha should have an independent foundation or set of
associated foundations with a parent foundation to promote Koha, assist
with funding, etc. There is no reason such foundations could not
associate themselves with other organisations such as SPI but I think that
independence is important so that the Koha community is able to put the
interests of Koha first. However, that topic should be moved to the
koha-devel list.

[..]

Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY 10003
USA
212-674-3783
http://www.agogme.com

_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.nongnu.org/mailman/listinfo/koha-zebra

Re: No Unicode support

2007-07-18T09:31:06Z

Mike Taylor <mike@...> wrote:
> Correct. We are as keen to fix this as you are, and would very much
> appreciate any funding you can scare up from your customers.

> > http://lists.indexdata.dk/pipermail/zebralist/2007-May/001522.html

What is the target amount? Would each interested customer conclude a
contract with indexdata or should it be gathered under one company?
Can it be structred as payment-on-delivery or payment-per-milestone?

Koha people - semi-related, when will kohala be able to be a
gathering-place for funding? Should we apply to associate with
Software in the Public Interest, Inc, or similar, even if only for
development topics?

Thanks,
--
MJ Ray - see/vidu http://mjr.towers.org.uk/email.html
Experienced webmaster-developers for hire http://www.ttllp.co.uk/
Also: statistician, sysadmin, online shop builder, workers co-op.
Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/

_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.nongnu.org/mailman/listinfo/koha-zebra

No Unicode support

2007-07-18T03:38:44Z

Correct. We are as keen to fix this as you are, and would very much
appreciate any funding you can scare up from your customers.

Thomas Dukleth writes:
> REPOSTED to correct my previous omission of a subject header:
>
>
> I was discussing Zebra with Frédéric DEMIANS today when he raised the
> issue of Zebra's lack of indexing support for Unicode. The message which
> he links shows that indexing support is limited to 256 characters which
> would be a serious problem for supporting many languages in Koha and seems
> to require significant funding to remedy.
>
> This issue may not trouble most libraries currently using Koha but will
> certainly prevent adoption until it is corrected at some libraries which I
> had thought would be well suited for Koha 3.0.
>
>
> ---------------------------- Original Message ----------------------------
> Subject: Zebra limitation
> From: Frédéric DEMIANS <f.demians [AT] tamil.fr>
> Date: Tue, July 17, 2007 8:35 pm
> To: koha [AT] agogme.com
> --------------------------------------------------------------------------
>
> As I told you, it appears that, even if koha 3 is Unicode, Zebra is not,so
> Koha is not:
>
> http://lists.indexdata.dk/pipermail/zebralist/2007-May/001522.html
>
> --
> Frédéric DEMIANS
> http://www.tamil.fr/u/fdemians.html
>
>
> Thomas Dukleth
> Agogme
> 109 E 9th Street, 3D
> New York, NY 10003
> USA
> 212-674-3783
> http://www.agogme.com
>
>
>
> _______________________________________________
> Koha-zebra mailing list
> Koha-zebra@...
> http://lists.nongnu.org/mailman/listinfo/koha-zebra

_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.nongnu.org/mailman/listinfo/koha-zebra

No Unicode support

2007-07-17T16:37:02Z

REPOSTED to correct my previous omission of a subject header:

I was discussing Zebra with Frédéric DEMIANS today when he raised the
issue of Zebra's lack of indexing support for Unicode. The message which
he links shows that indexing support is limited to 256 characters which
would be a serious problem for supporting many languages in Koha and seems
to require significant funding to remedy.

This issue may not trouble most libraries currently using Koha but will
certainly prevent adoption until it is corrected at some libraries which I
had thought would be well suited for Koha 3.0.

---------------------------- Original Message ----------------------------
Subject: Zebra limitation
From: Frédéric DEMIANS <f.demians [AT] tamil.fr>
Date: Tue, July 17, 2007 8:35 pm
To: koha [AT] agogme.com
--------------------------------------------------------------------------

As I told you, it appears that, even if koha 3 is Unicode, Zebra is not,so
Koha is not:

http://lists.indexdata.dk/pipermail/zebralist/2007-May/001522.html

--
Frédéric DEMIANS
http://www.tamil.fr/u/fdemians.html

Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY 10003
USA
212-674-3783
http://www.agogme.com

_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.nongnu.org/mailman/listinfo/koha-zebra

(no subject)

2007-07-17T16:08:31Z

I was discussing Zebra with Frédéric DEMIANS today when he raised the
issue of Zebra's lack of indexing support for Unicode. The message which
he links shows that indexing support is limited to 256 characters which
would be a serious problem for supporting many languages in Koha and seems
to require significant funding to remedy.

This issue may not trouble most libraries currently using Koha but will
certainly prevent adoption until it is corrected at some libraries which I
had thought would be well suited for Koha 3.0.

---------------------------- Original Message ----------------------------
Subject: Zebra limitation
From: Frédéric DEMIANS <f.demians [AT] tamil.fr>
Date: Tue, July 17, 2007 8:35 pm
To: koha [AT] agogme.com
--------------------------------------------------------------------------

As I told you, it appears that, even if koha 3 is Unicode, Zebra is not,so
Koha is not:

http://lists.indexdata.dk/pipermail/zebralist/2007-May/001522.html

--
Frédéric DEMIANS
http://www.tamil.fr/u/fdemians.html

Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY 10003
USA
212-674-3783
http://www.agogme.com

Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY 10003
USA
212-674-3783
http://www.agogme.com

_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.nongnu.org/mailman/listinfo/koha-zebra

Re: Problem with ZOOM installation

2007-06-13T00:52:56Z

LAURENT Henri-Damien wrote:

> Hi,
> I am installing a koha 30 in New Caledonia for a client on a new computer.
> I installed Fedora Core 6, yaz-2.1.54 and idzebra-2.0.12 from source.
> Installation and compilation went fine.
> But when trying testing ZOOM install, there is a problem with
>
> # Error: Can't load
> '/home/koha/paquets/Net-Z3950-ZOOM-1.18/blib/arch/auto/Net/Z3950/ZOOM/ZOOM.so'
> for module Net::Z3950::ZOOM: libyaz.so.2: cannot open shared object file :
> No file or directory at
> /usr/lib/perl5/5.8.8/i386-linux-thread-multi/DynaLoader.pm line 230.
>
> libyaz.so.2 is in /usr/local/lib.
> I checked user path and it points in /usr/local/lib

User PATH is not the same as library path. I don't think /usr/local/lib
is on your library path. Add
/usr/local/lib
to your /etc/ld.so.conf

/ Adam

> Is there anything else to check ?
>
> Thanks.
>
> Eurolines : Voyagez au meilleur prix : http://www.alinto.com/pub/
>
>
> _______________________________________________
> Koha-zebra mailing list
> Koha-zebra@...
> http://lists.nongnu.org/mailman/listinfo/koha-zebra
>
>

_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.nongnu.org/mailman/listinfo/koha-zebra

Problem with ZOOM installation

2007-06-12T21:38:14Z

Hi,
I am installing a koha 30 in New Caledonia for a client on a new computer.
I installed Fedora Core 6, yaz-2.1.54 and idzebra-2.0.12 from source.
Installation and compilation went fine.
But when trying testing ZOOM install, there is a problem with

# Error: Can't load
'/home/koha/paquets/Net-Z3950-ZOOM-1.18/blib/arch/auto/Net/Z3950/ZOOM/ZOOM.so'
for module Net::Z3950::ZOOM: libyaz.so.2: cannot open shared object file :
No file or directory at
/usr/lib/perl5/5.8.8/i386-linux-thread-multi/DynaLoader.pm line 230.

libyaz.so.2 is in /usr/local/lib.
I checked user path and it points in /usr/local/lib
Is there anything else to check ?

Thanks.

Eurolines : Voyagez au meilleur prix : http://www.alinto.com/pub/

_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.nongnu.org/mailman/listinfo/koha-zebra

Re: firstinfield and position attributes usage

2007-06-11T01:08:44Z

Henri-Damien LAURENT wrote:

> Hi,
> I have problems using firstinfield and position attributes and then
> querying with @attr 3=1.
> Indeed, some users would find it cool to search anatomy only with the
> beginning of the phrase.
>
>
> First of all, I wonder how I can define a custom index and use it.
> It seems that using completeness attribute implies @attr 6=1 if 0 @attr
> 6=2 or @attr 6=1.
> position is not defined in you documentation.
> firstinfield seems to be used along with it.
>
> I tried to define :
>
> index h
> completeness 0
> position 1
> firstinfield 1
> charmap sort-string-utf.chr
>
> in default.idx and
> used it in record.abs :
> melm 250$a Heading, Heading:h, Heading:s
>
> and queried my base as such :
> f @and @attr "1=Authority/format-id" @attr 5=100 MSC @attr "1=Heading"
> @attr 3=1 An
>
> Answer was :
> ERROR 119

Your index named 'h' is not used for "normal" searches. The structure
and sometimes the completeness attribute tell _what_ index type to use.
If no structure is given .. and completeness is omitted or set to 1
(incomplete subfield) then index 'w' is used. Not your index 'h'. The
error message suggests that firstinfield is not enabled for your index 'w'.

You can either just enable firstinfield for 'w' .. It's already enabled
for 'w' in tab/default.idx that comes with Zebra 2.0. But probably you
don't use that.

You can also just specify that you want to use index 'h' in your query
by using structure=h (@attr 4=h). This structure hack requires Zebra
2.0.14.

/ Adam

>
> Is there something I missed ?
>

_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.nongnu.org/mailman/listinfo/koha-zebra

Re: firstinfield and position attributes usage

2007-06-09T19:14:59Z

Henri-Damien LAURENT wrote:

Hi Henri,

Zebra at present does not support the first-in-field attribute, although
we sometimes have talked about doing so. You can simulate it pretty well
by using a combination of complete subfield and truncation. You'll note
there's also a way to configure an index to ignore leading articles
(the, an, a, etc.), which is a good way to increase your recall.. yes,
it's hard to make this word with word boundaries, (Adam might have a
suggestion for some regexp magic that would work), but I think that's
probably a minor problem in most cases.

--Sebastian

>I tried to define :
>
>index h
>completeness 0
>position 1
>firstinfield 1
>charmap sort-string-utf.chr
>
>in default.idx and
>used it in record.abs :
>melm 250$a Heading, Heading:h, Heading:s
>
>and queried my base as such :
>f @and @attr "1=Authority/format-id" @attr 5=100 MSC @attr "1=Heading"
>@attr 3=1 An
>
>Answer was :
>ERROR 119
>
>Is there something I missed ?
>
>
>

--
Sebastian Hammer, Index Data
quinn@... www.indexdata.com
Ph: (603) 209-6853 Fax: (866) 383-4485

_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.nongnu.org/mailman/listinfo/koha-zebra

firstinfield and position attributes usage

2007-02-03T01:48:53Z

Hi,
I have problems using firstinfield and position attributes and then
querying with @attr 3=1.
Indeed, some users would find it cool to search anatomy only with the
beginning of the phrase.

First of all, I wonder how I can define a custom index and use it.
It seems that using completeness attribute implies @attr 6=1 if 0 @attr
6=2 or @attr 6=1.
position is not defined in you documentation.
firstinfield seems to be used along with it.

I tried to define :

index h
completeness 0
position 1
firstinfield 1
charmap sort-string-utf.chr

in default.idx and
used it in record.abs :
melm 250$a Heading, Heading:h, Heading:s

and queried my base as such :
f @and @attr "1=Authority/format-id" @attr 5=100 MSC @attr "1=Heading"
@attr 3=1 An

Answer was :
ERROR 119

Is there something I missed ?

_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.nongnu.org/mailman/listinfo/koha-zebra

firstinfield and position attributes usage

2007-02-02T10:19:02Z

Hi,
I have problems using firstinfield and position attributes and then
querying with @attr 3=1.
Indeed, some users would find it cool to search anatomy only with the
beginning of the phrase.

First of all, I wonder how I can define a custom index and use it.
It seems that using completeness attribute implies @attr 6=1 if 0 @attr
6=2 or @attr 6=1.
position is not defined in you documentation.
firstinfield seems to be used along with it.

I tried to define :

index h
completeness 0
position 1
firstinfield 1
charmap sort-string-utf.chr

in default.idx and
used it in record.abs :
melm 250$a Heading, Heading:h, Heading:s

and queried my base as such :
f @and @attr "1=Authority/format-id" @attr 5=100 MSC @attr "1=Heading"
@attr 3=1 An

Answer was :
ERROR 119

Is there something I missed ?

--
Henri Damien LAURENT et Paul POULAIN
Consultants indépendants
en logiciels libres et bibliothéconomie (http://www.koha-fr.org)

_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.nongnu.org/mailman/listinfo/koha-zebra

Re: RE: Koha-zebra Digest, Vol 9, Issue 1

2007-01-25T10:50:25Z

Tümer Garip a écrit :
> Hi hdl,
> If i understood correctly:
> 1- The characters to escape (infact to be replaced by space) is defined
> in tab/*.chr file
>
I had overlooked that file. I thought it was a configuration in zebra.
> 2- If your default.idx file defines completeness=1 for phrases (@attr
> 4=1) this search should work
>
It works but I thought @attr 6=3 would ensure wholiness of subfield.
> 3- No it will only return exact match unless @attr 5=1(right truncation)
> is defined as default in your searches.Put @attr 5=100(no truncation) to
> make sure
>
OK.
Many thanks.

--
Henri-Damien LAURENT

_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.nongnu.org/mailman/listinfo/koha-zebra

RE: Koha-zebra Digest, Vol 9, Issue 1

2007-01-25T10:07:49Z

Hi hdl,
If i understood correctly:
1- The characters to escape (infact to be replaced by space) is defined
in tab/*.chr file
2- If your default.idx file defines completeness=1 for phrases (@attr
4=1) this search should work
3- No it will only return exact match unless @attr 5=1(right truncation)
is defined as default in your searches.Put @attr 5=100(no truncation) to
make sure

Hope helps
Tumer

-----Original Message-----
Message: 1
Date: Wed, 24 Jan 2007 18:03:46 +0100
From: Henri-Damien LAURENT <laurenthdl@...>
Subject: [Koha-zebra] Exact searches with zebra.
To: koha-zebra@...
Message-ID: <45B79172.9050206@...>
Content-Type: text/plain; charset=ISO-8859-1

Hi,
I am trying to provide exact search in zebra for authorities. But I have
a problem : using @attr 4=1 @attr 6=3 "TEST -- My record" double -- are
not taken into account. and it doesnot find any results since -- is
recorded in a field. If I test without @attr 6=3 it works, but what if i
have a second one which contains TEST -- My record -- special ? I bet
both of them will be returned.

I searched the documentation but couldnot find where jokers should be
defined nor how to escape them. Does anyone has a link ?
--
Henri-Damien LAURENT

------------------------------

_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.nongnu.org/mailman/listinfo/koha-zebra

End of Koha-zebra Digest, Vol 9, Issue 1
****************************************

_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.nongnu.org/mailman/listinfo/koha-zebra

Exact searches with zebra.

2007-01-24T09:03:46Z

Hi,
I am trying to provide exact search in zebra for authorities.
But I have a problem :
using @attr 4=1 @attr 6=3 "TEST -- My record"
double -- are not taken into account.
and it doesnot find any results since -- is recorded in a field.
If I test without @attr 6=3 it works, but what if i have a second one
which contains TEST -- My record -- special ?
I bet both of them will be returned.

I searched the documentation but couldnot find where jokers should be
defined nor how to escape them.
Does anyone has a link ?
--
Henri-Damien LAURENT

_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.nongnu.org/mailman/listinfo/koha-zebra

Re: [Koha-devel] record.abs and melm declaration order.

2006-10-31T06:16:08Z

Henri-Damien LAURENT wrote:

> Hi
> it seems that data indexed in record.abs depends on the order of
> declaration.
> Take for instance :
>
> melm 600 Subject-heading
> melm 600$a main-subject
>
> and
>
> melm 600$a main-subject
> melm 600 Subject-heading
>
> On the one hand, you will NOT be able to query for main-subject
> But on the other hand, declaring 600$a BEFORE tag 600, you will get data
> from 600$a when querying on main-subject.
>
> I have not read this on documentation. And this seems quite useful to know.

Correct. Good point.

To get what you want, use:

melm 600$a main-subject,Subject-heading
melm 600 Subject-heading

> Moreover, if you declare
>
> melm 600$a main-subject
> melm 600$a other-identifier
>
> the second declaration will be ignored.
Yes. Use

melm 600$a main-subject,other-identifier

to index both.

/ Adam

>
> Hopes that helps.

_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.nongnu.org/mailman/listinfo/koha-zebra

record.abs and melm declaration order.

2006-10-31T05:59:30Z

Hi
it seems that data indexed in record.abs depends on the order of
declaration.
Take for instance :

melm 600 Subject-heading
melm 600$a main-subject

and

melm 600$a main-subject
melm 600 Subject-heading

On the one hand, you will NOT be able to query for main-subject
But on the other hand, declaring 600$a BEFORE tag 600, you will get data
from 600$a when querying on main-subject.

I have not read this on documentation. And this seems quite useful to know.

Moreover, if you declare

melm 600$a main-subject
melm 600$a other-identifier

the second declaration will be ignored.

Hopes that helps.
--
Henri-Damien LAURENT

_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.nongnu.org/mailman/listinfo/koha-zebra

Re: Differently index same field numbers from different record types

2006-08-04T15:58:26Z

In my hurry to obtain a quick answer, I assembled the original question
with excess haste. The question was not well explained at the beginning
of the message and I left out a possibility which might be an important
part of an efficient solution. As there has been no answer yet, I here
completely replace the original form of the question with this reorganised
and corrected message. I also made a minor mistake with the attribution
of a quote from a previous thread from the zebra list, which I correct
here.

I am trying to obtain at least a quick partial answer with enough
information to know how or whether to start designing a schema for an
XML-meta-record containing other related MARCXML records. If there enough
of an easy answer to point the meta-record schema work in a correct
direction, I would like to have that answer as soon as possible. If an
answer which will help with other aspects of the question takes a little
longer to think about, then, give an additional more complete answer
later.

1. INDEXING PROBLEM.

We need to be able to differently index fields with the same field number
from different record types differently. How can different indexing for
the same field number from different record types be accomplished without
storing the different record types in separate databases?

One example is the case of MARC 21 bibliographic records with 500, general
note, and also MARC 21 authority records with 500, see also from
tracing--personal name.

The records are liable to be in some XML form that may be easy to work
with and helpful for indexing.

1.1. STANDARD MARCXML.

<record type="Bibliographic">
<leader>content</leader>
<controlfield tag="some field">content</controlfield>
<datafield tag="some field" ind1=" " ind2=" ">
<subfield code="some subfield">content</subfield>
</datafield>
<datafield tag="some other field" ind1=" " ind2=" ">
<subfield code="some subfield">content</subfield>
</datafield>
<datafield tag="500" ind1=" " ind2=" ">

<record type="Authority">
<leader>content</leader>
<datafield tag="some field" ind1=" " ind2=" ">
<subfield code="some subfield">content</subfield>
</datafield>
<datafield tag="500" ind1="1" ind2=" ">

1.2. VARIATIONS ON STANDARD MARCXML.

1.2.1. SUPPLEMENTARY ATTRIBUTES VARIATION FROM STANDARD MARCXML.

Adding additional attributes to standard elements provides a short
predictable path between the field needing indexing and the point where
record types are distinguished. Non-standard syntax and recordtype
attributes are added for this possibility.

<datafield tag="500" ind1=" " ind2=" " syntax="MARC 21
recordtype="Bibliographic">

<datafield tag="500" ind1="1" ind2=" " syntax="MARC21"
recordtype="Authority">

1.2.2. CHANGED ELEMENT NAMES FROM STANDARD MARCXML.

Changing element names standard elements provides a short predictable path
between the field needing indexing and the point where record types are
distinguished. However, this variation requires additional record
transformation before and after using standard MARCXML tools to change
element names to and from standard names. Non-standard element names
record the record syntax and record type for this possibility.

<datafield_marc21_bib tag="500" ind1=" " ind2=" ">

<datafield_marc21_auth tag="500" ind1="1" ind2=" ">

1.3. XML META-RECORDS.

The records may have a structure like the following simplified possibility.

<collection>
<bibliographic_record>
<related_authority_records>
</related_authority_records>
<related_holdings_records>
</related_holdings_records>
</bibliographic_record>
</collection>

1.3.1 STANDARD MARCXML INSIDE.

Using standard MARCXML in meta-records is much the same as indexing
standard MARCXML alone where the type attribute in the record element is
not part of the datafield element being indexed. The conclusion should be
the same for this issue as it would be for indexing standard MARCXML
without including it in a meta-record.

1.3.2. NON-STANDARD MARCXML INSIDE.

Using non-standard MARCXML in meta-records is much the same as indexing
non-standard MARCXML alone where the means of determining record type
would be part of the element being indexed. The conclusion should be the
same for this issue as it would be for indexing non-standard MARCXML
without including it in a meta-record.

2. PREVIOUS THREAD FOR SIMILAR ISSUE.

This issue revisits an indexing problem related to the problem which
appeared in the thread "[Zebralist] how to index everything ?" Perhaps
the answer to this issue would be similar to one of the answers given in
that earlier thread.

Sebastian Hammer wrote:

> Hi Paul,
>
> I don't know if this helps, but if you add the line 'xpath enable' to
> your .abs file, Zebra will build additional index structures to enable
> searches like:
>
> Z> find @attr 1=/*/title someterm
>
> What is supported is a subset of the XPATH spec, but I *think* you can do:
>
> Z> find @attr 1=/*/datafield[@tag='245'] someterm
>
> In other words, XPATH-statements are used to select elements for
> searching, as an alternative to numerical USE attributes.
>
> Performance is not quite as good as for the regular indexes, so it's not
> something you want to do a lot in production on a 10M record database...
> but it's fine for smaller applications.

Unlike the issue presented in the earlier thread, this issue requires high
performance.

Marc wrote:

> Hmm. You can speed things up by having a specialized tag index.
>
> something like
>
> xelem /record/datafield/@tag tag
>
> in your abs file.
>
> then you can query something like
>
> Z> find @and @attr 1=tag '245' @attr 1=/*/datafield/subfield[code='9']
> someterm
>
> to speed things up a bit.
>
>
> You could also define an index for each combination of tag/subfields,
> but that might be an administration nightmare.

Sebastian Hammer wrote:
> That wouldn't work out of the box. But this 'should work' (haven't tried
> it):
>
> Z> find @attr 1=/*/datafield[@tag='245']/subfield[@code='a'] someterm

Maybe we will need an administration nightmare to have the system function
as needed.

3. DISTINGUISHING MARC RECORD TYPES.

MARC Record type can be distinguished by the value of 000/06 but I am
uncertain that will help properly in all circumstances where we do
actually want to search across multiple record types as part of a
meta-record when the records are related.

Furthermore, there are multiple values for 000/06 for the same major
record type.

4. MARC CONFLICT EXAMPLES.

I have not inspected well to consider all the cases risking false results
if the record types are not distinguished well.

4.1. FIXED LENGTH FIELD CASE.

I have always believed that the basic fixed length data elements fields
need local use field analogues with appropriate values to ease searching
because record type and even bibliographic level within a record type
changes the meaning of fixed length data elements. MARC 21 008 and
UNIMARC 100 have this variance problem.

Supplementary local use fields might be a reasonable choice for solving
other problems in the case of the fixed length data elements fields.

4.2. A MARC 21 CASE.

I gave a case, in the problem statement for conflicting field use between
MARC 21 bibliographic records with 500, general note, and also MARC 21
authority records with 500, see also from tracing--personal name.

4.3. A UNIMARC CASE.

One UNIMARC case for conflicting field use would be UNIMARC bibliographic
records with 200, title and statement of responsibility, and also UNIMARC
authorities records with 200, heading--personal name.

5. ISO 2709 PROBLEM RESTATEMENT.

The immediate need is to know what direction to go in designing an XML
meta-record.

However, I would still be interested in knowing how to index the same
field number differently based on the value in 000/06 or an abstracted
value in a local use field.

An abstracted local use value might be in a local use field such as 01k as
follows.

000 content
001 content
01k ## $a MARC21 $b Bibliographic
100 ## $a content
245 ## $a content $c content
500 ## $a general note

000 content
001 content
01k ## $a MARC21 $b Authority
100 ## $a content
500 ## $a see also from personal name

Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY 10003
USA
http://www.agogme.com
212-674-3783

_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.nongnu.org/mailman/listinfo/koha-zebra

Differently index same field numbers from different record types

2006-08-04T04:23:37Z

This issue revisits an indexing problem related to the problem which
appeared in the thread "[Zebralist] how to index everything ?"

Sebastian Hammer wrote:

Unlike the issue presented in the earlier thread, this issue requires high
performance.

Sebastian Hammer wrote:

Sebastian Hammer wrote:
> That wouldn't work out of the box. But this 'should work' (haven't tried
> it):
>
> Z> find @attr 1=/*/datafield[@tag='245']/subfield[@code='a'] someterm

Maybe we will need an administration nightmare to have the system function
as needed.

1. INDEXING PROBLEM.

We need to be able to differently index fields with the same field number
from different record types differently. How can different indexing for
the same field number be accomplished without storing them in separate
databases?

Record type can be distinguished by the value of 000/06 but I am uncertain
that will help properly in all circumstances where we do actually want to
search across multiple record types when the records are related.

2. MARC CONFLICT EXAMPLES.

have not inspected well to consider all the cases risking false results
if the record types are not distinguished well.

2.1. FIXED LENGTH FIELD CASE.

I have always believed that the basic fixed length data elements fields
need local use field analogues with appropriate values to ease searching
because record type and even bibliographic level within a record type
changes the meaning of fixed length data elements. MARC 21 008 and
UNIMARC 100 have this variance problem.

Supplementary local use fields might be a reasonable choice for solving
other problems in the case of the fixed length data elements fields.

2.2. A MARC 21 CASE.

If we have MARC 21 bibliographic records with 500, general note, and also
MARC 21 authority records with 500, see also from tracing--personal name;
how can we index them differently?

2.3. A UNIMARC CASE.

If we have UNIMARC bibliographic records with 200, title and statement of
responsibility, and also UNIMARC authorities records with 200,
heading--personal name; how can we index them differently?

3. XML META RECORDS EXAMPLES.

We have been considering using XML meta-records to overcome the problem of
needing to index related records together.

The records may have a structure like the following simplified possibility.

<collection >
<bibliographic_record>
<related_authority_records>
</related_authority_records>
<related_holdings_records>
</related_holdings_records>
</bibliographic_record>
</collection>

3.1. PATH ELEMENT DIFFERENCE.

How can we a use a path element difference or even an attribute difference
to have fields of different record record types indexed differently?

<collection id="1">
<bibliographic_record>
<record>
<datafield tag="500" ind1=" " ind2=" ">

<collection id="1">
<bibliographic_record>
<record>
<related authorities records>
<record>
<datafield tag="500" ind1="1" ind2=" ">

3.2. PATH MINOR ATTRIBTE DIFFERENCE.

How can we a use a path element minor attribute difference to have fields
of different record record types indexed differently?

<record type="Bibliographic">
<datafield tag="500" ind1=" " ind2=" ">

<record type="Authority">
<datafield tag="500" ind1="1" ind2=" ">

Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY 10003
USA
http://www.agogme.com
212-674-3783

_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.nongnu.org/mailman/listinfo/koha-zebra

ZOOM-Perl release 1.10, now with different CCL

2006-06-15T09:49:02Z

Josh and others,

I've just made release 1.10 of ZOOM-Perl, which uses Adam's preferred
CCL API rather than the one I originally implemented. It will show up
on CPAN, but until then please use:
http://www.miketaylor.org.uk/tmp/Net-Z3950-ZOOM-1.10.tar.gz

It will build against the most recent YAZ release.

I am off to watch England vs. Trinidad and Tobago!

_/|_ ___________________________________________________________________
/o ) \/ Mike Taylor <mike@...> http://www.miketaylor.org.uk
)_v__/\ "If you are a fascinating writer, then you follow a deeper set
of rules which make the normal ones irrelevant. If not, then
you need to follow the normal rules until you get fascinating"
-- Greg Gunther.

_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.nongnu.org/mailman/listinfo/koha-zebra

ZOOM-Perl release 1.09, now with tasty CCL!

2006-06-13T10:56:08Z

Hi, Josh and others,

I've just made release 1.09 of ZOOM-Perl, which will show up on CPAN
in its own sweet time and which in the mean time is available from:
http://www.miketaylor.org.uk/tmp/Net-Z3950-ZOOM-1.09.tar.gz

The changes in this release should solve your UI query-language
problem:

1.09 Tue Jun 13 17:44:43 2006
- Add new function Net::Z3950::ZOOM::query_ccl2rpn(), for
client-side CCL compilation.
- Add new ZOOM::Query::CCL2RPN class, encapsulating CCL
compiler functionality as a Query subclass. This allows
client-side CCL to be used for both search and scan.
- Add two new error-codes, CCL_CONFIG and CCL_PARSE,
returned by the client-side CCL facilities.
- Supply a sample CCL profile file: samples/ccl/default.bib,
copied from the same-named file distributed with YAZ.
- The test-scripts t/12-query.t and t/22-query.t are extended
to also test client-side CCL searching.
- The test-scripts t/15-scan.t and t/25-scan.t are extended
to also test client-side CCL scanning.
- Documentation updated to describe use of CCL.
- Add a nice, simple update client: samples/zoom/update.pl

Because this is so very hot-off-the-press, it requires YAZ release
2.1.21 or better, which has not in fact been released yet; you can
build it against a CVS checkout of YAZ, or wait for the next release
(they seem to come along pretty frequently).

_/|_ ___________________________________________________________________
/o ) \/ Mike Taylor <mike@...> http://www.miketaylor.org.uk
)_v__/\ "Once I had a guy in my face telling me if I couldn't put my book
into a one sentence theme, I wasn't a good writer. I kicked
him in the shins. So that's my thinking on this subject" --
Jo Ann Yolanda Hernandez.

_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.nongnu.org/mailman/listinfo/koha-zebra

RE: Zebra setup suggestions, MARC::File::XML Probs

2006-04-12T11:40:22Z

Hi,
I have solved the problem with M:F:X.
In fact the problem exists for windows platforms and it has to do with
XML::SAX
Package that M::F::XML depends on. Any windows package using active perl
should reinstall XML::SAX from
ppm install http://theoryx5.uwinnipeg.ca/ppms//XML-SAX.ppd
And not from the origional activeperl repository.
Further details at
http://perl-xml.sourceforge.net/faq/#parserdetails.ini

Thanks everyone
Tumer
-----Original Message-----
From: Mike Rylander [mailto:mrylander@...]
Sent: Monday, April 10, 2006 9:50 PM
To: Joshua Ferraro
Cc: Tümer Garip; koha-zebra@...
Subject: Re: [Koha-zebra] Zebra setup suggestions, MARC::File::XML Probs

On 4/10/06, Joshua Ferraro <jmf@...> wrote:
> On Mon, Apr 10, 2006 at 08:38:42PM +0300, Tümer Garip wrote:
> > Hi all,
> > Thanks to Owen I can now commit on Savannah but before doing
> > anything I just want to clarify some matters and get opinions.
> > 1- I would like to setup zebra server using user-password for
> > updates and no write access for anonymous write access. Also we
> > should be using -f yazconfig.xml with the server which will allow us

> > define the location and name of our cql file outside Context.pm and

> > not hardcoded.
> Of course, by all means make these changes.
>
> > 2-At previous listings we discussed whether to use collection.abs or

> > record.abs for indexing Zebra. My understanding from that was Zebra
> > can not handle collection.abs properly so we should use record.abs
> > (Adam & Sebastian's remarks). This means using record->as_xml_record

> > of the new CVS version MARC::File::XML which I downloaded but it
> > does not work for me. MARC::File::XML does not get loaded properly
> > and throws everything out. Looks like an XML::SAX problem but I am
> > not sure. For those who managed to get it work please note that
> > record->as_xml_record call will not produce proper xml as there is a

> > quote missing at line 337 of XML.pm change slim> to slim"> and it
> > should work for you.
> >
> > Currently I modified my old version MARC::File::XML so that it has a
> > record->as_xml_record as well so that I can test and commit things.
>
> We should use record.abs, I dont' think we need collection.abs
> anymore. I think we should really try to use the new MARC::File::XML
> if at all possible and should modify all our 'as_xml' calls to be
> 'as_xml_record'. But before we can do that we need to resolve these
> issues you're having.
>
> Mike R, any comments on Tumer's probs with M::F::X?

I've fixed the missing-quote bug in CVS (thanks for spotting that,
Tümer), but without more details I won't be able to tell what's wrong
with MARC::File::SAX, if that is indeed the issue. I cannot get
anything to fail here after fixing that missing-quote bug.

Tümer, if you add

use warnings;
use diagnostics;

to the top of your script does it tell you where the problem with
MARC::File::XML is?

--
Mike Rylander
mrylander@...
GPLS -- PINES Development
Database Developer
http://open-ils.org

_______________________________________________
Koha-zebra mailing list
Koha-zebra@...
http://lists.nongnu.org/mailman/listinfo/koha-zebra