More separation

[Tony Linde]

My turn to catch up... I'll try to answer various emails and then cut a new
version of the model page and diagram.

> Thus, it must be possible for a service to sufficiently 
> describe the dataset it accesses (e.g. its coverage) since a 
> separate description may not exist.  

This shouldn't be an issue. We don't want data repeated because that'd make
searches very difficult. We shouldn't have users directly creating the xml
records. As long as there is a software interface between the user and the
storage of the metadata, creating the separate description is not difficult
and certainly no burden on the user (and, loing-term, a much less burden on
the developer).

> sub-type: ConeSearch, SimpleImageAccess, SkyNode.  Thus, if 
> you have a catalog that has both Cone Search and SkyNode 
> interfaces accessing it, it is not possible to describe both 
> those interfaces in a single record.  

I would classify the ConeSearch, SimpleImageAccess & SkyNode as separate
services. An interface is where a ConeSearch can be invoked both through cgi
and web service interfaces.

> DataScope needs to search the registry for all Cone Search 
> and SIA services.  To have the different service types 
> combined together complicates the view of the registry.  It's 

I agree, but these would be separate services in my terminology, not
interfaces to the same service.

Do we need a term intermediate between service and interface? In my model, I
had a service providing access to a data collection and assumed that such a
service could be of the sub-types Ray mentions but that a single such
sub-type service might be accessed in different ways, e.g. cgi or web
service (or have an interactive interface). It was the latter that I thought
could be a repeating group element in the service definition rather than a
separate resource.

Is this a fair description of reality?

Cheers,
Tony. 

> -----Original Message-----
> From: owner-registry at eso.org [mailto:owner-registry at eso.org] 
> On Behalf Of Ray Plante
> Sent: 14 December 2004 06:48
> To: registry at ivoa.net
> Subject: Re: More separation
> 
> Hi all,
> 
> I had low bandwidth last week, so I'm trying to catch up now 
> on various discussions.
> 
> First, I think Guy's proposal is fine.  The motivation is 
> clear, and his extension builds on the intended spirit of 
> v0.9.  (In fact, way back in Cambridge, I suggested that we 
> may one day find ourselves needing a Table resource).  I 
> would strongly urge, however, that you go ahead and do the 
> trivial conversion to the v0.10 style.  
> 
> The notion of separating the description of a dataset from 
> services that might access it is not unknown to NVO.  That 
> is, we currently support the DataCollection resource type.  
> The main difference from the AstroGrid driver, where it is 
> important for a portal to be able to carefully sort out the 
> relationships between the services and datasets, is that in 
> NVO, the registration of the dataset separately from the 
> service is optional.  
> Thus, it must be possible for a service to sufficiently 
> describe the dataset it accesses (e.g. its coverage) since a 
> separate description may not exist.  
> 
> A stricter practice of separating descriptions of datasets 
> from the services that access them may be well motivated (I 
> certainly like the sound of it); however, a big concern will 
> be ensuring that our registration model remains simple enough 
> to explain quickly to the people responsible for actually 
> registering the resources.  Some of this can be mitigated by 
> an effective registration portal interface, but this takes work.
> 
> On Thu, 9 Dec 2004, Tony Linde wrote:
> > > interfaces.  Each of these requires a different entry in the 
> > > Registry, but they are all just different interfaces to 
> the same data.
> >
> > I don't see why separate interfaces to the same service would need 
> > separate registry entries. They aren't separate resources. 
> The service 
> > is one resource with multiple interfaces, so should be one registry 
> > entry with repeating interface descriptions.
> 
> Treating them as different resources is certainly allowed 
> within the definition given in the RM (sect. 2).  To say they 
> are not separate resources assumes some additional criteria 
> that is not stated in the RM. 
> 
> Although, as Gretchen mentioned, we are supporting service 
> descriptions with multiple interfaces, there are some snags 
> to consider.  In particular, certain "standard" services are 
> defined as a Resource
> sub-type: ConeSearch, SimpleImageAccess, SkyNode.  Thus, if 
> you have a catalog that has both Cone Search and SkyNode 
> interfaces accessing it, it is not possible to describe both 
> those interfaces in a single record.  
> There are essentially two reasons for why standard services 
> are resource sub-types.
> 
> First is that there is a separate set of specialized metadata 
> associated with each of these standard services.  These are 
> the so-called "capability" metadata for the service.  They do 
> not describe the interface (i.e. how you communicate with the 
> service) but rather its behavior (e.g. 
> maximum search radius supported; see ConeSearch-v0.3.xsd as 
> an example).  
> In order to describe multiple interfaces in a single record, 
> one must reorganize the standard capability information to be 
> definitively associated with the standard interface description.  
> 
> We could do the necessary reorganization.  In fact, this 
> would bring us closer to the organization used in v0.9.  
> However, the second reason for the current organization is 
> that we needed a very clear way of identifying standard types 
> of services (in v0.9 this was unclear).  For example, 
> DataScope needs to search the registry for all Cone Search 
> and SIA services.  To have the different service types 
> combined together complicates the view of the registry.  It's 
> less of an issue for the current CDS records because none of 
> the multiple interfaces (essentially interactive and generic 
> non-interactive versions) are one of the standard types.  
> 
> I recommend that we in general register different interfaces 
> separately, making use of the "service-for" relationship, but 
> that we look into two
> exceptions: 
>   o  registering an interactive version next to the 
> non-interactive one
>   o  providing alternate access URLs to the same basic interface.  
> 
> hope this helps,
> Ray
> 
>