From jdsant at iaa.es Wed Nov 2 04:44:50 2005 From: jdsant at iaa.es (Juan de Dios Santander Vela) Date: Wed, 2 Nov 2005 13:44:50 +0100 Subject: UCD versioning? In-Reply-To: <6E25F7C3-4800-48FE-8A21-A3CC64C5C09D@noao.edu> References: <6E25F7C3-4800-48FE-8A21-A3CC64C5C09D@noao.edu> Message-ID: El 25/10/2005, a las 0:51, Rob Seaman escribi?: > Could someone summarize how UCD versioning is - or is not - > supposed to work? Alternately, feel free to point me toward > pertinent discussions. I'm really interested in this topic, too, and I think at least it should be known whether: a) The community is prepared to have several UCD versions, and has a plan for it b) The only versioning that has been thought is from old UCD (in the ROOTELEMENT_SUBELEMENT form) to UCD1+ (rootelement.subelement), and versioning through the schema; that would allow, I think, at least to know whether and old piece of software needs to be updated to cope with new UCDs, but no new meanigns, I guess... c) UCD1+ is the last version of the UCD, and will be superseded by "ontologies", when they're defined... Thanks to all in advance! -- Juan de Dios Santander Vela Diplomado en CC. F?sicas, Ingeniero en Electr?nica Doctorando en Tecnolog?as Multimedia Becario Predoctoral del Instituto de Astrof?sica de Andaluc?a Indiviudo: D?cese del hombre que pierde a su mujer en un momento ?nico. From andrea.preitemartinez at rm.iasf.cnr.it Mon Nov 7 07:47:55 2005 From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez) Date: Mon, 07 Nov 2005 16:47:55 +0100 Subject: No subject Message-ID: <20051107164755.cwtk98wgjvq8gkk8@webmail.sic.rm.cnr.it> Dear all, I received from the IVOA Exec a request to modify all UCD1+ words that do not conform to what is said in the standard UCD document, i.e.: UCD1+ words at the same level in the hierarchy cannot be a starting substring of another that is, we cannot have phot.flux and phot.fluxDens As you know, the document at http://www.ivoa.net/Documents/latest/UCDlist.html is in the PR status, and will be moved to IVOA Recommendation after an appropriate action on the words concerned. The rule mentioned above is violated for the following ucd1+ words: E | phot.fluxDens | Flux density (per wl/freq/energy interval) E | phot.fluxDens.sb | Flux density surface brightness Q | phys.atmol | Atomic and molecular physics (shared properties) Q | phys.atmol.branchingRatio | Branching ratio Q | phys.atmol.coll | Related to collisions Q | phys.atmol.configuration | Configuration Q | phys.atmol.crossSection | Atomic / molecular cross-section Q | phys.atmol.element | Element Q | phys.atmol.excitation | Atomic molecular excitation parameter Q | phys.atmol.final | Quantity refers to atomic/molecular final/ground state, level, ecc. Q | phys.atmol.initial | Quantity refers to atomic/molecular initial state, level, ecc. Q | phys.atmol.ion | Ion S | phys.atmol.ionization | Related to ionization S | phys.atmol.level | Atomic level Q | phys.atmol.lifetime | Lifetime of a level Q | phys.atmol.lineShift | Line shifting coefficient Q | phys.atmol.parity | Parity Q | phys.atmol.sweight | Statistical weight S | phys.atmol.trans | Transition between states Q | phys.energyDensity | Energy-density Q | phys.massToLight | Mass to light ratio Q | phys.massYield | Mass yield because of the already existing words phot.flux phys.at phys.energy phys.mass In order to reach a rapid convergence on the reformulation of these words, I?m suggesting a possible solution for each of them in the list that follows: Present Suggested new E | phot.fluxDens | phot.flux.fluxDens or: phot.flux.density E | phot.fluxDens.sb | phot.flux.fluxDens.sb or: phot.flux.density.sb Q | phys.atmol | suppress Q | phys.atmol.branchingRatio | phys.branchingRatio Q | phys.atmol.coll | phys.collision Q | phys.atmol.configuration | phys.state.configuration Q | phys.atmol.crossSection | phys.crossSection Q | phys.atmol.element | phys.element Q | phys.atmol.excitation | phys.excitation Q | phys.atmol.final | phys.state.final Q | phys.atmol.initial | phys.state.initial Q | phys.atmol.ion | phys.element.ion S | phys.atmol.ionization | phys.ionization S | phys.atmol.level | phys.level Q | phys.atmol.lifetime | phys.level.lifetime Q | phys.atmol.lineShift | phys.lineShift Q | phys.atmol.parity | phys.state.parity Q | phys.atmol.sweight | phys.state.sweight S | phys.atmol.trans | phys.state.trans Q | phys.energyDensity | phys.energy.density Q | phys.massToLight | phys.mass.light Q | phys.massYield | phys.mass.yield The other possibility for the phys.atmol.xxx group is to suppress the word phys.at Please let me know your opinion and/or your suggestions. Andrea ============================================================================== Andrea Preite Martinez andrea.preitemartinez at rm.iasf.cnr.it Istituto di Astrofisica Spaziale Tel.:+39.06.4993.4641 Area di Ricerca di Tor Vergata Fax.:+39.06.2066.0188 Via del Fosso del Cavaliere 100 Cell:+39.320.43.15.383 00133 Roma CDS :+33.3.90242473 ============================================================================== From Alberto.Micol at eso.org Mon Nov 7 08:35:16 2005 From: Alberto.Micol at eso.org (Alberto Micol) Date: Mon, 7 Nov 2005 17:35:16 +0100 Subject: In-Reply-To: <20051107164755.cwtk98wgjvq8gkk8@webmail.sic.rm.cnr.it> References: <20051107164755.cwtk98wgjvq8gkk8@webmail.sic.rm.cnr.it> Message-ID: <718d8e4897942ec4822d14397eb0ceb2@eso.org> Hi Andrea, Sorry to come back with this, but there is another possibility... If we state that each UCD word MUST end with the ';' character, -that is, even if there are no other subsequent words- then no UCD can ever be a substring of another one. Example: phot.flux; is not a substring of phot.fluxDens; The beauty of it is that no other changes are required. It is my laziness... I always prefer to change the least... Alberto PS: I send this email because I'm sure you are expecting it from me ;-) PPS: And I promise that this is the last time I mention this. On Nov 7, 2005, at 16:47, Andrea Preite Martinez wrote: > Dear all, > > I received from the IVOA Exec a request to modify all UCD1+ words that > do not conform to what is said in the standard UCD document, i.e.: > > UCD1+ words at the same level in the hierarchy cannot be a starting > substring of another > > that is, we cannot have phot.flux and phot.fluxDens > > As you know, the document at > http://www.ivoa.net/Documents/latest/UCDlist.html > is in the PR status, and will be moved to IVOA Recommendation after an > appropriate action on the words concerned. > > The rule mentioned above is violated for the following ucd1+ words: > > E | phot.fluxDens | Flux density (per wl/freq/energy > interval) > E | phot.fluxDens.sb | Flux density surface brightness > Q | phys.atmol | Atomic and molecular physics (shared > properties) > Q | phys.atmol.branchingRatio | Branching ratio > Q | phys.atmol.coll | Related to collisions > Q | phys.atmol.configuration | Configuration > Q | phys.atmol.crossSection | Atomic / molecular cross-section > Q | phys.atmol.element | Element > Q | phys.atmol.excitation | Atomic molecular excitation parameter > Q | phys.atmol.final | Quantity refers to atomic/molecular > final/ground state, level, ecc. > Q | phys.atmol.initial | Quantity refers to atomic/molecular > initial state, level, ecc. > Q | phys.atmol.ion | Ion > S | phys.atmol.ionization | Related to ionization > S | phys.atmol.level | Atomic level > Q | phys.atmol.lifetime | Lifetime of a level > Q | phys.atmol.lineShift | Line shifting coefficient > Q | phys.atmol.parity | Parity > Q | phys.atmol.sweight | Statistical weight > S | phys.atmol.trans | Transition between states > Q | phys.energyDensity | Energy-density > Q | phys.massToLight | Mass to light ratio > Q | phys.massYield | Mass yield > > because of the already existing words > phot.flux > phys.at > phys.energy > phys.mass > > In order to reach a rapid convergence on the reformulation of these > words, I?m suggesting a possible solution for each of them in the list > that follows: > > Present Suggested new > E | phot.fluxDens | phot.flux.fluxDens or: > phot.flux.density > E | phot.fluxDens.sb | phot.flux.fluxDens.sb or: > phot.flux.density.sb > Q | phys.atmol | suppress > Q | phys.atmol.branchingRatio | phys.branchingRatio > Q | phys.atmol.coll | phys.collision > Q | phys.atmol.configuration | phys.state.configuration > Q | phys.atmol.crossSection | phys.crossSection > Q | phys.atmol.element | phys.element > Q | phys.atmol.excitation | phys.excitation > Q | phys.atmol.final | phys.state.final > Q | phys.atmol.initial | phys.state.initial > Q | phys.atmol.ion | phys.element.ion S | > phys.atmol.ionization | phys.ionization > S | phys.atmol.level | phys.level > Q | phys.atmol.lifetime | phys.level.lifetime > Q | phys.atmol.lineShift | phys.lineShift > Q | phys.atmol.parity | phys.state.parity > Q | phys.atmol.sweight | phys.state.sweight > S | phys.atmol.trans | phys.state.trans Q | > phys.energyDensity | phys.energy.density > Q | phys.massToLight | phys.mass.light > Q | phys.massYield | phys.mass.yield > > The other possibility for the phys.atmol.xxx group is to suppress the > word phys.at > > Please let me know your opinion and/or your suggestions. > > Andrea > > > ======================================================================= > ======= > Andrea Preite Martinez > andrea.preitemartinez at rm.iasf.cnr.it > Istituto di Astrofisica Spaziale Tel.:+39.06.4993.4641 > Area di Ricerca di Tor Vergata Fax.:+39.06.2066.0188 > Via del Fosso del Cavaliere 100 Cell:+39.320.43.15.383 > 00133 Roma CDS :+33.3.90242473 > ======================================================================= > ======= > > Alberto Micol ST-ECF HST Archive Scientist From pdidelon at cea.fr Mon Nov 7 08:44:28 2005 From: pdidelon at cea.fr (Pierre Didelon) Date: Mon, 07 Nov 2005 17:44:28 +0100 Subject: In-Reply-To: <20051107164755.cwtk98wgjvq8gkk8@webmail.sic.rm.cnr.it> References: <20051107164755.cwtk98wgjvq8gkk8@webmail.sic.rm.cnr.it> Message-ID: <436F846C.3010009@cea.fr> Andrea Preite Martinez wrote: > Dear all, > > I received from the IVOA Exec a request to modify all UCD1+ words that > do not conform to what is said in the standard UCD document, i.e.: > > UCD1+ words at the same level in the hierarchy cannot be a starting > substring of another > > that is, we cannot have phot.flux and phot.fluxDens > > As you know, the document at > http://www.ivoa.net/Documents/latest/UCDlist.html > is in the PR status, and will be moved to IVOA Recommendation after an > appropriate action on the words concerned. > > The rule mentioned above is violated for the following ucd1+ words: > > E | phot.fluxDens | Flux density (per wl/freq/energy interval) > E | phot.fluxDens.sb | Flux density surface brightness > Q | phys.atmol | Atomic and molecular physics (shared properties) [SNIP]... > Q | phys.energyDensity | Energy-density > Q | phys.massToLight | Mass to light ratio > Q | phys.massYield | Mass yield > > because of the already existing words > phot.flux > phys.at > phys.energy > phys.mass > > In order to reach a rapid convergence on the reformulation of these > words, I?m suggesting a possible solution for each of them in the list > that follows: > > Present Suggested new > E | phot.fluxDens | phot.flux.fluxDens or: phot.flux.density > E | phot.fluxDens.sb | phot.flux.fluxDens.sb or: phot.flux.density.sb The second formulation seems more logical but then fluxDens atom desapear, is this a pb? [SNIP] > > The other possibility for the phys.atmol.xxx group is to suppress the > word phys.at why not modifying phys.at.xxx group to phys.atom.xxx > > Please let me know your opinion and/or your suggestions. > > Andrea > > > ============================================================================== > > Andrea Preite Martinez > andrea.preitemartinez at rm.iasf.cnr.it > Istituto di Astrofisica Spaziale Tel.:+39.06.4993.4641 > Area di Ricerca di Tor Vergata Fax.:+39.06.2066.0188 > Via del Fosso del Cavaliere 100 Cell:+39.320.43.15.383 > 00133 Roma CDS :+33.3.90242473 > ============================================================================== > > > SY -- Pierre ------------------------------------------------------------------ DIDELON :@: pdidelon_at_cea.fr Phone : 33 (0)1 69 08 58 89 CEA SACLAY - Service d'Astrophysique 91191 Gif-Sur-Yvette Cedex ------------------------------------------------------------------ Aidez les enfants Tib?tains : http://www.a-e-t.org/jcparrain.htm ou d'autres : http://www.sosesf.org/ ------------------------------------------------------------------ From ndelmott at eso.org Mon Nov 7 09:27:06 2005 From: ndelmott at eso.org (Nausicaa Delmotte) Date: Mon, 07 Nov 2005 18:27:06 +0100 Subject: In-Reply-To: <718d8e4897942ec4822d14397eb0ceb2@eso.org> References: <20051107164755.cwtk98wgjvq8gkk8@webmail.sic.rm.cnr.it> <718d8e4897942ec4822d14397eb0ceb2@eso.org> Message-ID: <436F8E6A.3000107@eso.org> Hi, But what is preventing us from adding the semicolon as ending separator? I do apologize for asking a question that seems to have already been answered in the past, but I could not find the answer in the archive mailing-list and since I did not follow all the UCD developments from the very beginning, probably I missed something. Could anybody give me a pointer to a discussion or a very brief comment on it? Or is it maybe to avoid having a possible NULL word at the end when parsing a UCD, assuming the ending semicolon? Thank you Nausicaa Alberto Micol wrote: > > Hi Andrea, > > Sorry to come back with this, but there is another possibility... > If we state that each UCD word MUST end with the ';' character, > -that is, even if there are no other subsequent words- then > no UCD can ever be a substring of another one. > > Example: > > phot.flux; is not a substring of phot.fluxDens; > > The beauty of it is that no other changes are required. > > It is my laziness... I always prefer to change the least... > > Alberto > PS: I send this email because I'm sure you are expecting it from me ;-) > PPS: And I promise that this is the last time I mention this. > > On Nov 7, 2005, at 16:47, Andrea Preite Martinez wrote: > >> Dear all, >> >> I received from the IVOA Exec a request to modify all UCD1+ words >> that do not conform to what is said in the standard UCD document, i.e.: >> >> UCD1+ words at the same level in the hierarchy cannot be a starting >> substring of another >> >> that is, we cannot have phot.flux and phot.fluxDens >> >> As you know, the document at >> http://www.ivoa.net/Documents/latest/UCDlist.html >> is in the PR status, and will be moved to IVOA Recommendation after >> an appropriate action on the words concerned. >> >> The rule mentioned above is violated for the following ucd1+ words: >> >> E | phot.fluxDens | Flux density (per wl/freq/energy >> interval) >> E | phot.fluxDens.sb | Flux density surface brightness >> Q | phys.atmol | Atomic and molecular physics >> (shared properties) >> Q | phys.atmol.branchingRatio | Branching ratio >> Q | phys.atmol.coll | Related to collisions >> Q | phys.atmol.configuration | Configuration >> Q | phys.atmol.crossSection | Atomic / molecular cross-section >> Q | phys.atmol.element | Element >> Q | phys.atmol.excitation | Atomic molecular excitation parameter >> Q | phys.atmol.final | Quantity refers to atomic/molecular >> final/ground state, level, ecc. >> Q | phys.atmol.initial | Quantity refers to atomic/molecular >> initial state, level, ecc. >> Q | phys.atmol.ion | Ion >> S | phys.atmol.ionization | Related to ionization >> S | phys.atmol.level | Atomic level >> Q | phys.atmol.lifetime | Lifetime of a level >> Q | phys.atmol.lineShift | Line shifting coefficient >> Q | phys.atmol.parity | Parity >> Q | phys.atmol.sweight | Statistical weight >> S | phys.atmol.trans | Transition between states >> Q | phys.energyDensity | Energy-density >> Q | phys.massToLight | Mass to light ratio >> Q | phys.massYield | Mass yield >> >> because of the already existing words >> phot.flux >> phys.at >> phys.energy >> phys.mass >> >> In order to reach a rapid convergence on the reformulation of these >> words, I?m suggesting a possible solution for each of them in the >> list that follows: >> >> Present Suggested new >> E | phot.fluxDens | phot.flux.fluxDens or: >> phot.flux.density >> E | phot.fluxDens.sb | phot.flux.fluxDens.sb or: >> phot.flux.density.sb >> Q | phys.atmol | suppress >> Q | phys.atmol.branchingRatio | phys.branchingRatio >> Q | phys.atmol.coll | phys.collision >> Q | phys.atmol.configuration | phys.state.configuration >> Q | phys.atmol.crossSection | phys.crossSection >> Q | phys.atmol.element | phys.element >> Q | phys.atmol.excitation | phys.excitation >> Q | phys.atmol.final | phys.state.final >> Q | phys.atmol.initial | phys.state.initial >> Q | phys.atmol.ion | phys.element.ion S | >> phys.atmol.ionization | phys.ionization >> S | phys.atmol.level | phys.level >> Q | phys.atmol.lifetime | phys.level.lifetime >> Q | phys.atmol.lineShift | phys.lineShift >> Q | phys.atmol.parity | phys.state.parity >> Q | phys.atmol.sweight | phys.state.sweight >> S | phys.atmol.trans | phys.state.trans Q | >> phys.energyDensity | phys.energy.density >> Q | phys.massToLight | phys.mass.light >> Q | phys.massYield | phys.mass.yield >> >> The other possibility for the phys.atmol.xxx group is to suppress the >> word phys.at >> >> Please let me know your opinion and/or your suggestions. >> >> Andrea >> >> >> ======================================================================= >> ======= >> Andrea Preite Martinez >> andrea.preitemartinez at rm.iasf.cnr.it >> Istituto di Astrofisica Spaziale Tel.:+39.06.4993.4641 >> Area di Ricerca di Tor Vergata Fax.:+39.06.2066.0188 >> Via del Fosso del Cavaliere 100 Cell:+39.320.43.15.383 >> 00133 Roma CDS :+33.3.90242473 >> ======================================================================= >> ======= >> >> > Alberto Micol > ST-ECF HST Archive Scientist -- Dr Nausicaa Delmotte @..@ ndelmott at eso.org European Southern Observatory (----) Tel: +49 (0)89 3200 6418 Karl-Schwarzschild-Str. 2 ( >__< ) Fax: +49 (0)89 3200 6480 D-85748 Garching bei Muenchen ^^ ~~ ^^ http://www.eso.org/~ndelmott/ From pfo at star.le.ac.uk Mon Nov 7 09:40:56 2005 From: pfo at star.le.ac.uk (Patricio F. Ortiz) Date: Mon, 7 Nov 2005 18:40:56 +0100 Subject: In-Reply-To: <20051107164755.cwtk98wgjvq8gkk8@webmail.sic.rm.cnr.it> References: <20051107164755.cwtk98wgjvq8gkk8@webmail.sic.rm.cnr.it> Message-ID: <6666189c0511070940s2c46e854qc2fcfbee82efcb9e@mail.gmail.com> Hi Andrea (et al :-) Well, maybe we should ask ourselves if we should ditch the rule! I mean, why is it that substrings are not allowed? Is it because of impleemntation issues (eg, recovering data based on UCDs)? I personally see little use for that rule (perhaps it was written without looking at the existing UCDs)? I see Alberto's point to go for the simplest solution, but I'd go one step further :-) :-) Cheers, Patricio On 11/7/05, Andrea Preite Martinez wrote: > Dear all, > > I received from the IVOA Exec a request to modify all UCD1+ words that > do not conform to what is said in the standard UCD document, i.e.: > > UCD1+ words at the same level in the hierarchy cannot be a starting > substring of another > From jat at star.le.ac.uk Mon Nov 7 09:49:36 2005 From: jat at star.le.ac.uk (Jonathan Tedds) Date: Mon, 7 Nov 2005 17:49:36 +0000 (GMT) Subject: In-Reply-To: <6666189c0511070940s2c46e854qc2fcfbee82efcb9e@mail.gmail.com> References: <20051107164755.cwtk98wgjvq8gkk8@webmail.sic.rm.cnr.it> <6666189c0511070940s2c46e854qc2fcfbee82efcb9e@mail.gmail.com> Message-ID: Patricio is surely right? There is a simple and added value to the logic of the substring approach so please can someone provide the justification that was put forward for not using it? A bit of extra coding effort (if even needed as others have alluded to?) will keep the interface to the more general user at a more intuitive level. Thanks, Jonathan -------------------------------------------------------------------- Dr Jonathan Tedds, Tel: +44 (0)116 252 3502 XMM-Newton Surveys & AstroGrid Science, Fax: +44 (0)116 252 3311 Department of Physics and Astronomy, University of Leicester, Email: jat at star.le.ac.uk Leicester LE1 7RH, UK http://xmmssc-www.star.le.ac.uk/~jat -------------------------------------------------------------------- On Mon, 7 Nov 2005, Patricio F. Ortiz wrote: > Hi Andrea (et al :-) > > Well, maybe we should ask ourselves if we should ditch the rule! I > mean, why is it that substrings are not allowed? Is it because of > impleemntation issues (eg, recovering data based on UCDs)? I > personally see little use for that rule (perhaps it was written > without looking at the existing UCDs)? > > I see Alberto's point to go for the simplest solution, but I'd go one > step further :-) :-) > > Cheers, > > Patricio > On 11/7/05, Andrea Preite Martinez wrote: > > Dear all, > > > > I received from the IVOA Exec a request to modify all UCD1+ words that > > do not conform to what is said in the standard UCD document, i.e.: > > > > UCD1+ words at the same level in the hierarchy cannot be a starting > > substring of another > > > > From derriere at newb6.u-strasbg.fr Mon Nov 7 11:13:01 2005 From: derriere at newb6.u-strasbg.fr (Sebastien Derriere) Date: Mon, 07 Nov 2005 20:13:01 +0100 Subject: References: <20051107164755.cwtk98wgjvq8gkk8@webmail.sic.rm.cnr.it> <436F846C.3010009@cea.fr> Message-ID: <436FA73D.33150E@astro.u-strasbg.fr> Hi, I'd be in favor of not changing the UCD Rec, and trying to follow the guidelines, therefore changing: phot.fluxDens phot.flux.density phot.fluxDens.sb phot.flux.density.sb phys.energyDensity phys.energy.density phys.massToLight phys.mass.light or phys.MLratio phys.massYield phys.mass.yield or phys.elementYield and also as Pierre suggested: phys.at phys.atom (also changing words at levels below phys.at) The debate on the usefulness of the semicolon at the end of the UCD1+ was concluded by introducing this rule of "no word should be substring of another at the same level". The main motivation was that users would be reluctant to add a ; at the end of every UCD. With the suggested rule, UCD curators have to be careful when defining new words (what we do now, but only once hopefully), but users life is made slightly easier. 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 jcm at head.cfa.harvard.edu Mon Nov 7 20:21:21 2005 From: jcm at head.cfa.harvard.edu (Jonathan McDowell) Date: Mon, 7 Nov 2005 23:21:21 -0500 (EST) Subject: Message-ID: <200511080421.jA84LL8f004051@sothis.cfa.harvard.edu> Dear Andrea and others, 1) In the first place, I never liked that rule. Alberto's suggestion could be implemented in the UCD-analysing software - in other words, I don't actually bother adding a terminal semicolon to my phot.fluxDens but when you pass it to your search/comparison tool, a trailing semicolon gets added automatically phot.fluxDens; This is a classic case of wanting to avoid writing 3 lines of code, and making things annoying for human readability and comprehension. 2) Nevertheless, the rule is what we adopted. > Present Suggested new > E | phot.fluxDens | phot.flux.fluxDens or: > phot.flux.density > E | phot.fluxDens.sb | phot.flux.fluxDens.sb or: > phot.flux.density.sb I agree that the second choices phot.flux.density.* are better. (Pierre - I don't think losing the fluxDens atom is a problem.) OK: > Q | phys.energyDensity | phys.energy.density I don't like this, since it's not a mass, it's a ratio. It's really talking about the composition of the physical environment (how much baryons, how much photons, etc.) Maybe phys.composition.massLight (or phys.abund.massLight) > Q | phys.massToLight | phys.mass.light Can you remind me what this means exactly? Is it a percentage, or e.g. an SNe yield of iron in solar masses? > Q | phys.massYield | phys.mass.yield I don't like suppressing the atmol element. It makes the UCDs too flat. We could just make them all "at" and explain that "at" includes "atmol". But if we are willing to make a bigger change, we can take something from the work of the DM At/Mol team: some of these items are species (atmol, particle), some are states (levels), some are transitions and interactions. I think it's clear that states and levels are associated with particles in a way that phys.mass.yield is not, so I would be in favor of > Q | phys.atmol | suppress > Q | phys.atmol.element | phys.species.element > Q | phys.atmol.excitation | phys.species.excitation > Q | phys.atmol.ion | phys.species.ion > S | phys.atmol.ionization | phys.species.ionization Q | phys.at.number | phys.species.atomicNumber Q | phys.at.weight | phys.species.weight > Q | phys.atmol.branchingRatio | phys.transition.branchingRatio > Q | phys.atmol.coll | phys.transition.collision > Q | phys.atmol.crossSection | phys.transition.crossSection > Q | phys.atmol.lineShift | phys.transition.lineShift > S | phys.atmol.trans | phys.transition.trans Q | phys.at.collStrength | phys.transition.collStrength Q | phys.at.damping | phys.transition.damping Q | phys.at.lande | phys.transition.Lande factor Q | phys.at.oscStrength | phys.transition.oscStrength Q | phys.at.radiationType | phys.transition.radiationType Q | phys.at.term | phys.transition.term Q | phys.at.transProb | phys.transition.prob Q | phys.at.wOscStrength | phys.transition.wOscStrength > Q | phys.atmol.parity | phys.state.parity > Q | phys.atmol.sweight | phys.state.sweight > Q | phys.atmol.configuration | phys.state.configuration > Q | phys.atmol.final | phys.state.final > Q | phys.atmol.initial | phys.state.initial > S | phys.atmol.level | phys.state.level > Q | phys.atmol.lifetime | phys.state.lifetime Q | phys.at.qn | phys.state.qn Q | phys.at.qn.I | phys.state.qn.I - Jonathan From hessman at astro.physik.uni-goettingen.de Tue Nov 8 01:28:59 2005 From: hessman at astro.physik.uni-goettingen.de (Frederic V. "Rick" Hessman) Date: Tue, 8 Nov 2005 10:28:59 +0100 Subject: In-Reply-To: <200511080421.jA84LL8f004051@sothis.cfa.harvard.edu> References: <200511080421.jA84LL8f004051@sothis.cfa.harvard.edu> Message-ID: <0F56C61F-8EAD-4A51-AF9E-53F3504D730D@astro.physik.uni-goettingen.de> > >> Present Suggested new >> E | phot.fluxDens | phot.flux.fluxDens or: >> phot.flux.density >> E | phot.fluxDens.sb | phot.flux.fluxDens.sb or: >> phot.flux.density.sb >> > > I agree that the second choices phot.flux.density.* are better. > (Pierre - I don't think losing the fluxDens atom is a problem.) Don't want to step on any radio astronomer's toes, but flux density is flux. Yes, I know, it's monochromatic flux per unit frequency, but where's the distinction between bolometric flux, monochromatic flux per unit frequency, and monochromatic flux per unit wavelength? Do we also then have to support the use of candela's, lux's, and the lot - also physical (even SI!) terms for the same things? How about (see, e.g., Mihalas): phot.flux generic net rate of radiant energy flow per unit area and time phot.flux.freq monochromatic flux per unit frequency, flux density phot.flux.wave monochromatic flux per unit wavelength phot.flux.bol bolometric flux phot.flux.Eddington Eddington flux = flux / 4PI I was going to suggest adding phot.flux.astr (that terrible factor of PI or /1PI, depending upon how you look at it!), but I won't...... >>> Q | phys.massToLight | phys.mass.light >>> > I don't like this, since it's not a mass, it's a ratio. > It's really talking about the composition of the physical > environment (how much baryons, how much photons, etc.) > Maybe phys.composition.massLight (or phys.abund.massLight) I prefer phys.composition.massLightRatio Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alberto.Micol at eso.org Tue Nov 8 01:53:32 2005 From: Alberto.Micol at eso.org (Alberto Micol) Date: Tue, 8 Nov 2005 10:53:32 +0100 Subject: In-Reply-To: <436FA73D.33150E@astro.u-strasbg.fr> References: <20051107164755.cwtk98wgjvq8gkk8@webmail.sic.rm.cnr.it> <436F846C.3010009@cea.fr> <436FA73D.33150E@astro.u-strasbg.fr> Message-ID: <008163c808564638c8a7415ae632b893@eso.org> Dear All, When we change UCDs we have to be careful, because those UCDs are probably already used out there. The same is true for the parsing (or writing) software, but I guess there is much less parsing software to change than there are catalogues making use of those UCDs. (And the suggested s/w change was really minimal) Nevertheless, mine (the ending semicolon) is a lost battle, I accept defeat. Overall, I think that the number of atoms should be kept small and structured, otherwise it become very difficult for data providers to assign UCDs in a consistent way. Having said that, I like the new structured atoms introduced by Jonathan (transition, state, species), exactly because "structure is good". Instead, I'm a bit skeptical regarding phys.energy.density and phot.flux.fluxDens or phot.flux.density. It is tempting to use: phys.energy;phys.density and phot.flux;phys.density Would that be so wrong? A couple of answers: Sebastien Derriere wrote: > > The debate on the usefulness of the semicolon at the end of the > UCD1+ > was concluded by introducing this rule of "no word should be substring > of another > at the same level". > The main motivation was that users would be reluctant to add a ; > at the end of every UCD. It is not affecting the end user, but just only the data provider, or actually, more often, the software written by a data provider. And since the software is always going to be written out of the UCDs specs I would have not seen any problem with the ending semicolon. > With the suggested rule, UCD curators have > to be careful when defining new words (what we do now, but only once > hopefully), but users life is made slightly easier. Jonathan McDowell wrote: > but when you pass it to your search/comparison tool, a trailing > semicolon gets added automatically > phot.fluxDens; Indeed, if the parsing software knew about the ';' then there would have been no problem whatsoever. And VO is about software, not about human readibility. Alberto From hessman at astro.physik.uni-goettingen.de Tue Nov 8 02:53:18 2005 From: hessman at astro.physik.uni-goettingen.de (Frederic V. "Rick" Hessman) Date: Tue, 8 Nov 2005 11:53:18 +0100 Subject: phot.flux - an Addendum In-Reply-To: <0F56C61F-8EAD-4A51-AF9E-53F3504D730D@astro.physik.uni-goettingen.de> References: <200511080421.jA84LL8f004051@sothis.cfa.harvard.edu> <0F56C61F-8EAD-4A51-AF9E-53F3504D730D@astro.physik.uni-goettingen.de> Message-ID: <315AEB18-8F62-4864-864D-82DEBC808069@astro.physik.uni-goettingen.de> > Don't want to step on any radio astronomer's toes, but flux density > is flux. Yes, I know, it's monochromatic flux per unit > frequency, but where's the distinction between bolometric flux, > monochromatic flux per unit frequency, and monochromatic flux per > unit wavelength? Do we also then have to support the use of > candela's, lux's, and the lot - also physical (even SI!) terms for > the same things? How about (see, e.g., Mihalas): > > phot.flux generic net rate of radiant > energy flow per unit area and time > phot.flux.freq monochromatic flux per unit > frequency, flux density > phot.flux.wave monochromatic flux per unit wavelength > phot.flux.bol bolometric flux > phot.flux.Eddington Eddington flux = flux / 4PI > > I was going to suggest adding phot.flux.astr (that terrible factor > of PI or /1PI, depending upon how you look at it!), but I won't...... Sorry - should have re-read the 1.02 documentation: "flux density" has been generalized beyond it's normal use. How do we then distinguish between the many different forms? By units alone, i.e. non-UCD things? That works fine for things like lengths and times and masses, since the physical quantities are well defined beyond their units, but F_nu and F_lambda are totally different quantities and this fact is utterly independent of the units. Perhaps phot.flux.perFreq phot.flux.perWave phot.flux.perEnergy phot.flux.perWavenumber phot.flux.perDecade nu*F_nu, lambda*F_lambda,... Looking at the current list, I'd also like to complain about phot.flux.sb Since when is surface brightness a flux? Surface brightness is an intensity and intensity != flux. So... phot.intensity generic directed rate of radiant energy flow per unit area, time, and solid angle, surface brightness phot.intensity.bol (not generally needed, but here for symmetry) phot.intensity.perFreq phot.intensity.perWave phot.intensity.perEnergy phot.intensity.perWavenumber phot.intensity.perDecade (Ibid.) I know this is a bit of a change, but I frankly didn't notice before.... sorry! Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrea.preitemartinez at rm.iasf.cnr.it Tue Nov 8 05:53:45 2005 From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez) Date: Tue, 08 Nov 2005 14:53:45 +0100 Subject: UCDlist document update Message-ID: <20051108145345.trrx6vmck0oc8g8s@webmail.sic.rm.cnr.it> Dear all, after a first round of comments and suggestions, let me summarize: 1. I think it will be unwise to re-open the discussion on the already standard UCD main document (thus de-classing it back to WD) to ease the approval of a second standard, just because we are too lazy to find a reasonable spelling for a few words! 2. Let?s keep changes to a minimum. I found suggestions on the atmol and flux/sb words very interesting and worth discussing with more time and care. Shortly we will know how to do it ! (http://www.ivoa.net/Documents/latest/UCDmaintenance.html) 3. atmol: I think the simplest solution in this particular case is to change the words phys.at.* into phys.atomic.* 4. ?obtorto collo? (we do it, but we whould have preferred not to do it!) we go for phot.flux.density* and phys.energy.density 5. phys.massToLight can become phys.composition.massLightRatio (indeed the ratio has to do with the barionic composition of galaxies or clusters of galaxies) 6. phys.massYield can become phys.composition.yield (also in this case the new version is better than the old one - mass just indicated units) I will wait for a few more days before changing the list of words. Cheers Andrea ============================================================================== Andrea Preite Martinez andrea.preitemartinez at rm.iasf.cnr.it Istituto di Astrofisica Spaziale Tel.:+39.06.4993.4641 Area di Ricerca di Tor Vergata Fax.:+39.06.2066.0188 Via del Fosso del Cavaliere 100 Cell:+39.339.3817355 00133 Roma CDS :+33.3.90242473 ============================================================================== From Pedro.Osuna at esa.int Tue Nov 8 06:45:23 2005 From: Pedro.Osuna at esa.int (Pedro Osuna) Date: Tue, 08 Nov 2005 15:45:23 +0100 Subject: UCDlist document update In-Reply-To: <20051108145345.trrx6vmck0oc8g8s@webmail.sic.rm.cnr.it> References: <20051108145345.trrx6vmck0oc8g8s@webmail.sic.rm.cnr.it> Message-ID: <1131461123.32035.196.camel@isol03.vilspa.esa.int> Dear all, on the phys.atmol subject, I'd like to see Marie-Lise opinion before you write any changes, as she introduced many of the initial UCDs for that. In principle, Jonathan's new names look OK in view of our own work on Line DM, but I insist that she should say a word on it. Unfortunately, she does not seem to be on-line, so: Andrea, can this part wait until we know from her? Cheers, P. On Tue, 2005-11-08 at 14:53 +0100, Andrea Preite Martinez wrote: > Dear all, > > after a first round of comments and suggestions, let me summarize: > > 1. I think it will be unwise to re-open the discussion on the already > standard UCD main document (thus de-classing it back to WD) to ease the > approval of a second standard, just because we are too lazy to find a > reasonable spelling for a few words! > > 2. Let?s keep changes to a minimum. I found suggestions on the atmol > and flux/sb words very interesting and worth discussing with more time > and care. Shortly we will know how to do it ! > (http://www.ivoa.net/Documents/latest/UCDmaintenance.html) > > 3. atmol: I think the simplest solution in this particular case is to > change the words phys.at.* into phys.atomic.* > > 4. ?obtorto collo? (we do it, but we whould have preferred not to do > it!) we go for phot.flux.density* and phys.energy.density > > 5. phys.massToLight can become phys.composition.massLightRatio (indeed > the ratio has to do with the barionic composition of galaxies or > clusters of galaxies) > > 6. phys.massYield can become phys.composition.yield (also in this case > the new version is better than the old one - mass just indicated units) > > I will wait for a few more days before changing the list of words. > > Cheers > > Andrea > > > ============================================================================== > Andrea Preite Martinez andrea.preitemartinez at rm.iasf.cnr.it > Istituto di Astrofisica Spaziale Tel.:+39.06.4993.4641 > Area di Ricerca di Tor Vergata Fax.:+39.06.2066.0188 > Via del Fosso del Cavaliere 100 Cell:+39.339.3817355 > 00133 Roma CDS :+33.3.90242473 > ============================================================================== > > From genova at cluster.u-strasbg.fr Tue Nov 8 06:54:49 2005 From: genova at cluster.u-strasbg.fr (Francoise Genova) Date: Tue, 8 Nov 2005 15:54:49 +0100 (MET) Subject: UCDlist document update Message-ID: <200511081454.jA8Esnx13829@astro.u-strasbg.fr> Hi, Marie-Lise is presently chairing a session of the French VO school. She will have a look ASAP Cheers Francoise From marie-lise.dubernet at obspm.fr Tue Nov 8 08:43:33 2005 From: marie-lise.dubernet at obspm.fr (marie-lise.dubernet at obspm.fr) Date: Tue, 8 Nov 2005 17:43:33 +0100 (CET) Subject: UCDlist document update In-Reply-To: <1131461123.32035.196.camel@isol03.vilspa.esa.int> References: <20051108145345.trrx6vmck0oc8g8s@webmail.sic.rm.cnr.it> <1131461123.32035.196.camel@isol03.vilspa.esa.int> Message-ID: dear all, sorry for delayed answer. the DM details are not final yet, therefore I would not advise to use the DM (even if UCD have no meaning without the DM). At present my view is to unify all quantities related to atomic and molecular physics under a single word phys.atmol.* "quantities related to atomic and molecular processes" A more complete list of UCD will be proposed once the DM is set "final". best regards marie lise On Tue, 8 Nov 2005, Pedro Osuna wrote: > Dear all, > > on the phys.atmol subject, I'd like to see Marie-Lise opinion before you > write any changes, as she introduced many of the initial UCDs for that. > In principle, Jonathan's new names look OK in view of our own work on > Line DM, but I insist that she should say a word on it. Unfortunately, > she does not seem to be on-line, so: Andrea, can this part wait until we > know from her? > > Cheers, > P. > > > On Tue, 2005-11-08 at 14:53 +0100, Andrea Preite Martinez wrote: > > Dear all, > > > > after a first round of comments and suggestions, let me summarize: > > > > 1. I think it will be unwise to re-open the discussion on the already > > standard UCD main document (thus de-classing it back to WD) to ease the > > approval of a second standard, just because we are too lazy to find a > > reasonable spelling for a few words! > > > > 2. Let?s keep changes to a minimum. I found suggestions on the atmol > > and flux/sb words very interesting and worth discussing with more time > > and care. Shortly we will know how to do it ! > > (http://www.ivoa.net/Documents/latest/UCDmaintenance.html) > > > > 3. atmol: I think the simplest solution in this particular case is to > > change the words phys.at.* into phys.atomic.* > > > > 4. ?obtorto collo? (we do it, but we whould have preferred not to do > > it!) we go for phot.flux.density* and phys.energy.density > > > > 5. phys.massToLight can become phys.composition.massLightRatio (indeed > > the ratio has to do with the barionic composition of galaxies or > > clusters of galaxies) > > > > 6. phys.massYield can become phys.composition.yield (also in this case > > the new version is better than the old one - mass just indicated units) > > > > I will wait for a few more days before changing the list of words. > > > > Cheers > > > > Andrea > > > > > > ============================================================================== > > Andrea Preite Martinez andrea.preitemartinez at rm.iasf.cnr.it > > Istituto di Astrofisica Spaziale Tel.:+39.06.4993.4641 > > Area di Ricerca di Tor Vergata Fax.:+39.06.2066.0188 > > Via del Fosso del Cavaliere 100 Cell:+39.339.3817355 > > 00133 Roma CDS :+33.3.90242473 > > ============================================================================== > > > > > > From seaman at noao.edu Tue Nov 8 13:19:57 2005 From: seaman at noao.edu (Rob Seaman) Date: Tue, 8 Nov 2005 14:19:57 -0700 Subject: UCD verifier? In-Reply-To: <200511080421.jA84LL8f004051@sothis.cfa.harvard.edu> References: <200511080421.jA84LL8f004051@sothis.cfa.harvard.edu> Message-ID: Hi, > UCD1+ words at the same level in the hierarchy cannot be a starting > substring of another With the recent talk about the UCD1+ list not conforming to the UCD specification, I am prompted to wonder whether anyone is working on a UCD verifier - or perhaps one already exists? It seems to me that a tool would be very useful for verifying that a single token is a conforming UCD and that a list of same avoids various classes of name collisions and other errors. This will help individuals who want to suggest new UCDs as well as projects who may be developing their own namespaces. Rob Seaman NOAO From seaman at noao.edu Wed Nov 9 05:55:26 2005 From: seaman at noao.edu (Rob Seaman) Date: Wed, 9 Nov 2005 06:55:26 -0700 Subject: UCD verifier? In-Reply-To: <20051109092326.ve3i452crb6s4wgs@webmail.sic.rm.cnr.it> References: <200511080421.jA84LL8f004051@sothis.cfa.harvard.edu> <20051109092326.ve3i452crb6s4wgs@webmail.sic.rm.cnr.it> Message-ID: On Nov 9, 2005, at 1:23 AM, Andrea Preite Martinez wrote: >> With the recent talk about the UCD1+ list not conforming to the >> UCD specification, I am prompted to wonder whether anyone is >> working on a UCD verifier - or perhaps one already exists? > > Yes, try the validate tool at > http://vizier.u-strasbg.fr/UCD/tools.htx Thanks. Other pointed me to that, too. The rules and meta-rules for UCD building imply that each UCD fills a niche in a larger semantic ecology. Each new UCD causes a potential challenge to all previously declared UCDs or lists or namespaces of same. The tool I was suggesting would not only test a single proposed UCD against the syntactical rules, but also test a list of same (e.g., representing a namespace) against the rules for building lists of UCDs. I suspect that the notion that two namespaces cannot contain identical UCDs (or more stringently, was it identical "words"?) will fall by the wayside, but if not, it would prove useful - almost mandatory - to have a tool to vet two lists against each other, or for instance, a newly proposed list against all previously registered namespaces. Which is to say that the choice of rules for assembling lists of UCDs is not a completely free design parameter. Rob Seaman NOAO From iz at sai.msu.ru Fri Nov 25 16:15:54 2005 From: iz at sai.msu.ru (Ivan Yu. Zolotukhin) Date: Sat, 26 Nov 2005 03:15:54 +0300 (MSK) Subject: question on UCD web service Message-ID: Hello, My question concerns some of the CDS web services, I'm trying to make use of http://cdsws.u-strasbg.fr/axis/services/UCD?wsdl and call method "assign" to resolve natural language description to UCD in my client. The main problem for my case is ambiguity: my client should propose to the user that provides ambiguous description like "astronomical coordinates" or "velocity" several variants to choose from. But above service provides only best match (you call it "suggested complete UCD" in the cgi interface), whereas in the cgi interface http://cdsweb.u-strasbg.fr/UCD/cgi-bin/descr2ucd all the matches are proposed. As far as I understand, it is not difficult to deploy a service that would reply with all the possible matches, because this functionality is already avaliable in the cgi. Maybe some flag to assign method or new method that does not affect existing clients? Sincerely, Ivan Zolotukhin From derriere at newb6.u-strasbg.fr Mon Nov 28 09:23:37 2005 From: derriere at newb6.u-strasbg.fr (Sebastien Derriere) Date: Mon, 28 Nov 2005 18:23:37 +0100 Subject: question on UCD web service References: Message-ID: <438B3D19.14606FCF@astro.u-strasbg.fr> "Ivan Yu. Zolotukhin" wrote: > > As far as I understand, it is not difficult to deploy a service that would > reply with all the possible matches, because this functionality is > already avaliable in the cgi. Maybe some flag to assign method or new > method that does not affect existing clients? Hi Ivan, I've just put a new method called "suggest" on this page: http://vizier.u-strasbg.fr/UCD/tools.htx It takes a description and returns a list of matching individual words, together with a score and the syntax flag, like what is provided on the descr2ucd page. Does this address your problem? There is only CGI access for the moment, but I'll try to make the WS access available soon. Cheers, 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 iz at sai.msu.ru Mon Nov 28 10:17:57 2005 From: iz at sai.msu.ru (Ivan Yu. Zolotukhin) Date: Mon, 28 Nov 2005 21:17:57 +0300 (MSK) Subject: question on UCD web service In-Reply-To: <438B3D19.14606FCF@astro.u-strasbg.fr> Message-ID: On Mon, 28 Nov 2005, Sebastien Derriere wrote: > I've just put a new method called "suggest" on this page: > http://vizier.u-strasbg.fr/UCD/tools.htx > It takes a description and returns a list of matching individual > words, together with a score and the syntax flag, like what is provided > on the descr2ucd page. > Does this address your problem? Yes, exactly, thanks! > There is only CGI access for the > moment, but I'll try to make the WS access available soon. I will make use of this web service right after you publish it, I do really need it. Sincerely, Ivan Zolotukhin From iz at sai.msu.ru Mon Nov 28 10:34:12 2005 From: iz at sai.msu.ru (Ivan Yu. Zolotukhin) Date: Mon, 28 Nov 2005 21:34:12 +0300 (MSK) Subject: UCD web service: possible bug of "assign" method Message-ID: Hello, Just want to post some comment on "assign" method of UCD web service, it works improperly in my opinion. It returns not UCD actually, but UCD plus \n symbol at the end of it. I thought that there is a problem with my client, but dump of SOAP conversation proves my guess: there is a '\n' symbol at the end of ucd inside element of soap envelope. So all clients return something like $real_ucd . "\n", using Perl terminology. Is it a correct behaviour? I think all the transformations with UCD should be left to client side, shouldn't they? Are there similar behaviour of other methods of this web service? If it is not correct, it's better to fix it now, otherwise many clients will depened on it. For instance, my client now removes this trailing linefeed to insert correct UCD into database. Sincerely, Ivan Zolotukhin From derriere at newb6.u-strasbg.fr Tue Nov 29 09:29:34 2005 From: derriere at newb6.u-strasbg.fr (Sebastien Derriere) Date: Tue, 29 Nov 2005 18:29:34 +0100 Subject: UCD web service: possible bug of "assign" method References: Message-ID: <438C8FFE.A6E4CADC@astro.u-strasbg.fr> "Ivan Yu. Zolotukhin" wrote: > > Hello, > > Just want to post some comment on "assign" method of UCD web service, it > works improperly in my opinion. It returns not UCD actually, but UCD plus > \n symbol at the end of it. I thought that there is a problem with my > client, but dump of SOAP conversation proves my guess: there is a '\n' > symbol at the end of ucd inside element of soap envelope. So all > clients return something like $real_ucd . "\n", using Perl terminology. > > Is it a correct behaviour? I think all the transformations with UCD should > be left to client side, shouldn't they? Are there similar behaviour of > other methods of this web service? > > If it is not correct, it's better to fix it now, otherwise many clients > will depened on it. For instance, my client now removes this trailing > linefeed to insert correct UCD into database. Hello, Indeed, most of the methods return a trailing '\n' character at the end of the result. But nobody had complained yet about this behaviour. I'm reluctant to change the behaviour of these methods now, because they may be already implemented in various places, and I guess developers have added a line of code to remove this character in case they needed to. And they might be upset to see a working implementation getting wrecked because of a "bug fix". Unless there is a large protest against this extra '\n', I'd rather keep the currently available methods as they are, and take care of better documenting the future ones. Regards, 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 derriere at newb6.u-strasbg.fr Wed Nov 30 01:43:29 2005 From: derriere at newb6.u-strasbg.fr (Sebastien Derriere) Date: Wed, 30 Nov 2005 10:43:29 +0100 Subject: question on UCD web service References: Message-ID: <438D7441.51BBB60E@astro.u-strasbg.fr> "Ivan Yu. Zolotukhin" wrote: > > On Mon, 28 Nov 2005, Sebastien Derriere wrote: > > > I've just put a new method called "suggest" on this page: > > http://vizier.u-strasbg.fr/UCD/tools.htx > > It takes a description and returns a list of matching individual > > words, together with a score and the syntax flag, like what is provided > > on the descr2ucd page. > > Does this address your problem? > > Yes, exactly, thanks! > > > There is only CGI access for the > > moment, but I'll try to make the WS access available soon. > > I will make use of this web service right after you publish it, I do > really need it. Hello, The "suggest" method has been added to the WebServices. Cheers, 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 dtody at nrao.edu Wed Nov 30 22:05:03 2005 From: dtody at nrao.edu (Doug Tody) Date: Wed, 30 Nov 2005 23:05:03 -0700 (MST) Subject: VOConcepts paper (fwd) Message-ID: [This discussion probably should be on the ucd or semantics list rather than voevent, which is an application.] ---------- Forwarded message ---------- Date: Wed, 30 Nov 2005 22:58:14 -0700 (MST) From: Doug Tody To: Roy Williams Cc: IVOA List VOEvent Subject: Re: VOConcepts paper The use-case identified in Madrid, which prompted the need for standard object type names was searching by object type in SSA. We want to be able to do things like query for spectra where targetclass=QSO. I was expecting to see a simple list of names like "star", "galaxy", "PN", "QSO", "AGN", "GRB", etc., which is what I think users would like to search for, but what we have instead are more UCD-like names such as "process.variation.burst;em.gamma" which I guess indicates a GRB. I can see where it could be useful to specify more precisely what type of object we have as the UCD approach suggested permits, but it would also be useful to standardize the actual, simple acronyms commonly used by astronomers. Perhaps what we need are two lists, one for precise characterisation of physical object types, another defining the common, standard acronym associated with such object types. This could be done by merely defining a standard list of acronyms for object types, and assigning one to each of the object type UCDs, where appropriate. - Doug On Wed, 30 Nov 2005, Roy Williams wrote: > Please find attached a white paper from Andrea Preite-Martinez, the chairman > of the IVOA Semantics working group, which is a first attempt to build a > standard vocabulary for astronomical phenomena and for astronomical objects. > I would like to have a brief discussion of this at the VOEvent meeting next > week, and/or receive comments by email from those who cannot attend the > meeting. Rick Hessman has already worked on exactly this topic. > > I would like to compile a "group response feedback" on this paper for Andrea > and the Semantics WG. > > Roy Williams > > California Institute of Technology > 626 395 3670 > > From jdsant at iaa.es Wed Nov 2 04:44:50 2005 From: jdsant at iaa.es (Juan de Dios Santander Vela) Date: Wed, 2 Nov 2005 13:44:50 +0100 Subject: UCD versioning? In-Reply-To: <6E25F7C3-4800-48FE-8A21-A3CC64C5C09D@noao.edu> References: <6E25F7C3-4800-48FE-8A21-A3CC64C5C09D@noao.edu> Message-ID: El 25/10/2005, a las 0:51, Rob Seaman escribi?: > Could someone summarize how UCD versioning is - or is not - > supposed to work? Alternately, feel free to point me toward > pertinent discussions. I'm really interested in this topic, too, and I think at least it should be known whether: a) The community is prepared to have several UCD versions, and has a plan for it b) The only versioning that has been thought is from old UCD (in the ROOTELEMENT_SUBELEMENT form) to UCD1+ (rootelement.subelement), and versioning through the schema; that would allow, I think, at least to know whether and old piece of software needs to be updated to cope with new UCDs, but no new meanigns, I guess... c) UCD1+ is the last version of the UCD, and will be superseded by "ontologies", when they're defined... Thanks to all in advance! -- Juan de Dios Santander Vela Diplomado en CC. F?sicas, Ingeniero en Electr?nica Doctorando en Tecnolog?as Multimedia Becario Predoctoral del Instituto de Astrof?sica de Andaluc?a Indiviudo: D?cese del hombre que pierde a su mujer en un momento ?nico. From andrea.preitemartinez at rm.iasf.cnr.it Mon Nov 7 07:47:55 2005 From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez) Date: Mon, 07 Nov 2005 16:47:55 +0100 Subject: No subject Message-ID: <20051107164755.cwtk98wgjvq8gkk8@webmail.sic.rm.cnr.it> Dear all, I received from the IVOA Exec a request to modify all UCD1+ words that do not conform to what is said in the standard UCD document, i.e.: UCD1+ words at the same level in the hierarchy cannot be a starting substring of another that is, we cannot have phot.flux and phot.fluxDens As you know, the document at http://www.ivoa.net/Documents/latest/UCDlist.html is in the PR status, and will be moved to IVOA Recommendation after an appropriate action on the words concerned. The rule mentioned above is violated for the following ucd1+ words: E | phot.fluxDens | Flux density (per wl/freq/energy interval) E | phot.fluxDens.sb | Flux density surface brightness Q | phys.atmol | Atomic and molecular physics (shared properties) Q | phys.atmol.branchingRatio | Branching ratio Q | phys.atmol.coll | Related to collisions Q | phys.atmol.configuration | Configuration Q | phys.atmol.crossSection | Atomic / molecular cross-section Q | phys.atmol.element | Element Q | phys.atmol.excitation | Atomic molecular excitation parameter Q | phys.atmol.final | Quantity refers to atomic/molecular final/ground state, level, ecc. Q | phys.atmol.initial | Quantity refers to atomic/molecular initial state, level, ecc. Q | phys.atmol.ion | Ion S | phys.atmol.ionization | Related to ionization S | phys.atmol.level | Atomic level Q | phys.atmol.lifetime | Lifetime of a level Q | phys.atmol.lineShift | Line shifting coefficient Q | phys.atmol.parity | Parity Q | phys.atmol.sweight | Statistical weight S | phys.atmol.trans | Transition between states Q | phys.energyDensity | Energy-density Q | phys.massToLight | Mass to light ratio Q | phys.massYield | Mass yield because of the already existing words phot.flux phys.at phys.energy phys.mass In order to reach a rapid convergence on the reformulation of these words, I?m suggesting a possible solution for each of them in the list that follows: Present Suggested new E | phot.fluxDens | phot.flux.fluxDens or: phot.flux.density E | phot.fluxDens.sb | phot.flux.fluxDens.sb or: phot.flux.density.sb Q | phys.atmol | suppress Q | phys.atmol.branchingRatio | phys.branchingRatio Q | phys.atmol.coll | phys.collision Q | phys.atmol.configuration | phys.state.configuration Q | phys.atmol.crossSection | phys.crossSection Q | phys.atmol.element | phys.element Q | phys.atmol.excitation | phys.excitation Q | phys.atmol.final | phys.state.final Q | phys.atmol.initial | phys.state.initial Q | phys.atmol.ion | phys.element.ion S | phys.atmol.ionization | phys.ionization S | phys.atmol.level | phys.level Q | phys.atmol.lifetime | phys.level.lifetime Q | phys.atmol.lineShift | phys.lineShift Q | phys.atmol.parity | phys.state.parity Q | phys.atmol.sweight | phys.state.sweight S | phys.atmol.trans | phys.state.trans Q | phys.energyDensity | phys.energy.density Q | phys.massToLight | phys.mass.light Q | phys.massYield | phys.mass.yield The other possibility for the phys.atmol.xxx group is to suppress the word phys.at Please let me know your opinion and/or your suggestions. Andrea ============================================================================== Andrea Preite Martinez andrea.preitemartinez at rm.iasf.cnr.it Istituto di Astrofisica Spaziale Tel.:+39.06.4993.4641 Area di Ricerca di Tor Vergata Fax.:+39.06.2066.0188 Via del Fosso del Cavaliere 100 Cell:+39.320.43.15.383 00133 Roma CDS :+33.3.90242473 ============================================================================== From Alberto.Micol at eso.org Mon Nov 7 08:35:16 2005 From: Alberto.Micol at eso.org (Alberto Micol) Date: Mon, 7 Nov 2005 17:35:16 +0100 Subject: In-Reply-To: <20051107164755.cwtk98wgjvq8gkk8@webmail.sic.rm.cnr.it> References: <20051107164755.cwtk98wgjvq8gkk8@webmail.sic.rm.cnr.it> Message-ID: <718d8e4897942ec4822d14397eb0ceb2@eso.org> Hi Andrea, Sorry to come back with this, but there is another possibility... If we state that each UCD word MUST end with the ';' character, -that is, even if there are no other subsequent words- then no UCD can ever be a substring of another one. Example: phot.flux; is not a substring of phot.fluxDens; The beauty of it is that no other changes are required. It is my laziness... I always prefer to change the least... Alberto PS: I send this email because I'm sure you are expecting it from me ;-) PPS: And I promise that this is the last time I mention this. On Nov 7, 2005, at 16:47, Andrea Preite Martinez wrote: > Dear all, > > I received from the IVOA Exec a request to modify all UCD1+ words that > do not conform to what is said in the standard UCD document, i.e.: > > UCD1+ words at the same level in the hierarchy cannot be a starting > substring of another > > that is, we cannot have phot.flux and phot.fluxDens > > As you know, the document at > http://www.ivoa.net/Documents/latest/UCDlist.html > is in the PR status, and will be moved to IVOA Recommendation after an > appropriate action on the words concerned. > > The rule mentioned above is violated for the following ucd1+ words: > > E | phot.fluxDens | Flux density (per wl/freq/energy > interval) > E | phot.fluxDens.sb | Flux density surface brightness > Q | phys.atmol | Atomic and molecular physics (shared > properties) > Q | phys.atmol.branchingRatio | Branching ratio > Q | phys.atmol.coll | Related to collisions > Q | phys.atmol.configuration | Configuration > Q | phys.atmol.crossSection | Atomic / molecular cross-section > Q | phys.atmol.element | Element > Q | phys.atmol.excitation | Atomic molecular excitation parameter > Q | phys.atmol.final | Quantity refers to atomic/molecular > final/ground state, level, ecc. > Q | phys.atmol.initial | Quantity refers to atomic/molecular > initial state, level, ecc. > Q | phys.atmol.ion | Ion > S | phys.atmol.ionization | Related to ionization > S | phys.atmol.level | Atomic level > Q | phys.atmol.lifetime | Lifetime of a level > Q | phys.atmol.lineShift | Line shifting coefficient > Q | phys.atmol.parity | Parity > Q | phys.atmol.sweight | Statistical weight > S | phys.atmol.trans | Transition between states > Q | phys.energyDensity | Energy-density > Q | phys.massToLight | Mass to light ratio > Q | phys.massYield | Mass yield > > because of the already existing words > phot.flux > phys.at > phys.energy > phys.mass > > In order to reach a rapid convergence on the reformulation of these > words, I?m suggesting a possible solution for each of them in the list > that follows: > > Present Suggested new > E | phot.fluxDens | phot.flux.fluxDens or: > phot.flux.density > E | phot.fluxDens.sb | phot.flux.fluxDens.sb or: > phot.flux.density.sb > Q | phys.atmol | suppress > Q | phys.atmol.branchingRatio | phys.branchingRatio > Q | phys.atmol.coll | phys.collision > Q | phys.atmol.configuration | phys.state.configuration > Q | phys.atmol.crossSection | phys.crossSection > Q | phys.atmol.element | phys.element > Q | phys.atmol.excitation | phys.excitation > Q | phys.atmol.final | phys.state.final > Q | phys.atmol.initial | phys.state.initial > Q | phys.atmol.ion | phys.element.ion S | > phys.atmol.ionization | phys.ionization > S | phys.atmol.level | phys.level > Q | phys.atmol.lifetime | phys.level.lifetime > Q | phys.atmol.lineShift | phys.lineShift > Q | phys.atmol.parity | phys.state.parity > Q | phys.atmol.sweight | phys.state.sweight > S | phys.atmol.trans | phys.state.trans Q | > phys.energyDensity | phys.energy.density > Q | phys.massToLight | phys.mass.light > Q | phys.massYield | phys.mass.yield > > The other possibility for the phys.atmol.xxx group is to suppress the > word phys.at > > Please let me know your opinion and/or your suggestions. > > Andrea > > > ======================================================================= > ======= > Andrea Preite Martinez > andrea.preitemartinez at rm.iasf.cnr.it > Istituto di Astrofisica Spaziale Tel.:+39.06.4993.4641 > Area di Ricerca di Tor Vergata Fax.:+39.06.2066.0188 > Via del Fosso del Cavaliere 100 Cell:+39.320.43.15.383 > 00133 Roma CDS :+33.3.90242473 > ======================================================================= > ======= > > Alberto Micol ST-ECF HST Archive Scientist From pdidelon at cea.fr Mon Nov 7 08:44:28 2005 From: pdidelon at cea.fr (Pierre Didelon) Date: Mon, 07 Nov 2005 17:44:28 +0100 Subject: In-Reply-To: <20051107164755.cwtk98wgjvq8gkk8@webmail.sic.rm.cnr.it> References: <20051107164755.cwtk98wgjvq8gkk8@webmail.sic.rm.cnr.it> Message-ID: <436F846C.3010009@cea.fr> Andrea Preite Martinez wrote: > Dear all, > > I received from the IVOA Exec a request to modify all UCD1+ words that > do not conform to what is said in the standard UCD document, i.e.: > > UCD1+ words at the same level in the hierarchy cannot be a starting > substring of another > > that is, we cannot have phot.flux and phot.fluxDens > > As you know, the document at > http://www.ivoa.net/Documents/latest/UCDlist.html > is in the PR status, and will be moved to IVOA Recommendation after an > appropriate action on the words concerned. > > The rule mentioned above is violated for the following ucd1+ words: > > E | phot.fluxDens | Flux density (per wl/freq/energy interval) > E | phot.fluxDens.sb | Flux density surface brightness > Q | phys.atmol | Atomic and molecular physics (shared properties) [SNIP]... > Q | phys.energyDensity | Energy-density > Q | phys.massToLight | Mass to light ratio > Q | phys.massYield | Mass yield > > because of the already existing words > phot.flux > phys.at > phys.energy > phys.mass > > In order to reach a rapid convergence on the reformulation of these > words, I?m suggesting a possible solution for each of them in the list > that follows: > > Present Suggested new > E | phot.fluxDens | phot.flux.fluxDens or: phot.flux.density > E | phot.fluxDens.sb | phot.flux.fluxDens.sb or: phot.flux.density.sb The second formulation seems more logical but then fluxDens atom desapear, is this a pb? [SNIP] > > The other possibility for the phys.atmol.xxx group is to suppress the > word phys.at why not modifying phys.at.xxx group to phys.atom.xxx > > Please let me know your opinion and/or your suggestions. > > Andrea > > > ============================================================================== > > Andrea Preite Martinez > andrea.preitemartinez at rm.iasf.cnr.it > Istituto di Astrofisica Spaziale Tel.:+39.06.4993.4641 > Area di Ricerca di Tor Vergata Fax.:+39.06.2066.0188 > Via del Fosso del Cavaliere 100 Cell:+39.320.43.15.383 > 00133 Roma CDS :+33.3.90242473 > ============================================================================== > > > SY -- Pierre ------------------------------------------------------------------ DIDELON :@: pdidelon_at_cea.fr Phone : 33 (0)1 69 08 58 89 CEA SACLAY - Service d'Astrophysique 91191 Gif-Sur-Yvette Cedex ------------------------------------------------------------------ Aidez les enfants Tib?tains : http://www.a-e-t.org/jcparrain.htm ou d'autres : http://www.sosesf.org/ ------------------------------------------------------------------ From ndelmott at eso.org Mon Nov 7 09:27:06 2005 From: ndelmott at eso.org (Nausicaa Delmotte) Date: Mon, 07 Nov 2005 18:27:06 +0100 Subject: In-Reply-To: <718d8e4897942ec4822d14397eb0ceb2@eso.org> References: <20051107164755.cwtk98wgjvq8gkk8@webmail.sic.rm.cnr.it> <718d8e4897942ec4822d14397eb0ceb2@eso.org> Message-ID: <436F8E6A.3000107@eso.org> Hi, But what is preventing us from adding the semicolon as ending separator? I do apologize for asking a question that seems to have already been answered in the past, but I could not find the answer in the archive mailing-list and since I did not follow all the UCD developments from the very beginning, probably I missed something. Could anybody give me a pointer to a discussion or a very brief comment on it? Or is it maybe to avoid having a possible NULL word at the end when parsing a UCD, assuming the ending semicolon? Thank you Nausicaa Alberto Micol wrote: > > Hi Andrea, > > Sorry to come back with this, but there is another possibility... > If we state that each UCD word MUST end with the ';' character, > -that is, even if there are no other subsequent words- then > no UCD can ever be a substring of another one. > > Example: > > phot.flux; is not a substring of phot.fluxDens; > > The beauty of it is that no other changes are required. > > It is my laziness... I always prefer to change the least... > > Alberto > PS: I send this email because I'm sure you are expecting it from me ;-) > PPS: And I promise that this is the last time I mention this. > > On Nov 7, 2005, at 16:47, Andrea Preite Martinez wrote: > >> Dear all, >> >> I received from the IVOA Exec a request to modify all UCD1+ words >> that do not conform to what is said in the standard UCD document, i.e.: >> >> UCD1+ words at the same level in the hierarchy cannot be a starting >> substring of another >> >> that is, we cannot have phot.flux and phot.fluxDens >> >> As you know, the document at >> http://www.ivoa.net/Documents/latest/UCDlist.html >> is in the PR status, and will be moved to IVOA Recommendation after >> an appropriate action on the words concerned. >> >> The rule mentioned above is violated for the following ucd1+ words: >> >> E | phot.fluxDens | Flux density (per wl/freq/energy >> interval) >> E | phot.fluxDens.sb | Flux density surface brightness >> Q | phys.atmol | Atomic and molecular physics >> (shared properties) >> Q | phys.atmol.branchingRatio | Branching ratio >> Q | phys.atmol.coll | Related to collisions >> Q | phys.atmol.configuration | Configuration >> Q | phys.atmol.crossSection | Atomic / molecular cross-section >> Q | phys.atmol.element | Element >> Q | phys.atmol.excitation | Atomic molecular excitation parameter >> Q | phys.atmol.final | Quantity refers to atomic/molecular >> final/ground state, level, ecc. >> Q | phys.atmol.initial | Quantity refers to atomic/molecular >> initial state, level, ecc. >> Q | phys.atmol.ion | Ion >> S | phys.atmol.ionization | Related to ionization >> S | phys.atmol.level | Atomic level >> Q | phys.atmol.lifetime | Lifetime of a level >> Q | phys.atmol.lineShift | Line shifting coefficient >> Q | phys.atmol.parity | Parity >> Q | phys.atmol.sweight | Statistical weight >> S | phys.atmol.trans | Transition between states >> Q | phys.energyDensity | Energy-density >> Q | phys.massToLight | Mass to light ratio >> Q | phys.massYield | Mass yield >> >> because of the already existing words >> phot.flux >> phys.at >> phys.energy >> phys.mass >> >> In order to reach a rapid convergence on the reformulation of these >> words, I?m suggesting a possible solution for each of them in the >> list that follows: >> >> Present Suggested new >> E | phot.fluxDens | phot.flux.fluxDens or: >> phot.flux.density >> E | phot.fluxDens.sb | phot.flux.fluxDens.sb or: >> phot.flux.density.sb >> Q | phys.atmol | suppress >> Q | phys.atmol.branchingRatio | phys.branchingRatio >> Q | phys.atmol.coll | phys.collision >> Q | phys.atmol.configuration | phys.state.configuration >> Q | phys.atmol.crossSection | phys.crossSection >> Q | phys.atmol.element | phys.element >> Q | phys.atmol.excitation | phys.excitation >> Q | phys.atmol.final | phys.state.final >> Q | phys.atmol.initial | phys.state.initial >> Q | phys.atmol.ion | phys.element.ion S | >> phys.atmol.ionization | phys.ionization >> S | phys.atmol.level | phys.level >> Q | phys.atmol.lifetime | phys.level.lifetime >> Q | phys.atmol.lineShift | phys.lineShift >> Q | phys.atmol.parity | phys.state.parity >> Q | phys.atmol.sweight | phys.state.sweight >> S | phys.atmol.trans | phys.state.trans Q | >> phys.energyDensity | phys.energy.density >> Q | phys.massToLight | phys.mass.light >> Q | phys.massYield | phys.mass.yield >> >> The other possibility for the phys.atmol.xxx group is to suppress the >> word phys.at >> >> Please let me know your opinion and/or your suggestions. >> >> Andrea >> >> >> ======================================================================= >> ======= >> Andrea Preite Martinez >> andrea.preitemartinez at rm.iasf.cnr.it >> Istituto di Astrofisica Spaziale Tel.:+39.06.4993.4641 >> Area di Ricerca di Tor Vergata Fax.:+39.06.2066.0188 >> Via del Fosso del Cavaliere 100 Cell:+39.320.43.15.383 >> 00133 Roma CDS :+33.3.90242473 >> ======================================================================= >> ======= >> >> > Alberto Micol > ST-ECF HST Archive Scientist -- Dr Nausicaa Delmotte @..@ ndelmott at eso.org European Southern Observatory (----) Tel: +49 (0)89 3200 6418 Karl-Schwarzschild-Str. 2 ( >__< ) Fax: +49 (0)89 3200 6480 D-85748 Garching bei Muenchen ^^ ~~ ^^ http://www.eso.org/~ndelmott/ From pfo at star.le.ac.uk Mon Nov 7 09:40:56 2005 From: pfo at star.le.ac.uk (Patricio F. Ortiz) Date: Mon, 7 Nov 2005 18:40:56 +0100 Subject: In-Reply-To: <20051107164755.cwtk98wgjvq8gkk8@webmail.sic.rm.cnr.it> References: <20051107164755.cwtk98wgjvq8gkk8@webmail.sic.rm.cnr.it> Message-ID: <6666189c0511070940s2c46e854qc2fcfbee82efcb9e@mail.gmail.com> Hi Andrea (et al :-) Well, maybe we should ask ourselves if we should ditch the rule! I mean, why is it that substrings are not allowed? Is it because of impleemntation issues (eg, recovering data based on UCDs)? I personally see little use for that rule (perhaps it was written without looking at the existing UCDs)? I see Alberto's point to go for the simplest solution, but I'd go one step further :-) :-) Cheers, Patricio On 11/7/05, Andrea Preite Martinez wrote: > Dear all, > > I received from the IVOA Exec a request to modify all UCD1+ words that > do not conform to what is said in the standard UCD document, i.e.: > > UCD1+ words at the same level in the hierarchy cannot be a starting > substring of another > From jat at star.le.ac.uk Mon Nov 7 09:49:36 2005 From: jat at star.le.ac.uk (Jonathan Tedds) Date: Mon, 7 Nov 2005 17:49:36 +0000 (GMT) Subject: In-Reply-To: <6666189c0511070940s2c46e854qc2fcfbee82efcb9e@mail.gmail.com> References: <20051107164755.cwtk98wgjvq8gkk8@webmail.sic.rm.cnr.it> <6666189c0511070940s2c46e854qc2fcfbee82efcb9e@mail.gmail.com> Message-ID: Patricio is surely right? There is a simple and added value to the logic of the substring approach so please can someone provide the justification that was put forward for not using it? A bit of extra coding effort (if even needed as others have alluded to?) will keep the interface to the more general user at a more intuitive level. Thanks, Jonathan -------------------------------------------------------------------- Dr Jonathan Tedds, Tel: +44 (0)116 252 3502 XMM-Newton Surveys & AstroGrid Science, Fax: +44 (0)116 252 3311 Department of Physics and Astronomy, University of Leicester, Email: jat at star.le.ac.uk Leicester LE1 7RH, UK http://xmmssc-www.star.le.ac.uk/~jat -------------------------------------------------------------------- On Mon, 7 Nov 2005, Patricio F. Ortiz wrote: > Hi Andrea (et al :-) > > Well, maybe we should ask ourselves if we should ditch the rule! I > mean, why is it that substrings are not allowed? Is it because of > impleemntation issues (eg, recovering data based on UCDs)? I > personally see little use for that rule (perhaps it was written > without looking at the existing UCDs)? > > I see Alberto's point to go for the simplest solution, but I'd go one > step further :-) :-) > > Cheers, > > Patricio > On 11/7/05, Andrea Preite Martinez wrote: > > Dear all, > > > > I received from the IVOA Exec a request to modify all UCD1+ words that > > do not conform to what is said in the standard UCD document, i.e.: > > > > UCD1+ words at the same level in the hierarchy cannot be a starting > > substring of another > > > > From derriere at newb6.u-strasbg.fr Mon Nov 7 11:13:01 2005 From: derriere at newb6.u-strasbg.fr (Sebastien Derriere) Date: Mon, 07 Nov 2005 20:13:01 +0100 Subject: References: <20051107164755.cwtk98wgjvq8gkk8@webmail.sic.rm.cnr.it> <436F846C.3010009@cea.fr> Message-ID: <436FA73D.33150E@astro.u-strasbg.fr> Hi, I'd be in favor of not changing the UCD Rec, and trying to follow the guidelines, therefore changing: phot.fluxDens phot.flux.density phot.fluxDens.sb phot.flux.density.sb phys.energyDensity phys.energy.density phys.massToLight phys.mass.light or phys.MLratio phys.massYield phys.mass.yield or phys.elementYield and also as Pierre suggested: phys.at phys.atom (also changing words at levels below phys.at) The debate on the usefulness of the semicolon at the end of the UCD1+ was concluded by introducing this rule of "no word should be substring of another at the same level". The main motivation was that users would be reluctant to add a ; at the end of every UCD. With the suggested rule, UCD curators have to be careful when defining new words (what we do now, but only once hopefully), but users life is made slightly easier. 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 jcm at head.cfa.harvard.edu Mon Nov 7 20:21:21 2005 From: jcm at head.cfa.harvard.edu (Jonathan McDowell) Date: Mon, 7 Nov 2005 23:21:21 -0500 (EST) Subject: Message-ID: <200511080421.jA84LL8f004051@sothis.cfa.harvard.edu> Dear Andrea and others, 1) In the first place, I never liked that rule. Alberto's suggestion could be implemented in the UCD-analysing software - in other words, I don't actually bother adding a terminal semicolon to my phot.fluxDens but when you pass it to your search/comparison tool, a trailing semicolon gets added automatically phot.fluxDens; This is a classic case of wanting to avoid writing 3 lines of code, and making things annoying for human readability and comprehension. 2) Nevertheless, the rule is what we adopted. > Present Suggested new > E | phot.fluxDens | phot.flux.fluxDens or: > phot.flux.density > E | phot.fluxDens.sb | phot.flux.fluxDens.sb or: > phot.flux.density.sb I agree that the second choices phot.flux.density.* are better. (Pierre - I don't think losing the fluxDens atom is a problem.) OK: > Q | phys.energyDensity | phys.energy.density I don't like this, since it's not a mass, it's a ratio. It's really talking about the composition of the physical environment (how much baryons, how much photons, etc.) Maybe phys.composition.massLight (or phys.abund.massLight) > Q | phys.massToLight | phys.mass.light Can you remind me what this means exactly? Is it a percentage, or e.g. an SNe yield of iron in solar masses? > Q | phys.massYield | phys.mass.yield I don't like suppressing the atmol element. It makes the UCDs too flat. We could just make them all "at" and explain that "at" includes "atmol". But if we are willing to make a bigger change, we can take something from the work of the DM At/Mol team: some of these items are species (atmol, particle), some are states (levels), some are transitions and interactions. I think it's clear that states and levels are associated with particles in a way that phys.mass.yield is not, so I would be in favor of > Q | phys.atmol | suppress > Q | phys.atmol.element | phys.species.element > Q | phys.atmol.excitation | phys.species.excitation > Q | phys.atmol.ion | phys.species.ion > S | phys.atmol.ionization | phys.species.ionization Q | phys.at.number | phys.species.atomicNumber Q | phys.at.weight | phys.species.weight > Q | phys.atmol.branchingRatio | phys.transition.branchingRatio > Q | phys.atmol.coll | phys.transition.collision > Q | phys.atmol.crossSection | phys.transition.crossSection > Q | phys.atmol.lineShift | phys.transition.lineShift > S | phys.atmol.trans | phys.transition.trans Q | phys.at.collStrength | phys.transition.collStrength Q | phys.at.damping | phys.transition.damping Q | phys.at.lande | phys.transition.Lande factor Q | phys.at.oscStrength | phys.transition.oscStrength Q | phys.at.radiationType | phys.transition.radiationType Q | phys.at.term | phys.transition.term Q | phys.at.transProb | phys.transition.prob Q | phys.at.wOscStrength | phys.transition.wOscStrength > Q | phys.atmol.parity | phys.state.parity > Q | phys.atmol.sweight | phys.state.sweight > Q | phys.atmol.configuration | phys.state.configuration > Q | phys.atmol.final | phys.state.final > Q | phys.atmol.initial | phys.state.initial > S | phys.atmol.level | phys.state.level > Q | phys.atmol.lifetime | phys.state.lifetime Q | phys.at.qn | phys.state.qn Q | phys.at.qn.I | phys.state.qn.I - Jonathan From hessman at astro.physik.uni-goettingen.de Tue Nov 8 01:28:59 2005 From: hessman at astro.physik.uni-goettingen.de (Frederic V. "Rick" Hessman) Date: Tue, 8 Nov 2005 10:28:59 +0100 Subject: In-Reply-To: <200511080421.jA84LL8f004051@sothis.cfa.harvard.edu> References: <200511080421.jA84LL8f004051@sothis.cfa.harvard.edu> Message-ID: <0F56C61F-8EAD-4A51-AF9E-53F3504D730D@astro.physik.uni-goettingen.de> > >> Present Suggested new >> E | phot.fluxDens | phot.flux.fluxDens or: >> phot.flux.density >> E | phot.fluxDens.sb | phot.flux.fluxDens.sb or: >> phot.flux.density.sb >> > > I agree that the second choices phot.flux.density.* are better. > (Pierre - I don't think losing the fluxDens atom is a problem.) Don't want to step on any radio astronomer's toes, but flux density is flux. Yes, I know, it's monochromatic flux per unit frequency, but where's the distinction between bolometric flux, monochromatic flux per unit frequency, and monochromatic flux per unit wavelength? Do we also then have to support the use of candela's, lux's, and the lot - also physical (even SI!) terms for the same things? How about (see, e.g., Mihalas): phot.flux generic net rate of radiant energy flow per unit area and time phot.flux.freq monochromatic flux per unit frequency, flux density phot.flux.wave monochromatic flux per unit wavelength phot.flux.bol bolometric flux phot.flux.Eddington Eddington flux = flux / 4PI I was going to suggest adding phot.flux.astr (that terrible factor of PI or /1PI, depending upon how you look at it!), but I won't...... >>> Q | phys.massToLight | phys.mass.light >>> > I don't like this, since it's not a mass, it's a ratio. > It's really talking about the composition of the physical > environment (how much baryons, how much photons, etc.) > Maybe phys.composition.massLight (or phys.abund.massLight) I prefer phys.composition.massLightRatio Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alberto.Micol at eso.org Tue Nov 8 01:53:32 2005 From: Alberto.Micol at eso.org (Alberto Micol) Date: Tue, 8 Nov 2005 10:53:32 +0100 Subject: In-Reply-To: <436FA73D.33150E@astro.u-strasbg.fr> References: <20051107164755.cwtk98wgjvq8gkk8@webmail.sic.rm.cnr.it> <436F846C.3010009@cea.fr> <436FA73D.33150E@astro.u-strasbg.fr> Message-ID: <008163c808564638c8a7415ae632b893@eso.org> Dear All, When we change UCDs we have to be careful, because those UCDs are probably already used out there. The same is true for the parsing (or writing) software, but I guess there is much less parsing software to change than there are catalogues making use of those UCDs. (And the suggested s/w change was really minimal) Nevertheless, mine (the ending semicolon) is a lost battle, I accept defeat. Overall, I think that the number of atoms should be kept small and structured, otherwise it become very difficult for data providers to assign UCDs in a consistent way. Having said that, I like the new structured atoms introduced by Jonathan (transition, state, species), exactly because "structure is good". Instead, I'm a bit skeptical regarding phys.energy.density and phot.flux.fluxDens or phot.flux.density. It is tempting to use: phys.energy;phys.density and phot.flux;phys.density Would that be so wrong? A couple of answers: Sebastien Derriere wrote: > > The debate on the usefulness of the semicolon at the end of the > UCD1+ > was concluded by introducing this rule of "no word should be substring > of another > at the same level". > The main motivation was that users would be reluctant to add a ; > at the end of every UCD. It is not affecting the end user, but just only the data provider, or actually, more often, the software written by a data provider. And since the software is always going to be written out of the UCDs specs I would have not seen any problem with the ending semicolon. > With the suggested rule, UCD curators have > to be careful when defining new words (what we do now, but only once > hopefully), but users life is made slightly easier. Jonathan McDowell wrote: > but when you pass it to your search/comparison tool, a trailing > semicolon gets added automatically > phot.fluxDens; Indeed, if the parsing software knew about the ';' then there would have been no problem whatsoever. And VO is about software, not about human readibility. Alberto From hessman at astro.physik.uni-goettingen.de Tue Nov 8 02:53:18 2005 From: hessman at astro.physik.uni-goettingen.de (Frederic V. "Rick" Hessman) Date: Tue, 8 Nov 2005 11:53:18 +0100 Subject: phot.flux - an Addendum In-Reply-To: <0F56C61F-8EAD-4A51-AF9E-53F3504D730D@astro.physik.uni-goettingen.de> References: <200511080421.jA84LL8f004051@sothis.cfa.harvard.edu> <0F56C61F-8EAD-4A51-AF9E-53F3504D730D@astro.physik.uni-goettingen.de> Message-ID: <315AEB18-8F62-4864-864D-82DEBC808069@astro.physik.uni-goettingen.de> > Don't want to step on any radio astronomer's toes, but flux density > is flux. Yes, I know, it's monochromatic flux per unit > frequency, but where's the distinction between bolometric flux, > monochromatic flux per unit frequency, and monochromatic flux per > unit wavelength? Do we also then have to support the use of > candela's, lux's, and the lot - also physical (even SI!) terms for > the same things? How about (see, e.g., Mihalas): > > phot.flux generic net rate of radiant > energy flow per unit area and time > phot.flux.freq monochromatic flux per unit > frequency, flux density > phot.flux.wave monochromatic flux per unit wavelength > phot.flux.bol bolometric flux > phot.flux.Eddington Eddington flux = flux / 4PI > > I was going to suggest adding phot.flux.astr (that terrible factor > of PI or /1PI, depending upon how you look at it!), but I won't...... Sorry - should have re-read the 1.02 documentation: "flux density" has been generalized beyond it's normal use. How do we then distinguish between the many different forms? By units alone, i.e. non-UCD things? That works fine for things like lengths and times and masses, since the physical quantities are well defined beyond their units, but F_nu and F_lambda are totally different quantities and this fact is utterly independent of the units. Perhaps phot.flux.perFreq phot.flux.perWave phot.flux.perEnergy phot.flux.perWavenumber phot.flux.perDecade nu*F_nu, lambda*F_lambda,... Looking at the current list, I'd also like to complain about phot.flux.sb Since when is surface brightness a flux? Surface brightness is an intensity and intensity != flux. So... phot.intensity generic directed rate of radiant energy flow per unit area, time, and solid angle, surface brightness phot.intensity.bol (not generally needed, but here for symmetry) phot.intensity.perFreq phot.intensity.perWave phot.intensity.perEnergy phot.intensity.perWavenumber phot.intensity.perDecade (Ibid.) I know this is a bit of a change, but I frankly didn't notice before.... sorry! Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrea.preitemartinez at rm.iasf.cnr.it Tue Nov 8 05:53:45 2005 From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez) Date: Tue, 08 Nov 2005 14:53:45 +0100 Subject: UCDlist document update Message-ID: <20051108145345.trrx6vmck0oc8g8s@webmail.sic.rm.cnr.it> Dear all, after a first round of comments and suggestions, let me summarize: 1. I think it will be unwise to re-open the discussion on the already standard UCD main document (thus de-classing it back to WD) to ease the approval of a second standard, just because we are too lazy to find a reasonable spelling for a few words! 2. Let?s keep changes to a minimum. I found suggestions on the atmol and flux/sb words very interesting and worth discussing with more time and care. Shortly we will know how to do it ! (http://www.ivoa.net/Documents/latest/UCDmaintenance.html) 3. atmol: I think the simplest solution in this particular case is to change the words phys.at.* into phys.atomic.* 4. ?obtorto collo? (we do it, but we whould have preferred not to do it!) we go for phot.flux.density* and phys.energy.density 5. phys.massToLight can become phys.composition.massLightRatio (indeed the ratio has to do with the barionic composition of galaxies or clusters of galaxies) 6. phys.massYield can become phys.composition.yield (also in this case the new version is better than the old one - mass just indicated units) I will wait for a few more days before changing the list of words. Cheers Andrea ============================================================================== Andrea Preite Martinez andrea.preitemartinez at rm.iasf.cnr.it Istituto di Astrofisica Spaziale Tel.:+39.06.4993.4641 Area di Ricerca di Tor Vergata Fax.:+39.06.2066.0188 Via del Fosso del Cavaliere 100 Cell:+39.339.3817355 00133 Roma CDS :+33.3.90242473 ============================================================================== From Pedro.Osuna at esa.int Tue Nov 8 06:45:23 2005 From: Pedro.Osuna at esa.int (Pedro Osuna) Date: Tue, 08 Nov 2005 15:45:23 +0100 Subject: UCDlist document update In-Reply-To: <20051108145345.trrx6vmck0oc8g8s@webmail.sic.rm.cnr.it> References: <20051108145345.trrx6vmck0oc8g8s@webmail.sic.rm.cnr.it> Message-ID: <1131461123.32035.196.camel@isol03.vilspa.esa.int> Dear all, on the phys.atmol subject, I'd like to see Marie-Lise opinion before you write any changes, as she introduced many of the initial UCDs for that. In principle, Jonathan's new names look OK in view of our own work on Line DM, but I insist that she should say a word on it. Unfortunately, she does not seem to be on-line, so: Andrea, can this part wait until we know from her? Cheers, P. On Tue, 2005-11-08 at 14:53 +0100, Andrea Preite Martinez wrote: > Dear all, > > after a first round of comments and suggestions, let me summarize: > > 1. I think it will be unwise to re-open the discussion on the already > standard UCD main document (thus de-classing it back to WD) to ease the > approval of a second standard, just because we are too lazy to find a > reasonable spelling for a few words! > > 2. Let?s keep changes to a minimum. I found suggestions on the atmol > and flux/sb words very interesting and worth discussing with more time > and care. Shortly we will know how to do it ! > (http://www.ivoa.net/Documents/latest/UCDmaintenance.html) > > 3. atmol: I think the simplest solution in this particular case is to > change the words phys.at.* into phys.atomic.* > > 4. ?obtorto collo? (we do it, but we whould have preferred not to do > it!) we go for phot.flux.density* and phys.energy.density > > 5. phys.massToLight can become phys.composition.massLightRatio (indeed > the ratio has to do with the barionic composition of galaxies or > clusters of galaxies) > > 6. phys.massYield can become phys.composition.yield (also in this case > the new version is better than the old one - mass just indicated units) > > I will wait for a few more days before changing the list of words. > > Cheers > > Andrea > > > ============================================================================== > Andrea Preite Martinez andrea.preitemartinez at rm.iasf.cnr.it > Istituto di Astrofisica Spaziale Tel.:+39.06.4993.4641 > Area di Ricerca di Tor Vergata Fax.:+39.06.2066.0188 > Via del Fosso del Cavaliere 100 Cell:+39.339.3817355 > 00133 Roma CDS :+33.3.90242473 > ============================================================================== > > From genova at cluster.u-strasbg.fr Tue Nov 8 06:54:49 2005 From: genova at cluster.u-strasbg.fr (Francoise Genova) Date: Tue, 8 Nov 2005 15:54:49 +0100 (MET) Subject: UCDlist document update Message-ID: <200511081454.jA8Esnx13829@astro.u-strasbg.fr> Hi, Marie-Lise is presently chairing a session of the French VO school. She will have a look ASAP Cheers Francoise From marie-lise.dubernet at obspm.fr Tue Nov 8 08:43:33 2005 From: marie-lise.dubernet at obspm.fr (marie-lise.dubernet at obspm.fr) Date: Tue, 8 Nov 2005 17:43:33 +0100 (CET) Subject: UCDlist document update In-Reply-To: <1131461123.32035.196.camel@isol03.vilspa.esa.int> References: <20051108145345.trrx6vmck0oc8g8s@webmail.sic.rm.cnr.it> <1131461123.32035.196.camel@isol03.vilspa.esa.int> Message-ID: dear all, sorry for delayed answer. the DM details are not final yet, therefore I would not advise to use the DM (even if UCD have no meaning without the DM). At present my view is to unify all quantities related to atomic and molecular physics under a single word phys.atmol.* "quantities related to atomic and molecular processes" A more complete list of UCD will be proposed once the DM is set "final". best regards marie lise On Tue, 8 Nov 2005, Pedro Osuna wrote: > Dear all, > > on the phys.atmol subject, I'd like to see Marie-Lise opinion before you > write any changes, as she introduced many of the initial UCDs for that. > In principle, Jonathan's new names look OK in view of our own work on > Line DM, but I insist that she should say a word on it. Unfortunately, > she does not seem to be on-line, so: Andrea, can this part wait until we > know from her? > > Cheers, > P. > > > On Tue, 2005-11-08 at 14:53 +0100, Andrea Preite Martinez wrote: > > Dear all, > > > > after a first round of comments and suggestions, let me summarize: > > > > 1. I think it will be unwise to re-open the discussion on the already > > standard UCD main document (thus de-classing it back to WD) to ease the > > approval of a second standard, just because we are too lazy to find a > > reasonable spelling for a few words! > > > > 2. Let?s keep changes to a minimum. I found suggestions on the atmol > > and flux/sb words very interesting and worth discussing with more time > > and care. Shortly we will know how to do it ! > > (http://www.ivoa.net/Documents/latest/UCDmaintenance.html) > > > > 3. atmol: I think the simplest solution in this particular case is to > > change the words phys.at.* into phys.atomic.* > > > > 4. ?obtorto collo? (we do it, but we whould have preferred not to do > > it!) we go for phot.flux.density* and phys.energy.density > > > > 5. phys.massToLight can become phys.composition.massLightRatio (indeed > > the ratio has to do with the barionic composition of galaxies or > > clusters of galaxies) > > > > 6. phys.massYield can become phys.composition.yield (also in this case > > the new version is better than the old one - mass just indicated units) > > > > I will wait for a few more days before changing the list of words. > > > > Cheers > > > > Andrea > > > > > > ============================================================================== > > Andrea Preite Martinez andrea.preitemartinez at rm.iasf.cnr.it > > Istituto di Astrofisica Spaziale Tel.:+39.06.4993.4641 > > Area di Ricerca di Tor Vergata Fax.:+39.06.2066.0188 > > Via del Fosso del Cavaliere 100 Cell:+39.339.3817355 > > 00133 Roma CDS :+33.3.90242473 > > ============================================================================== > > > > > > From seaman at noao.edu Tue Nov 8 13:19:57 2005 From: seaman at noao.edu (Rob Seaman) Date: Tue, 8 Nov 2005 14:19:57 -0700 Subject: UCD verifier? In-Reply-To: <200511080421.jA84LL8f004051@sothis.cfa.harvard.edu> References: <200511080421.jA84LL8f004051@sothis.cfa.harvard.edu> Message-ID: Hi, > UCD1+ words at the same level in the hierarchy cannot be a starting > substring of another With the recent talk about the UCD1+ list not conforming to the UCD specification, I am prompted to wonder whether anyone is working on a UCD verifier - or perhaps one already exists? It seems to me that a tool would be very useful for verifying that a single token is a conforming UCD and that a list of same avoids various classes of name collisions and other errors. This will help individuals who want to suggest new UCDs as well as projects who may be developing their own namespaces. Rob Seaman NOAO From seaman at noao.edu Wed Nov 9 05:55:26 2005 From: seaman at noao.edu (Rob Seaman) Date: Wed, 9 Nov 2005 06:55:26 -0700 Subject: UCD verifier? In-Reply-To: <20051109092326.ve3i452crb6s4wgs@webmail.sic.rm.cnr.it> References: <200511080421.jA84LL8f004051@sothis.cfa.harvard.edu> <20051109092326.ve3i452crb6s4wgs@webmail.sic.rm.cnr.it> Message-ID: On Nov 9, 2005, at 1:23 AM, Andrea Preite Martinez wrote: >> With the recent talk about the UCD1+ list not conforming to the >> UCD specification, I am prompted to wonder whether anyone is >> working on a UCD verifier - or perhaps one already exists? > > Yes, try the validate tool at > http://vizier.u-strasbg.fr/UCD/tools.htx Thanks. Other pointed me to that, too. The rules and meta-rules for UCD building imply that each UCD fills a niche in a larger semantic ecology. Each new UCD causes a potential challenge to all previously declared UCDs or lists or namespaces of same. The tool I was suggesting would not only test a single proposed UCD against the syntactical rules, but also test a list of same (e.g., representing a namespace) against the rules for building lists of UCDs. I suspect that the notion that two namespaces cannot contain identical UCDs (or more stringently, was it identical "words"?) will fall by the wayside, but if not, it would prove useful - almost mandatory - to have a tool to vet two lists against each other, or for instance, a newly proposed list against all previously registered namespaces. Which is to say that the choice of rules for assembling lists of UCDs is not a completely free design parameter. Rob Seaman NOAO From iz at sai.msu.ru Fri Nov 25 16:15:54 2005 From: iz at sai.msu.ru (Ivan Yu. Zolotukhin) Date: Sat, 26 Nov 2005 03:15:54 +0300 (MSK) Subject: question on UCD web service Message-ID: Hello, My question concerns some of the CDS web services, I'm trying to make use of http://cdsws.u-strasbg.fr/axis/services/UCD?wsdl and call method "assign" to resolve natural language description to UCD in my client. The main problem for my case is ambiguity: my client should propose to the user that provides ambiguous description like "astronomical coordinates" or "velocity" several variants to choose from. But above service provides only best match (you call it "suggested complete UCD" in the cgi interface), whereas in the cgi interface http://cdsweb.u-strasbg.fr/UCD/cgi-bin/descr2ucd all the matches are proposed. As far as I understand, it is not difficult to deploy a service that would reply with all the possible matches, because this functionality is already avaliable in the cgi. Maybe some flag to assign method or new method that does not affect existing clients? Sincerely, Ivan Zolotukhin From derriere at newb6.u-strasbg.fr Mon Nov 28 09:23:37 2005 From: derriere at newb6.u-strasbg.fr (Sebastien Derriere) Date: Mon, 28 Nov 2005 18:23:37 +0100 Subject: question on UCD web service References: Message-ID: <438B3D19.14606FCF@astro.u-strasbg.fr> "Ivan Yu. Zolotukhin" wrote: > > As far as I understand, it is not difficult to deploy a service that would > reply with all the possible matches, because this functionality is > already avaliable in the cgi. Maybe some flag to assign method or new > method that does not affect existing clients? Hi Ivan, I've just put a new method called "suggest" on this page: http://vizier.u-strasbg.fr/UCD/tools.htx It takes a description and returns a list of matching individual words, together with a score and the syntax flag, like what is provided on the descr2ucd page. Does this address your problem? There is only CGI access for the moment, but I'll try to make the WS access available soon. Cheers, 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 iz at sai.msu.ru Mon Nov 28 10:17:57 2005 From: iz at sai.msu.ru (Ivan Yu. Zolotukhin) Date: Mon, 28 Nov 2005 21:17:57 +0300 (MSK) Subject: question on UCD web service In-Reply-To: <438B3D19.14606FCF@astro.u-strasbg.fr> Message-ID: On Mon, 28 Nov 2005, Sebastien Derriere wrote: > I've just put a new method called "suggest" on this page: > http://vizier.u-strasbg.fr/UCD/tools.htx > It takes a description and returns a list of matching individual > words, together with a score and the syntax flag, like what is provided > on the descr2ucd page. > Does this address your problem? Yes, exactly, thanks! > There is only CGI access for the > moment, but I'll try to make the WS access available soon. I will make use of this web service right after you publish it, I do really need it. Sincerely, Ivan Zolotukhin From iz at sai.msu.ru Mon Nov 28 10:34:12 2005 From: iz at sai.msu.ru (Ivan Yu. Zolotukhin) Date: Mon, 28 Nov 2005 21:34:12 +0300 (MSK) Subject: UCD web service: possible bug of "assign" method Message-ID: Hello, Just want to post some comment on "assign" method of UCD web service, it works improperly in my opinion. It returns not UCD actually, but UCD plus \n symbol at the end of it. I thought that there is a problem with my client, but dump of SOAP conversation proves my guess: there is a '\n' symbol at the end of ucd inside element of soap envelope. So all clients return something like $real_ucd . "\n", using Perl terminology. Is it a correct behaviour? I think all the transformations with UCD should be left to client side, shouldn't they? Are there similar behaviour of other methods of this web service? If it is not correct, it's better to fix it now, otherwise many clients will depened on it. For instance, my client now removes this trailing linefeed to insert correct UCD into database. Sincerely, Ivan Zolotukhin From derriere at newb6.u-strasbg.fr Tue Nov 29 09:29:34 2005 From: derriere at newb6.u-strasbg.fr (Sebastien Derriere) Date: Tue, 29 Nov 2005 18:29:34 +0100 Subject: UCD web service: possible bug of "assign" method References: Message-ID: <438C8FFE.A6E4CADC@astro.u-strasbg.fr> "Ivan Yu. Zolotukhin" wrote: > > Hello, > > Just want to post some comment on "assign" method of UCD web service, it > works improperly in my opinion. It returns not UCD actually, but UCD plus > \n symbol at the end of it. I thought that there is a problem with my > client, but dump of SOAP conversation proves my guess: there is a '\n' > symbol at the end of ucd inside element of soap envelope. So all > clients return something like $real_ucd . "\n", using Perl terminology. > > Is it a correct behaviour? I think all the transformations with UCD should > be left to client side, shouldn't they? Are there similar behaviour of > other methods of this web service? > > If it is not correct, it's better to fix it now, otherwise many clients > will depened on it. For instance, my client now removes this trailing > linefeed to insert correct UCD into database. Hello, Indeed, most of the methods return a trailing '\n' character at the end of the result. But nobody had complained yet about this behaviour. I'm reluctant to change the behaviour of these methods now, because they may be already implemented in various places, and I guess developers have added a line of code to remove this character in case they needed to. And they might be upset to see a working implementation getting wrecked because of a "bug fix". Unless there is a large protest against this extra '\n', I'd rather keep the currently available methods as they are, and take care of better documenting the future ones. Regards, 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 derriere at newb6.u-strasbg.fr Wed Nov 30 01:43:29 2005 From: derriere at newb6.u-strasbg.fr (Sebastien Derriere) Date: Wed, 30 Nov 2005 10:43:29 +0100 Subject: question on UCD web service References: Message-ID: <438D7441.51BBB60E@astro.u-strasbg.fr> "Ivan Yu. Zolotukhin" wrote: > > On Mon, 28 Nov 2005, Sebastien Derriere wrote: > > > I've just put a new method called "suggest" on this page: > > http://vizier.u-strasbg.fr/UCD/tools.htx > > It takes a description and returns a list of matching individual > > words, together with a score and the syntax flag, like what is provided > > on the descr2ucd page. > > Does this address your problem? > > Yes, exactly, thanks! > > > There is only CGI access for the > > moment, but I'll try to make the WS access available soon. > > I will make use of this web service right after you publish it, I do > really need it. Hello, The "suggest" method has been added to the WebServices. Cheers, 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 dtody at nrao.edu Wed Nov 30 22:05:03 2005 From: dtody at nrao.edu (Doug Tody) Date: Wed, 30 Nov 2005 23:05:03 -0700 (MST) Subject: VOConcepts paper (fwd) Message-ID: [This discussion probably should be on the ucd or semantics list rather than voevent, which is an application.] ---------- Forwarded message ---------- Date: Wed, 30 Nov 2005 22:58:14 -0700 (MST) From: Doug Tody To: Roy Williams Cc: IVOA List VOEvent Subject: Re: VOConcepts paper The use-case identified in Madrid, which prompted the need for standard object type names was searching by object type in SSA. We want to be able to do things like query for spectra where targetclass=QSO. I was expecting to see a simple list of names like "star", "galaxy", "PN", "QSO", "AGN", "GRB", etc., which is what I think users would like to search for, but what we have instead are more UCD-like names such as "process.variation.burst;em.gamma" which I guess indicates a GRB. I can see where it could be useful to specify more precisely what type of object we have as the UCD approach suggested permits, but it would also be useful to standardize the actual, simple acronyms commonly used by astronomers. Perhaps what we need are two lists, one for precise characterisation of physical object types, another defining the common, standard acronym associated with such object types. This could be done by merely defining a standard list of acronyms for object types, and assigning one to each of the object type UCDs, where appropriate. - Doug On Wed, 30 Nov 2005, Roy Williams wrote: > Please find attached a white paper from Andrea Preite-Martinez, the chairman > of the IVOA Semantics working group, which is a first attempt to build a > standard vocabulary for astronomical phenomena and for astronomical objects. > I would like to have a brief discussion of this at the VOEvent meeting next > week, and/or receive comments by email from those who cannot attend the > meeting. Rick Hessman has already worked on exactly this topic. > > I would like to compile a "group response feedback" on this paper for Andrea > and the Semantics WG. > > Roy Williams > > California Institute of Technology > 626 395 3670 > >