metadata

[Paul Harrison]

On 30.04.2007, at 04:54, Doug Tody wrote:

> Hi Paul -
>
>
> All of this is true, and I have no problem with caching service
> metadata in the registry, automatically updating it as it changes,
> providing for detection of cache errors when they occur, monitoring
> service function with getAvailability, periodic service verification,
> etc.  There are many grid use-cases which will rely upon this sort
> of thing to function efficiently.
>
> Nonetheless, it is desirable for services to be self-contained
> (able to function without an external client such as the registry),
> and self-describing.  A similar issue pertains to any resource
> which is directly managed by a service, e.g., a collection of
> individual datasets.  If the service manages the datasets, tracking
> changes, mediating metadata, etc., it should be the source of any
> information describing the datasets, regardless of whether this is
> cached externally.  In the case of a data collection described as a
> single entity, the "service" responsible for the information is the
> registry itself, which manages information which is again cached by
> other clients, e.g, another registry.

This was essentially the thinking behind the getRegistration method  
of the VO standard interfaces - the service itself is the the best  
place to manage the metadata, but the registry is the best place to  
distribute the metadata, and a client should get the same answer when  
asking either source.
>
> If everything were static this might not be an issue, but the need
> to manage such information carefully becomes more clear when we  
> consider
> use cases such as services which are dynamic, e.g., accessing virtual
> data (where the external description of the data can only be resolved
> by the service which generated it), or other forms of dynamic data,
> such as a TSAP service which accesses a theoretical model.
>

This can lead to a philosophical discussion on what is metadata, and  
what is data - and involves the the fine-grained-ness of the registry  
entries, but it is clear that at one end of the spectrum there is no  
point in registering metadata about every data item in a VOSpace as  
then the registry becomes VOSpace, so they no-longer separate  
concepts (and maybe at some time in the distant future the registry  
could be considered just a corner of VOSpace). However, near the  
other end of the spectrum there is no point depriving clients of  
basic information necessary to interact with a service - if a client  
is trying to discover whether there is a STAP service with tables  
that contain a column described by particular UCD, there is no point  
in forcing the client to query every registered STAP service when the  
information could be discovered in one call to the registry. What I  
guess I am saying is for the class of S*AP protocols, they are  
'simple' enough that there should be no metadata that is not static.


Paul Harrison
ESO Garching
www.eso.org