new RI document

[Robert Hanisch]

I have to agreed with Ray here, but perhaps with a slightly different
rationale.  The VO is about defining interfaces, not about defining
implementations.  If we require registries to return identical results for
keyword searches we are crossing a line.  It is not just about which fields
should be searched, but about things like stemming, variants, anticipating
spelling errors, etc.  Does a search on "planets" also return results for
"planet"?  Does "stars" equal "stellar"?  "Galaxy" equal "galactic"?  An
easy answer is no, the search string is a literal and that is it, but good
search engines do much more than this, and I don't think VO standards should
inhibit implementers from providing such capabilities.  I would not expect
the AstroGrid registry to give me identical results to an NVO registry,
anymore than I would expect Sextractor to give me identical results to
DAOPhot.

> Indeed - I am all for innovation, and the new 1.0 services
> registration  model would allow for a registry to do precisely that -
> if they want to implement a better search, then they can publish an
> extra interface that does the better searching, whilst still doing
> the standard stuff (and no more) in the standard interface.
> 
> The whole motivation for the keyword search operation is simplicity -
> it is simpler both for the implementor and the client user if the
> list of fields searched is closed and fixed.
> 
> It is a common complaint amongst client software writers that IVOA
> services have too many "optional" features and the "core" of the
> service is too weak e.g. David Schade's comments on http://
> www.ivoa.net/twiki/bin/view/IVOA/InterOpMay2006Architecture - and
> there are more who share this view...

But your argument above suggests adding an optional feature.

I agree -- keep the interface simple.  But this does not mean that one
implementation or another must give identical results.

Bob