notes from Session 1 of Interop

[Paul Harrison]

Some comments from afar...
On 2010-05 -19, at 18:17, Ray Plante wrote:
>
> The Search interface
>
>    * See Mark's slides for the Topcat experience
>          o Mark uses the ivoaregistry Java library which returns  
> results
>            in DOM; the memory requirements can be quite large
>          o One UKIDSS record is 11 MB
>          o He replaced the DOM part with SAX streaming to extract  
> the few
>            things he was interested in
>          o He offered to make this code available
>    * Interest was expressed in his SAX streaming; Ray would like to  
> get
>      it into ivoaregistry.
>    * A common use case for applications is to extract a small part  
> of the
>      description in a light-weight way. Any new search interface we
>      consider should allow the client ask for the desired items.
>

When it comes to the registry search interface, I think that we should  
finally drop the notion that still seems to be prevalent that the  
registry service itself might ever be used directly by end user  
astronomers - the registry should be thought of only as a service that  
other software tools can use to locate other services/tools/data. Any  
useful end user "astronomy google" is going to have to aggregate other  
services (e.g. footprint services) and generally act as a mediator of  
the metadata that exist in the registry to enable the astronomer to i)  
make queries in a natural language ii) have the results presented in  
an understandable form. So a tool like Topcat just presents registry  
services to the end user as "find TAP services with Sloan data" or  
something similar, and the end user does not need to understand the  
complex relations between the metadata necessary to make this search -  
that said, the requirement from tool writers is that the registry  
query language be as complete, precise and flexible as possible.

> Registry Interoperability
>
>    * Mark: serious problem with Euro-VO registry: use of LIKE in ADQL
>      searches are case-sensitive.
>          o errata to RI on this point?
>    * dynamic discovery of Registries via the standard search  
> interface is
>      apparently broken with all registries.
>
> Ray:  Current assessment of full constraint-based search interface:
>  - Current based on deprecated version of ADQL
>  - Certain kinds of query not possible
>  + searching on any item is possible without change to standard
>
> New search interface should include:
>  + searching on any item (or future item) without change to standard
>  + from Mark: ability to select what information to return
>
> Possible directions:
>  o  push XQuery for relational databases
>  o  VOExplorer's Google-like syntax (title:LMC ability:TAP)
>      +comment: it is sufficient to expose this at the tool level;  
> rather
>                than server interface level.


In Astrogrid we asserted long ago that as the registry data model was  
essentially expressed as XML schema, then the natural choice for the  
query language was XQuery, and I think the experience of the  
intervening years has only strengthened this view. I believe that the  
inconsistencies between the registries are as a result of the  
difficulties and ambiguities of mapping the XML model to a relational  
model.

Anyway whatever the choice of query language, it should be at the  
XQuery end of the spectrum rather than the "natural language" end, as  
we need all registry implementations to return the same answer to the  
same query if we are to achieve interoperability.

Paul.