RofR

[Tony Linde]

> No, for an extensible system you cannot have a default of 
> "All" - ...

Yes you can if your system is capable of storing data in any schema. And
that is what I expect from what we've termed 'full' registries. The registry
does not have to understand the schema just store it - this can be done
whatever the schema.

> ...registry should not harvest records with namespaces 
> that it does not understand.

I agree. If a registry is only going to send back data for certain schemas
then it ought not store and serve up such data partially.

But a registry *could* choose to store only the voresource part of a record
and, if a user entered a query which matched that record, could then pull
the whole record back from the owner registry and serve it back to the
client unchanged. How we indicate to the user agent that the registry is
full from the resource point of view but not from the extension pov I don't
know.

Cheers,
Tony. 

> -----Original Message-----
> From: Paul Harrison [mailto:pharriso at eso.org] 
> Sent: 12 April 2005 10:28
> To: Tony Linde
> Cc: 'Ray Plante'; registry at ivoa.net
> Subject: Re: RofR
> 
> Tony Linde wrote:
> > 
> > Going on to Matthew's point, some registries can only search on 
> > specific extensions, so we'll need to be able to list the schemas 
> > supported by those registries (default is that all searches 
> are enabled).
> > 
> > Sound right?
> > 
> 
> No, for an extensible system you cannot have a default of 
> "All" - you need always to list explicitly the things that 
> you support, otherwise someone adds a new exension that you 
> do not know about (and do not
> support) and you would still be claiming with the default 
> "All" to support it.
> 
> It would probably need a list of namespaces that the registry 
> supports to make this distinction. However, this also has 
> implications for the harvesting - to avoid getting partial 
> records a registry should not harvest records with namespaces 
> that it does not understand.
> 
> The current situation is problematic
> 
> Consider this CEA resource
> 
> http://galahad.star.le.ac.uk:8081/astrogrid-registry/viewResou
> rceEntry.jsp?version=0.10&IVORN=ivo://org.astrogrid/JBORealCEC
> 
> it has an extension that lists the Applications that the 
> server can run
> - the cea:ApplicationReference elements
> 
> 
> This has been harvested into the STSCI registry as
> 
> http://nvo.stsci.edu/voregistry/registry.asmx/QueryVOResource?
> predicate=identifier%3D%27ivo%3a%2f%2forg.astrogrid%2fJBORealCEC%27
> 
> i.e. has lost all of the important extension information - it 
> would be 
> better not to find the resource at all in the STSCI registry, than to 
> gain a false impression of the capabilities of the resource 
> in the CEA case.
> 
> Carnivore does contain a correct record - It is just not so easy to 
> provide a URL that will point to the record. Search for JBORealCEC in 
> the simple search interface.
> 
> I think that the only practical course at the moment is to store the 
> necessary metadata about registries that describes their differences, 
> rather than mandate that all of them are the same. This does not 
> preclude a future where all registries are equally capable, 
> but allows 
> us to interoperate now.
> 
> -- 
> Paul Harrison
> ESO Garching
> www.eso.org
>