Resources = services!

[Ray Plante]

On Wed, 28 May 2003, Tony Linde wrote:
> > 1. A General, Extensible model
> 
> Extensibility needs to be bounded otherwise it leads to chaos. You want to
> set the boundaries at 'anything to do with VOs' while I would argue to
> narrow that to 'anything in the VO which can be invoked and can perform
> actions of benefit to the caller'. SMFs or registry extensions would then be
> used to manage either extensibility.

Yes, that's all cool.  My point is that the framework must be extensible.  
It is a matter of policy and responding to new needs that guide how it is 
extended.

> But in your example it only provides 'a complete and consistant picture' to
> the level one up from the lowest, so your service has a pointer to the
> organization resource but the metadata for the organization, unless it is
> only curation metadata, would not lead to other resources - it all has to
> stop somewhere. 
> (Shades of Derrida and continual deferral of meaning - AstroDeconstruction?
> :) )

The PublisherID is the mechanism for capturing the hierarchy.  (For 
example, an Organization's PublisherID can be that of another, broader 
organization: e.g. NASA oversees HEASARC, SAO oversees the Chandra 
Archive).  Thus, you can have as many levels as desired.  It does mean 
that for any hierarchy there is only one top that does not refer to 
anything higher.  

> > 4. The cost of filtering out non-service resources within a 
> > ...
> >    In the VOResource schema, service descriptions are clearly 
> > marked by their root element: <Service>.  
> 
> Does this <Service> item include all of the items that I've referred to as
> services (catalogs, datasets, images, cube cutouts, extraction, data
> copying, etc...) and ONLY those items?

It includes all those resources that "can be invoked by the user to 
perform some action on their behalf" (RSM)--that is, anything with an 
interface.  This includes data access services.  This includes cutout 
services, image retrieval (e.g. SIA or current custom services that do the 
same), catalog access (e.g. ConeSearch, Vizier), extraction, copying, ....

In the VOResource schema, a "DataCollection" is not by itself a service.  
This is because the collection may support multiple services for getting
data from the collection.  This class has been identified as being one
needing further work (i.e. extending to add DataCollection-specific
metadata).  One thing I would suggest adding is a list of IDs that point
to services that can be used to access the service.  One question to
answer is when your dealing with a simple collection that is accessable,
say, by FTP, should this access be captured as part of the DataCollection
metadata, or should be it be rendered strictly as a Service.

> > I sense that the cost to users, which I address in (4), is at ...
> 
> Cost is only a part of it; it is more a matter of consistency. It doesn't
> seem worth bundling together information which doesn't even share the most
> basic of metadata: you wouldn't normally speak of 'curation' metadata when
> talking about an organization or an astronomer (cure maybe but not
> curation).

Perhaps Curation is a confusing label.  However, if you look at individual
pieces of metadata, they can, to my mind, just as describe an organization
as naturally as a service.  If you disagree with this, then you have a 
point.  

In contrast, one might claim that the Coverage metadata does not sensibly 
apply to an organization.  This is a good argument for removing it from 
the top-level metadata and restricting it to the DataCollection and 
Service extensions.  

cheers,
Ray