Use Cases for new Registry search interface

[Paul Harrison]

On 2011-05 -23, at 19:05, Ray Plante wrote:

> Hi RWGers,
> 
> At Naples during our future directions discussion, we talked about a new 
> Registry search interface, and there was a call to collect use cases and 
> requirements.  This includes collecting the kinds of queries we would like 
> to be able make and process easily.  
> 
> I've taken the liberty of creating a page for this called 
> RestfulRegistryInterfaceReq 
> (http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/RestfulRegistryInterfaceReq) 
> and seeding it with some of the tidbits I've collected from various 
> discussions.  This page is open for further edits:  please add new items
> or comment on the ones that are there, including:
> 
>  o  sample queries to support
>  o  output formats
>  o  interface features
> 
> thanks,
> Ray
> 


Hi Ray,

that page seems like a pretty good summary to me.

One complaint that we have often heard with the simple "keyword" style searches is that different registries ended up giving different answers - I think that this is probably a consequence of the "registry data model" not being tightly enough defined - we defined the data model with XML schema and had a rather loose mapping to a possible relational model. I think that if we are to have consistency we need to be able to express the  "keyword" style queries directly in whatever the lowest level query language is, so that the "keyword" style interfaces are merely convenience interfaces that are defined formally to run a specific query in the low level query language.

Personally I think that if anything is going to be changed then a full relational registry data model should be attempted that can then be queried with TAP, and then TAP implementations can pretty directly be used as Registry implementations.

I think that there are two consequences of moving to a more TAP based registry data model.

1. We loose some of the ease of extensibility (the X in XML!). With the AstroGrid registry, because we chose to implement it as a native XML database, we could be very agile when it came to trying out new types or extensions of resource records - it was essentially zero configuration - the XML database would simply swallow them up, and they would immediately be available for querying.

2. If we change to a relational data model then we probably should stop using XML schema to describe the registry model... which does have consequences for existing standard registry extensions - I think that we should at least come up with a full model of all the existing resources an extensions, as partial models will still end up with implementation inconsistencies as we have already seen.


Paul.