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

[MJ Ray]

Joshua Ferraro wrote: [...]
> > 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.

It is, because CQL reserves more words and symbols. At the least,
translations needs to escape CQL keywords from att:val and change
attributes to CQL syntax. But if that gets koha simple att:val
searching, fine.

> > 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.

I don't advocate dropping it completely. I say it's too complex
for the default search interface. I don't think most librarians
have enough spare time to teach every library user, so let's
offer users a simple search interface default which is similar
to the common web search.

As I wrote before, the keyword issue raised in that article
seems largely independent of the search box syntax. It's more
about what you're searching and how you index it.

> [...] I think that
> the problems raised with RSS vs RDF rarely impact real-world usage
> of what is referred to as 'RSS'. 

In other words, you don't think namespaces solve real-world problems?

Over five years ago now, I worked on a way of distributing
data in XML between universities. Some of us successfully
argued against a namespace for the basic format, because it
made the parsing more complicated and the libraries we were
using didn't help. The computer scientists objected strongly,
but we prevailed.

Over time, the partners in the network used the format in new
ways with new tags to support new features and, before long,
detecting the different sets became more trouble to support
than it would have been to support namespaces and we couldn't
get enough people to upgrade the systems deployed. The network
decayed and then died. Not just because of this, but it helped.

Just one anecdote, but namespaces help give future-proofing
and encapsulation.

> These standards are more alike than
> they are different (the same goes for OpenSearch and SRW/U).

RSS 2 ("simple") is RSS 1 ("RDF") with some bits we'd use
missing, some bits renamed and I think no bits we'd use added. It
seems easier to produce RSS 1 and miss some bits to produce
RSS 2 than it is to produce RSS 2 and add bits to make RSS 1.

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

So it's not possible to interface to OpenSearch without a custom
engine? I didn't notice anything in the protocol requiring that.
What does?

> > 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.

Ah, that's the other side of it, with koha searches being
translated into external source searches.

                                      ,-> SRWUOut
User <-> opac-search <-> SearchPool <-+-> Search (koha)
                                      +-> RDFSearchOut <+-> OpenSearchOut
                                      |                 `-> ISBNSearchOut
                                      `-> Z3950SearchOut

[...]
> Note that this would not be viewable from lynx or any
> other command-line browser ;-).

Why not? What have you or A9 got against accessibility?

-- 
MJ Ray (slef), K. Lynn, England, email see http://mjr.towers.org.uk/