Data and services

[Doug Tody]

On Fri, 12 Sep 2003, Tony Linde wrote:

> I'd forgotten about Coverage. Maybe SkyService should stay so that when
> solar and stp people create their schemas they can have a SolarService and
> STPService.
> 
> Maybe we need a DataService which includes a pointer to the root data
> collection plus any other data-ish metadata and then SkyService,
> SolarService and STPService can inherit from that?
> 
> And should Coverage be renamed to SkyCoverage? Or is there enough
> commonality between 'coverage' in the disciplines to deal with the
> differences with one or two optional elements?

Thanks Tony, this helps make the point I was trying to make earlier.

In principle we can have any number of services which we wish to register
and describe using a general registry framework.  The registry framework
should be dynamically extensible to allow new services (service types)
to be added.  At most the registry should identify categories of such
resources.  Anything else, such as a new type of data access service,
or the metadata used to describe such a service, is essentially "data"
which is being added to the registry.


> Maybe we need a DataService which includes a pointer to the root data
> collection plus any other data-ish metadata and then SkyService,
> SolarService and STPService can inherit from that?

It is not that simple of course, as a DataService may well serve data
from multiple data collections, or may generate virtual data not belonging
to any data collection.

Trying to build too much structure into the registry framework itself
is probably a mistake.  Try to make it fairly general and let the services
(or other resources) describe themselves.  At most the registry should
define some standard categories of resources, and some minimal standard
metadata (such as RSM, category, service type, etc.) which is used to
characterize each resource instance.

Doug