re: VOResource v0.8.2

Ray et al.,

The organisation of the new schemas suggested by Ray http://www.ivoa.net/forum/registry/0591.htm seems nice and logical to me, with a few possible omissions. I think some of my detailed points are similar to those made by Tony, e.g. on links to articles http://www.ivoa.net/forum/registry/0634.htm which I have made more specific.

I apologise if I have missed anything but already included but it would be nice to have a text version, either an updated RSM or a tree with comments which exactly corresponds to the schemas; also if we can try and keep replies with subjects which attatch them to the right thread. There are some general points which concern me:

1. Testing schemas How are we are going to test the schemas by generating xml describing sample data sets, services etc.? Filling a few in by hand is the best way I have found of understanding what is implied and whether it matches Registry needs. These schemas are at the limit of my understanding of xml and Arnold Rots' STC schemas are way beyond it, but I do not know how to generate complete xml templates (using Oxygen) when many elements have 'minOccurs="0"' - please can someone enlighten me?
2. Populating the registry How are service and data providers going to supply the necessary information? The most widely floated suggestion so far is web forms, but these should be kept to about 2 pages max or they won't get filled in. They need to be self-contained (e.g. each element has a pop-up with definition, restrictions - in English) and the processing script needs to translate obvious language into restricted terms (e.g. basic data to BasicData), convert units approximately etc.

Where data sets are already in Vizier or other services with standard metadata some information can be harvested, and other elements are VO housekeeping which we can supply. Not all the elements are relevant to any one service. However we should sketch a few dummy forms (or other methods e.g. email questionnaire) to check that it is not all getting too complicated for data/service providers without full-time archivists etc. - or for most VO staff!

3. Detailed comments from AstroGrid work Some of these points probably contradict my plea above for simplicity, if any element is consistently unfilled in the first dozen services/data sets registered then it should probably be dropped. Also, I think that the registries of IVOA members should contain at least all the IVOA elements but there may be others which only we want. However these are what I think are missing or need significant ammendment:

Subject
VOResource-v0.8.2.xsd
defined as
"Terms for Subject should be drawn from the IAU Astronomy Thesaurus

           (http://msowww.anu.edu.au/library/thesaurus/)"

I agree that the IAU Astronomy Thesaurus should be the definative document, but it needs updating, expanding and major work to produce a namespace. The IVOA should probably get the IAU to get it (the IVOA) to update it but in the meanwhile I suggested several alternatives http://wiki.astrogrid.org/bin/view/Astrogrid/RegistryKeywords and adopted one (based on the cut-down set of NASA keywords used by CDS) which I have set up as a namespace.
http://wiki.astrogrid.org/pub/Astrogrid/RegistryIt03Metadata/keywords.xsd

Documentation
VOResource-v0.8.2.xsd
More constraints on what this could contain: As Elizabeth Auden noted http://www.ivoa.net/forum/registry/0625.htm, a link to a Vizier-style ReadMe (e.g. Vizier itself) would be useful as the most concise way to describe catalogues for humans. The VO would not directly search this but it would be readily available to the user if they want to make a manual catalogue selection. Ideally this should contain the UCDs, if available, alongside the native column headings.

UCDs
These should be in the Registry if they exist, possibly under Documentation or in the section which includes Coverage. Attempting to impliment the AstroGrid science cases showed that being able to search for terms like Proper Motion was very useful. If UCDs are not available nothing is lost but the selection may be more complicated.

source - bibcode etc.
In RSMV0.8 this is under content but it should be under Documentation I think.

Data set size and query restrictions, included in AstroGrid registry This will be useful e.g. to help decide which catalogue to search first in a cross-matching exercise; whether it is necessary to call a cut-out server; how long a job will take. RSMv0.8 contains examples of query restrictions (e.g. max. radius of cone search) which seem useful but are not here.

DataService
Elizabeth Auden proposed http://www.ivoa.net/forum/registry/0625.htm that we need a broader term than SkyService, and in fact we need to cover non-observational catalogues like lists of phenomena and other non-positional data - hence I suggest DataService (rather than the subdivisions Elizabeth suggested, as some data may not be easy to categorise).

Coverage
Spatial, Spectral, Temporal - maybe Resolution should be one of the subelements in each of these, along with dimensional coverage, accuracy, regionOfRegard etc. - maybe depth/sensitivity is extra? RSMv0.8 seemed to do very well, with a little reorganisation. The STC documentation seems very comprehensive but we will only find out how complete the related schemas are and how far it is necessary to go when using them to answer queries. The Registry should only use a tiny fraction of their complexity and will impose added restrictions (I hope!) e.g. units.

Otherwise I support Elizabeth Auden's suggestions, especially the need to include services like MySpace.

thanks

a

• - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dr. Anita M. S. Richards, AVO Astronomer MERLIN/VLBI National Facility, University of Manchester, Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K. tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).