From pfo at star.le.ac.uk Tue May 4 04:41:15 2004 From: pfo at star.le.ac.uk (Patricio F. Ortiz) Date: Tue, 4 May 2004 12:41:15 +0100 (BST) Subject: towards UCD1+ In-Reply-To: <408D217A.58F8CB30@astro.u-strasbg.fr> Message-ID: 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 in the 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, UK From Alberto.Micol at eso.org Wed May 5 04:44:46 2004 From: Alberto.Micol at eso.org (Alberto Micol) Date: Wed, 05 May 2004 13:44:46 +0200 Subject: UCDs as substrings of other UCDs? Message-ID: <4098D3AE.5050209@eso.org> After having written my original message (see below) I found the solution to my problem (also explained below). I explicit the solution here first asking the following question: Would it be possible to change ::= | to ::= | ? To understand what I'm talking about, I think it's better to read the original message, unless you are good -damn good- at those games where given an answer you have to guess the question. Alberto PS: If you like to play, the subject probably helps ... --- original message, which explains the problem and the way I got to the above-mentioned solution--- Dear UCD builders, It would be very convenient NOT to allow a word to be a substring of other words. Example: Suppose the following two UCDs existed (I'm inventing here): 1. em.IR.H 2. em.IR.Hgamma (Luckily the second one is just only my invention, but it is just to illustrate the point) In this case 1. would be a substring of 2. Why it woud be bad? Because it would unnecessarily complicate a sql query to a table listing UCDs. A query like select * from whatever where UCD like "%em.IR.H%" would return not only the UCD I'm really interested in (em.IR.H) but also the em.IT.Hgamma. The way out, given the fact that UCDs are composed of multiple words semicolon separated, would be to use an "OR" but that is not so efficient: select * from whatever (could be a complicated join) where UCD like "%em.IR.H" or UCD like "%em.IR.H;%" OR, as said, are not efficiently handled. To simplify the usage of UCD in RDBMSes it would be nice to see such rule (not allowing substrings) explicited in the UCD document. I checked the UCD1+ list and I could not find any such case (probably by design?), a part from those obvious cases like em.IR being a substring of em.IR.H where the hierarchy is implied. Even these cases could be avoided if the high level UCD would be formulated differently, eg, em.IR.main (or em.IR.def, def for definition or default) instead of em.IR. But this is less disturbing then the example cited above. Actually, another way out would be to always terminate a word with the semicolon! even if at the end of UCD. E.g., "em.IR;" would do the job quite nicely. This could be avoided quite nicely by change the Backus-Naur definition to always end with a semicolon! Thanks, Alberto From Alberto.Micol at eso.org Wed May 5 05:43:43 2004 From: Alberto.Micol at eso.org (Alberto Micol) Date: Wed, 05 May 2004 14:43:43 +0200 Subject: UCDs as substrings of other UCDs? References: <4098D3AE.5050209@eso.org> Message-ID: <4098E17F.2000000@eso.org> > Would it be possible to change > ::= | > to > ::= > | > ? I forgot to mention that, obviously, also the Backus-Naur form for UCD should be changed accordingly, that is, by removing the which was moved to the level of a : ::= | Alberto PS: Basically, I find better to always have explicit separators, and not to rely on the implicit "end of string" one. From rgm at roe.ac.uk Fri May 7 07:54:08 2004 From: rgm at roe.ac.uk (Bob Mann) Date: Fri, 7 May 2004 15:54:08 +0100 (BST) Subject: towards UCD1+ In-Reply-To: <408D217A.58F8CB30@astro.u-strasbg.fr> References: <408D217A.58F8CB30@astro.u-strasbg.fr> Message-ID: Hi folks, I've read with interest the new document from Sebastien and Andrea, and the comments from Martin, Alberto and Patricio. I think that the new document is a clear statement of good principles, and is a significant improvement on the previous documents that have been circulated. I have only a few specific comments, but one general comment on skimming through the current list of UCDs > http://vizier.u-strasbg.fr/UCD/lists/ is that it still shows too strongly its origin in Vizier: a system that defines a specific term for a (b-y) Stromgren colour, but doesn't, so far as I can tell, provide a simple mechanism for denoting something as being an X-ray/optical flux ratio seems a little biased in its perspective to me. If UCD1+ is supposed to be modest in ambition, then my vote would be to have phot.fluxratio (or some such) and delete all the specific phot.color UCDs. One strength of the new document is the discussion of the matching functions. I'd not been convinced of their practical utility before, but I am now, after reading the example given. It would be interesting for that table of mu values to include those from the other proposed matching function, just to indicate how similar they are. I agree with Martin's suggestion that it would be preferable to use complete words, rather than abbreviations. Patricio's comment about equinoxes is an interesting one. The same goes for units, of course, since they are also additional metadata without which the data cannot be used in a meaningful way. But modifying UCD1+ to include grouping of UCDs, as he suggests, would seem to be a significant change, albeit one that is attractive from many points of view. I won't be attending the interoperability meeting in Boston, but I trust that the UCD discussion goes well there - it should, given that Sebastien and Andrea have given it a firm foundation with this document. cheers Bob From roy at caltech.edu Tue May 11 08:01:59 2004 From: roy at caltech.edu (Roy Williams) Date: Tue, 11 May 2004 08:01:59 -0700 Subject: towards UCD1+ References: <408D217A.58F8CB30@astro.u-strasbg.fr> <408F6FD3.6020009@dial.pipex.com> Message-ID: <032701c43768$e9ee1fc0$6701a8c0@Ropy> I would also like to thank Sebastien and Andrea for this excellent paper. I look forward to discussing in Boston the comments from Martin Hill, Patricio Ortiz, and Bob Mann. However, I think there needs to be an additional document showing the current state of the UCD1+ tree. A printable, versioned IVOA draft document. This will force the rigour of versioning, and allow the IVOA process to control the list of words. When Sebastian and Andrea want to make changes, they should not just change it arbitrarily, but rather build a new version of the UCD Tree document and run it past the IVOA, or the UCD Steering committee, or this mailing list. Is that too rigid and formal? Comments? Roy -------- California Institute of Technology roy at caltech.edu 626 395 3670 From posuna at iso.vilspa.esa.es Tue May 11 08:25:23 2004 From: posuna at iso.vilspa.esa.es (Pedro Osuna) Date: Tue, 11 May 2004 17:25:23 +0200 Subject: towards UCD1+ In-Reply-To: <032701c43768$e9ee1fc0$6701a8c0@Ropy> References: <408D217A.58F8CB30@astro.u-strasbg.fr> <408F6FD3.6020009@dial.pipex.com> <032701c43768$e9ee1fc0$6701a8c0@Ropy> Message-ID: <1084289123.12201.7381.camel@isol03.vilspa.esa.int> Hi Roy, we proposed to have a proper board for the control of the UCDs, and a centralized place where all UCD related issues (concerning the inclusion of new UCDs, procedures for request of inclusion of new UCDs, etc) should be handled. I would think it is time to implement this solution (chapter 9 of the latest UCD document). What I do not know is whether this should be agreed at a IVOA exec or what... What do you think? P. On Tue, 2004-05-11 at 17:01, Roy Williams wrote: > I would also like to thank Sebastien and Andrea for this excellent paper. > > I look forward to discussing in Boston the comments from Martin Hill, Patricio > Ortiz, and Bob Mann. > > However, I think there needs to be an additional document showing the current > state of the UCD1+ tree. A printable, versioned IVOA draft document. This will > force the rigour of versioning, and allow the IVOA process to control the list > of words. When Sebastian and Andrea want to make changes, they should not just > change it arbitrarily, but rather build a new version of the UCD Tree document > and run it past the IVOA, or the UCD Steering committee, or this mailing list. > > Is that too rigid and formal? Comments? > > Roy > > -------- > California Institute of Technology > roy at caltech.edu > 626 395 3670 -- Pedro Osuna Alcalaya Software Engineer VILSPA Archive Development Team e-mail: Pedro.Osuna at esa.int Tel + 34 91 8131314 European Space Agency VILLAFRANCA Satellites Tracking Station P.O. Box 50727 E-28080 Villafranca del Castillo MADRID - SPAIN From roy at caltech.edu Tue May 11 08:36:28 2004 From: roy at caltech.edu (Roy Williams) Date: Tue, 11 May 2004 08:36:28 -0700 Subject: towards UCD1+ References: <408D217A.58F8CB30@astro.u-strasbg.fr> <408F6FD3.6020009@dial.pipex.com> <032701c43768$e9ee1fc0$6701a8c0@Ropy> <1084289123.12201.7381.camel@isol03.vilspa.esa.int> Message-ID: <037a01c4376d$ba961f20$6701a8c0@Ropy> Yes I know. My idea is to have the UCD Steering Committee work with CDS on (a) The next version of the list of words -- working through the IVOA drafting process. (b) The application of UCD in the Simple Data Services (cone, SIAP, SSAP) Are you coming to Boston? Roy -------- California Institute of Technology roy at caltech.edu 626 395 3670 ----- Original Message ----- From: "Pedro Osuna" To: "Roy Williams" Cc: ; Sent: Tuesday, May 11, 2004 8:25 AM Subject: Re: towards UCD1+ > Hi Roy, > > we proposed to have a proper board for the control of the UCDs, and a > centralized place where all UCD related issues (concerning the inclusion > of new UCDs, procedures for request of inclusion of new UCDs, etc) > should be handled. I would think it is time to implement this solution > (chapter 9 of the latest UCD document). What I do not know is whether > this should be agreed at a IVOA exec or what... What do you think? > > P. > > On Tue, 2004-05-11 at 17:01, Roy Williams wrote: > > I would also like to thank Sebastien and Andrea for this excellent paper. > > > > I look forward to discussing in Boston the comments from Martin Hill, Patricio > > Ortiz, and Bob Mann. > > > > However, I think there needs to be an additional document showing the current > > state of the UCD1+ tree. A printable, versioned IVOA draft document. This will > > force the rigour of versioning, and allow the IVOA process to control the list > > of words. When Sebastian and Andrea want to make changes, they should not just > > change it arbitrarily, but rather build a new version of the UCD Tree document > > and run it past the IVOA, or the UCD Steering committee, or this mailing list. > > > > Is that too rigid and formal? Comments? > > > > Roy > > > > -------- > > California Institute of Technology > > roy at caltech.edu > > 626 395 3670 > -- > Pedro Osuna Alcalaya > > > Software Engineer > VILSPA Archive Development Team > e-mail: Pedro.Osuna at esa.int > Tel + 34 91 8131314 > > European Space Agency > VILLAFRANCA Satellites Tracking Station > P.O. Box 50727 > E-28080 Villafranca del Castillo > MADRID - SPAIN > > > From posuna at iso.vilspa.esa.es Tue May 11 08:40:33 2004 From: posuna at iso.vilspa.esa.es (Pedro Osuna) Date: Tue, 11 May 2004 17:40:33 +0200 Subject: towards UCD1+ In-Reply-To: <037a01c4376d$ba961f20$6701a8c0@Ropy> References: <408D217A.58F8CB30@astro.u-strasbg.fr> <408F6FD3.6020009@dial.pipex.com> <032701c43768$e9ee1fc0$6701a8c0@Ropy> <1084289123.12201.7381.camel@isol03.vilspa.esa.int> <037a01c4376d$ba961f20$6701a8c0@Ropy> Message-ID: <1084290033.12201.7392.camel@isol03.vilspa.esa.int> Yes, I will arrive there on saturday the 22nd with Jesus Salgado for whatever might be needed (including beers on sunday, if applicable). P. On Tue, 2004-05-11 at 17:36, Roy Williams wrote: > Yes I know. > > My idea is to have the UCD Steering Committee work with CDS on > > (a) The next version of the list of words -- working through the IVOA drafting > process. > > (b) The application of UCD in the Simple Data Services (cone, SIAP, SSAP) > > Are you coming to Boston? > Roy > > > -------- > California Institute of Technology > roy at caltech.edu > 626 395 3670 > ----- Original Message ----- > From: "Pedro Osuna" > To: "Roy Williams" > Cc: ; > Sent: Tuesday, May 11, 2004 8:25 AM > Subject: Re: towards UCD1+ > > > > Hi Roy, > > > > we proposed to have a proper board for the control of the UCDs, and a > > centralized place where all UCD related issues (concerning the inclusion > > of new UCDs, procedures for request of inclusion of new UCDs, etc) > > should be handled. I would think it is time to implement this solution > > (chapter 9 of the latest UCD document). What I do not know is whether > > this should be agreed at a IVOA exec or what... What do you think? > > > > P. > > > > On Tue, 2004-05-11 at 17:01, Roy Williams wrote: > > > I would also like to thank Sebastien and Andrea for this excellent paper. > > > > > > I look forward to discussing in Boston the comments from Martin Hill, > Patricio > > > Ortiz, and Bob Mann. > > > > > > However, I think there needs to be an additional document showing the > current > > > state of the UCD1+ tree. A printable, versioned IVOA draft document. This > will > > > force the rigour of versioning, and allow the IVOA process to control the > list > > > of words. When Sebastian and Andrea want to make changes, they should not > just > > > change it arbitrarily, but rather build a new version of the UCD Tree > document > > > and run it past the IVOA, or the UCD Steering committee, or this mailing > list. > > > > > > Is that too rigid and formal? Comments? > > > > > > Roy > > > > > > -------- > > > California Institute of Technology > > > roy at caltech.edu > > > 626 395 3670 > > -- > > Pedro Osuna Alcalaya > > > > > > Software Engineer > > VILSPA Archive Development Team > > e-mail: Pedro.Osuna at esa.int > > Tel + 34 91 8131314 > > > > European Space Agency > > VILLAFRANCA Satellites Tracking Station > > P.O. Box 50727 > > E-28080 Villafranca del Castillo > > MADRID - SPAIN > > > > > > -- Pedro Osuna Alcalaya Software Engineer VILSPA Archive Development Team e-mail: Pedro.Osuna at esa.int Tel + 34 91 8131314 European Space Agency VILLAFRANCA Satellites Tracking Station P.O. Box 50727 E-28080 Villafranca del Castillo MADRID - SPAIN From roy at caltech.edu Mon May 17 11:37:19 2004 From: roy at caltech.edu (Roy Williams) Date: Mon, 17 May 2004 11:37:19 -0700 Subject: UCD agenda and UCD/DAL agenda Message-ID: <0a8e01c43c3d$fc8765e0$0c0ba8c0@cacr.caltech.edu> Please find below a suggested draft agenda for the UCD session at the Interop meeting. Note that the second half is joint with the DAL group. If you would like to contribute to the session, or change the agenda below, please drop me a line. Roy ---------------------------------------------- UCD working group Agenda for Interop meeting 1. Sebastien Derriere, UCD Services at CDS 2. Andrea Preite-Martinez, Realization of UCD1+ 3. Roy Williams, UCDs for the Image Access Protocol 4. Doug Tody, UCDs for the Spectral Access Protocol -------- California Institute of Technology roy at caltech.edu 626 395 3670 From derriere at newb6.u-strasbg.fr Fri May 21 10:37:10 2004 From: derriere at newb6.u-strasbg.fr (Sebastien Derriere) Date: Fri, 21 May 2004 19:37:10 +0200 Subject: UCD material Message-ID: <40AE3E46.57E45165@astro.u-strasbg.fr> Hello, I have placed on the IVOA Wiki some new documents: http://www.ivoa.net/twiki/bin/view/IVOA/IvoaUCD A revised version of the EM Spectrum division for UCD v0.3 (following the registry main domains): http://www.ivoa.net/internal/IVOA/IvoaUCD/NoteEMSpectrum-20040520.pdf A slightly revised list of words for UCD1+, with explanations on the choice of the top-level 'atoms' (branches): v0.1 http://www.ivoa.net/internal/IVOA/IvoaUCD/WD-UCDlist-20040520.pdf There is also an on-line form to leave feedback for deletion/ modification/addition of new words: http://cdsweb.u-strasbg.fr/UCD/cgi-bin/comment/ucdComments This can be a technical support for the board in charge of UCD1+, as it sends notifications by email when feedback is left. See you in Boston, 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 From pfo at star.le.ac.uk Tue May 4 04:41:15 2004 From: pfo at star.le.ac.uk (Patricio F. Ortiz) Date: Tue, 4 May 2004 12:41:15 +0100 (BST) Subject: towards UCD1+ In-Reply-To: <408D217A.58F8CB30@astro.u-strasbg.fr> Message-ID: 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 in the 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, UK From Alberto.Micol at eso.org Wed May 5 04:44:46 2004 From: Alberto.Micol at eso.org (Alberto Micol) Date: Wed, 05 May 2004 13:44:46 +0200 Subject: UCDs as substrings of other UCDs? Message-ID: <4098D3AE.5050209@eso.org> After having written my original message (see below) I found the solution to my problem (also explained below). I explicit the solution here first asking the following question: Would it be possible to change ::= | to ::= | ? To understand what I'm talking about, I think it's better to read the original message, unless you are good -damn good- at those games where given an answer you have to guess the question. Alberto PS: If you like to play, the subject probably helps ... --- original message, which explains the problem and the way I got to the above-mentioned solution--- Dear UCD builders, It would be very convenient NOT to allow a word to be a substring of other words. Example: Suppose the following two UCDs existed (I'm inventing here): 1. em.IR.H 2. em.IR.Hgamma (Luckily the second one is just only my invention, but it is just to illustrate the point) In this case 1. would be a substring of 2. Why it woud be bad? Because it would unnecessarily complicate a sql query to a table listing UCDs. A query like select * from whatever where UCD like "%em.IR.H%" would return not only the UCD I'm really interested in (em.IR.H) but also the em.IT.Hgamma. The way out, given the fact that UCDs are composed of multiple words semicolon separated, would be to use an "OR" but that is not so efficient: select * from whatever (could be a complicated join) where UCD like "%em.IR.H" or UCD like "%em.IR.H;%" OR, as said, are not efficiently handled. To simplify the usage of UCD in RDBMSes it would be nice to see such rule (not allowing substrings) explicited in the UCD document. I checked the UCD1+ list and I could not find any such case (probably by design?), a part from those obvious cases like em.IR being a substring of em.IR.H where the hierarchy is implied. Even these cases could be avoided if the high level UCD would be formulated differently, eg, em.IR.main (or em.IR.def, def for definition or default) instead of em.IR. But this is less disturbing then the example cited above. Actually, another way out would be to always terminate a word with the semicolon! even if at the end of UCD. E.g., "em.IR;" would do the job quite nicely. This could be avoided quite nicely by change the Backus-Naur definition to always end with a semicolon! Thanks, Alberto From Alberto.Micol at eso.org Wed May 5 05:43:43 2004 From: Alberto.Micol at eso.org (Alberto Micol) Date: Wed, 05 May 2004 14:43:43 +0200 Subject: UCDs as substrings of other UCDs? References: <4098D3AE.5050209@eso.org> Message-ID: <4098E17F.2000000@eso.org> > Would it be possible to change > ::= | > to > ::= > | > ? I forgot to mention that, obviously, also the Backus-Naur form for UCD should be changed accordingly, that is, by removing the which was moved to the level of a : ::= | Alberto PS: Basically, I find better to always have explicit separators, and not to rely on the implicit "end of string" one. From rgm at roe.ac.uk Fri May 7 07:54:08 2004 From: rgm at roe.ac.uk (Bob Mann) Date: Fri, 7 May 2004 15:54:08 +0100 (BST) Subject: towards UCD1+ In-Reply-To: <408D217A.58F8CB30@astro.u-strasbg.fr> References: <408D217A.58F8CB30@astro.u-strasbg.fr> Message-ID: Hi folks, I've read with interest the new document from Sebastien and Andrea, and the comments from Martin, Alberto and Patricio. I think that the new document is a clear statement of good principles, and is a significant improvement on the previous documents that have been circulated. I have only a few specific comments, but one general comment on skimming through the current list of UCDs > http://vizier.u-strasbg.fr/UCD/lists/ is that it still shows too strongly its origin in Vizier: a system that defines a specific term for a (b-y) Stromgren colour, but doesn't, so far as I can tell, provide a simple mechanism for denoting something as being an X-ray/optical flux ratio seems a little biased in its perspective to me. If UCD1+ is supposed to be modest in ambition, then my vote would be to have phot.fluxratio (or some such) and delete all the specific phot.color UCDs. One strength of the new document is the discussion of the matching functions. I'd not been convinced of their practical utility before, but I am now, after reading the example given. It would be interesting for that table of mu values to include those from the other proposed matching function, just to indicate how similar they are. I agree with Martin's suggestion that it would be preferable to use complete words, rather than abbreviations. Patricio's comment about equinoxes is an interesting one. The same goes for units, of course, since they are also additional metadata without which the data cannot be used in a meaningful way. But modifying UCD1+ to include grouping of UCDs, as he suggests, would seem to be a significant change, albeit one that is attractive from many points of view. I won't be attending the interoperability meeting in Boston, but I trust that the UCD discussion goes well there - it should, given that Sebastien and Andrea have given it a firm foundation with this document. cheers Bob From roy at caltech.edu Tue May 11 08:01:59 2004 From: roy at caltech.edu (Roy Williams) Date: Tue, 11 May 2004 08:01:59 -0700 Subject: towards UCD1+ References: <408D217A.58F8CB30@astro.u-strasbg.fr> <408F6FD3.6020009@dial.pipex.com> Message-ID: <032701c43768$e9ee1fc0$6701a8c0@Ropy> I would also like to thank Sebastien and Andrea for this excellent paper. I look forward to discussing in Boston the comments from Martin Hill, Patricio Ortiz, and Bob Mann. However, I think there needs to be an additional document showing the current state of the UCD1+ tree. A printable, versioned IVOA draft document. This will force the rigour of versioning, and allow the IVOA process to control the list of words. When Sebastian and Andrea want to make changes, they should not just change it arbitrarily, but rather build a new version of the UCD Tree document and run it past the IVOA, or the UCD Steering committee, or this mailing list. Is that too rigid and formal? Comments? Roy -------- California Institute of Technology roy at caltech.edu 626 395 3670 From posuna at iso.vilspa.esa.es Tue May 11 08:25:23 2004 From: posuna at iso.vilspa.esa.es (Pedro Osuna) Date: Tue, 11 May 2004 17:25:23 +0200 Subject: towards UCD1+ In-Reply-To: <032701c43768$e9ee1fc0$6701a8c0@Ropy> References: <408D217A.58F8CB30@astro.u-strasbg.fr> <408F6FD3.6020009@dial.pipex.com> <032701c43768$e9ee1fc0$6701a8c0@Ropy> Message-ID: <1084289123.12201.7381.camel@isol03.vilspa.esa.int> Hi Roy, we proposed to have a proper board for the control of the UCDs, and a centralized place where all UCD related issues (concerning the inclusion of new UCDs, procedures for request of inclusion of new UCDs, etc) should be handled. I would think it is time to implement this solution (chapter 9 of the latest UCD document). What I do not know is whether this should be agreed at a IVOA exec or what... What do you think? P. On Tue, 2004-05-11 at 17:01, Roy Williams wrote: > I would also like to thank Sebastien and Andrea for this excellent paper. > > I look forward to discussing in Boston the comments from Martin Hill, Patricio > Ortiz, and Bob Mann. > > However, I think there needs to be an additional document showing the current > state of the UCD1+ tree. A printable, versioned IVOA draft document. This will > force the rigour of versioning, and allow the IVOA process to control the list > of words. When Sebastian and Andrea want to make changes, they should not just > change it arbitrarily, but rather build a new version of the UCD Tree document > and run it past the IVOA, or the UCD Steering committee, or this mailing list. > > Is that too rigid and formal? Comments? > > Roy > > -------- > California Institute of Technology > roy at caltech.edu > 626 395 3670 -- Pedro Osuna Alcalaya Software Engineer VILSPA Archive Development Team e-mail: Pedro.Osuna at esa.int Tel + 34 91 8131314 European Space Agency VILLAFRANCA Satellites Tracking Station P.O. Box 50727 E-28080 Villafranca del Castillo MADRID - SPAIN From roy at caltech.edu Tue May 11 08:36:28 2004 From: roy at caltech.edu (Roy Williams) Date: Tue, 11 May 2004 08:36:28 -0700 Subject: towards UCD1+ References: <408D217A.58F8CB30@astro.u-strasbg.fr> <408F6FD3.6020009@dial.pipex.com> <032701c43768$e9ee1fc0$6701a8c0@Ropy> <1084289123.12201.7381.camel@isol03.vilspa.esa.int> Message-ID: <037a01c4376d$ba961f20$6701a8c0@Ropy> Yes I know. My idea is to have the UCD Steering Committee work with CDS on (a) The next version of the list of words -- working through the IVOA drafting process. (b) The application of UCD in the Simple Data Services (cone, SIAP, SSAP) Are you coming to Boston? Roy -------- California Institute of Technology roy at caltech.edu 626 395 3670 ----- Original Message ----- From: "Pedro Osuna" To: "Roy Williams" Cc: ; Sent: Tuesday, May 11, 2004 8:25 AM Subject: Re: towards UCD1+ > Hi Roy, > > we proposed to have a proper board for the control of the UCDs, and a > centralized place where all UCD related issues (concerning the inclusion > of new UCDs, procedures for request of inclusion of new UCDs, etc) > should be handled. I would think it is time to implement this solution > (chapter 9 of the latest UCD document). What I do not know is whether > this should be agreed at a IVOA exec or what... What do you think? > > P. > > On Tue, 2004-05-11 at 17:01, Roy Williams wrote: > > I would also like to thank Sebastien and Andrea for this excellent paper. > > > > I look forward to discussing in Boston the comments from Martin Hill, Patricio > > Ortiz, and Bob Mann. > > > > However, I think there needs to be an additional document showing the current > > state of the UCD1+ tree. A printable, versioned IVOA draft document. This will > > force the rigour of versioning, and allow the IVOA process to control the list > > of words. When Sebastian and Andrea want to make changes, they should not just > > change it arbitrarily, but rather build a new version of the UCD Tree document > > and run it past the IVOA, or the UCD Steering committee, or this mailing list. > > > > Is that too rigid and formal? Comments? > > > > Roy > > > > -------- > > California Institute of Technology > > roy at caltech.edu > > 626 395 3670 > -- > Pedro Osuna Alcalaya > > > Software Engineer > VILSPA Archive Development Team > e-mail: Pedro.Osuna at esa.int > Tel + 34 91 8131314 > > European Space Agency > VILLAFRANCA Satellites Tracking Station > P.O. Box 50727 > E-28080 Villafranca del Castillo > MADRID - SPAIN > > > From posuna at iso.vilspa.esa.es Tue May 11 08:40:33 2004 From: posuna at iso.vilspa.esa.es (Pedro Osuna) Date: Tue, 11 May 2004 17:40:33 +0200 Subject: towards UCD1+ In-Reply-To: <037a01c4376d$ba961f20$6701a8c0@Ropy> References: <408D217A.58F8CB30@astro.u-strasbg.fr> <408F6FD3.6020009@dial.pipex.com> <032701c43768$e9ee1fc0$6701a8c0@Ropy> <1084289123.12201.7381.camel@isol03.vilspa.esa.int> <037a01c4376d$ba961f20$6701a8c0@Ropy> Message-ID: <1084290033.12201.7392.camel@isol03.vilspa.esa.int> Yes, I will arrive there on saturday the 22nd with Jesus Salgado for whatever might be needed (including beers on sunday, if applicable). P. On Tue, 2004-05-11 at 17:36, Roy Williams wrote: > Yes I know. > > My idea is to have the UCD Steering Committee work with CDS on > > (a) The next version of the list of words -- working through the IVOA drafting > process. > > (b) The application of UCD in the Simple Data Services (cone, SIAP, SSAP) > > Are you coming to Boston? > Roy > > > -------- > California Institute of Technology > roy at caltech.edu > 626 395 3670 > ----- Original Message ----- > From: "Pedro Osuna" > To: "Roy Williams" > Cc: ; > Sent: Tuesday, May 11, 2004 8:25 AM > Subject: Re: towards UCD1+ > > > > Hi Roy, > > > > we proposed to have a proper board for the control of the UCDs, and a > > centralized place where all UCD related issues (concerning the inclusion > > of new UCDs, procedures for request of inclusion of new UCDs, etc) > > should be handled. I would think it is time to implement this solution > > (chapter 9 of the latest UCD document). What I do not know is whether > > this should be agreed at a IVOA exec or what... What do you think? > > > > P. > > > > On Tue, 2004-05-11 at 17:01, Roy Williams wrote: > > > I would also like to thank Sebastien and Andrea for this excellent paper. > > > > > > I look forward to discussing in Boston the comments from Martin Hill, > Patricio > > > Ortiz, and Bob Mann. > > > > > > However, I think there needs to be an additional document showing the > current > > > state of the UCD1+ tree. A printable, versioned IVOA draft document. This > will > > > force the rigour of versioning, and allow the IVOA process to control the > list > > > of words. When Sebastian and Andrea want to make changes, they should not > just > > > change it arbitrarily, but rather build a new version of the UCD Tree > document > > > and run it past the IVOA, or the UCD Steering committee, or this mailing > list. > > > > > > Is that too rigid and formal? Comments? > > > > > > Roy > > > > > > -------- > > > California Institute of Technology > > > roy at caltech.edu > > > 626 395 3670 > > -- > > Pedro Osuna Alcalaya > > > > > > Software Engineer > > VILSPA Archive Development Team > > e-mail: Pedro.Osuna at esa.int > > Tel + 34 91 8131314 > > > > European Space Agency > > VILLAFRANCA Satellites Tracking Station > > P.O. Box 50727 > > E-28080 Villafranca del Castillo > > MADRID - SPAIN > > > > > > -- Pedro Osuna Alcalaya Software Engineer VILSPA Archive Development Team e-mail: Pedro.Osuna at esa.int Tel + 34 91 8131314 European Space Agency VILLAFRANCA Satellites Tracking Station P.O. Box 50727 E-28080 Villafranca del Castillo MADRID - SPAIN From roy at caltech.edu Mon May 17 11:37:19 2004 From: roy at caltech.edu (Roy Williams) Date: Mon, 17 May 2004 11:37:19 -0700 Subject: UCD agenda and UCD/DAL agenda Message-ID: <0a8e01c43c3d$fc8765e0$0c0ba8c0@cacr.caltech.edu> Please find below a suggested draft agenda for the UCD session at the Interop meeting. Note that the second half is joint with the DAL group. If you would like to contribute to the session, or change the agenda below, please drop me a line. Roy ---------------------------------------------- UCD working group Agenda for Interop meeting 1. Sebastien Derriere, UCD Services at CDS 2. Andrea Preite-Martinez, Realization of UCD1+ 3. Roy Williams, UCDs for the Image Access Protocol 4. Doug Tody, UCDs for the Spectral Access Protocol -------- California Institute of Technology roy at caltech.edu 626 395 3670 From derriere at newb6.u-strasbg.fr Fri May 21 10:37:10 2004 From: derriere at newb6.u-strasbg.fr (Sebastien Derriere) Date: Fri, 21 May 2004 19:37:10 +0200 Subject: UCD material Message-ID: <40AE3E46.57E45165@astro.u-strasbg.fr> Hello, I have placed on the IVOA Wiki some new documents: http://www.ivoa.net/twiki/bin/view/IVOA/IvoaUCD A revised version of the EM Spectrum division for UCD v0.3 (following the registry main domains): http://www.ivoa.net/internal/IVOA/IvoaUCD/NoteEMSpectrum-20040520.pdf A slightly revised list of words for UCD1+, with explanations on the choice of the top-level 'atoms' (branches): v0.1 http://www.ivoa.net/internal/IVOA/IvoaUCD/WD-UCDlist-20040520.pdf There is also an on-line form to leave feedback for deletion/ modification/addition of new words: http://cdsweb.u-strasbg.fr/UCD/cgi-bin/comment/ucdComments This can be a technical support for the board in charge of UCD1+, as it sends notifications by email when feedback is left. See you in Boston, 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