Koha Zebra Searching Report (from NPL)

[Joshua Ferraro-3]

Hi all,

I had a day-long session with NPL staff members today to get some
feedback on the Koha Zebra search options as they stand right now.
The demo we used is here: http://kohatest.liblime.com. It's the
entire (150K or so records from NPL's database indexed using the
record.abs that I committed to CVS yesterday and the latest
SearchMarc.pm.

PRELIMINARY COMMENTS

NPL was very pleased with the new system and we got a lot of
positive feedback. They are of course quite familiar now with
the open source process of feedback so were more than happy to
offer suggestions for how to improve.
So ... here we go ...

The advanced search should include true boolean searching as is
standard on many library advanced search interfaces (select
from multiple type of searches and have the ability to AND OR
XOR NOT).

Search by format should work (currently doesn't). Also, there is
some question as to whether 'format' differs from 'type' differs
from 'category'. We need to take a closer look at the bib1 profile
and see what is available.

Search by Branch should work -- and really, I'm not sure that
bib1 suppors a 'Branch' option so I'm not sure how that would
work ...

Search by Call # (LCC or Dewey) should work.

Search by Publisher didn't seem to be working -- it should use
at least 260$c but we need to better define where pub info is
supposed to be kept.

Sort by date should use the 008 field's dates (no other field
is normalized enough to have sort by be consistant -- unless
someone on this list knows of another field).

SPELLCHECKING

Does zebra have an integrated spellcheck feature? NPL was hoping
that zebra would use variant spelling and misspelling (via a
soundex or something) to pull up results even when the record's
form differs from the search term. If not, we should expand the
spellchecking feature LibLime wrote to be more complete.

TITLE SEARCHING

The consensus seems to be that the default relevance ranking should not
be how many times the search terms appear in the record, but whether
the title starts with or contains the search terms. So for instance,
a title search on "the civil war" should pull up all the titles with
that exact title first, followed by records that contain that phrase
in the title (even if not starting with it), followed by records where
the terms appear in some title field somewhere in the record. Contrast
that with the current behavior which puts "Voices from the Civil War"
first (I'm assuming this is because the terms "the, civil, war" appear
more times in that record than any other, or because they appear the
same number of times but that record was indexed more recently.)

One-word titles like "Tango" should come up first with a title search
for "Tango".

AUTHOR SEARCHING

Again, the current relevance ranking doesn't quite cut it. A good
example is a relevance ranked author search on "James Joyce". Some
records sneak into high relevance because they have multiple authors
with names like "James Henry" and "Paul Joyce" (take  "Bob the Builder
in the NPL database as an example). The relevance ranking
should account for proximity and use that as the highest ranking
consideration to ensure that a search on "James Joyce" returns all the
books by "James Joyce" first. Also, they requested that the default
ranking secondarily sort the items by date as well because they often
are asked to find the 'latest' book by so and so. We concluded that
the copyright date stored in the 008 is probably the only date
normalized enough to use for sorting though I'm not sure if zebra can
use that for sorting.

SUBJECT SEARCHING

They seemed pleased with the way subject searching was working, it
will correctly find things like "horses--psychology" where the first
term is in 650$a and the second in $x. However, it seems not to
rank things based on proximity within a tag -- meaning that a search
on horses--psychology will pull up records containing:

650$a horses
$x pets

650$a humans
$x psychology

and records with the actual 'horses--psychology' (650$a$x) subject
heading aren't given any favor in the ranking (I misplaced my actual
example and the one above is one I invented).

SUBJECT HEADING SEARCH

NPL would like to see a demonstration of a 'Subject Heading' search
using authorities generated from the data to compile a list of
authoritative headings (which would be compiled from multiple fields
within a given subject tag such as $650$a$v$x, etc.). So I think
to do this right we'd need to look at putting our authority records
in Zebra as well.

SERIES TITLE SEARCHING

Series title should pull from series title fields, not just general
title fields. We need to compile a list of these fields and create
an index for just series titles.

KEYWORD SEARCHING

I saved this one for last on purpose. We're not really sure what
keyword searching is supposed to be :-). We suspect that patrons
expect that the keyword search is equivilent to a web search engine
search box like Google. Given our limitations in the MARC format,
what are our ranking options? Should titles be given priority,
authors, subjects? We're not really sure. However, NPL did like the
idea of offering a two-column results page for keyword searching--
one side with library items and the other with results from the web
using Google's API or something.

Well, that's it for now. NPL staff are going to continue looking at
the demo and providing me with feedback so I'll pass it along as I
recieve it. Please feel free to add your own comments on the demo
as well as comment on NPL's ideas.

Cheers,

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


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

[Joshua Ferraro-3]

Hi all,

I just realized that I should have specified that we used
the 'advanced search' for our tests:

http://kohatest.liblime.com/cgi-bin/koha/opac-search.pl

Also, for any of you that tried to access the previous
link and found it to be password-protected -- that's been
fixed ... sorry about that ...

Cheers,

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


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

[Sebastian Hammer]

Joshua Ferraro wrote:

>Hi all,
>
>I had a day-long session with NPL staff members today to get some
>feedback on the Koha Zebra search options as they stand right now.
>The demo we used is here: http://kohatest.liblime.com. It's the
>entire (150K or so records from NPL's database indexed using the
>record.abs that I committed to CVS yesterday and the latest
>SearchMarc.pm.
>
>PRELIMINARY COMMENTS
>
>NPL was very pleased with the new system and we got a lot of
>positive feedback. They are of course quite familiar now with
>the open source process of feedback so were more than happy to
>offer suggestions for how to improve.
>So ... here we go ...
>  
>

Congrats on the demo!

>The advanced search should include true boolean searching as is
>standard on many library advanced search interfaces (select
>from multiple type of searches and have the ability to AND OR
>XOR NOT).
>  
>
Can't do XOR today. I suppose it would be a possible new feature, but
I've frankly never heard of it in an ILS.. can a XOR b be mapped to

(a OR b) NOT (a AND b) ?   or am I just showing my fading math skills to
ill effect, here?

>Search by format should work (currently doesn't). Also, there is
>some question as to whether 'format' differs from 'type' differs
>from 'category'. We need to take a closer look at the bib1 profile
>and see what is available.
>
>Search by Branch should work -- and really, I'm not sure that
>bib1 suppors a 'Branch' option so I'm not sure how that would
>work ...
>  
>

Why do you see yourelf limited to Bib-1? Within Koha, you can do
whatever you want -- specifically extend Bib-1 into the 8000-range
(IIRC) for local USE attributes or define a private set.

>Search by Call # (LCC or Dewey) should work.
>
>Search by Publisher didn't seem to be working -- it should use
>at least 260$c but we need to better define where pub info is
>supposed to be kept.
>
>Sort by date should use the 008 field's dates (no other field
>is normalized enough to have sort by be consistant -- unless
>someone on this list knows of another field).
>  
>

I think 008 is it if you want a really predictable date.

>SPELLCHECKING
>
>Does zebra have an integrated spellcheck feature? NPL was hoping
>that zebra would use variant spelling and misspelling (via a
>soundex or something) to pull up results even when the record's
>form differs from the search term. If not, we should expand the
>spellchecking feature LibLime wrote to be more complete.
>  
>
It isn't soundex, but it will behave somewhat the same in many cases.
Try searching with truncation=Regexp-2  (103). This enables
error-tolerant searching. By default, one error (insert/delete/replace)
per term will still lead to a match. More at
http://www.indexdata.com/zebra/doc/protocol-support.tkl#search

>TITLE SEARCHING
>
>The consensus seems to be that the default relevance ranking should not
>be how many times the search terms appear in the record, but whether
>the title starts with or contains the search terms. So for instance,
>a title search on "the civil war" should pull up all the titles with
>that exact title first, followed by records that contain that phrase
>in the title (even if not starting with it), followed by records where
>the terms appear in some title field somewhere in the record. Contrast
>that with the current behavior which puts "Voices from the Civil War"
>first (I'm assuming this is because the terms "the, civil, war" appear
>more times in that record than any other, or because they appear the
>same number of times but that record was indexed more recently.)
>
>One-word titles like "Tango" should come up first with a title search
>for "Tango".
>  
>

This would, I believe, require new development. It's possible that one
of the experimental ranking algorithms that are included might provide
better results for these people, but I *think* that boosting the score
for one field in a ranked keyword search would require an extension to
the index structure.

>AUTHOR SEARCHING
>
>Again, the current relevance ranking doesn't quite cut it. A good
>example is a relevance ranked author search on "James Joyce". Some
>records sneak into high relevance because they have multiple authors
>with names like "James Henry" and "Paul Joyce" (take  "Bob the Builder
>in the NPL database as an example
>
It might be worth checking whether one of the custom ranking algos did
better on this..you an look in the NEWS file for instructions on how to
enable them.

> relevance ranking
>should account for proximity and use that as the highest ranking
>consideration to ensure that a search on "James Joyce" returns all the
>books by "James Joyce" first. Also, they requested that the default
>ranking secondarily sort the items by date as well because they often
>are asked to find the 'latest' book by so and so. We concluded that
>the copyright date stored in the 008 is probably the only date
>normalized enough to use for sorting though I'm not sure if zebra can
>use that for sorting.
>  
>

It could with the XSLT index rules of Zebra 1.4.

>SUBJECT SEARCHING
>
>They seemed pleased with the way subject searching was working, it
>will correctly find things like "horses--psychology" where the first
>term is in 650$a and the second in $x. However, it seems not to
>rank things based on proximity within a tag -- meaning that a search
>on horses--psychology will pull up records containing:
>
>650$a horses
>$x pets
>
>650$a humans
>$x psychology
>
>and records with the actual 'horses--psychology' (650$a$x) subject
>heading aren't given any favor in the ranking (I misplaced my actual
>example and the one above is one I invented).
>  
>

Same thing. I don't know how hard it would be to add a score for
proximity.. that data is at least in the index structure, but I've no
idea how hard it would be to fit into the code. We can ask the Zebra
wranglers what it would entail if you're interested.

>SUBJECT HEADING SEARCH
>
>NPL would like to see a demonstration of a 'Subject Heading' search
>using authorities generated from the data to compile a list of
>authoritative headings (which would be compiled from multiple fields
>within a given subject tag such as $650$a$v$x, etc.). So I think
>to do this right we'd need to look at putting our authority records
>in Zebra as well.
>  
>

Hmm. Not sure I fully grok the requirement here.. you seem to suggest
both constructing a specific index key based on a concatenation of
multiple fields (easy in the XSLT indexing rules of 1.4, not compatible
with the 'melm' directive.

>SERIES TITLE SEARCHING
>
>Series title should pull from series title fields, not just general
>title fields. We need to compile a list of these fields and create
>an index for just series titles.
>  
>
Seems easy enough.

>KEYWORD SEARCHING
>
>I saved this one for last on purpose. We're not really sure what
>keyword searching is supposed to be :-). We suspect that patrons
>expect that the keyword search is equivilent to a web search engine
>search box like Google. Given our limitations in the MARC format,
>what are our ranking options? Should titles be given priority,
>authors, subjects? We're not really sure. However, NPL did like the
>idea of offering a two-column results page for keyword searching--
>one side with library items and the other with results from the web
>using Google's API or something.
>
>Well, that's it for now. NPL staff are going to continue looking at
>the demo and providing me with feedback so I'll pass it along as I
>recieve it. Please feel free to add your own comments on the demo
>as well as comment on NPL's ideas.
>  
>

I think boosting the title is probably not the worst thing that could be
done, maybe a slightly smaller boost to the subejct keywords

Neat. Interesting feedback.

--Sebastian

--
Sebastian Hammer, Index Data
quinn@...   www.indexdata.com
Ph: [phone]



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

[Joshua Ferraro-3]

On Wed, Mar 22, 2006 at 08:28:26PM -0500, Sebastian Hammer wrote:
> Can't do XOR today. I suppose it would be a possible new feature, but
> I've frankly never heard of it in an ILS.. can a XOR b be mapped to
>
> (a OR b) NOT (a AND b) ?   or am I just showing my fading math skills to
> ill effect, here?
Yep, that's the correct mapping. Voyager's where NPL originally
saw the XOR function.

> Why do you see yourelf limited to Bib-1? Within Koha, you can do
> whatever you want -- specifically extend Bib-1 into the 8000-range
> (IIRC) for local USE attributes or define a private set.
Right, I was just hoping there was some way to map it to bib-1 as
I assume that would be useful in cross-domain searching. If not we
can certainly do a locally defined attribute or set.

> >SPELLCHECKING
> It isn't soundex, but it will behave somewhat the same in many cases.
> Try searching with truncation=Regexp-2  (103). This enables
> error-tolerant searching. By default, one error (insert/delete/replace)
> per term will still lead to a match. More at
> http://www.indexdata.com/zebra/doc/protocol-support.tkl#search
Neat, we'll look into it.

> >TITLE SEARCHING
> >
> This would, I believe, require new development. It's possible that one
> of the experimental ranking algorithms that are included might provide
> better results for these people, but I *think* that boosting the score
> for one field in a ranked keyword search would require an extension to
> the index structure.
I've looked high and low for documentation on the ranking algorithms in
Zebra but haven't found much more than a few sentences in the official
docs and some list messages ...

> >AUTHOR SEARCHING
> >
> >Again, the current relevance ranking doesn't quite cut it. A good
> >example is a relevance ranked author search on "James Joyce". Some
> >records sneak into high relevance because they have multiple authors
> >with names like "James Henry" and "Paul Joyce" (take  "Bob the Builder
> >in the NPL database as an example
> >
> It might be worth checking whether one of the custom ranking algos did
> better on this..you an look in the NEWS file for instructions on how to
> enable them.

Will do.

> >relevance ranking
> >should account for proximity and use that as the highest ranking
> >consideration to ensure that a search on "James Joyce" returns all the
> >books by "James Joyce" first. Also, they requested that the default
> >ranking secondarily sort the items by date as well because they often
> >are asked to find the 'latest' book by so and so. We concluded that
> >the copyright date stored in the 008 is probably the only date
> >normalized enough to use for sorting though I'm not sure if zebra can
> >use that for sorting.
> >
> >
> It could with the XSLT index rules of Zebra 1.4.

Cool, and are there docs on that somewhere? :-)

> >SUBJECT SEARCHING
> >
> >They seemed pleased with the way subject searching was working, it
> >will correctly find things like "horses--psychology" where the first
> >term is in 650$a and the second in $x. However, it seems not to
> >rank things based on proximity within a tag -- meaning that a search
> >on horses--psychology will pull up records containing:
> >
> >650$a horses
> >$x pets
> >
> >650$a humans
> >$x psychology
> >
> >and records with the actual 'horses--psychology' (650$a$x) subject
> >heading aren't given any favor in the ranking (I misplaced my actual
> >example and the one above is one I invented).
> >
> Same thing. I don't know how hard it would be to add a score for
> proximity.. that data is at least in the index structure, but I've no
> idea how hard it would be to fit into the code. We can ask the Zebra
> wranglers what it would entail if you're interested.

Yes, please do, we're very interested in that particular one.

> >SUBJECT HEADING SEARCH
> >
> >NPL would like to see a demonstration of a 'Subject Heading' search
> >using authorities generated from the data to compile a list of
> >authoritative headings (which would be compiled from multiple fields
> >within a given subject tag such as $650$a$v$x, etc.). So I think
> >to do this right we'd need to look at putting our authority records
> >in Zebra as well.
> >
> Hmm. Not sure I fully grok the requirement here.. you seem to suggest
> both constructing a specific index key based on a concatenation of
> multiple fields (easy in the XSLT indexing rules of 1.4, not compatible
> with the 'melm' directive.

I'm unclear about the differences between 'elm' and 'melm'. The docs
seem to indicate that they are the same...

Thanks!

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


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

[Sebastian Hammer]

Joshua Ferraro wrote:

>On Wed, Mar 22, 2006 at 08:28:26PM -0500, Sebastian Hammer wrote:
>  
>
>>Can't do XOR today. I suppose it would be a possible new feature, but
>>I've frankly never heard of it in an ILS.. can a XOR b be mapped to
>>
>>(a OR b) NOT (a AND b) ?   or am I just showing my fading math skills to
>>ill effect, here?
>>    
>>
>Yep, that's the correct mapping. Voyager's where NPL originally
>saw the XOR function.
>  
>

Ok. It can be faked in the front-end then, or implemented deeper in the
guts of Zebra.

>>Why do you see yourelf limited to Bib-1? Within Koha, you can do
>>whatever you want -- specifically extend Bib-1 into the 8000-range
>>(IIRC) for local USE attributes or define a private set.
>>    
>>
>Right, I was just hoping there was some way to map it to bib-1 as
>I assume that would be useful in cross-domain searching. If not we
>can certainly do a locally defined attribute or set.
>  
>

I think beyond what's in the Bath profile or the US national profile,
you have little hope of interoperable search.. in my experience,
cross-domain searching still entails the need to do query-mapping
independently per target or for groups of targets with similar
characteristics. I use the CCL parser that's available through the YAZ
ZOOM API, and include a reference to a set of mapping directives as part
of the configuration for each target.. that allows you to get pretty far
towards an interoperable-feeling search with a minimum of code.

>>This would, I believe, require new development. It's possible that one
>>of the experimental ranking algorithms that are included might provide
>>better results for these people, but I *think* that boosting the score
>>for one field in a ranked keyword search would require an extension to
>>the index structure.
>>    
>>
>I've looked high and low for documentation on the ranking algorithms in
>Zebra but haven't found much more than a few sentences in the official
>docs and some list messages ...
>  
>

 It isn't documented beyond what's in the code, AFAIK.

>>>AUTHOR SEARCHING
>>>
>>>Again, the current relevance ranking doesn't quite cut it. A good
>>>example is a relevance ranked author search on "James Joyce". Some
>>>records sneak into high relevance because they have multiple authors
>>>with names like "James Henry" and "Paul Joyce" (take  "Bob the Builder
>>>in the NPL database as an example
>>>
>>>      
>>>
>>It might be worth checking whether one of the custom ranking algos did
>>better on this..you an look in the NEWS file for instructions on how to
>>enable them.
>>    
>>
>Will do.
>
>>>relevance ranking
>>>should account for proximity and use that as the highest ranking
>>>consideration to ensure that a search on "James Joyce" returns all the
>>>books by "James Joyce" first. Also, they requested that the default
>>>ranking secondarily sort the items by date as well because they often
>>>are asked to find the 'latest' book by so and so. We concluded that
>>>the copyright date stored in the 008 is probably the only date
>>>normalized enough to use for sorting though I'm not sure if zebra can
>>>use that for sorting.
>>>
>>>
>>>      
>>>
>>It could with the XSLT index rules of Zebra 1.4.
>>    
>>
>Cool, and are there docs on that somewhere? :-)
>  
>

There will be by the time Zebra 1.4 is released. For now, it's
pre-release stuff. However, the CVS version of Zebra contains an example
setup under examples/alvis-oai/conf. I think for really gnarly indexing
schemes, this is probably the wave of the future, since it's pretty much
infinitely flexible. It should also be pretty easy to perl-map one of
the existing ABS files into this format.

>>Same thing. I don't know how hard it would be to add a score for
>>proximity.. that data is at least in the index structure, but I've no
>>idea how hard it would be to fit into the code. We can ask the Zebra
>>wranglers what it would entail if you're interested.
>>    
>>
>Yes, please do, we're very interested in that particular one.
>  
>
Ok.

>>>SUBJECT HEADING SEARCH
>>>
>>>NPL would like to see a demonstration of a 'Subject Heading' search
>>>using authorities generated from the data to compile a list of
>>>authoritative headings (which would be compiled from multiple fields
>>>within a given subject tag such as $650$a$v$x, etc.). So I think
>>>to do this right we'd need to look at putting our authority records
>>>in Zebra as well.
>>>
>>>      
>>>
>>Hmm. Not sure I fully grok the requirement here.. you seem to suggest
>>both constructing a specific index key based on a concatenation of
>>multiple fields (easy in the XSLT indexing rules of 1.4, not compatible
>>with the 'melm' directive.
>>    
>>
>I'm unclear about the differences between 'elm' and 'melm'. The docs
>seem to indicate that they are the same...
>  
>

They are actually described as being quite different, but I can see how
the nature of the difference could be more clear.

The 'elm' directive is the original.. it's parameter structure is based
on the way that Z39.50 abstract record models were typically represented
in the old days.. hence the weird ordering of elements, etc. It also has
the limitation that you can't address attributes, because the old Z39.50
record model didn't have attributes.  The xelm directive was introduced
to fix that.. it allows you to express tag paths in the XPATH style, and
to address attributes, either in [predicates] or directly, for indexing.

The usmarc.abs file that comes with Zebra assumes that records were
ingested in ISO2709 using the record type grs.marc.<absfilename>. The
grs.marc input filter actually generates an internal abstract structure
which is incompatible with MARCXML.. it looks more like
<245><11><a>content</a></11></245>. When MARCXML came along it became
clear that it'd be nicer to work with that.. so the grs.marcxml input
filter was introduced to parse ISO2709 and map them internally to
MARCXML. Of course, if you're starting with MARCXML, you can just use
grs.xml with the same effect.

But now the old usmarc.abs file won't work anymore, because MARCXML is
all about attributes for field names and subfield codes, and the 'elm'
directive can't handle that... in fact, to index 245$a, you'd have to
write something like

xelm /*/datafield[@tag=245]/subfield[@code=a]     title

At some point, we got a bit of money from the LoC to develop a simple
set of Bath level 0 indexing rules for Zebra.. I started working on
that, but got so fed up with the syntax above that I rebelled and
implemented the 'melm' directive (and it takes a lot for me to touch the
innards of Zebra, in my old days), so instead of the above, I could write

melm 245$a  title

Which is totally equivalent to the above, but nice and to the point..
however, none of these mechanisms allows you to construct phrase indexes
that span multiple subfields.. and they don't allow you to do cool stuff
like extract a date from the guts of 008... in fact, there are lots of
situations where you'd like to do some form of massaging on the input
before processing. In the past, I would sometimes translate MARC records
to an ASCII-line based format, and use the magic of the regexp input
filters (http://www.indexdata.com/zebra/doc/record-model.tkl#id2530050)
to massage the data at index/retrieval time... because I can write Tcl
code in the input filters to do stuff to the data, the sky is the
limit.. but, because I have to write Tcl code to accomplish anything, I
become sad and gray-haired.  So when I build applications on Zebra these
days, I am more likely to do some form of preprocessing of the records
in Perl or similar BEFORE feeding them to Zebra.. not very satisfying,
but it brings home the bacon.

Well, in Zebra 1.4, XSLT comes to the rescue, in a way that only XSLT
can do it, with lots of angular brackets and much verbosity.... for
instance, in an XSLT index filter,

melm 245$a title:w

becomes

<xsl:template
match="marc:record/marc:datafield[@tag='245']/marc:subfield[@code='a']">
  <z:index name="title"type="w">
    <xsl:value-of select="."/>
  </z:index>
</xsl:template>

Eek.

But of course the magic of that is that you could put just about
anything you could possibly imagine instead of that simple
<xsl:value-of> in the middle... using substr() to extract a date from
008, a code from the leader, combining subfields, doing math, looking
stuff up in supporting tables, etc... the sky is the limit, and I'd  
prefer this to programming in Tcl anytime. And of course, if you want a
more compact configuration file, you could write something like

<koha:melm field="245$a" index="title:w"/>

and use XSLT to map that into the diatribe above before sending it to
Zebra.. we might even offer some options like that as part of the
software down the road. In addition to the stylesheet which maps records
to 'index documents' like above, Zebra 1.4 can be configured to support
multiple retrieval schemas (i.e. DC, MODS, MARCXML), simply by providing
stylesheets for each desired schema -- the translation is done on the
fly when records are retrieved.

--Sebastian


>Thanks!
>
>  
>

--
Sebastian Hammer, Index Data
quinn@...   www.indexdata.com
Ph: [phone]



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

[Mike Taylor-2]

> Date: Wed, 22 Mar 2006 22:43:40 -0500
> From: Sebastian Hammer <quinn@...>
>
>>> Can't do XOR today. I suppose it would be a possible new feature,
>>> but I've frankly never heard of it in an ILS.. can a XOR b be
>>> mapped to (a OR b) NOT (a AND b) ?  or am I just showing my fading
>>> math skills to ill effect, here?
>>    
>> Yep, that's the correct mapping. Voyager's where NPL originally
>> saw the XOR function.
>
> Ok. It can be faked in the front-end then, or implemented deeper in
> the guts of Zebra.

... but the real question is, can anyone thing of _any_ use-case for
this?  I admit I've not tried very hard, but I can't imagine any
scenario in which I'd say, oh no, I don't want to see records that
have _both_ those terms!

>> I've looked high and low for documentation on the ranking
>> algorithms in Zebra but haven't found much more than a few
>> sentences in the official docs and some list messages ...
>
>  It isn't documented beyond what's in the code, AFAIK.

Marc might have something.

> In fact, to index 245$a, you'd have to write something like
> xelm /*/datafield[@tag=245]/subfield[@code=a]     title
> [...]
> however, none of these mechanisms allows you to construct phrase
> indexes that span multiple subfields.. and they don't allow you to
> do cool stuff like extract a date from the guts of 008...

Really?  Surely it would be possible to write an XPath expression that
does this?

> Well, in Zebra 1.4, XSLT comes to the rescue, in a way that only
> XSLT can do it, with lots of angular brackets and much verbosity....

... which is _way_ easier to write than TCL :-) ...

> for instance, in an XSLT index filter,
>
> melm 245$a title:w
>
> becomes
>
> <xsl:template
> match="marc:record/marc:datafield[@tag='245']/marc:subfield[@code='a']">
>   <z:index name="title"type="w">
>     <xsl:value-of select="."/>
>   </z:index>
> </xsl:template>
>
> Eek.

I think that "Eek" only scratches the surface, here.  :-)

But: talk about power and generality!

 _/|_ ___________________________________________________________________
/o ) \/  Mike Taylor  <mike@...>  http://www.miketaylor.org.uk
)_v__/\  "Those who mourn for 'USENET like it was' should remember the
         original design estimates of maximum traffic volume: two articles
         per day" -- Steven Bellovin.



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

[Sebastian Hammer]

Mike Taylor wrote:

>>Date: Wed, 22 Mar 2006 22:43:40 -0500
>>From: Sebastian Hammer <quinn@...>
>>
>>    
>>
>>>>Can't do XOR today. I suppose it would be a possible new feature,
>>>>but I've frankly never heard of it in an ILS.. can a XOR b be
>>>>mapped to (a OR b) NOT (a AND b) ?  or am I just showing my fading
>>>>math skills to ill effect, here?
>>>>        
>>>>
>>>  
>>>Yep, that's the correct mapping. Voyager's where NPL originally
>>>saw the XOR function.
>>>      
>>>
>>Ok. It can be faked in the front-end then, or implemented deeper in
>>the guts of Zebra.
>>    
>>
>
>... but the real question is, can anyone thing of _any_ use-case for
>this?  I admit I've not tried very hard, but I can't imagine any
>scenario in which I'd say, oh no, I don't want to see records that
>have _both_ those terms!
>
>  
>
>>>I've looked high and low for documentation on the ranking
>>>algorithms in Zebra but haven't found much more than a few
>>>sentences in the official docs and some list messages ...
>>>      
>>>
>> It isn't documented beyond what's in the code, AFAIK.
>>    
>>
>
>Marc might have something.
>
>  
>
>>In fact, to index 245$a, you'd have to write something like
>> xelm /*/datafield[@tag=245]/subfield[@code=a]     title
>>[...]
>>however, none of these mechanisms allows you to construct phrase
>>indexes that span multiple subfields.. and they don't allow you to
>>do cool stuff like extract a date from the guts of 008...
>>    
>>
>
>Really?  Surely it would be possible to write an XPath expression that
>does this?
>  
>

Not unlikely, but not one that Zebra can grok, AFAIK. It only implements
a subset of XPATH.

>>Well, in Zebra 1.4, XSLT comes to the rescue, in a way that only
>>XSLT can do it, with lots of angular brackets and much verbosity....
>>    
>>
>
>... which is _way_ easier to write than TCL :-) ...
>  
>
Well, I've found it so. YMMV.

>>for instance, in an XSLT index filter,
>>
>>melm 245$a title:w
>>
>>becomes
>>
>><xsl:template
>>match="marc:record/marc:datafield[@tag='245']/marc:subfield[@code='a']">
>>  <z:index name="title"type="w">
>>    <xsl:value-of select="."/>
>>  </z:index>
>></xsl:template>
>>
>>Eek.
>>    
>>
>
>I think that "Eek" only scratches the surface, here.  :-)
>
>But: talk about power and generality!
>  
>

Yep.

--Seb

> _/|_ ___________________________________________________________________
>/o ) \/  Mike Taylor  <mike@...>  http://www.miketaylor.org.uk
>)_v__/\  "Those who mourn for 'USENET like it was' should remember the
> original design estimates of maximum traffic volume: two articles
> per day" -- Steven Bellovin.
>
>
>  
>

--
Sebastian Hammer, Index Data
quinn@...   www.indexdata.com
Ph: [phone]



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

[Joshua Ferraro-3]

On Wed, Mar 22, 2006 at 08:28:26PM -0500, Sebastian Hammer wrote:
> Why do you see yourelf limited to Bib-1? Within Koha, you can do
> whatever you want -- specifically extend Bib-1 into the 8000-range
> (IIRC) for local USE attributes or define a private set.
And how would we represent that in a CQL query?

> It isn't soundex, but it will behave somewhat the same in many cases.
> Try searching with truncation=Regexp-2  (103). This enables
> error-tolerant searching. By default, one error (insert/delete/replace)
> per term will still lead to a match. More at
> http://www.indexdata.com/zebra/doc/protocol-support.tkl#search
Same here ... not sure how to do that in CQL ... could you shed some
light on that?

Thanks,

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


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

[Sebastian Hammer]

Joshua Ferraro wrote:

>On Wed, Mar 22, 2006 at 08:28:26PM -0500, Sebastian Hammer wrote:
>  
>
>>Why do you see yourelf limited to Bib-1? Within Koha, you can do
>>whatever you want -- specifically extend Bib-1 into the 8000-range
>>(IIRC) for local USE attributes or define a private set.
>>    
>>
>And how would we represent that in a CQL query?
>  
>

A private index set? Mike is the CQL guru, so he might have a better
answer.. but you can create your own index set -- even ask the LoC to
list it, although you don't need to.

>>It isn't soundex, but it will behave somewhat the same in many cases.
>>Try searching with truncation=Regexp-2  (103). This enables
>>error-tolerant searching. By default, one error (insert/delete/replace)
>>per term will still lead to a match. More at
>>http://www.indexdata.com/zebra/doc/protocol-support.tkl#search
>>    
>>
>Same here ... not sure how to do that in CQL ... could you shed some
>light on that?
>  
>

There's no standard way of representing this... in Zebra it's a
truncation attribute, not particularly standard.. what would be a good
way of representing something like that in CQL, Mike?

--Seb

>Thanks,
>
>  
>

--
Sebastian Hammer, Index Data
quinn@...   www.indexdata.com
Ph: [phone]



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

[Mike Taylor-2]

Sebastian Hammer writes:

>>> Why do you see yourelf limited to Bib-1? Within Koha, you can do
>>> whatever you want -- specifically extend Bib-1 into the 8000-range
>>> (IIRC) for local USE attributes or define a private set.
>>
>> And how would we represent that in a CQL query?
>
> A private index set? Mike is the CQL guru, so he might have a better
> answer.. but you can create your own index set -- even ask the LoC
> to list it, although you don't need to.

Unfortunately, I can't remember what "this" is any more, as the
mailing-list software seems to have held your message up for the best
part of a week!  Please contact me off-list and let me know what
specifically you're trying to express in CQL.

>>> It isn't soundex, but it will behave somewhat the same in many
>>> cases.  Try searching with truncation=Regexp-2 (103). This enables
>>> error-tolerant searching. By default, one error
>>> (insert/delete/replace) per term will still lead to a match. More at
>>> http://www.indexdata.com/zebra/doc/protocol-support.tkl#search
>>
>> Same here ... not sure how to do that in CQL ... could you shed some
>> light on that?
>
> There's no standard way of representing this... in Zebra it's a
> truncation attribute, not particularly standard.. what would be a
> good way of representing something like that in CQL, Mike?

The relation-modifier "fuzzy" is described at:
        http://www.loc.gov/standards/sru/cql/cql-context-set.html
as meaning:
        The server should be liberal in what it counts as a match. The
        exact details of this are left up to the server, but might
        include permutations of character order, off-by-one for
        numerical terms and so forth.

which sounds about right to me.  So you want to have the CQL module
translate the "fuzzy" relation modifier into the Z39.50 Type-1 query
attribute truncation=Regexp-2 (5=103).  So can get this effect by
adding:
        relationModifier.fuzzy = 5=103
to your "pqf.properties" file.  (In fact, there is already a rule for
relationModifier.fuzzy, which you'll want to _replace_ with this one,
as it's clearly incorrect).

Then you can search for:

        dc.title =/fuzzy paleontology

Awesome!  :-)

 _/|_ ___________________________________________________________________
/o ) \/  Mike Taylor  <mike@...>  http://www.miketaylor.org.uk
)_v__/\  "Shut up, be happy.  The conveniences you demanded are now
         mandatory" -- Jello Biafra.



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

[Chris Cormack]

> The relation-modifier "fuzzy" is described at:
> http://www.loc.gov/standards/sru/cql/cql-context-set.html
> as meaning:
> The server should be liberal in what it counts as a match. The
> exact details of this are left up to the server, but might
> include permutations of character order, off-by-one for
> numerical terms and so forth.
>
> which sounds about right to me.  So you want to have the CQL module
> translate the "fuzzy" relation modifier into the Z39.50 Type-1 query
> attribute truncation=Regexp-2 (5=103).  So can get this effect by
> adding:
> relationModifier.fuzzy = 5=103
> to your "pqf.properties" file.  (In fact, there is already a rule for
> relationModifier.fuzzy, which you'll want to _replace_ with this one,
> as it's clearly incorrect).
>
> Then you can search for:
>
> dc.title =/fuzzy paleontology
>
> Awesome!  :-)
>

Awesome indeed! :)

I wonder if we can do something similair for proximity?

Chris

--
Chris Cormack                                                     Programmer
027 4500 789                                       Katipo Communications Ltd
chris@...                                          www.katipo.co.nz


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

[Mike Taylor-2]

>> Then you can search for:
>>
>> dc.title =/fuzzy paleontology
>>
>> Awesome!  :-)
>>
>
> Awesome indeed! :)
>
> I wonder if we can do something similair for proximity?

proximity should "just work":

        new prox york
        new prox (york or jersey)
        dinosaur prox/distance<=5 taxonomy

Have you tried it?

 _/|_ ___________________________________________________________________
/o ) \/  Mike Taylor  <mike@...>  http://www.miketaylor.org.uk
)_v__/\  "The mark of a good conspiracy theory is its untestability" --
         Andrew Spring.



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

[Adam Dickmeiss]

Mike Taylor wrote:

>>>Then you can search for:
>>>
>>> dc.title =/fuzzy paleontology
>>>
>>>Awesome!  :-)
>>>
>>
>>Awesome indeed! :)
>>
>>I wonder if we can do something similair for proximity?
>
>
> proximity should "just work":
>
> new prox york
> new prox (york or jersey)
> dinosaur prox/distance<=5 taxonomy
>
> Have you tried it?

I have not. For it to work it the prox conversion must generate RPN
Proximity with Unit=Word.

/ Adam

>  _/|_ ___________________________________________________________________
> /o ) \/  Mike Taylor  <mike@...>  http://www.miketaylor.org.uk
> )_v__/\  "The mark of a good conspiracy theory is its untestability" --
> Andrew Spring.
>
>
>
> _______________________________________________
> 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

[Mike Taylor-2]

 > > proximity should "just work":
 > >
 > > new prox york
 > > new prox (york or jersey)
 > > dinosaur prox/distance<=5 taxonomy
 > >
 > > Have you tried it?
 >
 > I have not. For it to work it the prox conversion must generate RPN
 > Proximity with Unit=Word.

Yup -- I fixed that very code last week.

(Chris, make sure you have a bang-up-to-date YAZ release.)

 _/|_ ___________________________________________________________________
/o ) \/  Mike Taylor  <mike@...>  http://www.miketaylor.org.uk
)_v__/\  "You can't have free speech without responsibility, and anyone in
         such a high profile position has to know the difference between
         saying what you want and saying what you ought" -- Geoff Thompson,
         acting FA chairman, shows his ignorance.



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

[Joshua Ferraro-3]

On Wed, Mar 29, 2006 at 01:18:25PM +0100, Mike Taylor wrote:
> Yup -- I fixed that very code last week.
>
> (Chris, make sure you have a bang-up-to-date YAZ release.)
Does bang-up-to-date cover the deb package?

Cheers,

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


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

[Mike Taylor-2]

 > > Yup -- I fixed that very code last week.
 > >
 > > (Chris, make sure you have a bang-up-to-date YAZ release.)
 >
 > Does bang-up-to-date cover the deb package?

'fraid not.  I made the fix on 20th March, so you need either a
version of YAZ built from CVS (which is was I always use) or one of
the nightly builds that I can never remember the location of and which
are still not linked from
        http://indexdata.com/yaz/
:-)

 _/|_ ___________________________________________________________________
/o ) \/  Mike Taylor  <mike@...>  http://www.miketaylor.org.uk
)_v__/\  "Ask not what fruitbats can do for you.  Rather, ask what you
         can do for fruitbats" -- Ian "Zobbo" Cottee.



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

[Mike Taylor-2]

I wrote --

        >> Yup -- I fixed that very code last week.
        >>
        >> (Chris, make sure you have a bang-up-to-date YAZ release.)
        >
        > Does bang-up-to-date cover the deb package?

        'fraid not.  I made the fix on 20th March, so you need either
        a version of YAZ built from CVS (which is was I always use) or
        one of the nightly builds [...]

The new YAZ v2.1.6 (see below) gives you the required proximity
support.  Don't forget to rebuild Zebra after installing the new YAZ!

 _/|_ ___________________________________________________________________
/o ) \/  Mike Taylor  <mike@...>  http://www.miketaylor.org.uk
)_v__/\  "Now I lay me down to bed / Darkness won't engulf my head / I can
         see by intra-red / How I hate the night" -- Marvin the Android,
         "Hitch-hiker's Guide to the Galaxy"




------- start of forwarded message -------
Return-path: <yazlist-bounces@...>
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on bagel.indexdata.dk
X-Spam-Level:
Envelope-to: mike@...
Delivery-date: Fri, 31 Mar 2006 14:25:02 +0200
Received: from localhost.localdomain [127.0.0.1]
        by localhost with POP3 (fetchmail-6.2.5)
        for mike@localhost (single-drop); Fri, 31 Mar 2006 14:56:11 +0100 (BST)
Received: from kebab.indexdata.dk ([83.133.64.60])
        by bagel.indexdata.dk with esmtp (Exim 3.35 #1 (Debian))
        id 1FPIgY-0000Nu-00
        for <mike@...>; Fri, 31 Mar 2006 14:25:02 +0200
Received: from localhost ([127.0.0.1] helo=kebab.indexdata.dk)
        by kebab.indexdata.dk with esmtp (Exim 4.50)
        id 1FPIcM-0003Yu-6x; Fri, 31 Mar 2006 14:20:42 +0200
Received: from user.indexdata.dk ([213.150.43.10] helo=bagel.indexdata.dk)
        by kebab.indexdata.dk with esmtp (Exim 4.50) id 1FPIcF-0003Ym-8T
        for yazlist@...; Fri, 31 Mar 2006 14:20:39 +0200
Received: from user.indexdata.dk ([213.150.43.10] helo=[10.0.1.68])
        by bagel.indexdata.dk with esmtp (Exim 3.35 #1 (Debian))
        id 1FPIfU-0000L8-00
        for <yazlist@...>; Fri, 31 Mar 2006 14:23:56 +0200
Message-ID: <442D1F56.4050908@...>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; da-DK;
        rv:1.7.12) Gecko/20060205 Debian/1.7.12-1.1
X-Accept-Language: en-us, da, en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: yazlist@...
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: "Discussion on the YAZ Z39.50 toolkit" <yazlist@...>
List-Id: "Discussion on the YAZ Z39.50 toolkit" <yazlist.lists.indexdata.dk>
List-Unsubscribe: <http://lists.indexdata.dk/cgi-bin/mailman/listinfo/yazlist>,
        <mailto:yazlist-request@...?subject=unsubscribe>
List-Archive: <http://lists.indexdata.dk/pipermail/yazlist>
List-Post: <mailto:yazlist@...>
List-Help: <mailto:yazlist-request@...?subject=help>
List-Subscribe: <http://lists.indexdata.dk/cgi-bin/mailman/listinfo/yazlist>,
        <mailto:yazlist-request@...?subject=subscribe>
Errors-To: yazlist-bounces@...
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: yazlist-bounces@...
X-SA-Exim-Scanned: No (on kebab.indexdata.dk); SAEximRunCond expanded to false
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,
        FORGED_RCVD_HELO autolearn=ham version=3.1.0
From: Adam Dickmeiss <adam@...>
Sender: yazlist-bounces@...
To: "Discussion on the YAZ Z39.50 toolkit" <yazlist@...>
Subject: [Yazlist] YAZ 2.1.16 available
Date: Fri, 31 Mar 2006 14:23:50 +0200

YAZ 2.1.16 is available.

Apart from source we have produced packages for: Debian
woody/sarge/etch, RedHat FC4/FC5, Windows and Ubuntu 5.10.

News below since last release.. / Adam

Allow multiple languages and charsets to be specified with
yaz-client. Each item must be separated by comma (NO BLANKS). E.g.
   negcharset iso-8859-1,utf-8

Translation of proximity nodes from CQL into PQF now works.

Moved to automake 1.8, 1.9.

Added function yaz_log_set_handler which allows a log handler
to be installed. This handler will be called for all log messages.
Output to file is also produced; but that can be disabled by passing
NULL fname to yaz_log_init_file.

Fixed another problem with MARC-8 -> ISO-8859-1 conversions. Bug #537.

For SRW (including GFS), accept application/soap+xml as content-type
for SOAP msg.

For GFS in SRU mode, an empty stylesheet in SRU URL (&stylesheet=&)
produces NO stylesheet reference even if a default stylesheet is
specified in GFS XML config.

_______________________________________________
Yazlist mailing list
Yazlist@...
http://lists.indexdata.dk/cgi-bin/mailman/listinfo/yazlist
------- end of forwarded message -------


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

[Joshua Ferraro-3]

Strangely, the deb package for yaz 2.1.16 doesn't seem to be
working for my sarge box:

sam:/# yaz-client -V
YAZ version: 2.1.14
sam:/# apt-get install libyaz
Reading Package Lists... Done
Building Dependency Tree... Done
libyaz is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

I've got the correct entry in sources.list:

#Yaz Toolkit
deb http://ftp.indexdata.dk/debian indexdata/sarge released
deb-src http://ftp.indexdata.dk/debian indexdata/sarge released

and ran apt-get update to try to update the package lists ...
and it's showing up here: http://ftp.indexdata.dk/pub/yaz/debian/sarge/

any ideas?

Cheers,

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

On Fri, Mar 31, 2006 at 03:41:52PM +0100, Mike Taylor wrote:

> I wrote --
>
> >> Yup -- I fixed that very code last week.
> >>
> >> (Chris, make sure you have a bang-up-to-date YAZ release.)
> >
> > Does bang-up-to-date cover the deb package?
>
> 'fraid not.  I made the fix on 20th March, so you need either
> a version of YAZ built from CVS (which is was I always use) or
> one of the nightly builds [...]
>
> The new YAZ v2.1.6 (see below) gives you the required proximity
> support.  Don't forget to rebuild Zebra after installing the new YAZ!
>
>  _/|_ ___________________________________________________________________
> /o ) \/  Mike Taylor  <mike@...>  http://www.miketaylor.org.uk
> )_v__/\  "Now I lay me down to bed / Darkness won't engulf my head / I can
> see by intra-red / How I hate the night" -- Marvin the Android,
> "Hitch-hiker's Guide to the Galaxy"
>
> Apart from source we have produced packages for: Debian
> woody/sarge/etch, RedHat FC4/FC5, Windows and Ubuntu 5.10.
>
> News below since last release.. / Adam
>
> Allow multiple languages and charsets to be specified with
> yaz-client. Each item must be separated by comma (NO BLANKS). E.g.
>    negcharset iso-8859-1,utf-8
>
> Translation of proximity nodes from CQL into PQF now works.
>
> Moved to automake 1.8, 1.9.
>
> Added function yaz_log_set_handler which allows a log handler
> to be installed. This handler will be called for all log messages.
> Output to file is also produced; but that can be disabled by passing
> NULL fname to yaz_log_init_file.
>
> Fixed another problem with MARC-8 -> ISO-8859-1 conversions. Bug #537.
>
> For SRW (including GFS), accept application/soap+xml as content-type
> for SOAP msg.
>
> For GFS in SRU mode, an empty stylesheet in SRU URL (&stylesheet=&)
> produces NO stylesheet reference even if a default stylesheet is
> specified in GFS XML config.
>
> _______________________________________________
> Yazlist mailing list
> Yazlist@...
> http://lists.indexdata.dk/cgi-bin/mailman/listinfo/yazlist
> ------- end of forwarded message -------

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

[Adam Dickmeiss]

Joshua Ferraro wrote:
> Strangely, the deb package for yaz 2.1.16 doesn't seem to be
> working for my sarge box:
>

The Debian packages lists were not yet updated. It should be now. Sorry
about that.

/ Adam

> sam:/# yaz-client -V
> YAZ version: 2.1.14
> sam:/# apt-get install libyaz
> Reading Package Lists... Done
> Building Dependency Tree... Done
> libyaz is already the newest version.
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>
> I've got the correct entry in sources.list:
>
> #Yaz Toolkit
> deb http://ftp.indexdata.dk/debian indexdata/sarge released
> deb-src http://ftp.indexdata.dk/debian indexdata/sarge released
>
> and ran apt-get update to try to update the package lists ...
> and it's showing up here: http://ftp.indexdata.dk/pub/yaz/debian/sarge/
>
> any ideas?
>
> Cheers,
>
> --
> Joshua Ferraro               VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE
> President, Technology       migration, training, maintenance, support
> LibLime                                Featuring Koha Open-Source ILS
> jmf@... |Full Demos at http://liblime.com/koha |1(888)KohaILS
>
> On Fri, Mar 31, 2006 at 03:41:52PM +0100, Mike Taylor wrote:
>
>>I wrote --
>>
>> >> Yup -- I fixed that very code last week.
>> >>
>> >> (Chris, make sure you have a bang-up-to-date YAZ release.)
>> >
>> > Does bang-up-to-date cover the deb package?
>>
>> 'fraid not.  I made the fix on 20th March, so you need either
>> a version of YAZ built from CVS (which is was I always use) or
>> one of the nightly builds [...]
>>
>>The new YAZ v2.1.6 (see below) gives you the required proximity
>>support.  Don't forget to rebuild Zebra after installing the new YAZ!
>>
>> _/|_ ___________________________________________________________________
>>/o ) \/  Mike Taylor  <mike@...>  http://www.miketaylor.org.uk
>>)_v__/\  "Now I lay me down to bed / Darkness won't engulf my head / I can
>> see by intra-red / How I hate the night" -- Marvin the Android,
>> "Hitch-hiker's Guide to the Galaxy"
>>
>>Apart from source we have produced packages for: Debian
>>woody/sarge/etch, RedHat FC4/FC5, Windows and Ubuntu 5.10.
>>
>>News below since last release.. / Adam
>>
>>Allow multiple languages and charsets to be specified with
>>yaz-client. Each item must be separated by comma (NO BLANKS). E.g.
>>   negcharset iso-8859-1,utf-8
>>
>>Translation of proximity nodes from CQL into PQF now works.
>>
>>Moved to automake 1.8, 1.9.
>>
>>Added function yaz_log_set_handler which allows a log handler
>>to be installed. This handler will be called for all log messages.
>>Output to file is also produced; but that can be disabled by passing
>>NULL fname to yaz_log_init_file.
>>
>>Fixed another problem with MARC-8 -> ISO-8859-1 conversions. Bug #537.
>>
>>For SRW (including GFS), accept application/soap+xml as content-type
>>for SOAP msg.
>>
>>For GFS in SRU mode, an empty stylesheet in SRU URL (&stylesheet=&)
>>produces NO stylesheet reference even if a default stylesheet is
>>specified in GFS XML config.
>>
>>_______________________________________________
>>Yazlist mailing list
>>Yazlist@...
>>http://lists.indexdata.dk/cgi-bin/mailman/listinfo/yazlist
>>------- end of forwarded message -------
>
>

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