What is the expected procedure for diagnosing and documenting
unsupported SRU server features?
As I have alluded to previously, Ed S. has written two object oriented
Perl modules implementing much (if not all) of SRU and CQL. See:
http://search.cpan.org/dist/SRU/
http://search.cpan.org/dist/CQL-Parser/
Using these modules I have gone a long way in implementing an SRU
server:
http://alert.ockham.org/sru-server.cgi
My next steps are to:
1. create a more robust ZeeRex record for my
explain operation documenting what features
my server supports
2. trap unsupported features that are requested
anyway and return the appropriate diagnostic
For better or for worse, my underlying search engine is swish-e:
http://www.swish-e.org/
(Incidentally, my particular implementation does not hard code the use
of swish-e. The interface to swish-e is supported through a toSwish
method, and other indexers/search engines could be supported by writing
things like a toPlucene or toYourFavoriteIndexer modules.)
Swish-e supports much of what I desire:
* simple single-term searches
* multi-word searches implemented as Boolean and
* phrase searches
* Boolean logic
* nesting
* field (index) searching
* sorting
* a C, Perl, and a PHP API
Unfortunately, the swish-e search interface does not support much of
CQL. For example, it does not support:
* exact match (exact)
* proximity searches (prox)
* relations other than equals (<, >, <>, etc.)
* robust pattern matching except right-hand truncation
Consequently, I will document these features (or lack thereof) in the
ZeeRex record of my explain response, but what do I do when my server
gets queries like exact or prox anyway? I suppose I will have to trap
for these kind of queries and return appropriate diagnostics. No?
--
Eric Morgan
|