Rwp03: RSM changes

[Ray Plante]

Hi Tony,

On Tue, 27 May 2003, Tony Linde wrote:
> As it was in UK, but more like the end of a seven-day week (and beginning of
> another) for those of us preparing the AstroGrid-2 bid to PPARC. (I
> shouldn't really be spending time on this!)

(BTW, if it would be better for you, we can table this and the identifier 
threads till when you're out from under the proposal grind.  Just give us 
the high sign over here.)

> Me too. Let me play devil's advocate and ... (I've cut the text here into a
> separate email)

See separate response.

> > motivation.  Do you expect that people will want multiple ways of
> describing 
> > themselves (i.e. saying the same thing with different schemas), or are 
> > you trying to address the issue of different resources types will need a 
> > different set of vocabulary to describe themselves?  
> 
> Yes :) ie, both
> 
> > Perhaps you could give an example of the situation you want 
> > to address.  
> 
> Catalog, image collection, data copier, Sextractor, generic visualisation
> service, cube extraction, ...

I think these fall into the latter catagory.  I don't see a need for 
supporting multiple schemas for saying the same thing.  With OAI, 
muliple metadata formats allow one to describe entities using either a 
cross-disciplinary schema (OAI Dublin Core) or one or more 
community-specific schema.  VOResource and its extensions are meant to be 
our community-specific schema.

> > example, I envision that a description of an SIA service will 
> > use the VOSIA schema, which extends the VOResource schema.  
> 
> If you're saying, Ray, that different resources will supply generic metadata
> and then supply resource-specific metadata then that is what I'm saying - I
> think. This is the first I've heard of 'extend[ing] the VOResource schema'.

See slide 5 of my PP presentation at the Cambridge meeting 
(http://www.ivoa.net/internal/IVOA/InterOpMay2003ResReg/VOResource.ppt).

> But we need to regulate the extensions to the VOResource schema otherwise
> everyone creates their own - which is why I proposed standardised SMF
> schemas.

Yes, this is my expectation.  Each extension should go through the 
standards process.  Service-specific metadata would usually be defined as 
part of a standard service specification (e.g. SIA which defines a list of 
metadata to be included in the registry; see slide 8 and SIA V1.0).  

I don't think it is useful to define special metadata for one-of-a-kind 
services (say, for example, a galaxy morphology compute service) for 2 
reasons:
  *  No one will know what to do with the information (from an automated 
     sense).  
  *  If think of metadata as variables containing values, they are only 
     useful when they vary between implementations.  If there's only one 
     implementation, you don't need the metadata.
Any special information about a one-of-kind service can be described in 
the human-readable document pointed to by ReferenceURL.  

The extended service metadata describe general classes of services.  This 
may be a specific standard service (like SIA) where there are many 
implementations, or something more general, like a Web Service (see slide 
6).  

cheers,
Ray