[Koha-devel] Searching and ILL (from: Searching Group Meeting Notes)

[Joshua Ferraro]

Thanks for your reply MJ. Here's my response:

On Sun, Aug 07, 2005 at 06:31:20PM +0100, MJ Ray wrote:
> Summary:
> 1. Referring to practical problems as ideology looks like trying
> to polarise the discussion, even if it's not.
I disagree that there are practical problems with CQL. I think that
the problems raised with RSS vs RDF rarely impact real-world usage
of what is referred to as 'RSS'. These standards are more alike than
they are different (the same goes for OpenSearch and SRW/U).

> 2. CQL default for advanced search, att:val for simple search.
As I wrote, I'm all for supporting att:val. However, note that
it's not any more difficult to use than CQL's att=val.

> 3. Implement as few search engines as possible, translate to/from
> any other similar ones.
Agreed.

> 4. OpenSearch should be supported, but not with its own engine.
Without an OpenSearch engine we cannot access most OpenSearch Sources.

> I'm sorry that Joshua has missed the points I'm trying
> to make.  This is best shown by describing some of them as
> "ideological". If you think any of this is ideology, please ask
> me to explain it further. I've no great love for namespaces
> for their own sake. I love what they allow us to do and hate
> the problems they solve.
>
> Some specific comments:
> 
> Joshua Ferraro <jmf at liblime.com> wrote:
> Unfortunately, CQL barfs on some every day searches because it
> reserves too many words and symbols (exact for mathematicians,
> for example).  It seems a long way from "do what you mean"
> for web-opac users.  For that reason alone, I think it should
> not be the default for searching. Can it be the default for
> "advanced search" only?
My conception of the searching in Koha will be that the 'simple'
search page will have a single input box that will take all the
query syntax that it's given. Then, if a user wants a 'guided'
search interface they can click on 'advanced search' and they
can point and click to choose fields/relationships to perform
their search.

> What would persuade you to accept it as "well-defined"? Here are
> three definitions of the style:
> 
> http://www.altavista.com/help/search/syntax
> http://www.gigablast.com/help.html
> http://www.google.co.uk/help/basics.html
I agree that it's a nice simple syntax. I disagree that it's
more difficult than CQL's att=val.

> Those other search types aren't directly expressable. I don't
> think many ordinary users want them (feel free to prove me
> wrong), as evidenced by the complaints in your reference:
Well, it's true that ordinary users won't use them but they
are critical for serious research purposes when dealing with
large datasets. I think the Library Journal article I cited
is a great example of how keyword and 'simple' searching can
be inadequate. My assumption is that part of the role of the
librarian is to understand the ILSes syntax and teach patrons
how to use it to maxamize the effectiveness of their research.

For reference, the Library Journal article is here:

http://www.libraryjournal.com/article/CA623006.html

> That's largely independent of the default syntaxes, though. If
> anything, I think offering a web-search-like subject:English
> subject:dialect way in the default will make using catalogue
> headings more popular. (I've already seen some searches which
> check web page returns against VLib and the Open Directory
> to suggest subject headings, which can be a big improvement.
> It would be even better if we had more librarians, but wouldn't
> lots of things?)
I agree that Koha should support subject:English subject:dialect.
But I disagree that CQL's subject=English subject=dialect is
more difficult for patrons to use.

> A syntax which can do all of the advanced searches is needed
> for the advanced search, but please don't curse web-opac users
> with poor usability. Give them an obvious syntax for today.
> If it's easy to translate att:val to CQL, then yippee!
It's easy ... just replace the ':' with a '=' ;-)

> > [...] So I propose that Koha
> > support all three of the major standards for record sharing to
> > maximize the number of clients that can access the database.
> 
> I agree with that and I suggested a possible way to do this
> with translators, which would avoid having to maintain three
> more external interfaces to Koha's catalogue (and more later).
> What do you think?
Could you expand on your idea? I didn't mean to suggest that we
maintain three more external interfaces to Koha's catalog. What
I would like to see is a single OPAC interface that was able
to display multiple source listings similar to the way that
Amazon.com's A9 search works.

> It's no easier to implement than doing the right thing (RDF),
> which would help show Koha seriously supports the Semantic Web.
> 
> It's only marginally harder to implement the right thing and then
> add OpenSearch's bugs. If they're as responsive as you suggest,
> then we'll strip the bugs away over time and we should have
> the benefit of being able to add support for other Semantic
> Web searches easily. Can we do it that way?
I see no reason not to read OpenSearch sources as RSS 2.0 sources.
I also see no reason not to include our use of the OpenSearch
namespace within a RDF DDT. These two are more alike that
different.
> [...]
> > I grok the Perl analogy and I agree that RSS 2 namespaces aren't
> > ideal. The problem is that OpenSearch is widely adopted and if
> > we want to tap into those sources we'll need an OpenSearch 
> > search and retrieval engine.
> 
> Not necessarily. We only need an OpenSearch interface, as above.
> If we add an entire engine for each external search protocol,
> we're probably going to drive developers insane.
The engine isn't difficult to implement. We'll already have
support for Z39.50, SRW/U and everything else that Zebra
supports. Adding OpenSearch support to Zebra would be a
single day process.

> > > do any other search engines use opensearch yet? 
> > Yes ... lots. Peruse through the 'columns' section of the 
> > opensearch.a9.com site and you'll see many many search engines
> > that have adopted the standard. [...]
> 
> If you don't know, please just say you don't know. There's no
> "columns" section on that site, but a little digging shows 253,
> mostly specialised web search engines. Maybe useful after all.
Sorry you didn't understand what I meant. In A9 searching, 'columns'
is the term use to describe the sources that are available (since
each source is displayed in a different 'column' when results are
returned). Note that this would not be viewable from lynx or any
other command-line browser ;-).

Cheers,

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