Resources = services!

[Ray Plante]

(what is the opposite of devil's advocate?)

On Tue, 27 May 2003, Tony Linde wrote:
> Following on from Ray's response to my RSM comments, I'd like to make a
> proposal...
> 
> The *Resource Registry* should only store details of resources which can be
> invoked and can perform actions of benefit to the caller (in general I would
> imagine such resources to be web or grid services but might be cgi scripts
> or other invokable scripts - applet, servlet?).

By "Resource Registry", are you refering to the "Full Registry" as defined 
in Keith's architecture proposal?  (If not, I might suggest your registry 
is misnamed: what you want is a "Service Registry", which would fall in 
the "Local Registry" catagory.)  In general, I'll assume you mean Full.

I disagree with this on several grounds.  

1. A General, Extensible model

   The main objection you raise is one of "clutter".  This is the question 
   of granularity which I don't think we, as a community, have an answer 
   to yet.  Our approach has been to start at the high level, 
   rough-granularity and extended to the finer-grain as necessary.  

   What's important for this is that our framework be general 
   and extensible.  Everything is a resource (not a service) provides the 
   generality.  Extendable schemas provide the extensibility. 

   One way to prevent every astronomer to be listed in this registry is 
   not to define an Astronomer extension.  Another is to disallow the 
   harvesting of Astronomer resources by Full Registries.

2. The Need for a Complete and Consistant Registry

   A Full registry, when it contains resources of all classes, provides a 
   complete and consistant picture of everything the VO knows about VO 
   components.  This is important, because it provides a roadmap for 
   understanding the origins of data.  For example, a Service description 
   includes a PublisherID pointing to the Organization or Project that 
   maintains the service; you can use that ID to get a description of the 
   Publisher (including the Web page and contact info).  If your Full 
   registry does not contain Organization or Project records, then you 
   need to go somewhere else to get this description.

3. Inclusion in a IVO-wide registry serves as a recognition of 
   IVO compliance.

   The registration of an organization or project can be the VO's way of 
   recognizing it as a legitimate scientific concern that can publish 
   legitimate data and services.  This bolsters the delegation of "trust" 
   (or more precisely, of "approval") described as part of our registry 
   model:  a publishing registry can "approve" a project with some care, 
   but then delegate the approval of its services to that project.  

   The prototype publishing registry at NCSA 
   (http://rai.ncsa.uiuc.edu/nvoregistration.html) requires that one first 
   register one's organization before registering any services.  
   Furthermore, the PublisherID for any service is constrained to be one 
   of the resources already registered.  Thus, this thread of recognition 
   is preserved.

   In our recent discussions of standard service metadata, we have talked 
   about registering the specification for a standard service (e.g. SIA).  
   Doing so provides a way of recognizing the spec as an accepted 
   standard.  

4. The cost of filtering out non-service resources within a registry query 
   is low.

   In the VOResource schema, service descriptions are clearly marked by 
   their root element: <Service>.  Thus, it is trivial to select only 
   services in a registry query.  I would give an example; however, I 
   would have to assume a DB implementation or a registry QL.  Just think, 
   "select Services where ...."

   Given this, it would be very easy to implement a "Local" Service 
   Registry, and you wouldn't need to replicate any part of the Full 
   registry.  You would just implement an interface that automatically 
   puts this filtering constraint onto any queries.  Thus, this is just an 
   interface issue.  

I sense that the cost to users, which I address in (4), is at the heart of 
Tony's desire to only include services in the registry.  I really think 
this is a non-issue.  The benefits of the general, extensible approach, 
therefore, should not be thrown away.

cheers,
Ray