Drop SkyService?

[Tony Linde]

> out.  I didn't 
> worry about this, because (for one) the user interface to the 
> registry could handle this conveniently.  For example, our prototype 

Good point, Ray.

> In any event, our model needs to allow for the following:
>    *  a data collection might be accessible my multiple services
>    *  a service may access multiple data collections.

I think in these cases the registry will need to use the Relationship route.

Anyway, as Tom has shown, we do need to cater for both cases, where a
service includes the source metadata *and* where it refers to it by
Relationship.

What do we do if a SkyService includes the 'CanQuery' (or whatever)
relationship? Do we search both coverage metadata for the SkyService *and*
the DataCollection it is related to, or specify that if both are present,
only one is searched?

Cheers,
Tony. 

> -----Original Message-----
> From: owner-registry at eso.org [mailto:owner-registry at eso.org] 
> On Behalf Of Ray Plante
> Sent: 26 September 2003 19:41
> To: registry at ivoa.net
> Subject: Re: Drop SkyService? 
> 
> 
> Hi Tony,
> 
> Your suggestion would be fine.  One ramification is that if 
> one wants to 
> provide the coverage info, one must register the collection 
> explicitly.  
> 
> One intention behind the various resource classes is that, in 
> principle, 
> a provider would only need to register those resources he/she 
> cares to.  
> One would not be required to register, for example, an 
> organization or a 
> data collection to register a service.  However, by doing so, 
> one could 
> provide richer information, particularly with respect to 
> relationships.
> 
> This can lead to some duplicated information as you point 
> out.  I didn't 
> worry about this, because (for one) the user interface to the 
> registry could handle this conveniently.  For example, our prototype 
> registry (http://nvo.ncsa.uiuc.edu/nvoregistration.html) 
> allows one to 
> register a service by starting with a copy of the DataCollection 
> description it accesses.  
> 
> In any event, our model needs to allow for the following:
>    *  a data collection might be accessible my multiple services
>    *  a service may access multiple data collections.
> 
> cheers,
> Ray
>  
> 
>