Rwp03: RSM changes

[Tony Linde]

> It was a three-day weekend here in the States, so I didn't 

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!)

> I'm wondering about your use of the word 'service'  

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

> As you might recall from my presentation, the VOResource XML schema 
> identifies several classes of resources--organization, project, data 

I agree with the idea, but not with some of the types you identify
(organization, project etc.).

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

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

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

> I feel like this is essentially the roadmap that WP03 is on.

Excellent!

Cheers,
Tony. 


> -----Original Message-----
> From: Ray Plante [mailto:rplante at poplar.ncsa.uiuc.edu] 
> Sent: 27 May 2003 17:51
> To: registry at ivoa.net
> Subject: Re: Rwp03: RSM changes
> 
> 
> Hi Tony,
> 
> > I think that's enough for people to work on over the weekend :)
> 
> It was a three-day weekend here in the States, so I didn't 
> think about 
> nuthin'!
> 
> > 2. In 2. Architecture, rather than an 'organization', I'd propose a 
> > 'community service'. Such a resource would point to a service which 
> > provides information about organizations, groups, funding 
> bodies etc.
> 
> I'm wondering about your use of the word 'service' as "in its generic 
> sense".  Do you see this generic sense consistant with the definition 
> given in the document?  Do we need to alter the definition?  
> 
> All resources are described by a ReferenceURL metadatum that 
> points to a human-readable document describing the resource.  
> For a service, this is in addition to any URL used for 
> accessing the interface.  For things like organizations or 
> data collections, these are the home pages for those things.  
> Is this the sort of thing you had in mind?
> 
> I sense from your suggestion a desire to look at resources as 
> services.  
> This may be a reasonable perspective, but I don't think it is 
> intent of 
> the architecture described in the RSM.  Organization is a 
> resource that 
> can be described separately from any of the services it provides.  I 
> prefer this simpler view of an organization.  Thus, in the 
> architecture of 
> the RSM, all services are resources, but not all resources 
> are services.  
> 
> > I don't think
> > the registry should be a 'list of everything', only of 
> resources which 
> > provide a realizable service to the VO (using service in 
> its generic 
> > sense)
> > - ie, returns data, displays spectra, merges VOTables etc. 
> Otherwise it'll
> > become impossible to manage and cumbersome to search.
> 
> Do you mean impossible for the user or the registry maintainer? 
> 
> As you might recall from my presentation, the VOResource XML schema 
> identifies several classes of resources--organization, project, data 
> collection, and service; additional classes are expected to 
> be defined.  
> These classes, I believe, would in practice map well to the kinds of 
> queries that users would put to the registry:  "Find me all data 
> collections that ..." or "Find me all services that ...."  Thus, from 
> the user perspective, the class (in addition to the Type 
> metadatum) can be 
> effective in filtering out irrelevent resources from a query.
> 
> The class essentially defines what additional metadata (beyond the 
> top-level resource metadata) are used to describe the 
> resource.  (Again, 
> see my presentation, 
> http://www.ivoa.net/internal/IVOA/InterOpMay2003ResReg/VOResou
> rce.ppt).  
> The fact that the metadata employed depends on the resource type does 
> makes it harder to stick them into a RDB--you can't use a single flat 
> table very well.  Nevertheless, I believe this heterogeneity is 
> inescapable; just looking at the different services we have to 
> support bears this out.  Each standard service will have its 
> own set of 
> metadata for describing its capabilities.  I think, though, 
> the VOResource 
> structure supports this variation well.
> 
> Getting back to the issue of listing "non-services", I would 
> guess that 
> direct searches for Organizations by users would be rare.  
> Still, I think 
> allowing the registering of Organizations will play an 
> important role in 
> tracking provenance and integrity.  The PublisherID 
> associated with all 
> resources, including services, would allow one to find out more 
> information about the data collection(s) serviced by a 
> particular service.  
> 
> Another "non-service" I think would be good to register is a standard 
> service interface definition (e.g. SIA).  This means that 
> implementations 
> can reference the definition in their service descriptions, 
> and the ID can 
> be used to recognize services of a particular type.  The 
> registry record 
> describing the definition would include pointers to the specification 
> document (via the ReferenceURL), the generic WSDL document (if 
> applicable), and the service-specific schema used to describe 
> implementations.  This idea is actually alluded to in the 
> defintion of the 
> ServiceStandardURI metadatum.  
> 
> > 5. The only other top level item, included in the Content Metadata 
> > should be Interface metadata (currently section 4.1). This should 
> > describe the mode of
> > invocation: how to access and utilise the resource.
> 
> Again, I get the sense that you wish to view all resources as 
> services.  
> If Services are only a type of Resource, then this should not 
> be part of 
> the top-level metadata.  
> 
> > 6. Finally, each resource should provide a list of 
> 'Supported Metadata 
> > Formats' (SMFs). This will be a list of namespaces, each of which 
> > refers (but doesn't point) to a metadata schema which that resource 
> > supports, ie the resource describes itself using those schema.
> > 
> > 7. The rest of the metadata held on a given resource fulfils its 
> > contract to support the list of metadata formats. So a data 
> conversion 
> > would provide metadata about input format and output format; a data 
> > query resource would provide metadata about query format, 
> data content 
> > and output format; etc. [Should only be a standardised list of 
> > metadata formats - if we allow anyone to generate their own it'd be 
> > difficult for user services to cope with them. Perhaps the 
> Type field 
> > in the content metadata should indicate a set list of SMFs 
> which are 
> > mandatory and the resource can choose to support others???]
> 
> This SMF idea is very interesting (it is one of the features 
> of the OAI 
> protocol); however, I think I need a clearer idea of your 
> 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?  
> 
> If it is the latter, this is, I think, handled transparently 
> by the VOResource schema framework using XML mechanisms.  For 
> example, I envision that a description of an SIA service will 
> use the VOSIA schema, which extends the VOResource schema.  
> This would be a standard schema in that it is part of the SIA 
> specification (that is registered!).
> 
> Perhaps you could give an example of the situation you want 
> to address.  
> 
> > 8. The RSM mentions the idea of hierarchies of resources (eg 
> > MAST/HST). This needs discussion and resolution as to how it is 
> > handled. If the hierarchy is allowed, it will be possible to return 
> > from a registry query with both the MAST and HST resource 
> within the 
> > answer. We need to either constrain the registry to only low-level 
> > resources or to indicate hierarchy in some way and set a rule (or 
> > user-settable switch) that the registry only returns the 
> lowest level 
> > from any hierarchy.
> 
> The hierarchical idea is one that I feel needs strengthening in the 
> VOResource metadata and probably, therefore, in the RSM.  
> 
> > If people agree with the above I think we need to start 
> defining the 
> > SMFs. I suspect these might be hierarchical when it comes 
> to resources 
> > which query data. The top level data content SMF would 
> support generic 
> > information like coverage, while lower level SMFs would provide 
> > data-specific metadata, so a query resource would always 
> support the 
> > top level SMF but will pick from lower level ones.
> 
> I feel like this is essentially the roadmap that WP03 is on.
> 
> cheers,
> Ray
> 
>