comments

[Tony Linde]

A few comments on the traffic here and in the us-vo/metadata list. I'll
not identify the sources to which my comments are directed - these are
my thoughts/proposals prompted by reading the other messages on the
train yesterday.

1. The VO is not a thing, it is a space with rules of entry and
engagement which we are all helping to create (like the 'web').

2. Registries will exist within the VO to:
 a. catalogue metadata for VO resources; 
 b. help with narrowing the search for resources.

3. Registries will be organised in some IVOA standard manner (peer to
peer, DNS-type hierarchy etc.) that does not require any central
authority.

4. Each registry will have a namespace as its unique ID. (A new registry
attempting to enter the VO space with a conflicting ID will be denied
entry.)

5. Every resource must have a unique ID. The resource id will be created
by the registry with which the resource registers. That id will consist
of the registry namespace followed by some (registry-specified) unique
identifier.

6. Elements within a registered resource may or may not be uniquely
identified. Any id will have the resource as its scope.

7. Registries will share resource metadata using some IVOA standard
method (to support active - harvesting - and passive updating).

8. Resource owners will make updated resource metadata available in one
of several standard ways.

9. Resource relationships (eg 'is derived from', 'was copied from', 'was
extracted from', 'provides access to', etc.) will be specified as
metadata in one or both resource registry entries.


Finally, some ideas or potential guidelines:

A. IVOA should define minimum standards needed to make interoperability
feasible.

B. IDs should identify one thing only; they should not carry any
embedded meaning or structure (eg 5th letter codes for the astronomer's
gender preference). This is FATAL to any system.

C. Registry granularity beyond the IVOA minimum is up to the Registry
owner. A Resource owner may register that resource with a registry which
maintains a preferred level of metadata.

D. Registries should provide both a web service and GUI interface for
registering and updating resource metadata.

E. A registry may implement a 'time to live' for entries, so unless a
resource regulary states that it is still alive, the resource entry is
removed or flagged as dormant.

F. 'Sameness' is a major and very difficult issue. Not just about copies
of data. If one field in one row of a 10Gb table is changed, is it the
same resource? If so, how do we enable reruns or checks on published
analyses? If not, how do we maintain identity linkage? Tricky!

G. I've been assuming that everything in a registry is a 'resource',
whether it is a service, archive, dataset etc. I think that a service
which gives access to a dataset should be registered as that dataset.
Further metadata will describe how to get the data using the service. If
the service provides further features, perhaps it should also be
registered, but as a service.


That's all for now - all I can think of - I'll try to keep up with
traffic in future and comment at the right time.

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