More separation

[Ray Plante]

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