#508: Combined SPIRES/Invenio syntax queries
------------------------+-----------------
Reporter: tbrooks | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: WebSearch | Version:
Resolution: | Keywords:
------------------------+-----------------
Comment (by simko):
Yes, it can be somewhat dangerous to do it for every existing SPIRES
search operator, e.g. `ps` comes to mind. When people type `not ps`
in Google style, do they mean to start the SPIRES search operator, or
an abbreviation for Proton Synchrotron, or picoseconds? The parser
would have to try to be smart by context-guessing (which can fail, and
it is always annoying to users if computers try to be too smart), or
it would have to provide a way to "escape" reserved words e.g. by
quoting (which can work, but leads to learning "new" syntax, as it
were).
Note that SPIRES and Invenio syntax combinations mostly work right now
if done in reverse order, i.e. `find author ellis, j and title:quark`.
Though this requires the presence of leading `find` that was only
optional in SPIRES and that many people do omit...
A simple alternative to always passing via SPIRES syntax compatibility
mode would be to attempt to guess when SPIRES more should used,
e.g. by looking at the presence of substrings such as
`space-author-space`, `space-t-space`, `space-ps-space`,
`leading-a-space` and the like. When found, then leading `find...`
would be added to the query so that users see it that way. This is
not fully working solution either, as it require guessing that can go
wrong, but it is an ultra simple thing to implement that can catch a
good number of SPIRES style queries, while educating users about the
leading `find` at the same time. If we want to preserve this
`find`-based SPIRES-syntax mode trigger for the future, then it can be
a simple alternative to offering free mix-up of both styles. And it
may be a cleaner alternative perhaps, since more explicit about
behavioural differences concerning quotes, parens, regexp slashes,
matching types, and the like.
Thinking about whether it may be advantageous to keep-and-underline,
or to abolish, the leading `find`...
--
Ticket URL: <http://invenio-software.org/ticket/508#comment:1>
Invenio <http://invenio-software.org>
