comments

[Tony Linde]

Couple more thoughts.

The registry is really a sort of Resource Name Server but providing more
that just identifiers with extra metadata about the resource, more
functional search facilities and, possibly, additional services.

People, groups and communities won't be first registered in a Registry
but in a Community Server (Community Name Server?) where they'll be
assigned unique IDs created from the community namespace plus some
community-specific identifier (eg //cas.le.ac.uk/TonyLinde).

Cheers,
Tony. 

> -----Original Message-----
> From: Tony Linde [mailto:ael at star.le.ac.uk] 
> Sent: 31 January 2003 13:57
> To: Registry_Ivoa_List
> Subject: comments
> 
> 
> 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
>