.abs file and subfield ordering

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

.abs file and subfield ordering

Joshua Ferraro-3
Hi guys,

I've been playing around with the .abs file for Koha's MARC records,
trying to put together some solid mappings between the 'attributes'
and MARC tag/subfield combos (ie, 'title' => (245$a$f$g, etc.) and
have a couple of questions.

First, this is strange, but using the MODS mapping as a guideline,
I note that they map things differently depending on subfield order
in the record. For instance, in tag 245, if  $f$g$h$k follow $b they
go with <subTitle>. If they follow $a they go with <title>. I'm
wondering whether this is possible in Zebra and if so, how it can
be acomplished. If your answer is that MARC MUST DIE, I'll completely
understand :-).

Also, speaking of mappings, I've got a few CQL questions. So I
understand the notion of a 'context set' and 'indexes' within
each context set. I'm not clear on what the best context set
would be for the MARC records in the libraries using Koha. bath?
cql?

Also, though the bath context set defines indexes, it doesn't clearly
specify mappings for those indexes into any specific record format
like MARC. Are there specifications anywhere that define such
mappings? Bib-1 maybe? MODS? Any suggestions?

Finally, in some of the ABS files included with Zebra I see a
? after the tag like in this entry:

elm 245                 title           -
elm 245/?               title           !:w
elm 245/?/a             title           !:w,!:p

Is this a 'WildThing'? could someone explain what that means? :-)

Thanks,

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


_______________________________________________
Koha-zebra mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/koha-zebra
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: .abs file and subfield ordering

Sebastian Hammer
Joshua Ferraro wrote:

>Hi guys,
>
>I've been playing around with the .abs file for Koha's MARC records,
>trying to put together some solid mappings between the 'attributes'
>and MARC tag/subfield combos (ie, 'title' => (245$a$f$g, etc.) and
>have a couple of questions.
>
>First, this is strange, but using the MODS mapping as a guideline,
>I note that they map things differently depending on subfield order
>in the record. For instance, in tag 245, if  $f$g$h$k follow $b they
>go with <subTitle>. If they follow $a they go with <title>. I'm
>wondering whether this is possible in Zebra and if so, how it can
>be acomplished. If your answer is that MARC MUST DIE, I'll completely
>understand :-).
>  
>
Of course MARC must die... but I don't think this is a major issue. I've
had extensive conversations with staff at the LoC about Zebra's
weaknesses as pertains to MARC, so I'm acutely aware of the weaknesses,
but I'm not sure this is one of them. Most of their concerns have
concerned the ability to combine multiple subfields into one phrase
index for scanning or complete subfield searching... I've never heard of
a wish to control indexing based on what subfield follows what other
subfield... others on the list may have other experiences (indeed, other
formats than MARC21 may pose other challenges here).

>Also, speaking of mappings, I've got a few CQL questions. So I
>understand the notion of a 'context set' and 'indexes' within
>each context set. I'm not clear on what the best context set
>would be for the MARC records in the libraries using Koha. bath?
>cql?
>  
>
I'll defer to Mike, since he's on the editorial board. I imagine this
might be something that'd be good to bring to the ZING list.

>Also, though the bath context set defines indexes, it doesn't clearly
>specify mappings for those indexes into any specific record format
>like MARC. Are there specifications anywhere that define such
>mappings? Bib-1 maybe? MODS? Any suggestions?
>
>Finally, in some of the ABS files included with Zebra I see a
>? after the tag like in this entry:
>
>elm 245                 title           -
>elm 245/?               title           !:w
>elm 245/?/a             title           !:w,!:p
>
>Is this a 'WildThing'? could someone explain what that means? :-)
>  
>
I think Bath has been roundly criticized for stopping short of mapping
USE attributes (to say nothing of indexes) to MARC fields. The Bib-1
semantics document makes a half-baked effort, but I don't think anyone
would consider it an authority today. I've heard some folks say that
either the US national profile or the ZTexas profile actually specify
mappings to MARC fields for the basic stuff.

But the marc21.abs file that comes with Zebra should be a really good
starting point for the most simple and obvious stuff. I developed that
over several iterations with Larry Dixson of the LoC, and it was
directly based on a set of requirements that they developed for their
LIS vendor when they migrated to Voyager (of course, the vendor totally
ignored them). And the folks at the LoC sure do know their MARC.  :-)

--Sebastian

>Thanks,
>
>  
>

--
Sebastian Hammer, Index Data
[hidden email]   www.indexdata.com
Ph: (603) 209-6853



_______________________________________________
Koha-zebra mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/koha-zebra
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: .abs file and subfield ordering

Joshua Ferraro-3
On Tue, Feb 14, 2006 at 11:47:09PM -0500, Sebastian Hammer wrote:
> Of course MARC must die... but I don't think this is a major issue. I've
> had extensive conversations with staff at the LoC about Zebra's
> weaknesses as pertains to MARC, so I'm acutely aware of the weaknesses,
> but I'm not sure this is one of them. Most of their concerns have
> concerned the ability to combine multiple subfields into one phrase
> index for scanning or complete subfield searching... I've never heard of
> a wish to control indexing based on what subfield follows what other
> subfield... others on the list may have other experiences (indeed, other
> formats than MARC21 may pose other challenges here).
OK ... I won't worry about the ordering prob then ... with regards
to the multiple subfields in one phrase search, I have actually
been saving that one :-). A while ago I found a thread on the lists:
http://lists.indexdata.dk/pipermail/zebralist/2005-August/000875.html

That seems to indicate there is a solution for that -- or am I
reading it wrong?

> >Also, speaking of mappings, I've got a few CQL questions. So I
> >understand the notion of a 'context set' and 'indexes' within
> >each context set. I'm not clear on what the best context set
> >would be for the MARC records in the libraries using Koha. bath?
> >cql?
> >
> I'll defer to Mike, since he's on the editorial board. I imagine this
> might be something that'd be good to bring to the ZING list.
Right ... I'll do that then.

> >Also, though the bath context set defines indexes, it doesn't clearly
> >specify mappings for those indexes into any specific record format
> >like MARC. Are there specifications anywhere that define such
> >mappings? Bib-1 maybe? MODS? Any suggestions?
> >
> >Finally, in some of the ABS files included with Zebra I see a
> >? after the tag like in this entry:
> >
> >elm 245                 title           -
> >elm 245/?               title           !:w
> >elm 245/?/a             title           !:w,!:p
> >
> >Is this a 'WildThing'? could someone explain what that means? :-)
> >
> I think Bath has been roundly criticized for stopping short of mapping
> USE attributes (to say nothing of indexes) to MARC fields. The Bib-1
> semantics document makes a half-baked effort, but I don't think anyone
> would consider it an authority today. I've heard some folks say that
> either the US national profile or the ZTexas profile actually specify
> mappings to MARC fields for the basic stuff.
Thanks, I'll check those out.

> But the marc21.abs file that comes with Zebra should be a really good
> starting point for the most simple and obvious stuff. I developed that
> over several iterations with Larry Dixson of the LoC, and it was
> directly based on a set of requirements that they developed for their
> LIS vendor when they migrated to Voyager (of course, the vendor totally
> ignored them). And the folks at the LoC sure do know their MARC.  :-)
OK ... I'll check this out as well.  Thanks!

Cheers,

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


_______________________________________________
Koha-zebra mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/koha-zebra
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

CQL queries into MARC records (Was: .abs file and subfield ordering)

Mike Taylor-2
In reply to this post by Joshua Ferraro-3
> Date: Tue, 14 Feb 2006 20:27:57 -0800
> From: Joshua Ferraro <[hidden email]>
>
> Also, speaking of mappings, I've got a few CQL questions. So I
> understand the notion of a 'context set' and 'indexes' within each
> context set. I'm not clear on what the best context set would be for
> the MARC records in the libraries using Koha. bath?  cql?

Hi, Josh.  The first thing to get clear is that when figuring out how
to do particular searches with CQL, the question is not what _context
set_ to us, but what profile -- and in general a profile will draw
indexes from multiple context sets.  This is analagous to the choice
you make when wanting to represent data in XML: you don't choose what
_namespace_ to use, but what schema to use -- and in general a schema
will draw elements from multiple namespaces.  (The correspondance
between CQL context sets and XML namespaces is so strong that I have
wondered whether we should rename the former as CQL namespaces.  What
do you think?)

With that cleared up, it's time to evade your question!  We'll be able
to give you more definitive answer after the the big SRU meeting in
The Hague at the start of March, but to summarise the state of play,
there are potentially four ways to do bibliographic searching with CQL
on the table(!)

One approach is to use the Bath profile at
        http://zing.z3950.org/srw/bath/2.0/
which as you'll notice draws indexes both from the DC context set and
from its own Bath context set.  Regarding this approach, you
compained:

> Also, though the bath context set defines indexes, it doesn't
> clearly specify mappings for those indexes into any specific record
> format like MARC.

That's deliberate: the Bath set is not searching MARC records
specifically, but bibliographic records in general.  The indexes are
defined in terms of their semantics (delegating these definitions to
the DC element set and the Bath Z39.50 Profile) rather than their
encoding in a particular record format.

For some applications, this is what you want; but for Koha, which can
be seen as an application for maintaining MARC records, it's probably
not.  Think of the Bath profile as primarily for facilitating
interoperability between diverse bibliographic searching
implementations, especially to make metasearching more comprehensible.

The second approach to bibliographic searching in CQL is to use the
forthcoming MODS profile.  That's yet to be nailed down, but as the
name suggests will be based on the MODS XML Schema, with mappings
between indexes and elements clearly specified.  It fills more or less
the same ecological niche as the Bath profile, and may even supersede
it.  Again, the idea is that the indexes are primarily defined
semantically (and the crosswalk to MODS elements is a bit of an
after-the-event helping hand) so it's probably not what you want.

The third approach is to use the forthcoming MARC profile, and I
suggest that this _is_ what you need, as it's tied to the MARC syntax
specifically.  The proposal has not yet been written up, but basically
searches will look like this:
        marc.245=dinosaur and marc.245$c=farlow
As you can see, it's very structural.

(The fourth approach is based on the OpenURL metadata formats for
books, articles, dissertations and patents; I think it's a pretty bad
idea, but even if it's accepted the intention will be that it's
pretty much exclusively for the use of OpenURL resolvers, so it's
really not directly relevant to what you want to do.)

Hope this is helpful; sorry if it's more detail than you wanted.

 _/|_ ___________________________________________________________________
/o ) \/  Mike Taylor  <[hidden email]>  http://www.miketaylor.org.uk
)_v__/\  "There is hopeful symbolism in the fact that flags do not wave
         in a vacuum" -- Arthur C. Clarke, on the moon landings.



_______________________________________________
Koha-zebra mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/koha-zebra
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CQL queries into MARC records (Was: .abs file and subfield ordering)

Mike Taylor-2
In reply to this post by Joshua Ferraro-3
By happy coincidence, the three previously undocumented approaches to
bibliographic searching in CQL have just now been written up as a
proposal, which you can find at
        http://www.loc.gov/standards/sru/march06-meeting/bib-indexes.html

Hope that helps!

 _/|_ ___________________________________________________________________
/o ) \/  Mike Taylor  <[hidden email]>  http://www.miketaylor.org.uk
)_v__/\  "There are three rules for writing a novel.  Unfortunately,
         no one knows what they are" -- W. Somerset Maugham.



_______________________________________________
Koha-zebra mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/koha-zebra
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CQL queries into MARC records (Was: .abs file and subfield ordering)

Paul POULAIN-2
In reply to this post by Mike Taylor-2
Hello,

I just wanted to add 2 words : when designing Search in Koha, we have to
remember that we have 2 kinds of users :
* librarians. For them it's possible to have complex syntax (like
marc.245=dinosaur and marc.245$c=farlow) to do complex search.
* borrowers/users/patrons : for them, we must avoid at all cost giving
them complex queries. "title=XXX or author=YYY" will be enough. Bath-2
seems to be simple and acceptable to me (but you may have an other
opinion) (not the complete one, but the table in the middle of
http://zing.z3950.org/srw/bath/2.0/)

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


_______________________________________________
Koha-zebra mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/koha-zebra
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CQL queries into MARC records (Was: .abs file and subfield ordering)

Joshua Ferraro-3
In reply to this post by Mike Taylor-2
On Wed, Feb 15, 2006 at 10:32:27AM +0000, Mike Taylor wrote:

> > Date: Tue, 14 Feb 2006 20:27:57 -0800
> > From: Joshua Ferraro <[hidden email]>
> >
> > Also, speaking of mappings, I've got a few CQL questions. So I
> > understand the notion of a 'context set' and 'indexes' within each
> > context set. I'm not clear on what the best context set would be for
> > the MARC records in the libraries using Koha. bath?  cql?
>
> Hi, Josh.  The first thing to get clear is that when figuring out how
> to do particular searches with CQL, the question is not what _context
> set_ to us, but what profile -- and in general a profile will draw
> indexes from multiple context sets.  This is analagous to the choice
> you make when wanting to represent data in XML: you don't choose what
> _namespace_ to use, but what schema to use -- and in general a schema
> will draw elements from multiple namespaces.  (The correspondance
> between CQL context sets and XML namespaces is so strong that I have
> wondered whether we should rename the former as CQL namespaces.  What
> do you think?)
Hmmm ... still not clear to me. The document you link to here:
http://www.loc.gov/standards/sru/march06-meeting/bib-indexes.html

starts out "This is a proposal for three new CQL context sets, MODS,
MARC, and OpenURL" ... whereas in your answer below, you're calling them
'profiles'. so which is it, are they context sets or profiles? :-)

And are context sets analagous to index sets? I think calling them
namespaces is just going to lead to more confusion ... are there documents
out there explaining what the role of all of these terms is in the
greater scheme of 'searching'?

(naming conventions in Z3950 and related standards seem just willy
nilly to me ... what exactly is a Type-1 query ... and what is
'bib-1' supposed to mean? Why the obsession with the number '1'?) :-).

> With that cleared up, it's time to evade your question!  We'll be able
> to give you more definitive answer after the the big SRU meeting in
> The Hague at the start of March, but to summarise the state of play,
> there are potentially four ways to do bibliographic searching with CQL
> on the table(!)
>
> One approach is to use the Bath profile at
> http://zing.z3950.org/srw/bath/2.0/
> which as you'll notice draws indexes both from the DC context set and
> from its own Bath context set.  Regarding this approach, you
> compained:
So does this mean that a CQL search for dc.title is identical to a
search for bath.title since the bath profile's title access point is
drawn from the DC context set?

> > Also, though the bath context set defines indexes, it doesn't
> > clearly specify mappings for those indexes into any specific record
> > format like MARC.
>
> That's deliberate: the Bath set is not searching MARC records
> specifically, but bibliographic records in general.  The indexes are
> defined in terms of their semantics (delegating these definitions to
> the DC element set and the Bath Z39.50 Profile) rather than their
> encoding in a particular record format.
Could you expand on this just a bit ... maybe with an example or two?
The Bath profile delegates defining where in the MARC records the
indexes should apply? And they delegate it to the Bath Z39.50 profile
and the DC element set? I've just recently read Bath and there is
definitely no mention of MARC mappings. Or have I misunderstood ...

> For some applications, this is what you want; but for Koha, which can
> be seen as an application for maintaining MARC records, it's probably
> not.  Think of the Bath profile as primarily for facilitating
> interoperability between diverse bibliographic searching
> implementations, especially to make metasearching more comprehensible.
>
> The second approach to bibliographic searching in CQL is to use the
> forthcoming MODS profile.  That's yet to be nailed down, but as the
> name suggests will be based on the MODS XML Schema, with mappings
> between indexes and elements clearly specified.  It fills more or less
> the same ecological niche as the Bath profile, and may even supersede
> it.  Again, the idea is that the indexes are primarily defined
> semantically (and the crosswalk to MODS elements is a bit of an
> after-the-event helping hand) so it's probably not what you want.
My initial impression after perusing the MODS mappings for MARC have
led me to conclude that it's far too basic -- lots of MARC fields
would simply be unsearched using it.

> The third approach is to use the forthcoming MARC profile, and I
> suggest that this _is_ what you need, as it's tied to the MARC syntax
> specifically.  The proposal has not yet been written up, but basically
> searches will look like this:
> marc.245=dinosaur and marc.245$c=farlow
> As you can see, it's very structural.
Right ... well I'm pretty sure we _don't_ want _just_ the MARC profile,
though I do know a few librarians who would like it. Most library
users never want to touch MARC -- or know what it is -- they want to
be able to do searches on things like title, author, subject and keyword.

Our goal with Koha 3.x is not to limit ourselves to a single record
format. We're actually getting quite a few requests from libraries
interested in accessing all kinds of record types from the ILS:
MODS, DC, other XML, etc.

In practical terms, supposing I can come up with solid mappings for
the record types we want to index, (marc21, unimarc, mods, dc, etc.),
how would I account for CQL's ability to search with multiple context
sets in the same query? Would I need one giant .abs file with each
access point fully expressed (dc.title, etc.)?

Some of this stuff is starting to sink in, but I still feel a bit
lost.

> (The fourth approach is based on the OpenURL metadata formats for
> books, articles, dissertations and patents; I think it's a pretty bad
> idea, but even if it's accepted the intention will be that it's
> pretty much exclusively for the use of OpenURL resolvers, so it's
> really not directly relevant to what you want to do.)
>
> Hope this is helpful; sorry if it's more detail than you wanted.
Not at all ... more detail please :-)

Cheers,

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


_______________________________________________
Koha-zebra mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/koha-zebra
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: .abs file and subfield ordering

Sebastian Hammer
In reply to this post by Joshua Ferraro-3
Joshua Ferraro wrote:

>On Tue, Feb 14, 2006 at 11:47:09PM -0500, Sebastian Hammer wrote:
>  
>
>>Of course MARC must die... but I don't think this is a major issue. I've
>>had extensive conversations with staff at the LoC about Zebra's
>>weaknesses as pertains to MARC, so I'm acutely aware of the weaknesses,
>>but I'm not sure this is one of them. Most of their concerns have
>>concerned the ability to combine multiple subfields into one phrase
>>index for scanning or complete subfield searching... I've never heard of
>>a wish to control indexing based on what subfield follows what other
>>subfield... others on the list may have other experiences (indeed, other
>>formats than MARC21 may pose other challenges here).
>>    
>>
>OK ... I won't worry about the ordering prob then ... with regards
>to the multiple subfields in one phrase search, I have actually
>been saving that one :-). A while ago I found a thread on the lists:
>http://lists.indexdata.dk/pipermail/zebralist/2005-August/000875.html
>
>That seems to indicate there is a solution for that -- or am I
>reading it wrong?
>  
>
Some Russians have developed functionality that allows you to combine
subfields into an index and do other fancy stuff. I haven't looked much
at it myself.

The up-and-coming XSLT-based indexing system will allow *any* kind of
crazy logic on the records to support indexing, including mapping the
whole damn thing to sound like a pirate, aargh.. It should be easy
enough to write some perl to map an old-style .abs to an XSLT-based
filter if/when the need arises.

--Seb

>  
>
>>>Also, speaking of mappings, I've got a few CQL questions. So I
>>>understand the notion of a 'context set' and 'indexes' within
>>>each context set. I'm not clear on what the best context set
>>>would be for the MARC records in the libraries using Koha. bath?
>>>cql?
>>>
>>>      
>>>
>>I'll defer to Mike, since he's on the editorial board. I imagine this
>>might be something that'd be good to bring to the ZING list.
>>    
>>
>Right ... I'll do that then.
>
>  
>
>>>Also, though the bath context set defines indexes, it doesn't clearly
>>>specify mappings for those indexes into any specific record format
>>>like MARC. Are there specifications anywhere that define such
>>>mappings? Bib-1 maybe? MODS? Any suggestions?
>>>
>>>Finally, in some of the ABS files included with Zebra I see a
>>>? after the tag like in this entry:
>>>
>>>elm 245                 title           -
>>>elm 245/?               title           !:w
>>>elm 245/?/a             title           !:w,!:p
>>>
>>>Is this a 'WildThing'? could someone explain what that means? :-)
>>>
>>>      
>>>
>>I think Bath has been roundly criticized for stopping short of mapping
>>USE attributes (to say nothing of indexes) to MARC fields. The Bib-1
>>semantics document makes a half-baked effort, but I don't think anyone
>>would consider it an authority today. I've heard some folks say that
>>either the US national profile or the ZTexas profile actually specify
>>mappings to MARC fields for the basic stuff.
>>    
>>
>Thanks, I'll check those out.
>
>  
>
>>But the marc21.abs file that comes with Zebra should be a really good
>>starting point for the most simple and obvious stuff. I developed that
>>over several iterations with Larry Dixson of the LoC, and it was
>>directly based on a set of requirements that they developed for their
>>LIS vendor when they migrated to Voyager (of course, the vendor totally
>>ignored them). And the folks at the LoC sure do know their MARC.  :-)
>>    
>>
>OK ... I'll check this out as well.  Thanks!
>
>Cheers,
>
>  
>

--
Sebastian Hammer, Index Data
[hidden email]   www.indexdata.com
Ph: (603) 209-6853



_______________________________________________
Koha-zebra mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/koha-zebra
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CQL queries into MARC records (Was: .abs file and subfield ordering)

Sebastian Hammer
In reply to this post by Paul POULAIN-2
Hi Paul,

I've developed a lot of systems for both end-users and professionals
over the years. Unlike Mike, I don't believe there are really any
circumstances where you'll want to let end-users loose with CQL, anymore
than you do with SQL (let the query language flame wars begin).

If I were building a query interface for Koha for either type of users,
I would use YAZ's CCL parser as the starting point. It is flexible
enough to provide a basic query language that feels to most users like
the google one, but it also is a naturally comfortable way for
professionals to express arbitrarily complex queries. I'm *assuming*
that Mike's API exposes YAZ's client-side support for CCL? Ortherwise,
it should.

(CCL is an ISO/NISO standard which hasn't received much attention after
the advent of forms-based web interfaces, but it's still a language that
comes very naturally to most librarians).

Configuration info at http://www.indexdata.dk/yaz/doc/tools.tkl#CCL

For the default search, I typically use an 's=al' if I'm searching
arbitrary targets.. this turns a list of words into an and-list, which
typically provides similar responses to what the user expects.. it can
be overriden by the use of "", in the way you'd expect. You specify
preconfigured fields using field=someterm, similar to CQL. But I believe
the vast majority of librarians (at least the ones I've met) would be
happier FOR MOST PURPOSES with a comprehensive list of mnemonic index
names than an ability to address MARC fields directly. Most librarians
like MARC, but they're not fanatics.

The CCL parrser of course also supports truncation, paranthesises, and
the use of boolean operators, all of which are configurable to allow for
different languages (well, except the paranthesises). Even better, if
you decide you'd like to search different targets at the same time as
you search your local server, it is an easy matter to provide different
configurations for each target to allow for different USE attribute
mappings, search capabilities. In fact, the YAZ CCL parser is at the
heart of every single metasearch solution we have deployed in the past
8-9 years or so, and it's proven really excellent for the job of
tayloring queries to different, more or less cooperative targets.

There's presently no obvious way of directing searches directly at named
subfields in CCL.

--Sebastian


_______________________________________________
Koha-zebra mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/koha-zebra
Loading...