Hi Sebastien,
here are some of my comments on UCD1+.
Section 2: Syntax
if UCDs are case insensitive for all practical purposes, why not limiting the valid characters to uppercase or lowercase alphabet? Allowing both may suggest that B-V is different from b-v (as in the original UCDs), and given that it is easier to type in lowercase than uppercase, I'd suggest that we define UCDs in lowercase only.
Section 3.3: combining simple words.
After the example, refering to meta.code it says
applies a magnitude
should say
applies to a magnitude
In the same section:
Examples of UCD1+...
in the case of a "maximum temperature of an instrument" my initial reading was "maximum reachable temperature of an instrument" rather than "maximum temperatured reached by an instrument during observation". Surely you meant the second. For the first, do we have now something to denote a feasible range? I can think of few cases where this could be needed though.
Page 10, right after equation 2:
I think it should read "And define \mu ..."
About distances and matching functions:
I would like to point to the usefulness of using regular expressions as a way to "discover" related UCDs. Accurate matching is paramount, distances are quite useful, but what if I want to find the quantities involving em.opt.b Those could be phot.mag, colors, errors, etc. As em.opt.b is not a primary word, measuring distances using this element as the starting point may or may not lead anywhere in the matchhing functions described. I've had the chance to play with these features in the original UCDs and sometimes one does not need to start with the main word (or perhaps as Martin pointed out, we should name it differently, "concept" perhaps?)
Fortunately, this is an implementation issue and does not require any changes in the structure to UCD1+ to offer a regExp search engine.
Section 7.3:
hidden in one of the paragraphs is a phrase which I think deserves to be highlighted:
<<
The capacity to lauch broad scope queries (to a number of services)
looking for resources containing certain UCDs, freeing ourselves of
having to know the specific column names which at the end the service
DBMS should use to dig the data.
>>
The goal is not small, as it implies
- accepting UCDs and column names within a query language, - a mechanism to recognize that a "name" represents a UCD - a mechanism to locate those resources which contain the UCDs present inthe query and a conversion to column names - a mechanism to launch individual queries to each selected resource - a collection and delivery mechanism.
Comment on pos.eq.ra and pos.eq.dec
A serious problem I found last year while working in a data federation tool was the fact that ra and dec are meaningless without knowing to which equinox they refer to. In a number of catalogues (I was using Vizier's metadata) the position refered as POS_EQ_RA_MAIN in one catalogue was for J2000, while in others it was for B1950 or other equinoxes.
VOTable provides the coosys element, but even with this feature it's not always possible to find the correct match other than resourcing to the using the column name (which is the case of vizier is OK because of its homogeneity, but is not assured in the case of other minor data providers). Besides, some catalogues list positions in more than one equinox and VOTable crashes there.
I feel that a sensible way to address this issue is to attach to pos.eq.ra the equinox element, eg, eqnx.J2000 or eqnx.B1975. It is not the best solution, as new elements of meta-data seem to be needed, also to define Groups of elements. I'm thinking in the cases when one works with the meta-data at the registry level rather than the VOTable level, besides, the VOTAble groups and coosys must come from some kind of registry elements (I can guess where these are in Vizier :-)
I also feel that the problem is serious enough for us to adress it as soon as possible, as exchange services are being built and they will face these issues as soon as they leave their sand-box and interact with the real world.
Finally, congratulations for the document and the way to address the issues, it seems to be a big step in the right direction.
Cheers,
Patricio
On Mon, 26 Apr 2004, Sebastien Derriere wrote:
>
> Hello,
>
> I have placed on the IVOA wiki a PDF version of the latest document
> on UCD: http://www.ivoa.net/internal/IVOA/IvoaUCD/WD-UCD-20040426.pdf
> This document describes the motivations and procedure to evolve
> the first generation of UCD into a new scheme called UCD1+.
> The new scheme has been quite successfully tested on VizieR. It also
> includes inputs from other fields, like the latest SIAP discussions.
> As the UCD1+ vocabulary is likely to evolve faster than the reference
> document itself, the reference lists are available online, together with
> old
> versions and history of changes:
> http://vizier.u-strasbg.fr/UCD/lists/
>
> The document currently has a Working Draft status, but the idea is
> to promote it to an IVOA Proposed Recommendation. This can be done
> once agreement is reached within the discussion group, if I understand
> well the IVOA document lifecycle.
> So... time for discussion now !
>
> Sebastien.
> --
> _______
> / ~ /, Sebastien Derriere mailto:derriere-at-astro.u-strasbg.fr
> / ~~~~ // Observatoire de Strasbourg Phone +33 (0) 390 242 444
> /______// 11, rue de l'universite Telefax +33 (0) 390 242 417
> (______(/ F-67000 Strasbourg France
>
--- Patricio F. Ortiz pfo-at-star.le.ac.uk AstroGrid project Department of Physics and Astronomy University of Leicester Tel: +44 (0)116 252 2015 LE1 7RH, UKReceived on 2004-05-04Z11:41:43