[Koha-zebra] Re: CQL queries into MARC records (Was: .abs file and subfield ordering)

[Joshua Ferraro]

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 <address@hidden>
> > 
> > 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
address@hidden |Full Demos at http://liblime.com/koha |1(888)KohaILS