Rwp03: RSM changes

[Tony Linde]

Hi Ray,

> (BTW, if it would be better for you, we can table this and 

No problems. These debates are my _relaxation_ :)

> ... 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.

Ah, right! But one could imagine a service that performed a service that
crossed several boundaries (eg, provided catalog information *and* performed
image cutouts, say) so we should allow one service type to choose to supply
other SMFs.

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

Oops! Must have been writing one of the proposal docs.

> 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 

Agreed. But the RSM/RM doc, if it is to become a standard, must identify how
SMFs fit into the overall registry schema and the process for documenting
them.

Then again, should we allow non-standard MFs which are separately
namespaced? Thus, s/w which understands the namespace could make use of it.
Needs more thought.

Cheers,
Tony. 

> -----Original Message-----
> From: Ray Plante [mailto:rplante at poplar.ncsa.uiuc.edu] 
> Sent: 28 May 2003 04:50
> To: Tony Linde
> Cc: registry at ivoa.net
> Subject: RE: Rwp03: RSM changes
> 
> 
> 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/VOReso
urce.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