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/