new RI document

[Paul Harrison]

On 16.06.2006, at 15:38, Robert Hanisch wrote:

>> 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.
>
yes, but crucially *not* to the standard interface, but as an  
extension interface. This means that people can write "aggregating"  
applications that query many services and get consistent results - it  
is one of the promises of the VO that we are trying to provide  
uniform interfaces to data to allow just such applications. If a  
particular implementor thinks that he has a smarter way of searching  
the registry - such as the semantic search that you suggested then  
they can publish that as an extra interface with a  
semanticKeywordSearch() call - if it becomes popular  then it could  
possibly be incorporated in future versions of the registry interface  
standard.
> I agree -- keep the interface simple.  But this does not mean that one
> implementation or another must give identical results.

I still think it is pretty unintuitive that different instances of a  
simple service like the registry to return different results for a  
simple call like keyword query,  when there are standards covering

1. the programmatic interface
2. a data model for the contents
3. a harvesting mechanism for replicating the content between instances

it is only the "optional" parts in 1 for the keyword search that  
allow this.

I know that this view is in part coloured by what I conceive the  
registry to be - for me it is simply a service that other services  
can query to find resources - not an end-user tool at all, and so to  
build services on top of it, the registry needs to be deterministic.  
However, if it is expected to be an end user tool in itself then the  
more "fuzzy" matches are appropriate - but perhaps the solution to  
this is to include both these styles of query call in the standard  
interface and be explicit that for the simple keyword search is  
expected to use a fixed algorithm and the fuzzy keyword search can  
use whatever algorithm they feel appropriate.

Paul.