Rwp03: RSM changes

[Tony Linde]

I've had a look at RSM v0.7. Rather than attempt changes to the document
itself, I'd like to raise issues which might lead to changes.

1. The name of the document and references in the document (eg 1.
Introduction) to 'resource and service metadata' should be changed to
'resource metadata' to reflect our decision that everything in the registry
is a resource. We can then go on to explain that resources can be data or
service types (or other types possibly).

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

3. as with 1. above, sections 3 & 4 should be merged into 'Resource
metadata'. Identity and Curation metadata look fine.

4. I think Content Metadata, like identity and curation, should be a
top-level, everyone fills it in, section. In this case it should contain
only Type (mandatory) and perhaps Content Level (optional) and Access Policy
(like Rights but pointing to some standardised type of access policy
document - xml file probably) but certainly not coverage, facility etc. 

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.

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???]

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.

I realise that all the above means a radical change to the structure of the
RSM (RM now?) but I think it is necessary to move it forward towards
becoming the standard for the IVOA registry metadata.

The most drastic change is the addition of the SMFs but this is in line with
discussions at the interop meeting about needing to support subsets of
metadata for different types of resource and it also fits in with the OAI
metadata format ideas (which is hardly surprising since I stole the idea
from there).

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.

Finally, when RSM v0.8 comes out I think we need to pull together
information from the three core work packages (2, 3, 4) and produce a
baseline document which works through one or two use cases exercising the
interfaces and making use of the metadata.

I think that's enough for people to work on over the weekend :)

Cheers,
Tony. 

__
Tony Linde                       Phone:  +44 (0)116 223 1292
AstroGrid Project Manager        Fax:    +44 (0)116 252 3311
Dept of Physics & Astronomy      Mobile: +44 (0)7753 603356
University of Leicester          Email:  ael at star.le.ac.uk
Leicester, UK   LE1 7RH          Web:    http://www.astrogrid.org