Search Query Syntax
Ross Singer
common search syntax.
What I mean here is beyond the OpenSearch description document, but
actually identifying how to construct specific searches within a given
resource (such as a date span or some such). My initial impression is
that OpenSearch's parameterized query syntax is too limiting and not
terribly scalable in this context (although I'm open to somebody that
can give arguments to the contrary).
Instead, I'm proposing an alternative query syntax to put in the
{searchTerms} URL parameter.
An obvious (although possibly non-trivial) choice would be CQL. This
would allow for more complex queries (if desired), but give a default
fallback of keyword terms if no index or relation is provided. The
downside is that, without an explain document, how would anybody know
what indexes/relations are defined (although this is true of _any_
search syntax)?
Another option would be something on the order of Lucene's Query
Parser Syntax, which, while not any sort of official standard, has
definitely become a de facto standard for searching.
And, of course, there's the option of rolling our own, but I would
like to avoid that all costs. If the discussion around how to make
things available via GET gets as little response as it does, I hate to
think about the level of interest in building a query language :)
Anyway, food for thought.
-Ross.
Mike Rylander
>
> It would be helpful, in my mind, if Jangle implementations had a
> common search syntax.
>
> What I mean here is beyond the OpenSearch description document, but
> actually identifying how to construct specific searches within a given
> resource (such as a date span or some such). My initial impression is
> that OpenSearch's parameterized query syntax is too limiting and not
> terribly scalable in this context (although I'm open to somebody that
> can give arguments to the contrary).
>
> Instead, I'm proposing an alternative query syntax to put in the
> {searchTerms} URL parameter.
>
> An obvious (although possibly non-trivial) choice would be CQL. This
> would allow for more complex queries (if desired), but give a default
> fallback of keyword terms if no index or relation is provided. The
> downside is that, without an explain document, how would anybody know
> what indexes/relations are defined (although this is true of _any_
> search syntax)?
CQL seems natural to me, and
http://www.loc.gov/standards/sru/cql-bibliographic-searching.html (see
http://www.loc.gov/standards/sru/cql-bibliographic-searching.html#table
for a summary of indexes) seems a reasonable default context set.
Even searches of a user database could be reasonably mapped to the
majority of those index groups.
>
> Another option would be something on the order of Lucene's Query
> Parser Syntax, which, while not any sort of official standard, has
> definitely become a de facto standard for searching.
>
> And, of course, there's the option of rolling our own, but I would
> like to avoid that all costs. If the discussion around how to make
> things available via GET gets as little response as it does, I hate to
> think about the level of interest in building a query language :)
>
> Anyway, food for thought.
>
> -Ross.
>
> >
>
--
Mike Rylander
| VP, Research and Design
| Equinox Software, Inc. / The Evergreen Experts
| phone: 1-877-OPEN-ILS (673-6457)
| email: mi...@esilibrary.com
| web: http://www.esilibrary.com