MyUCDs & Registry

[Tony Linde]

I've read the posts from yesterday in more detail and have a couple more
points:

4. It has been suggested a couple of times that the Registry should be able
to take in complete data-oriented queries and should analyse these to
determine a) which resources can answer the query and b) how to formulate
the query for each resource. 

On b) I don't think the registry should ever do this - it should be left to
the resource to translate a standard format (VOQL, AQL) query into its own
format.

Point a) is more problematic. It would be nice if the Registry could do this
but I would prefer to keep the registry simply answering questions about
resource metadata and leave it to the workflow engine to construct the
standard query from the user's statement of needs. At this stage of VO
development, it might pay to keep such components separate to speed
evolution and possibly bring them together later. 

5. Should the Registry store the column names and units used in a catalog or
data table? I would say 'definitely' for the column names and 'probably' for
the units. The column names are essential to resolve duplicate UCDs before a
generic query is farmed out. Units may not be needed. Would a user need to
know the units a column's data is stored in? Not if the query uses UCDs and
standard units for those UCDs - it is then up to the resource to resolve the
standard query into a sql query by unit conversion. Any other reasons for
storing units?

*NOTE: when I talk about the registry 'storing' metadata, I simply mean that
the registry must answer questions about that metadata and be able to return
it; whether an implementation of a registry stores it or retrieves it from
the resource when needed is strictly an implementation issue.

6. Gretchen mentions wanting to get started building a registry. This is
exactly what we are doing in AstroGrid. No-one should wait for the final
V1.0 registry specification. Let's work with what we've got and feed the
results back into the deliberations. As long as everyone expects to do at
least 300% refactoring :)

Cheers,
Tony. 

> -----Original Message-----
> From: Tony Linde [mailto:ael at star.le.ac.uk] 
> Sent: 19 May 2003 22:51
> To: registry at ivoa.net
> Subject: RE: MyUCDs & Registry
> 
> 
> Wow! This topic seems to have mushroomed. A few points:
> 
> 1. The IVOA will define interfaces to the Registry and the 
> minimum standard that any registry should conform to. It will 
> be up to each registry how it implements those standards and 
> whether they offer extension services. 
> 
> So, to the first point, the standard may say that a registry 
> must return the columns defined in a dataset but one 
> implementation might store that information for every dataset 
> and another might query a dataset when it needs to answer 
> such a query. On the second point, a registry might offer to 
> run queries and consolidate results on behalf of clients - 
> that does not mean that all registries have to offer such services.
> 
> 2. There is likely to be very little information which is 
> mandated across all resources listed in a registry. Simple 
> curation metadata (owner email, phone number etc) is probably 
> all that every resource will have in common. 
> 
> We can then imagine an inheritance hierarchy of metadata sets 
> branching out from that. One branch will be resources 
> offering to provide data from a query (such metadata will 
> include data type, coverage etc); one branch from that might 
> be for images and another for catalog data etc. Another 
> top-level branch might be for services; from that a branch 
> for visualisation tools etc. Each branch will have metadata 
> associated with it; and lower levels will have more specific 
> data associated with them.
> 
> This is similar to the OAI 'metadata format'. A resource, 
> when added to the registry, will state that it is of type 'X' 
> and that it will agree to provide metadata in formats A, B, C 
> (ie it will provide metadata under those branches). Having 
> signed up to provide such metadata, a registry query against 
> that resource can then identify one, some or all of the 
> metadata formats required as an answer to the query.
> 
> 3. For data-oriented resources, the metadata should include 
> UCDs and column names. The UCD will go some way towards 
> identifying the type of data in a column. It will be possible 
> to query the registry for all 'data-oriented resources' (eg 
> all resources which have agreed to satisfy the 'dataset' 
> metadata format) for which there is one or more columns 
> described by POS_EQ_RA or equivalent.
> 
> 
> In summary, the RSM must expand to cover all the above if we 
> intend it to be the final standard for describing the 
> metadata in the Registry.
> 
> 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
> 
>