From andrea.preitemartinez at rm.iasf.cnr.it Mon Jul 11 08:01:03 2005 From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez) Date: Mon, 11 Jul 2005 17:01:03 +0200 Subject: draft PR doc on ucd-words Message-ID: <20050711170103.buzzas2dadesw8cs@webmail.sic.rm.cnr.it> After 4 weeks of discussion in the Sci-board and some extra time to set up the document, you'll find attached a draft version of the document containing the list of ucd-words. Note for the Sci-board: I included the last comments. I also had to modify a number of words to be compliant with the UCD-Rec document ("... for any two words at the same level in the hierarchy, one can't be a starting substring of the other..."), so old version =============> new version phot.fluxDensity phot.fluDensity phys.energyDensity phys.energDensity phys.massYield phys.mYield pos.earthop pos.eop Of course there is still the case of phys.at/atmol, but we can wait for the revision of the whole list of atomic and molecular ucds. I submit the document+list to the members of the UCD-WG because this is the IVOA standard procedure, and I formally ask you if we can move from the WD phase to the PR phase. In this particular case we also had to follow another "formal" procedure, estabished by the UCD main document, to generate and maintain the list of ucd-words. This is why I'm sending the draft to both mailing lists. The document is already in the PR "format" but, being a draft, the link to the RFC page is of course not yet activated. If you have major objections (on the content of the document/list of words) please let me know asap. According to our roadmap, we have to move the UCD-list document from the WD phase to the PR phase within July. This would mean asking for comments on the PR document during a holiday period. I think it would be better to issue the RFC in the second half of August. Please let me know if you disagree on that. Best regards Andrea ============================================================================== Andrea Preite Martinez andrea 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 ============================================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: UCDlist-20050711.pdf Type: application/pdf Size: 1199680 bytes Desc: not available URL: From dtody at nrao.edu Mon Jul 11 09:36:25 2005 From: dtody at nrao.edu (Doug Tody) Date: Mon, 11 Jul 2005 10:36:25 -0600 (MDT) Subject: draft PR doc on ucd-words In-Reply-To: <20050711170103.buzzas2dadesw8cs@webmail.sic.rm.cnr.it> Message-ID: On Mon, 11 Jul 2005, Andrea Preite Martinez wrote: > Note for the Sci-board: I included the last comments. I also had to modify a > number of words to be compliant with the UCD-Rec document ("... for any two > words at the same level in the hierarchy, one can't be a starting substring > of the other..."), so > > old version =============> new version > > phot.fluxDensity phot.fluDensity > phys.energyDensity phys.energDensity > phys.massYield phys.mYield > pos.earthop pos.eop I haven't been following the UCD discussions, and while I am sure there is some reason for this change, these name changes do not look like an improvement. The "old" version is clearly preferable here. - Doug From jcm at head.cfa.harvard.edu Mon Jul 11 10:24:49 2005 From: jcm at head.cfa.harvard.edu (Jonathan McDowell) Date: Mon, 11 Jul 2005 13:24:49 -0400 (EDT) Subject: draft PR doc on ucd-words Message-ID: <200507111724.j6BHOnJa000739@sothis.cfa.harvard.edu> On Mon, 11 Jul 2005, Andrea Preite Martinez wrote: > Note for the Sci-board: I included the last comments. I also had to modify a > number of words to be compliant with the UCD-Rec document ("... for any two > words at the same level in the hierarchy, one can't be a starting substring > of the other..."), so > > old version =============> new version > > phot.fluxDensity phot.fluDensity I agree with Doug. I hate the new versions. I think the "can't be a starting substring" was put in to make some kinds of searching easier, but I never found the argument convincing and would argue that we should instead remove this restriction from the UCD-Rec document. - Jonathan From sla at ucolick.org Mon Jul 11 10:55:54 2005 From: sla at ucolick.org (Steve Allen) Date: Mon, 11 Jul 2005 10:55:54 -0700 Subject: draft PR doc on ucd-words In-Reply-To: References: <20050711170103.buzzas2dadesw8cs@webmail.sic.rm.cnr.it> Message-ID: <20050711175554.GD26543@ucolick.org> On Mon 2005-07-11T10:36:25 -0600, Doug Tody hath writ: > > old version =============> new version > > pos.earthop pos.eop In this one case the new version is actually more mnemonic for those of us who look at such data regularly. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99858 University of California Voice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From andrea.preitemartinez at rm.iasf.cnr.it Tue Jul 12 06:32:45 2005 From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez) Date: Tue, 12 Jul 2005 15:32:45 +0200 Subject: UCD-list: pdf/html file Message-ID: <20050712153245.dzuvuukco8hwkw0s@webmail.sic.rm.cnr.it> Sorry for yersteday, the attached file had extension ".pdf" but it was a .ps!! As for the content of the document, I agree with Doug and Jonathan, so it is a pleasure for me to come back to the old spelling "phot.fluxDens" ! I keep "pos.eop" (by the way, this was the spelling proposed by planetary people!) I added a note in the doc explaining that a few words are not complying with one of the recs in the main document. I uploaded the document in the ivoa doc repository http://www.ivoa.net/Documents. I hope it'll be made available soon. Andrea ============================================================================== Andrea Preite Martinez andrea 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 ============================================================================== From Matteo.Guainazzi at sciops.esa.int Wed Jul 13 00:45:28 2005 From: Matteo.Guainazzi at sciops.esa.int (Matteo Guainazzi) Date: Wed, 13 Jul 2005 07:45:28 +0000 Subject: Late comments (mainly) on the UCD word list Message-ID: <42D4C698.70908@sciops.esa.int> Dear Andrea et al., you will find below some comments, mainly on the current UCD list, prepared by Ana and myself. If I interpret correctly your last message to the UCD SciBoard, we have passed the deadline, when the contributions from the UCD SciBoard were expected to come. If so, we have obviously missed some important information about the time-line. We apologize for that. Should our comment be arrived beyond the time horizon, feel free to ignore them for the time being, and to postpone them for the next round of comments, if anyhow interesting: 1. we propose to remove all the words containing an explicit specification of the wavelength or frequency range. They should be replaced by words of the type: "em.wl.start; em.wl.end" (these words do not exist, and should be added). Rationale: the current method lacks flexibility, and is very likely not to cover all the interesting wavelengths ranges in existing catalogues, where "standard" wavelength ranges do not exist (e.g., high-energy) 2. we propose to substitute "instr.${band}" for all words of the type "em.${band}". Rationale: the sensitive bandpass is a property of the detector 3. we propose to add the words "em.wl.start" and "em.wl.stop". Rationale: they may be useful and flexible characterizations of the bandpass 4. we propose to move "instr.obsty.site.seeing" to "obs.seeing". Rationale: this is a property of an observation rather than of an instrument 5. we propose to unify "instr.beam" and "instr.det.psf" into "instr.psf". Rationale: in most cases, users are interested in the overall PSF (optics+detector). "Beam" is the radio jargon for PSF. Should the detector PSF be necessary, one could use: "instr.psf; instr.det" 6. we propose to remove "instr.precision". Rationale: too generic, probably useless 7. we propose to add the following radio-related words: "instr.interferometry", and "instr.resolution". Rationale: the former is self-explaining; the latter indicates the spatial resolution 8. we propose to change the word code of "instr.filter.transm" and "instr.spect.resolution" to "V". Rationale: the filter transmission is an intrinsically vectorial quantity; the spectral resolution as well (dependence on energy and/or order) 9. we propose to add a further atom to the "Multiplicity of binarity flag": "meta.code.multip.star", "meta.code.multip.planet". Rationale: self-explaining 10. we propose to add a further "meta" atom: "meta.subexp". Rationale: this will allow to characterize the rank of sub-exposures in a multi-exposure observations, whenever useful for, e.g., variability studies 11. we propose to add a further "meta" atom: "meta.rank". Rationale: useful to indicate an element in an intrinsically vectorial quantity 12. we propose to move "meta.id" and "meta.id.assoc" to "src.id" and "src.id.assoc". Rationale: they belong to "sources" rather then to "metadata" 13. we believe that the following "phys" word should be moved to "src": "phys.angArea", "phys.AngSize" (and associated words), "phys.area", "phys.size" (and associated words). Rationale: the same as #12 above 14. we believe that words belonging to the following categories: "phot", "pos", "spec", should be placed under the category "src" (e.g.: "phot.antennaTemp" -> "src.phot.antennaTemp", "pos.angDistance" -> "src.pos.angDistance"; "spect.Doppler" -> "src.spect.Doppler". Rationale: all these words ultimately describe source properties 15. the words for coupling of quantum numbers do not cover all the possible coupling cases. A more general method is needed, and the Data Line Model sub-group is indeed working on this. We propose to wait for the conclusion of their work, before this issue is ultimately addressed 16. a new word "pos.offaxis" should be added. Rationale: the off-axis angle may be a useful quantity is some catalogs 17. "pos.earth", "pos.earth.lat", "pos.earth.lon" should be placed under the "obs" category. Rationale: these quantity belongs logically to an observation, not to (the position of) a source 18. "pos.earth.nutation" should be removed. Rationale: it is no longer consistent with the IAU specification 19. a new word "src.ephem" should be added. Rationale: it is necessary to separate "observatory" from "source" ephemeris 20. "spect.veloc" should be replaced by "src.radial.vel". Rationale: it is a property of the source, rather than of a spectrum 21. we propose to add "src.stellarityIndex". Rationale: it may be useful to easily discriminate point-like from extended sources 22. we propose to add the following words in the "stat" category: "stat.distribution", "stat.fit.model". Rationale: without them, the information on the statistical quantities and/or the fit are incomplete 23. we propose to replace "stat.moment" (as a vectorial quantity) for "stat.mean" and "stat.stdev". Any of the statistical moments could be therefore indicated by the UCD: "stat.moment; meta.rank". Rationale: the proposed method is more flexible, and could avoid the proliferation of new words to indicate skewness, kurtosis ... 24. the following words should be moved from the category "time" to "src": "time.age", "time.crossing", "time.period", "time.phase", "time.relax". E.g.: "time.age" -> "src.time.age". Rationale: they logically belong to a source rather them to the 4th dimension 25. we propose to add the following word: "time.deadtime". Rationale: useful for photon-counting devices based catalogues An additional point that we have discussed concerns the units in which interferometric data shall be provided. Is it accepted that data providers have to convert them in physical units at the server level? If not, we need probably to include specific UCD words to deal with "images" in the Fourier space. I again apologize for the long and late message. Thanks for your attention. Regards, Matteo & Ana -- Matteo Guainazzi XMM-Newton SOC Matteo.Guainazzi at sciops.esa.int European Space Astronomy Center of ESA Phone: +34 91 8131 176 VILSPA, Apartado 50727, E-28080 Madrid Fax: +34 91 8131 172 From sla at ucolick.org Wed Jul 13 06:39:46 2005 From: sla at ucolick.org (Steve Allen) Date: Wed, 13 Jul 2005 06:39:46 -0700 Subject: Late comments (mainly) on the UCD word list In-Reply-To: <42D4C698.70908@sciops.esa.int> References: <42D4C698.70908@sciops.esa.int> Message-ID: <20050713133946.GA17964@ucolick.org> On Wed 2005-07-13T07:45:28 +0000, Matteo Guainazzi hath writ: > 20. "spect.veloc" should be replaced by "src.radial.vel". Rationale: it > is a property of the source, rather than of a spectrum This is quite contrary to the notions clearly espoused by Lindegren and Dravins (2003) A&A 401, 1185. Without a model there is no way to assign a radial velocity to a source. The measurable quantity, is a spectral shift for which any apparent radial velocity is merely conventional. That said, it remains the case that many instances of conventional radial velocity measures exist in the literature. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99858 University of California Voice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From hessman at Astro.physik.Uni-Goettingen.DE Thu Jul 14 02:45:30 2005 From: hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. Hessman) Date: Thu, 14 Jul 2005 11:45:30 +0200 Subject: Late comments (mainly) on the UCD word list In-Reply-To: <42D4C698.70908@sciops.esa.int> References: <42D4C698.70908@sciops.esa.int> Message-ID: <6180f164fbf9daa4f9084e652f649cc6@astro.physik.uni-goettingen.de> > 2. we propose to substitute "instr.${band}" for all words of the type > "em.${band}". Rationale: the sensitive bandpass is a property of the > detector I agree that we'll never have a complete list of useful wavelength regions, but there is still a difference between "an instrument with the bandpass of a Bessel V filter" (instr.opt.V) and "photons with wavelength corresponding to the peak of a Bessel V filter" (em.opt.V). Although I see arguments for both, I personally prefer the old form. > 4. we propose to move "instr.obsty.site.seeing" to "obs.seeing". > Rationale: this is a property of an observation rather than of an > instrument Did anyone ever respond to my suggestion of using the primary word "weather"? Seeing is only the property of an observation if used to describe image properties. If one is careful, it's not even the property of an observatory but simply part of the "weather". We need other weather words anyway, so weather.seeing weather.temp weather.humidity weather.precipitation which permits the weather generally or the "weather" inside a dome to be described. If you want the seeing within an image (which is implied by "instr.obsty.site.seeing" since it's tied to an instr), then you need things like > 9. we propose to add a further atom to the "Multiplicity of binarity > flag": "meta.code.multip.star", "meta.code.multip.planet". Rationale: > self-explaining YUK! I propose to DROP meta.code.multip ALTOGETHER : why single out this one property of objects when there are zillions of others? The other meta.codes are tolerable because they're very general and inspecific (e.g. "quality" or "class") or at the very worst boolean ("membership"). > 10. we propose to add a further "meta" atom: "meta.subexp". Rationale: > this will allow to characterize the rank of sub-exposures in a > multi-exposure observations, whenever useful for, e.g., variability > studies Sorry - another YUK! This is even worse than using src.class.distance officially only for Abell distance class. The only reasonable solution is a general-purpose hierarchy structure word: meta.pos or maybe meta.hierarch, where one can easily recognize that, e.g., the value "0" or "A" is the top level, "1" or "B" the next, etc. Then one could use this for all kinds of things. > 11. we propose to add a further "meta" atom: "meta.rank". Rationale: > useful to indicate an element in an intrinsically vectorial quantity See above. > 12. we propose to move "meta.id" and "meta.id.assoc" to "src.id" and > "src.id.assoc". Rationale: they belong to "sources" rather then to > "metadata" Only if one is applying them to sources: when applying them to other things (e.g. XML document id's), one would have a problem with src. > 13. we believe that the following "phys" word should be moved to > "src": > "phys.angArea", "phys.AngSize" (and associated words), "phys.area", > "phys.size" (and associated words). Rationale: the same as #12 above Ibid. > 14. we believe that words belonging to the following categories: > "phot", > "pos", "spec", should be placed under the category "src" (e.g.: > "phot.antennaTemp" -> "src.phot.antennaTemp", "pos.angDistance" -> > "src.pos.angDistance"; "spect.Doppler" -> "src.spect.Doppler". > Rationale: all these words ultimately describe source properties Just as you argued above to place the words appropriately, antennaTemp is DEFINITELY not a property of a src but of an obs or instr. > 15. the words for coupling of quantum numbers do not cover all the > possible coupling cases. A more general method is needed, and the Data > Line Model sub-group is indeed working on this. We propose to wait for > the conclusion of their work, before this issue is ultimately addressed > > 16. a new word "pos.offaxis" should be added. Rationale: the off-axis > angle may be a useful quantity is some catalogs A better and more general choice would be "pos.relative". > 21. we propose to add "src.stellarityIndex". Rationale: it may be > useful > to easily discriminate point-like from extended sources Too specific. The current "src.class.starGalaxy" is just as bad or worse (as if there are only stars and galaxies out there!). A MUCH better solution is "src.class.resolved". Please dump src.class.starGalaxy!!!! Finally, there are still two corrections to the descriptions to remove narrow applications of general concepts: src.morph.type | morphological type, e.g. Hubble (there are others!!!) src.morph.scLength | scale length, e.g. of disk or bulge in a galaxy (there are others!!!) src.spType | spectral type, e.g. MK (there are others!!!!) Otherwise, OK. I'm still not enthusiastic about the inconsistant use of contractions ("lg" is OK for "local group" but "sg" is not OK for "supergalactic"???), but there are obviously too many of us old people who grew up worrying about to get our data into 4k of computer memory or (like myself) wrote their disserations at home using an acoustic modem at 300 baud and so don't trust computers and networks to handle strings longer than about 8 characters. ;-) Rick ------------------------------------------------------------------------ ------------------------ NEW ADDRESS!!! ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Institut f?r Astrophysik Tel. +49-551-39-5052 Friedrich-Hund-Platz 1 Fax +49-551-39-5043 37077 Goettingen Room F04-133 http://www.Astro.physik.Uni-Goettingen.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.Uni-Goettingen.de ------------------------------------------------------------------------ ------------------------- From andrea.preitemartinez at rm.iasf.cnr.it Fri Jul 15 04:54:59 2005 From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez) Date: Fri, 15 Jul 2005 13:54:59 +0200 Subject: Late comments (mainly) on the UCD word list In-Reply-To: <42D4C698.70908@sciops.esa.int> References: <42D4C698.70908@sciops.esa.int> Message-ID: <20050715135459.s5rkrvu5rp4wcgs8@webmail.sic.rm.cnr.it> > 1. we propose to remove all the words containing an explicit > specification of the wavelength or frequency range... > 2. we propose to substitute "instr.${band}" for all words of the type > "em.${band}". Rationale: the sensitive bandpass is a property of the > detector This has been a problem since the very beginning of the ucd's history. The pros and cons of different possible solutions were carefully considered, and at the end it was decided to consider that words were only a way to describe the wl/freq axis, NOT the properties of an instrument, and that the spelling was only mnemonic. The job of assigning the right em-word to a point or interval on that axis is done by a script, who takes care of units, band codes, intervals, difference of intervals (i.e.: colours in astronomy), so that, for example: 2.456mm is translated into em.mm.100-200GHz L em.IR.3-4um 0.1eV em.IR.8-15um 0.001nm em.gamma.hard V-N em.opt.V;em.IR.8-15um , and even F439W em.opt.B (Warning: the on-line script needs a quantity to assign an ucd. em-words are not, so add mag/flux... to your wl/freq/energy to get an answer) > 3. we propose to add the words "em.wl.start" and "em.wl.stop". > Rationale: they may be useful and flexible characterizations of the > bandpass In many cases I found a data/column description saying: beginning/minimum wl, ending/maximum wl, that I translated using stat.min, stat.max. On the other hand, beginning/ending of observation/exposure deserved wholly new ucd-words! So I'm in favour of introducing these concepts, but as generic qualifiers that can be applied to any axis (time, wl, freq, ..) > 4. we propose to move "instr.obsty.site.seeing" to "obs.seeing". > Rationale: this is a property of an observation rather than of an instrument I whould say seeing is a property of a . I also agree with Rick's suggestion, it's a property of the at a given site. > 5. we propose to unify "instr.beam" and "instr.det.psf" into > "instr.psf"... > 6. we propose to remove "instr.precision". Rationale: too generic, > probably useless A good occasion to repeat that the list of words was initially built entirely bottom-up, i.e. from data description. If "instr.precision" exists, it means that the description "precision", although too generic, has been used by some author. > 7. we propose to add the following radio-related words: > "instr.interferometry", and "instr.resolution". Rationale: the former is > self-explaining; the latter indicates the spatial resolution The former can be one of the many with syntax-flag S. As for the latter, at present: instrument resolution => pos.resolution image resolution => pos.resolution;obs.image spatial resolution => pos.resolution > 8. we propose to change the word code of "instr.filter.transm" and > "instr.spect.resolution" to "V". Rationale: the filter transmission is > an intrinsically vectorial quantity; the spectral resolution as well > (dependence on energy and/or order) The V-flag indicates a vector in space > 9. we propose to add a further atom to the "Multiplicity of binarity > flag": "meta.code.multip.star", "meta.code.multip.planet". Rationale: > self-explaining I think that is tolerable because it's sufficiently generic, and because it is used. > 10. we propose to add a further "meta" atom: "meta.subexp"... > 11. we propose to add a further "meta" atom: "meta.rank"... I need a use-case to make-up my mind > 12. we propose to move "xxx" to "src.xxx" > 13. as above > 14. as above > 20. as above > 24. as above In doing this, I think we would narrow the meaning of those words. > 16. a new word "pos.offaxis" should be added. Rationale: the off-axis > angle may be a useful quantity is some catalogs I agree. > 17. "pos.earth", "pos.earth.lat", "pos.earth.lon" should be placed under > the "obs" category. Rationale: these quantity belongs logically to an > observation, not to (the position of) a source I can assure you that pos.earth means position ON the earth, not source position on some earth-based coordinate frame!! > 18. "pos.earth.nutation" should be removed. Rationale: it is no longer > consistent with the IAU specification Changed. > 21. we propose to add "src.stellarityIndex". Rationale: it may be useful > to easily discriminate point-like from extended sources A word with the description ?stellarity index? already exists. > 22. we propose to add the following words in the "stat" category... > 23. Yes, I think a revision of the "stat" category is probably necessary. > 25. we propose to add the following word: "time.deadtime". Rationale: > useful for photon-counting devices based catalogues I agree. > An additional point that we have discussed concerns the units in which > interferometric data shall be provided... ?? UCDs do not care about units.. > Finally, there are still two corrections to the descriptions to > remove narrow applications of general concepts: > src.morph.type | morphological type, e.g. Hubble (there are others!!!) > src.morph.scLength | scale length, e.g. of disk or bulge in a > galaxy (there are others!!!) > src.spType | spectral type, e.g. MK (there are others!!!!) Sorry, but I did not study english at school. I studied latin. When you write: i.e. = id est, you mean: that is e.g. = exempli gratia, which means: for example (i.e., of course, there are others!!!) > I'm still not enthusiastic about the inconsistant use of contractions > ("lg" is OK for "local group" but "sg" is not OK for > "supergalactic"???), > but there are obviously too many of us old > people who grew up worrying about to get our > data into 4k of > computer memory... Indeed!!! I still feel that changing to ?supergalactic? was a terrible waste of memory!! :-) Andrea ============================================================================== Andrea Preite Martinez andrea 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 ============================================================================== From anai_gomez at mat.ucm.es Fri Jul 15 10:14:29 2005 From: anai_gomez at mat.ucm.es (Ana Ines Gomez de Castro) Date: Fri, 15 Jul 2005 19:14:29 +0200 (CEST) Subject: Late comments (mainly) on the UCD word list In-Reply-To: <20050715135459.s5rkrvu5rp4wcgs8@webmail.sic.rm.cnr.it> Message-ID: Hi, On Fri, 15 Jul 2005, Andrea Preite Martinez wrote: > > > 1. we propose to remove all the words containing an explicit > > specification of the wavelength or frequency range... > > 2. we propose to substitute "instr.${band}" for all words of the type > > "em.${band}". Rationale: the sensitive bandpass is a property of the > > detector > > This has been a problem since the very beginning of the ucd's history. The > pros and cons of different possible solutions were carefully considered, > and at the end it was decided to consider that words were only a way > to describe the wl/freq axis, NOT the properties of an instrument, and that > the spelling was only mnemonic. > The job of assigning the right em-word to a point or interval on that axis > is done by a script, who takes care of units, band codes, intervals, > difference of intervals (i.e.: colours in astronomy), so that, for example: > > 2.456mm is translated into em.mm.100-200GHz > L em.IR.3-4um > 0.1eV em.IR.8-15um > 0.001nm em.gamma.hard > V-N em.opt.V;em.IR.8-15um , and even > F439W em.opt.B > > (Warning: the on-line script needs a quantity to assign an ucd. em-words are > not, so add mag/flux... to your wl/freq/energy to get an answer) > Fine! How are you planing to deal with E230M, F28x50LP, F25CN2700 "filters" or GRISM? (these are standard optical elements in HST/STIS or ACS) > > 3. we propose to add the words "em.wl.start" and "em.wl.stop". > > Rationale: they may be useful and flexible characterizations of the > > bandpass > > In many cases I found a data/column description saying: beginning/minimum > wl, ending/maximum wl, that I translated using stat.min, stat.max. On the > other hand, beginning/ending of observation/exposure deserved wholly new > ucd-words! So I'm in favour of introducing these concepts, but as generic > qualifiers that can be applied to any axis (time, wl, freq, ..) > Fine! > > 4. we propose to move "instr.obsty.site.seeing" to "obs.seeing". > > Rationale: this is a property of an observation rather than of an instrument > > I whould say seeing is a property of a . > I also agree with Rick's suggestion, it's a property of the at a > given site. Fine. Should there also be some UCD for transparency? > > > 5. we propose to unify "instr.beam" and "instr.det.psf" into > > "instr.psf"... > > 6. we propose to remove "instr.precision". Rationale: too generic, > > probably useless > > A good occasion to repeat that the list of words was initially built > entirely bottom-up, i.e. from data description. If "instr.precision" > exists, it means that the description "precision", although too generic, > has been used by some author. > Could you ask the author what did he mean? > > 7. we propose to add the following radio-related words: > > "instr.interferometry", and "instr.resolution". Rationale: the former is > > self-explaining; the latter indicates the spatial resolution > > The former can be one of the many with syntax-flag S. > As for the latter, at present: > instrument resolution => pos.resolution > image resolution => pos.resolution;obs.image > spatial resolution => pos.resolution > > > 8. we propose to change the word code of "instr.filter.transm" and > > "instr.spect.resolution" to "V". Rationale: the filter transmission is > > an intrinsically vectorial quantity; the spectral resolution as well > > (dependence on energy and/or order) > > The V-flag indicates a vector in space > At the very first AVO meeting organized by Piero in Garching there was a long discussion about this issue. To fully understand the meaning of an image obtained with a given filter you need the Transmittance function of the filter ( T(lambda) ). Unless you force all the observatories to use exactly the same filters and qualify them, specifying the transmittance function is the easiest way to qualify them and allow proper comparisons between observations obtained with different instruments. Are "functions" allowed as UCDs > > 9. we propose to add a further atom to the "Multiplicity of binarity > > flag": "meta.code.multip.star", "meta.code.multip.planet". Rationale: > > self-explaining > > I think that is tolerable because it's sufficiently > generic, and because it is used. In the coming years, planets are going to be searched for in basically all stars around. There will be searched for not only on "single" star systems but on multiple systems. How are you planing to classify them? > > > 10. we propose to add a further "meta" atom: "meta.subexp"... > > 11. we propose to add a further "meta" atom: "meta.rank"... > HST is divides the exposure time into subexposures. For each sub-exposure an "image" is produced and archived within a single "archive record" that corresponds to the "exposure". In rapidly variable objects, it is relevant to make use of the "sub-exposures". If you wish to see a direct application where this relevance is oustanding take a glance to Gomez de Castro, 2002 (MNRAS). The target is AB Dor and the spectra where obtained with HST/HRS. > I need a use-case to make-up my mind > > > 12. we propose to move "xxx" to "src.xxx" > > 13. as above > > 14. as above > > 20. as above > > 24. as above I think that they are self-explanatory > > In doing this, I think we would narrow the meaning of those words. > Why? > > 16. a new word "pos.offaxis" should be added. Rationale: the off-axis > > angle may be a useful quantity is some catalogs > I agree. > > > 17. "pos.earth", "pos.earth.lat", "pos.earth.lon" should be placed under > > the "obs" category. Rationale: these quantity belongs logically to an > > observation, not to (the position of) a source > > I can assure you that pos.earth means position ON the earth, not source > position on some earth-based coordinate frame!! Then, why are them within the "pos" category? I thought that "pos" is related with "source" and "obs" with the observation/observatory. Doesn't it look more natural, obs.pos.earth.lat? > > > 18. "pos.earth.nutation" should be removed. Rationale: it is no longer > > consistent with the IAU specification > Changed. > > > 21. we propose to add "src.stellarityIndex". Rationale: it may be useful > > to easily discriminate point-like from extended sources > > A word with the description ?stellarity index? already exists. > > > 22. we propose to add the following words in the "stat" category... > > 23. > > Yes, I think a revision of the "stat" category is probably necessary. > > > 25. we propose to add the following word: "time.deadtime". Rationale: > > useful for photon-counting devices based catalogues > I agree. > > > An additional point that we have discussed concerns the units in which > > interferometric data shall be provided... Matteo and I were dicussing about how interferometric data were going to be provided to VO's from the observatories. Interferometric data are basically images in the "Fourier space" and not in the "physical space". During the AVO experience, Joddrell Bank provided directly "physical images" since they carried out the Inverse Fourier Tranform before given access to the data through the web. So, our question is a generic issue. Interferometric data are going to become more and more common in Astronomy. The "measuring space" of interferometric data is the "Fourier- I mean , space frequencies - space". Are the interferometric data providers going to release their products in the "physical" or in the "Fourier" space? Has this issue be discussed?, has been discussed how does it affect UCD's? Finally, I've kept thinking about UCD's for "simulations" and this is very tricky. As important as the method, resolution, time-scales etcc. is to describe the boundary and the initial conditions. I still wonder how!!! Cheers, Ana Prof. Ana I. Gomez de Castro Instituto de Astronomia y Geodesia (CSIC-UCM) Fac. de CC Matematicas Universidad Complutense de Madrid 28040 Madrid, Spain Ph. 34-913944578 (office) 34-659783338 (mobile) Email: aig at mat.ucm.es From seaman at noao.edu Fri Jul 15 08:42:13 2005 From: seaman at noao.edu (Rob Seaman) Date: Fri, 15 Jul 2005 08:42:13 -0700 Subject: Late comments (mainly) on the UCD word list In-Reply-To: <20050715135459.s5rkrvu5rp4wcgs8@webmail.sic.rm.cnr.it> References: <42D4C698.70908@sciops.esa.int> <20050715135459.s5rkrvu5rp4wcgs8@webmail.sic.rm.cnr.it> Message-ID: <6A441722-CBE8-42C9-AE85-9EAD58AD711D@noao.edu> On Jul 15, 2005, at 4:54 AM, Andrea Preite Martinez wrote: > I whould say seeing is a property of a . > I also agree with Rick's suggestion, it's a property of the > at a > given site. For any given tabular example, the concept of "seeing" likely includes effects local to the dome and telescope, which often dominate the resulting measured PSF, independent of the theoretical diffraction limit of the telescope. Rarely will seeing strictly derived from the weather be measured or recorded. > A good occasion to repeat that the list of words was initially built > entirely bottom-up, i.e. from data description. If "instr.precision" > exists, it means that the description "precision", although too > generic, > has been used by some author. This is a good way to build such a list. It is not the only way one might proceed. If namespaces (or the potential for same) are not introduced early in the process, there will be much more trouble later when the VO inevitably finds some way to squeeze them in. > I need a use-case to make-up my mind A single use-case is not much point. The idea is to assemble a range of use-cases such that all the potential behaviors of the system or model are elucidated. > ?? UCDs do not care about units.. Indeed, but sometimes a preference is implicit. Seeing is likely in arcseconds, dates are likely ISO 8601, and so forth. Rob Seaman NOAO -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alberto.Micol at eso.org Fri Jul 15 09:33:09 2005 From: Alberto.Micol at eso.org (Alberto Micol) Date: Fri, 15 Jul 2005 18:33:09 +0200 Subject: What is that a UCD can be assigned to? In-Reply-To: <42D4C698.70908@sciops.esa.int> References: <42D4C698.70908@sciops.esa.int> Message-ID: <0c98fa388c24f6627eccd21e02333daf@eso.org> Dear All, I'm trying to catch up with UCDs, sorry to be so late. Matteo's and Ana's comments, plus my own way of reading the list of words, and especially the comments associated with each word, make me think that something is not yet properly defined, and that some ambiguity is still to be removed. While historically UCDs were assigned to *columns* in the Vizier collection of tables, I wonder if this is still true. That is, I cannot find in any document of the UCD1+ the answer to the question: What is that a UCD can be assigned to? I know that it CAN be assigned to a scalar quantity; I know that it CAN be assigned to a column in a table; but CAN it be assigned to an image, to a table, or any other piece of Astronomical Data? I cannot find the answer in any recent UCD-related document (correct me if wrong). I think we need to fill this gap, and give a clear answer. The answer can be: NO --- If the answer is that a UCD can NOT be assigned to anything else than a scalar quantity or an array of identical quantities (i.e., the column in a table), then I do not see why we should have a UCD like instr.interferometry (Thanks Matteo for the good example) YES --- If, at the contrary, UCDs can be assigned to generic, however complicated, data structures then instr.interferometry becomes a nice UCD (though I would suggest data.interferometry instead). Furthermore, if UCDs can be assigned to complex data structures then suddenly I can make sense of other UCDs (like instr.filter.transm) which are currently defined in an ambiguous way: > instr.filter.transm | Filter transmission Is it for a typical value of the transmission of my filter (e.g. 0.2)? or Does it refer to the entire array that represents the "transmission curve" ? On the other hand, if the answer is YES, then a table could have its own UCDs, (and in that case the VOTable standard will need a revision to support UCDs at the table level). But I think that the answer is NO, because otherwise the vocabulary would need to explode and include all kind of things. Hence, if the answer is NO, then I would suggest to make the comments a bit more strict to avoid confusion. A couple of examples: Current Description Possibly less ambiguous description ------------------- ----------------------------------------- Filter transmission -> Typical value for the filter transmission Spectral resolution -> Typical value of the spectral resolution Resolution -> Typical value of the angular resolution Spectral line -> Common name of the spectral line Detector -> Name of the detector Photographic Plate -> Type of emulsion etc. etc. Alberto PS: Did I get the right answer? Menace: Many more comments to come (e.g. UCDs for Characterisation DM, etc.), hopefully next week. From pdidelon at cea.fr Tue Jul 19 05:09:34 2005 From: pdidelon at cea.fr (Pierre Didelon) Date: Tue, 19 Jul 2005 14:09:34 +0200 Subject: Late comments (mainly) on the UCD word list In-Reply-To: References: Message-ID: <42DCED7E.3010008@cea.fr> Hi, some comments related to DM ... ;-) SY, Pierre Ana Ines Gomez de Castro wrote: > Hi, > > On Fri, 15 Jul 2005, Andrea Preite Martinez wrote: > > >>>3. we propose to add the words "em.wl.start" and "em.wl.stop". >>>Rationale: they may be useful and flexible characterizations of the >>>bandpass >> >>In many cases I found a data/column description saying: beginning/minimum >>wl, ending/maximum wl, that I translated using stat.min, stat.max. On the >>other hand, beginning/ending of observation/exposure deserved wholly new >>ucd-words! So I'm in favour of introducing these concepts, but as generic >>qualifiers that can be applied to any axis (time, wl, freq, ..) >> > > > > Fine! > > ... >>>8. we propose to change the word code of "instr.filter.transm" and >>>"instr.spect.resolution" to "V". Rationale: the filter transmission is >>>an intrinsically vectorial quantity; the spectral resolution as well >>>(dependence on energy and/or order) >> >>The V-flag indicates a vector in space >> > > > At the very first AVO meeting organized by Piero in Garching there was > a long discussion about this issue. To fully understand the meaning of > an image obtained with a given filter you need the Transmittance > function of the filter ( T(lambda) ). Unless you force all the > observatories to use exactly the same filters and qualify them, > specifying the transmittance function is the easiest way to qualify > them and allow proper comparisons between observations obtained > with different instruments. Are "functions" allowed as UCDs > It is may be more related to DM dealing with characterization http://alinda.u-strasbg.fr/Model/Characterisation/DM_vers0.1/ to "fully" describe metadata conserning an observation, including filters and theirs properties... http://alinda.u-strasbg.fr/Model/Characterisation/DM_vers0.1/3771728084_130.html UCD is perhaps to general/generic to be complete? >> >>>17. "pos.earth", "pos.earth.lat", "pos.earth.lon" should be placed under >>>the "obs" category. Rationale: these quantity belongs logically to an >>>observation, not to (the position of) a source >> >>I can assure you that pos.earth means position ON the earth, not source >>position on some earth-based coordinate frame!! > > > Then, why are them within the "pos" category? I thought that "pos" is > related with "source" and "obs" with the observation/observatory. > Doesn't it look more natural, obs.pos.earth.lat? > but pos.earth.lat or pos.earth.* can perhaps be related to something else than observation? >> >> >>>An additional point that we have discussed concerns the units in which >>>interferometric data shall be provided... > > > Matteo and I were dicussing about how interferometric data were > going to be provided to VO's from the observatories. Interferometric > data are basically images in the "Fourier space" and not in the > "physical space". During the AVO experience, Joddrell Bank > provided directly "physical images" since they carried out > the Inverse Fourier Tranform before given access to the data > through the web. So, our question is a generic issue. > > Interferometric data are going to become more and more > common in Astronomy. The "measuring space" of interferometric > data is the "Fourier- I mean , space frequencies - space". > Are the interferometric data providers going to release their > products in the "physical" or in the "Fourier" space? > Has this issue be discussed?, has been discussed how does > it affect UCD's? What UCD did you forsee to be able to describe more precisely interferometry data. DM group working on characterization would certainly be interested also by this topic. > > > Finally, I've kept thinking about UCD's for "simulations" > and this is very tricky. As important as the method, > resolution, time-scales etcc. is to describe the > boundary and the initial conditions. I still wonder how!!! > > > Cheers, > > Ana > > > Prof. Ana I. Gomez de Castro > Instituto de Astronomia y Geodesia (CSIC-UCM) > Fac. de CC Matematicas > Universidad Complutense de Madrid > 28040 Madrid, Spain > > Ph. 34-913944578 (office) 34-659783338 (mobile) > Email: aig at mat.ucm.es > > -- 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/ ------------------------------------------------------------------ La carte n'est pas le territoire - Alfred KORZYBSKI ------------------------------------------------------------------ From pdidelon at cea.fr Tue Jul 19 05:38:40 2005 From: pdidelon at cea.fr (Pierre Didelon) Date: Tue, 19 Jul 2005 14:38:40 +0200 Subject: What is that a UCD can be assigned to? In-Reply-To: <0c98fa388c24f6627eccd21e02333daf@eso.org> References: <42D4C698.70908@sciops.esa.int> <0c98fa388c24f6627eccd21e02333daf@eso.org> Message-ID: <42DCF450.8090709@cea.fr> Alberto Micol wrote: > > Dear All, > > I'm trying to catch up with UCDs, sorry to be so late. > > Matteo's and Ana's comments, plus my own way of reading the list of words, > and especially the comments associated with each word, make me think that > something is not yet properly defined, and that some ambiguity is still > to be removed. > > While historically UCDs were assigned to *columns* in the Vizier > collection of tables, > I wonder if this is still true. That is, I cannot find in any document > of the UCD1+ > the answer to the question: > > What is that a UCD can be assigned to? > > I know that it CAN be assigned to a scalar quantity; > I know that it CAN be assigned to a column in a table; > > but > > CAN it be assigned to an image, to a table, or any other piece of > Astronomical Data? > > I cannot find the answer in any recent UCD-related document (correct me > if wrong). > I think we need to fill this gap, and give a clear answer. > > The answer can be: > > NO > --- > If the answer is that a UCD can NOT be assigned to anything else than a > scalar quantity > or an array of identical quantities (i.e., the column in a table), > then I do not see why we should have a UCD like instr.interferometry > (Thanks Matteo for the good example) > > > YES > --- > If, at the contrary, UCDs can be assigned to generic, however > complicated, data structures > then instr.interferometry becomes a nice UCD (though I would suggest > data.interferometry instead). > > Furthermore, if UCDs can be assigned to complex data structures then > suddenly I can make sense of other UCDs (like instr.filter.transm) > which are currently defined in an ambiguous way: > > > instr.filter.transm | Filter transmission > > Is it for a typical value of the transmission of my filter (e.g. 0.2)? > or > Does it refer to the entire array that represents the "transmission > curve" ? May be it can be both, depending of the context and the data decribed? But transmission curve is certainly more precisely described by SED-DM, and in this context why not associating this structure with such an UCD? > > On the other hand, if the answer is YES, then a table could have its own > UCDs, > (and in that case the VOTable standard will need a revision to support > UCDs at the table level). It is the only "special" case where ucd are allowed aside column (FIELD) or "individual" (which can contain an array nevertheless) quantity (PARAM), not speaking of column or quantity grouping (GROUP) ;-) > > > But I think that the answer is NO, because otherwise the vocabulary > would need to explode > and include all kind of things. > Hence, if the answer is NO, then I would suggest to make the comments a > bit more strict > to avoid confusion. It is perhaps neither YES nor NO. Actually the main usage is still column characterization but who can forsee all possible usefull usage... and/or try to forbid it? > A couple of examples: > > Current Description Possibly less ambiguous description > ------------------- ----------------------------------------- > Filter transmission -> Typical value for the filter transmission > Spectral resolution -> Typical value of the spectral resolution > Resolution -> Typical value of the angular resolution > Spectral line -> Common name of the spectral line > Detector -> Name of the detector > Photographic Plate -> Type of emulsion > etc. etc. > > Alberto Friendly, Pierre From hessman at Astro.physik.Uni-Goettingen.DE Mon Jul 25 10:02:32 2005 From: hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. Hessman) Date: Mon, 25 Jul 2005 19:02:32 +0200 Subject: Late comments (mainly) on the UCD word list In-Reply-To: <20050715135459.s5rkrvu5rp4wcgs8@webmail.sic.rm.cnr.it> References: <42D4C698.70908@sciops.esa.int> <20050715135459.s5rkrvu5rp4wcgs8@webmail.sic.rm.cnr.it> Message-ID: <94beff6f1861cfe20667d9677887ac38@astro.physik.uni-goettingen.de> >> 16. a new word "pos.offaxis" should be added. Rationale: the off-axis >> angle may be a useful quantity is some catalogs > I agree. But "pos.relative" is much more general and just as good for this particular use. >> 21. we propose to add "src.stellarityIndex". Rationale: it may be >> useful >> to easily discriminate point-like from extended sources > > A word with the description ?stellarity index? already exists. Yes, but "src.starGalaxy" is obviously not general enough for a galactic nebular catalogue: is the value in the table indicating that the object is a star, a non-stellar nebula, or really a galaxy? Thus: "src.pointlike" or "src.resolved" ! >> Finally, there are still two corrections to the descriptions to >> remove narrow applications of general concepts: >> src.morph.type | morphological type, e.g. Hubble (there are >> others!!!) >> src.morph.scLength | scale length, e.g. of disk or bulge in a >> galaxy (there are others!!!) >> src.spType | spectral type, e.g. MK (there are others!!!!) > > Sorry, but I did not study english at school. I studied latin. > When you write: > i.e. = id est, you mean: that is > e.g. = exempli gratia, which means: for example (i.e., of course, > there are > others!!!) Sorry - I obviously meant for you to edit out the "(there are others!!!)" but didn't say so. >> I'm still not enthusiastic about the inconsistant use of contractions >> ("lg" is OK for "local group" but "sg" is not OK for >> "supergalactic"???), > but there are obviously too many of us old >> people who grew up worrying about to get our > data into 4k of >> computer memory... > > Indeed!!! I still feel that changing to ?supergalactic? was a terrible > waste of memory!! :-) XML is a waste of memory in any case, but the point is that it doesn't matter. We're talking about a 5% effect in the size of documents - it's a waste of time to even think about it, so one might as well be explicit. Rick ------------------------------------------------------------------------ ------------------------ NEW ADDRESS!!! ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Institut f?r Astrophysik Tel. +49-551-39-5052 Friedrich-Hund-Platz 1 Fax +49-551-39-5043 37077 Goettingen Room F04-133 http://www.Astro.physik.Uni-Goettingen.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.Uni-Goettingen.de ------------------------------------------------------------------------ ------------------------- From andrea.preitemartinez at rm.iasf.cnr.it Mon Jul 11 08:01:03 2005 From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez) Date: Mon, 11 Jul 2005 17:01:03 +0200 Subject: draft PR doc on ucd-words Message-ID: <20050711170103.buzzas2dadesw8cs@webmail.sic.rm.cnr.it> After 4 weeks of discussion in the Sci-board and some extra time to set up the document, you'll find attached a draft version of the document containing the list of ucd-words. Note for the Sci-board: I included the last comments. I also had to modify a number of words to be compliant with the UCD-Rec document ("... for any two words at the same level in the hierarchy, one can't be a starting substring of the other..."), so old version =============> new version phot.fluxDensity phot.fluDensity phys.energyDensity phys.energDensity phys.massYield phys.mYield pos.earthop pos.eop Of course there is still the case of phys.at/atmol, but we can wait for the revision of the whole list of atomic and molecular ucds. I submit the document+list to the members of the UCD-WG because this is the IVOA standard procedure, and I formally ask you if we can move from the WD phase to the PR phase. In this particular case we also had to follow another "formal" procedure, estabished by the UCD main document, to generate and maintain the list of ucd-words. This is why I'm sending the draft to both mailing lists. The document is already in the PR "format" but, being a draft, the link to the RFC page is of course not yet activated. If you have major objections (on the content of the document/list of words) please let me know asap. According to our roadmap, we have to move the UCD-list document from the WD phase to the PR phase within July. This would mean asking for comments on the PR document during a holiday period. I think it would be better to issue the RFC in the second half of August. Please let me know if you disagree on that. Best regards Andrea ============================================================================== Andrea Preite Martinez andrea 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 ============================================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: UCDlist-20050711.pdf Type: application/pdf Size: 1199680 bytes Desc: not available URL: From dtody at nrao.edu Mon Jul 11 09:36:25 2005 From: dtody at nrao.edu (Doug Tody) Date: Mon, 11 Jul 2005 10:36:25 -0600 (MDT) Subject: draft PR doc on ucd-words In-Reply-To: <20050711170103.buzzas2dadesw8cs@webmail.sic.rm.cnr.it> Message-ID: On Mon, 11 Jul 2005, Andrea Preite Martinez wrote: > Note for the Sci-board: I included the last comments. I also had to modify a > number of words to be compliant with the UCD-Rec document ("... for any two > words at the same level in the hierarchy, one can't be a starting substring > of the other..."), so > > old version =============> new version > > phot.fluxDensity phot.fluDensity > phys.energyDensity phys.energDensity > phys.massYield phys.mYield > pos.earthop pos.eop I haven't been following the UCD discussions, and while I am sure there is some reason for this change, these name changes do not look like an improvement. The "old" version is clearly preferable here. - Doug From jcm at head.cfa.harvard.edu Mon Jul 11 10:24:49 2005 From: jcm at head.cfa.harvard.edu (Jonathan McDowell) Date: Mon, 11 Jul 2005 13:24:49 -0400 (EDT) Subject: draft PR doc on ucd-words Message-ID: <200507111724.j6BHOnJa000739@sothis.cfa.harvard.edu> On Mon, 11 Jul 2005, Andrea Preite Martinez wrote: > Note for the Sci-board: I included the last comments. I also had to modify a > number of words to be compliant with the UCD-Rec document ("... for any two > words at the same level in the hierarchy, one can't be a starting substring > of the other..."), so > > old version =============> new version > > phot.fluxDensity phot.fluDensity I agree with Doug. I hate the new versions. I think the "can't be a starting substring" was put in to make some kinds of searching easier, but I never found the argument convincing and would argue that we should instead remove this restriction from the UCD-Rec document. - Jonathan From sla at ucolick.org Mon Jul 11 10:55:54 2005 From: sla at ucolick.org (Steve Allen) Date: Mon, 11 Jul 2005 10:55:54 -0700 Subject: draft PR doc on ucd-words In-Reply-To: References: <20050711170103.buzzas2dadesw8cs@webmail.sic.rm.cnr.it> Message-ID: <20050711175554.GD26543@ucolick.org> On Mon 2005-07-11T10:36:25 -0600, Doug Tody hath writ: > > old version =============> new version > > pos.earthop pos.eop In this one case the new version is actually more mnemonic for those of us who look at such data regularly. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99858 University of California Voice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From andrea.preitemartinez at rm.iasf.cnr.it Tue Jul 12 06:32:45 2005 From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez) Date: Tue, 12 Jul 2005 15:32:45 +0200 Subject: UCD-list: pdf/html file Message-ID: <20050712153245.dzuvuukco8hwkw0s@webmail.sic.rm.cnr.it> Sorry for yersteday, the attached file had extension ".pdf" but it was a .ps!! As for the content of the document, I agree with Doug and Jonathan, so it is a pleasure for me to come back to the old spelling "phot.fluxDens" ! I keep "pos.eop" (by the way, this was the spelling proposed by planetary people!) I added a note in the doc explaining that a few words are not complying with one of the recs in the main document. I uploaded the document in the ivoa doc repository http://www.ivoa.net/Documents. I hope it'll be made available soon. Andrea ============================================================================== Andrea Preite Martinez andrea 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 ============================================================================== From Matteo.Guainazzi at sciops.esa.int Wed Jul 13 00:45:28 2005 From: Matteo.Guainazzi at sciops.esa.int (Matteo Guainazzi) Date: Wed, 13 Jul 2005 07:45:28 +0000 Subject: Late comments (mainly) on the UCD word list Message-ID: <42D4C698.70908@sciops.esa.int> Dear Andrea et al., you will find below some comments, mainly on the current UCD list, prepared by Ana and myself. If I interpret correctly your last message to the UCD SciBoard, we have passed the deadline, when the contributions from the UCD SciBoard were expected to come. If so, we have obviously missed some important information about the time-line. We apologize for that. Should our comment be arrived beyond the time horizon, feel free to ignore them for the time being, and to postpone them for the next round of comments, if anyhow interesting: 1. we propose to remove all the words containing an explicit specification of the wavelength or frequency range. They should be replaced by words of the type: "em.wl.start; em.wl.end" (these words do not exist, and should be added). Rationale: the current method lacks flexibility, and is very likely not to cover all the interesting wavelengths ranges in existing catalogues, where "standard" wavelength ranges do not exist (e.g., high-energy) 2. we propose to substitute "instr.${band}" for all words of the type "em.${band}". Rationale: the sensitive bandpass is a property of the detector 3. we propose to add the words "em.wl.start" and "em.wl.stop". Rationale: they may be useful and flexible characterizations of the bandpass 4. we propose to move "instr.obsty.site.seeing" to "obs.seeing". Rationale: this is a property of an observation rather than of an instrument 5. we propose to unify "instr.beam" and "instr.det.psf" into "instr.psf". Rationale: in most cases, users are interested in the overall PSF (optics+detector). "Beam" is the radio jargon for PSF. Should the detector PSF be necessary, one could use: "instr.psf; instr.det" 6. we propose to remove "instr.precision". Rationale: too generic, probably useless 7. we propose to add the following radio-related words: "instr.interferometry", and "instr.resolution". Rationale: the former is self-explaining; the latter indicates the spatial resolution 8. we propose to change the word code of "instr.filter.transm" and "instr.spect.resolution" to "V". Rationale: the filter transmission is an intrinsically vectorial quantity; the spectral resolution as well (dependence on energy and/or order) 9. we propose to add a further atom to the "Multiplicity of binarity flag": "meta.code.multip.star", "meta.code.multip.planet". Rationale: self-explaining 10. we propose to add a further "meta" atom: "meta.subexp". Rationale: this will allow to characterize the rank of sub-exposures in a multi-exposure observations, whenever useful for, e.g., variability studies 11. we propose to add a further "meta" atom: "meta.rank". Rationale: useful to indicate an element in an intrinsically vectorial quantity 12. we propose to move "meta.id" and "meta.id.assoc" to "src.id" and "src.id.assoc". Rationale: they belong to "sources" rather then to "metadata" 13. we believe that the following "phys" word should be moved to "src": "phys.angArea", "phys.AngSize" (and associated words), "phys.area", "phys.size" (and associated words). Rationale: the same as #12 above 14. we believe that words belonging to the following categories: "phot", "pos", "spec", should be placed under the category "src" (e.g.: "phot.antennaTemp" -> "src.phot.antennaTemp", "pos.angDistance" -> "src.pos.angDistance"; "spect.Doppler" -> "src.spect.Doppler". Rationale: all these words ultimately describe source properties 15. the words for coupling of quantum numbers do not cover all the possible coupling cases. A more general method is needed, and the Data Line Model sub-group is indeed working on this. We propose to wait for the conclusion of their work, before this issue is ultimately addressed 16. a new word "pos.offaxis" should be added. Rationale: the off-axis angle may be a useful quantity is some catalogs 17. "pos.earth", "pos.earth.lat", "pos.earth.lon" should be placed under the "obs" category. Rationale: these quantity belongs logically to an observation, not to (the position of) a source 18. "pos.earth.nutation" should be removed. Rationale: it is no longer consistent with the IAU specification 19. a new word "src.ephem" should be added. Rationale: it is necessary to separate "observatory" from "source" ephemeris 20. "spect.veloc" should be replaced by "src.radial.vel". Rationale: it is a property of the source, rather than of a spectrum 21. we propose to add "src.stellarityIndex". Rationale: it may be useful to easily discriminate point-like from extended sources 22. we propose to add the following words in the "stat" category: "stat.distribution", "stat.fit.model". Rationale: without them, the information on the statistical quantities and/or the fit are incomplete 23. we propose to replace "stat.moment" (as a vectorial quantity) for "stat.mean" and "stat.stdev". Any of the statistical moments could be therefore indicated by the UCD: "stat.moment; meta.rank". Rationale: the proposed method is more flexible, and could avoid the proliferation of new words to indicate skewness, kurtosis ... 24. the following words should be moved from the category "time" to "src": "time.age", "time.crossing", "time.period", "time.phase", "time.relax". E.g.: "time.age" -> "src.time.age". Rationale: they logically belong to a source rather them to the 4th dimension 25. we propose to add the following word: "time.deadtime". Rationale: useful for photon-counting devices based catalogues An additional point that we have discussed concerns the units in which interferometric data shall be provided. Is it accepted that data providers have to convert them in physical units at the server level? If not, we need probably to include specific UCD words to deal with "images" in the Fourier space. I again apologize for the long and late message. Thanks for your attention. Regards, Matteo & Ana -- Matteo Guainazzi XMM-Newton SOC Matteo.Guainazzi at sciops.esa.int European Space Astronomy Center of ESA Phone: +34 91 8131 176 VILSPA, Apartado 50727, E-28080 Madrid Fax: +34 91 8131 172 From sla at ucolick.org Wed Jul 13 06:39:46 2005 From: sla at ucolick.org (Steve Allen) Date: Wed, 13 Jul 2005 06:39:46 -0700 Subject: Late comments (mainly) on the UCD word list In-Reply-To: <42D4C698.70908@sciops.esa.int> References: <42D4C698.70908@sciops.esa.int> Message-ID: <20050713133946.GA17964@ucolick.org> On Wed 2005-07-13T07:45:28 +0000, Matteo Guainazzi hath writ: > 20. "spect.veloc" should be replaced by "src.radial.vel". Rationale: it > is a property of the source, rather than of a spectrum This is quite contrary to the notions clearly espoused by Lindegren and Dravins (2003) A&A 401, 1185. Without a model there is no way to assign a radial velocity to a source. The measurable quantity, is a spectral shift for which any apparent radial velocity is merely conventional. That said, it remains the case that many instances of conventional radial velocity measures exist in the literature. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99858 University of California Voice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From hessman at Astro.physik.Uni-Goettingen.DE Thu Jul 14 02:45:30 2005 From: hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. Hessman) Date: Thu, 14 Jul 2005 11:45:30 +0200 Subject: Late comments (mainly) on the UCD word list In-Reply-To: <42D4C698.70908@sciops.esa.int> References: <42D4C698.70908@sciops.esa.int> Message-ID: <6180f164fbf9daa4f9084e652f649cc6@astro.physik.uni-goettingen.de> > 2. we propose to substitute "instr.${band}" for all words of the type > "em.${band}". Rationale: the sensitive bandpass is a property of the > detector I agree that we'll never have a complete list of useful wavelength regions, but there is still a difference between "an instrument with the bandpass of a Bessel V filter" (instr.opt.V) and "photons with wavelength corresponding to the peak of a Bessel V filter" (em.opt.V). Although I see arguments for both, I personally prefer the old form. > 4. we propose to move "instr.obsty.site.seeing" to "obs.seeing". > Rationale: this is a property of an observation rather than of an > instrument Did anyone ever respond to my suggestion of using the primary word "weather"? Seeing is only the property of an observation if used to describe image properties. If one is careful, it's not even the property of an observatory but simply part of the "weather". We need other weather words anyway, so weather.seeing weather.temp weather.humidity weather.precipitation which permits the weather generally or the "weather" inside a dome to be described. If you want the seeing within an image (which is implied by "instr.obsty.site.seeing" since it's tied to an instr), then you need things like > 9. we propose to add a further atom to the "Multiplicity of binarity > flag": "meta.code.multip.star", "meta.code.multip.planet". Rationale: > self-explaining YUK! I propose to DROP meta.code.multip ALTOGETHER : why single out this one property of objects when there are zillions of others? The other meta.codes are tolerable because they're very general and inspecific (e.g. "quality" or "class") or at the very worst boolean ("membership"). > 10. we propose to add a further "meta" atom: "meta.subexp". Rationale: > this will allow to characterize the rank of sub-exposures in a > multi-exposure observations, whenever useful for, e.g., variability > studies Sorry - another YUK! This is even worse than using src.class.distance officially only for Abell distance class. The only reasonable solution is a general-purpose hierarchy structure word: meta.pos or maybe meta.hierarch, where one can easily recognize that, e.g., the value "0" or "A" is the top level, "1" or "B" the next, etc. Then one could use this for all kinds of things. > 11. we propose to add a further "meta" atom: "meta.rank". Rationale: > useful to indicate an element in an intrinsically vectorial quantity See above. > 12. we propose to move "meta.id" and "meta.id.assoc" to "src.id" and > "src.id.assoc". Rationale: they belong to "sources" rather then to > "metadata" Only if one is applying them to sources: when applying them to other things (e.g. XML document id's), one would have a problem with src. > 13. we believe that the following "phys" word should be moved to > "src": > "phys.angArea", "phys.AngSize" (and associated words), "phys.area", > "phys.size" (and associated words). Rationale: the same as #12 above Ibid. > 14. we believe that words belonging to the following categories: > "phot", > "pos", "spec", should be placed under the category "src" (e.g.: > "phot.antennaTemp" -> "src.phot.antennaTemp", "pos.angDistance" -> > "src.pos.angDistance"; "spect.Doppler" -> "src.spect.Doppler". > Rationale: all these words ultimately describe source properties Just as you argued above to place the words appropriately, antennaTemp is DEFINITELY not a property of a src but of an obs or instr. > 15. the words for coupling of quantum numbers do not cover all the > possible coupling cases. A more general method is needed, and the Data > Line Model sub-group is indeed working on this. We propose to wait for > the conclusion of their work, before this issue is ultimately addressed > > 16. a new word "pos.offaxis" should be added. Rationale: the off-axis > angle may be a useful quantity is some catalogs A better and more general choice would be "pos.relative". > 21. we propose to add "src.stellarityIndex". Rationale: it may be > useful > to easily discriminate point-like from extended sources Too specific. The current "src.class.starGalaxy" is just as bad or worse (as if there are only stars and galaxies out there!). A MUCH better solution is "src.class.resolved". Please dump src.class.starGalaxy!!!! Finally, there are still two corrections to the descriptions to remove narrow applications of general concepts: src.morph.type | morphological type, e.g. Hubble (there are others!!!) src.morph.scLength | scale length, e.g. of disk or bulge in a galaxy (there are others!!!) src.spType | spectral type, e.g. MK (there are others!!!!) Otherwise, OK. I'm still not enthusiastic about the inconsistant use of contractions ("lg" is OK for "local group" but "sg" is not OK for "supergalactic"???), but there are obviously too many of us old people who grew up worrying about to get our data into 4k of computer memory or (like myself) wrote their disserations at home using an acoustic modem at 300 baud and so don't trust computers and networks to handle strings longer than about 8 characters. ;-) Rick ------------------------------------------------------------------------ ------------------------ NEW ADDRESS!!! ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Institut f?r Astrophysik Tel. +49-551-39-5052 Friedrich-Hund-Platz 1 Fax +49-551-39-5043 37077 Goettingen Room F04-133 http://www.Astro.physik.Uni-Goettingen.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.Uni-Goettingen.de ------------------------------------------------------------------------ ------------------------- From andrea.preitemartinez at rm.iasf.cnr.it Fri Jul 15 04:54:59 2005 From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez) Date: Fri, 15 Jul 2005 13:54:59 +0200 Subject: Late comments (mainly) on the UCD word list In-Reply-To: <42D4C698.70908@sciops.esa.int> References: <42D4C698.70908@sciops.esa.int> Message-ID: <20050715135459.s5rkrvu5rp4wcgs8@webmail.sic.rm.cnr.it> > 1. we propose to remove all the words containing an explicit > specification of the wavelength or frequency range... > 2. we propose to substitute "instr.${band}" for all words of the type > "em.${band}". Rationale: the sensitive bandpass is a property of the > detector This has been a problem since the very beginning of the ucd's history. The pros and cons of different possible solutions were carefully considered, and at the end it was decided to consider that words were only a way to describe the wl/freq axis, NOT the properties of an instrument, and that the spelling was only mnemonic. The job of assigning the right em-word to a point or interval on that axis is done by a script, who takes care of units, band codes, intervals, difference of intervals (i.e.: colours in astronomy), so that, for example: 2.456mm is translated into em.mm.100-200GHz L em.IR.3-4um 0.1eV em.IR.8-15um 0.001nm em.gamma.hard V-N em.opt.V;em.IR.8-15um , and even F439W em.opt.B (Warning: the on-line script needs a quantity to assign an ucd. em-words are not, so add mag/flux... to your wl/freq/energy to get an answer) > 3. we propose to add the words "em.wl.start" and "em.wl.stop". > Rationale: they may be useful and flexible characterizations of the > bandpass In many cases I found a data/column description saying: beginning/minimum wl, ending/maximum wl, that I translated using stat.min, stat.max. On the other hand, beginning/ending of observation/exposure deserved wholly new ucd-words! So I'm in favour of introducing these concepts, but as generic qualifiers that can be applied to any axis (time, wl, freq, ..) > 4. we propose to move "instr.obsty.site.seeing" to "obs.seeing". > Rationale: this is a property of an observation rather than of an instrument I whould say seeing is a property of a . I also agree with Rick's suggestion, it's a property of the at a given site. > 5. we propose to unify "instr.beam" and "instr.det.psf" into > "instr.psf"... > 6. we propose to remove "instr.precision". Rationale: too generic, > probably useless A good occasion to repeat that the list of words was initially built entirely bottom-up, i.e. from data description. If "instr.precision" exists, it means that the description "precision", although too generic, has been used by some author. > 7. we propose to add the following radio-related words: > "instr.interferometry", and "instr.resolution". Rationale: the former is > self-explaining; the latter indicates the spatial resolution The former can be one of the many with syntax-flag S. As for the latter, at present: instrument resolution => pos.resolution image resolution => pos.resolution;obs.image spatial resolution => pos.resolution > 8. we propose to change the word code of "instr.filter.transm" and > "instr.spect.resolution" to "V". Rationale: the filter transmission is > an intrinsically vectorial quantity; the spectral resolution as well > (dependence on energy and/or order) The V-flag indicates a vector in space > 9. we propose to add a further atom to the "Multiplicity of binarity > flag": "meta.code.multip.star", "meta.code.multip.planet". Rationale: > self-explaining I think that is tolerable because it's sufficiently generic, and because it is used. > 10. we propose to add a further "meta" atom: "meta.subexp"... > 11. we propose to add a further "meta" atom: "meta.rank"... I need a use-case to make-up my mind > 12. we propose to move "xxx" to "src.xxx" > 13. as above > 14. as above > 20. as above > 24. as above In doing this, I think we would narrow the meaning of those words. > 16. a new word "pos.offaxis" should be added. Rationale: the off-axis > angle may be a useful quantity is some catalogs I agree. > 17. "pos.earth", "pos.earth.lat", "pos.earth.lon" should be placed under > the "obs" category. Rationale: these quantity belongs logically to an > observation, not to (the position of) a source I can assure you that pos.earth means position ON the earth, not source position on some earth-based coordinate frame!! > 18. "pos.earth.nutation" should be removed. Rationale: it is no longer > consistent with the IAU specification Changed. > 21. we propose to add "src.stellarityIndex". Rationale: it may be useful > to easily discriminate point-like from extended sources A word with the description ?stellarity index? already exists. > 22. we propose to add the following words in the "stat" category... > 23. Yes, I think a revision of the "stat" category is probably necessary. > 25. we propose to add the following word: "time.deadtime". Rationale: > useful for photon-counting devices based catalogues I agree. > An additional point that we have discussed concerns the units in which > interferometric data shall be provided... ?? UCDs do not care about units.. > Finally, there are still two corrections to the descriptions to > remove narrow applications of general concepts: > src.morph.type | morphological type, e.g. Hubble (there are others!!!) > src.morph.scLength | scale length, e.g. of disk or bulge in a > galaxy (there are others!!!) > src.spType | spectral type, e.g. MK (there are others!!!!) Sorry, but I did not study english at school. I studied latin. When you write: i.e. = id est, you mean: that is e.g. = exempli gratia, which means: for example (i.e., of course, there are others!!!) > I'm still not enthusiastic about the inconsistant use of contractions > ("lg" is OK for "local group" but "sg" is not OK for > "supergalactic"???), > but there are obviously too many of us old > people who grew up worrying about to get our > data into 4k of > computer memory... Indeed!!! I still feel that changing to ?supergalactic? was a terrible waste of memory!! :-) Andrea ============================================================================== Andrea Preite Martinez andrea 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 ============================================================================== From anai_gomez at mat.ucm.es Fri Jul 15 10:14:29 2005 From: anai_gomez at mat.ucm.es (Ana Ines Gomez de Castro) Date: Fri, 15 Jul 2005 19:14:29 +0200 (CEST) Subject: Late comments (mainly) on the UCD word list In-Reply-To: <20050715135459.s5rkrvu5rp4wcgs8@webmail.sic.rm.cnr.it> Message-ID: Hi, On Fri, 15 Jul 2005, Andrea Preite Martinez wrote: > > > 1. we propose to remove all the words containing an explicit > > specification of the wavelength or frequency range... > > 2. we propose to substitute "instr.${band}" for all words of the type > > "em.${band}". Rationale: the sensitive bandpass is a property of the > > detector > > This has been a problem since the very beginning of the ucd's history. The > pros and cons of different possible solutions were carefully considered, > and at the end it was decided to consider that words were only a way > to describe the wl/freq axis, NOT the properties of an instrument, and that > the spelling was only mnemonic. > The job of assigning the right em-word to a point or interval on that axis > is done by a script, who takes care of units, band codes, intervals, > difference of intervals (i.e.: colours in astronomy), so that, for example: > > 2.456mm is translated into em.mm.100-200GHz > L em.IR.3-4um > 0.1eV em.IR.8-15um > 0.001nm em.gamma.hard > V-N em.opt.V;em.IR.8-15um , and even > F439W em.opt.B > > (Warning: the on-line script needs a quantity to assign an ucd. em-words are > not, so add mag/flux... to your wl/freq/energy to get an answer) > Fine! How are you planing to deal with E230M, F28x50LP, F25CN2700 "filters" or GRISM? (these are standard optical elements in HST/STIS or ACS) > > 3. we propose to add the words "em.wl.start" and "em.wl.stop". > > Rationale: they may be useful and flexible characterizations of the > > bandpass > > In many cases I found a data/column description saying: beginning/minimum > wl, ending/maximum wl, that I translated using stat.min, stat.max. On the > other hand, beginning/ending of observation/exposure deserved wholly new > ucd-words! So I'm in favour of introducing these concepts, but as generic > qualifiers that can be applied to any axis (time, wl, freq, ..) > Fine! > > 4. we propose to move "instr.obsty.site.seeing" to "obs.seeing". > > Rationale: this is a property of an observation rather than of an instrument > > I whould say seeing is a property of a . > I also agree with Rick's suggestion, it's a property of the at a > given site. Fine. Should there also be some UCD for transparency? > > > 5. we propose to unify "instr.beam" and "instr.det.psf" into > > "instr.psf"... > > 6. we propose to remove "instr.precision". Rationale: too generic, > > probably useless > > A good occasion to repeat that the list of words was initially built > entirely bottom-up, i.e. from data description. If "instr.precision" > exists, it means that the description "precision", although too generic, > has been used by some author. > Could you ask the author what did he mean? > > 7. we propose to add the following radio-related words: > > "instr.interferometry", and "instr.resolution". Rationale: the former is > > self-explaining; the latter indicates the spatial resolution > > The former can be one of the many with syntax-flag S. > As for the latter, at present: > instrument resolution => pos.resolution > image resolution => pos.resolution;obs.image > spatial resolution => pos.resolution > > > 8. we propose to change the word code of "instr.filter.transm" and > > "instr.spect.resolution" to "V". Rationale: the filter transmission is > > an intrinsically vectorial quantity; the spectral resolution as well > > (dependence on energy and/or order) > > The V-flag indicates a vector in space > At the very first AVO meeting organized by Piero in Garching there was a long discussion about this issue. To fully understand the meaning of an image obtained with a given filter you need the Transmittance function of the filter ( T(lambda) ). Unless you force all the observatories to use exactly the same filters and qualify them, specifying the transmittance function is the easiest way to qualify them and allow proper comparisons between observations obtained with different instruments. Are "functions" allowed as UCDs > > 9. we propose to add a further atom to the "Multiplicity of binarity > > flag": "meta.code.multip.star", "meta.code.multip.planet". Rationale: > > self-explaining > > I think that is tolerable because it's sufficiently > generic, and because it is used. In the coming years, planets are going to be searched for in basically all stars around. There will be searched for not only on "single" star systems but on multiple systems. How are you planing to classify them? > > > 10. we propose to add a further "meta" atom: "meta.subexp"... > > 11. we propose to add a further "meta" atom: "meta.rank"... > HST is divides the exposure time into subexposures. For each sub-exposure an "image" is produced and archived within a single "archive record" that corresponds to the "exposure". In rapidly variable objects, it is relevant to make use of the "sub-exposures". If you wish to see a direct application where this relevance is oustanding take a glance to Gomez de Castro, 2002 (MNRAS). The target is AB Dor and the spectra where obtained with HST/HRS. > I need a use-case to make-up my mind > > > 12. we propose to move "xxx" to "src.xxx" > > 13. as above > > 14. as above > > 20. as above > > 24. as above I think that they are self-explanatory > > In doing this, I think we would narrow the meaning of those words. > Why? > > 16. a new word "pos.offaxis" should be added. Rationale: the off-axis > > angle may be a useful quantity is some catalogs > I agree. > > > 17. "pos.earth", "pos.earth.lat", "pos.earth.lon" should be placed under > > the "obs" category. Rationale: these quantity belongs logically to an > > observation, not to (the position of) a source > > I can assure you that pos.earth means position ON the earth, not source > position on some earth-based coordinate frame!! Then, why are them within the "pos" category? I thought that "pos" is related with "source" and "obs" with the observation/observatory. Doesn't it look more natural, obs.pos.earth.lat? > > > 18. "pos.earth.nutation" should be removed. Rationale: it is no longer > > consistent with the IAU specification > Changed. > > > 21. we propose to add "src.stellarityIndex". Rationale: it may be useful > > to easily discriminate point-like from extended sources > > A word with the description ?stellarity index? already exists. > > > 22. we propose to add the following words in the "stat" category... > > 23. > > Yes, I think a revision of the "stat" category is probably necessary. > > > 25. we propose to add the following word: "time.deadtime". Rationale: > > useful for photon-counting devices based catalogues > I agree. > > > An additional point that we have discussed concerns the units in which > > interferometric data shall be provided... Matteo and I were dicussing about how interferometric data were going to be provided to VO's from the observatories. Interferometric data are basically images in the "Fourier space" and not in the "physical space". During the AVO experience, Joddrell Bank provided directly "physical images" since they carried out the Inverse Fourier Tranform before given access to the data through the web. So, our question is a generic issue. Interferometric data are going to become more and more common in Astronomy. The "measuring space" of interferometric data is the "Fourier- I mean , space frequencies - space". Are the interferometric data providers going to release their products in the "physical" or in the "Fourier" space? Has this issue be discussed?, has been discussed how does it affect UCD's? Finally, I've kept thinking about UCD's for "simulations" and this is very tricky. As important as the method, resolution, time-scales etcc. is to describe the boundary and the initial conditions. I still wonder how!!! Cheers, Ana Prof. Ana I. Gomez de Castro Instituto de Astronomia y Geodesia (CSIC-UCM) Fac. de CC Matematicas Universidad Complutense de Madrid 28040 Madrid, Spain Ph. 34-913944578 (office) 34-659783338 (mobile) Email: aig at mat.ucm.es From seaman at noao.edu Fri Jul 15 08:42:13 2005 From: seaman at noao.edu (Rob Seaman) Date: Fri, 15 Jul 2005 08:42:13 -0700 Subject: Late comments (mainly) on the UCD word list In-Reply-To: <20050715135459.s5rkrvu5rp4wcgs8@webmail.sic.rm.cnr.it> References: <42D4C698.70908@sciops.esa.int> <20050715135459.s5rkrvu5rp4wcgs8@webmail.sic.rm.cnr.it> Message-ID: <6A441722-CBE8-42C9-AE85-9EAD58AD711D@noao.edu> On Jul 15, 2005, at 4:54 AM, Andrea Preite Martinez wrote: > I whould say seeing is a property of a . > I also agree with Rick's suggestion, it's a property of the > at a > given site. For any given tabular example, the concept of "seeing" likely includes effects local to the dome and telescope, which often dominate the resulting measured PSF, independent of the theoretical diffraction limit of the telescope. Rarely will seeing strictly derived from the weather be measured or recorded. > A good occasion to repeat that the list of words was initially built > entirely bottom-up, i.e. from data description. If "instr.precision" > exists, it means that the description "precision", although too > generic, > has been used by some author. This is a good way to build such a list. It is not the only way one might proceed. If namespaces (or the potential for same) are not introduced early in the process, there will be much more trouble later when the VO inevitably finds some way to squeeze them in. > I need a use-case to make-up my mind A single use-case is not much point. The idea is to assemble a range of use-cases such that all the potential behaviors of the system or model are elucidated. > ?? UCDs do not care about units.. Indeed, but sometimes a preference is implicit. Seeing is likely in arcseconds, dates are likely ISO 8601, and so forth. Rob Seaman NOAO -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alberto.Micol at eso.org Fri Jul 15 09:33:09 2005 From: Alberto.Micol at eso.org (Alberto Micol) Date: Fri, 15 Jul 2005 18:33:09 +0200 Subject: What is that a UCD can be assigned to? In-Reply-To: <42D4C698.70908@sciops.esa.int> References: <42D4C698.70908@sciops.esa.int> Message-ID: <0c98fa388c24f6627eccd21e02333daf@eso.org> Dear All, I'm trying to catch up with UCDs, sorry to be so late. Matteo's and Ana's comments, plus my own way of reading the list of words, and especially the comments associated with each word, make me think that something is not yet properly defined, and that some ambiguity is still to be removed. While historically UCDs were assigned to *columns* in the Vizier collection of tables, I wonder if this is still true. That is, I cannot find in any document of the UCD1+ the answer to the question: What is that a UCD can be assigned to? I know that it CAN be assigned to a scalar quantity; I know that it CAN be assigned to a column in a table; but CAN it be assigned to an image, to a table, or any other piece of Astronomical Data? I cannot find the answer in any recent UCD-related document (correct me if wrong). I think we need to fill this gap, and give a clear answer. The answer can be: NO --- If the answer is that a UCD can NOT be assigned to anything else than a scalar quantity or an array of identical quantities (i.e., the column in a table), then I do not see why we should have a UCD like instr.interferometry (Thanks Matteo for the good example) YES --- If, at the contrary, UCDs can be assigned to generic, however complicated, data structures then instr.interferometry becomes a nice UCD (though I would suggest data.interferometry instead). Furthermore, if UCDs can be assigned to complex data structures then suddenly I can make sense of other UCDs (like instr.filter.transm) which are currently defined in an ambiguous way: > instr.filter.transm | Filter transmission Is it for a typical value of the transmission of my filter (e.g. 0.2)? or Does it refer to the entire array that represents the "transmission curve" ? On the other hand, if the answer is YES, then a table could have its own UCDs, (and in that case the VOTable standard will need a revision to support UCDs at the table level). But I think that the answer is NO, because otherwise the vocabulary would need to explode and include all kind of things. Hence, if the answer is NO, then I would suggest to make the comments a bit more strict to avoid confusion. A couple of examples: Current Description Possibly less ambiguous description ------------------- ----------------------------------------- Filter transmission -> Typical value for the filter transmission Spectral resolution -> Typical value of the spectral resolution Resolution -> Typical value of the angular resolution Spectral line -> Common name of the spectral line Detector -> Name of the detector Photographic Plate -> Type of emulsion etc. etc. Alberto PS: Did I get the right answer? Menace: Many more comments to come (e.g. UCDs for Characterisation DM, etc.), hopefully next week. From pdidelon at cea.fr Tue Jul 19 05:09:34 2005 From: pdidelon at cea.fr (Pierre Didelon) Date: Tue, 19 Jul 2005 14:09:34 +0200 Subject: Late comments (mainly) on the UCD word list In-Reply-To: References: Message-ID: <42DCED7E.3010008@cea.fr> Hi, some comments related to DM ... ;-) SY, Pierre Ana Ines Gomez de Castro wrote: > Hi, > > On Fri, 15 Jul 2005, Andrea Preite Martinez wrote: > > >>>3. we propose to add the words "em.wl.start" and "em.wl.stop". >>>Rationale: they may be useful and flexible characterizations of the >>>bandpass >> >>In many cases I found a data/column description saying: beginning/minimum >>wl, ending/maximum wl, that I translated using stat.min, stat.max. On the >>other hand, beginning/ending of observation/exposure deserved wholly new >>ucd-words! So I'm in favour of introducing these concepts, but as generic >>qualifiers that can be applied to any axis (time, wl, freq, ..) >> > > > > Fine! > > ... >>>8. we propose to change the word code of "instr.filter.transm" and >>>"instr.spect.resolution" to "V". Rationale: the filter transmission is >>>an intrinsically vectorial quantity; the spectral resolution as well >>>(dependence on energy and/or order) >> >>The V-flag indicates a vector in space >> > > > At the very first AVO meeting organized by Piero in Garching there was > a long discussion about this issue. To fully understand the meaning of > an image obtained with a given filter you need the Transmittance > function of the filter ( T(lambda) ). Unless you force all the > observatories to use exactly the same filters and qualify them, > specifying the transmittance function is the easiest way to qualify > them and allow proper comparisons between observations obtained > with different instruments. Are "functions" allowed as UCDs > It is may be more related to DM dealing with characterization http://alinda.u-strasbg.fr/Model/Characterisation/DM_vers0.1/ to "fully" describe metadata conserning an observation, including filters and theirs properties... http://alinda.u-strasbg.fr/Model/Characterisation/DM_vers0.1/3771728084_130.html UCD is perhaps to general/generic to be complete? >> >>>17. "pos.earth", "pos.earth.lat", "pos.earth.lon" should be placed under >>>the "obs" category. Rationale: these quantity belongs logically to an >>>observation, not to (the position of) a source >> >>I can assure you that pos.earth means position ON the earth, not source >>position on some earth-based coordinate frame!! > > > Then, why are them within the "pos" category? I thought that "pos" is > related with "source" and "obs" with the observation/observatory. > Doesn't it look more natural, obs.pos.earth.lat? > but pos.earth.lat or pos.earth.* can perhaps be related to something else than observation? >> >> >>>An additional point that we have discussed concerns the units in which >>>interferometric data shall be provided... > > > Matteo and I were dicussing about how interferometric data were > going to be provided to VO's from the observatories. Interferometric > data are basically images in the "Fourier space" and not in the > "physical space". During the AVO experience, Joddrell Bank > provided directly "physical images" since they carried out > the Inverse Fourier Tranform before given access to the data > through the web. So, our question is a generic issue. > > Interferometric data are going to become more and more > common in Astronomy. The "measuring space" of interferometric > data is the "Fourier- I mean , space frequencies - space". > Are the interferometric data providers going to release their > products in the "physical" or in the "Fourier" space? > Has this issue be discussed?, has been discussed how does > it affect UCD's? What UCD did you forsee to be able to describe more precisely interferometry data. DM group working on characterization would certainly be interested also by this topic. > > > Finally, I've kept thinking about UCD's for "simulations" > and this is very tricky. As important as the method, > resolution, time-scales etcc. is to describe the > boundary and the initial conditions. I still wonder how!!! > > > Cheers, > > Ana > > > Prof. Ana I. Gomez de Castro > Instituto de Astronomia y Geodesia (CSIC-UCM) > Fac. de CC Matematicas > Universidad Complutense de Madrid > 28040 Madrid, Spain > > Ph. 34-913944578 (office) 34-659783338 (mobile) > Email: aig at mat.ucm.es > > -- 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/ ------------------------------------------------------------------ La carte n'est pas le territoire - Alfred KORZYBSKI ------------------------------------------------------------------ From pdidelon at cea.fr Tue Jul 19 05:38:40 2005 From: pdidelon at cea.fr (Pierre Didelon) Date: Tue, 19 Jul 2005 14:38:40 +0200 Subject: What is that a UCD can be assigned to? In-Reply-To: <0c98fa388c24f6627eccd21e02333daf@eso.org> References: <42D4C698.70908@sciops.esa.int> <0c98fa388c24f6627eccd21e02333daf@eso.org> Message-ID: <42DCF450.8090709@cea.fr> Alberto Micol wrote: > > Dear All, > > I'm trying to catch up with UCDs, sorry to be so late. > > Matteo's and Ana's comments, plus my own way of reading the list of words, > and especially the comments associated with each word, make me think that > something is not yet properly defined, and that some ambiguity is still > to be removed. > > While historically UCDs were assigned to *columns* in the Vizier > collection of tables, > I wonder if this is still true. That is, I cannot find in any document > of the UCD1+ > the answer to the question: > > What is that a UCD can be assigned to? > > I know that it CAN be assigned to a scalar quantity; > I know that it CAN be assigned to a column in a table; > > but > > CAN it be assigned to an image, to a table, or any other piece of > Astronomical Data? > > I cannot find the answer in any recent UCD-related document (correct me > if wrong). > I think we need to fill this gap, and give a clear answer. > > The answer can be: > > NO > --- > If the answer is that a UCD can NOT be assigned to anything else than a > scalar quantity > or an array of identical quantities (i.e., the column in a table), > then I do not see why we should have a UCD like instr.interferometry > (Thanks Matteo for the good example) > > > YES > --- > If, at the contrary, UCDs can be assigned to generic, however > complicated, data structures > then instr.interferometry becomes a nice UCD (though I would suggest > data.interferometry instead). > > Furthermore, if UCDs can be assigned to complex data structures then > suddenly I can make sense of other UCDs (like instr.filter.transm) > which are currently defined in an ambiguous way: > > > instr.filter.transm | Filter transmission > > Is it for a typical value of the transmission of my filter (e.g. 0.2)? > or > Does it refer to the entire array that represents the "transmission > curve" ? May be it can be both, depending of the context and the data decribed? But transmission curve is certainly more precisely described by SED-DM, and in this context why not associating this structure with such an UCD? > > On the other hand, if the answer is YES, then a table could have its own > UCDs, > (and in that case the VOTable standard will need a revision to support > UCDs at the table level). It is the only "special" case where ucd are allowed aside column (FIELD) or "individual" (which can contain an array nevertheless) quantity (PARAM), not speaking of column or quantity grouping (GROUP) ;-) > > > But I think that the answer is NO, because otherwise the vocabulary > would need to explode > and include all kind of things. > Hence, if the answer is NO, then I would suggest to make the comments a > bit more strict > to avoid confusion. It is perhaps neither YES nor NO. Actually the main usage is still column characterization but who can forsee all possible usefull usage... and/or try to forbid it? > A couple of examples: > > Current Description Possibly less ambiguous description > ------------------- ----------------------------------------- > Filter transmission -> Typical value for the filter transmission > Spectral resolution -> Typical value of the spectral resolution > Resolution -> Typical value of the angular resolution > Spectral line -> Common name of the spectral line > Detector -> Name of the detector > Photographic Plate -> Type of emulsion > etc. etc. > > Alberto Friendly, Pierre From hessman at Astro.physik.Uni-Goettingen.DE Mon Jul 25 10:02:32 2005 From: hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. Hessman) Date: Mon, 25 Jul 2005 19:02:32 +0200 Subject: Late comments (mainly) on the UCD word list In-Reply-To: <20050715135459.s5rkrvu5rp4wcgs8@webmail.sic.rm.cnr.it> References: <42D4C698.70908@sciops.esa.int> <20050715135459.s5rkrvu5rp4wcgs8@webmail.sic.rm.cnr.it> Message-ID: <94beff6f1861cfe20667d9677887ac38@astro.physik.uni-goettingen.de> >> 16. a new word "pos.offaxis" should be added. Rationale: the off-axis >> angle may be a useful quantity is some catalogs > I agree. But "pos.relative" is much more general and just as good for this particular use. >> 21. we propose to add "src.stellarityIndex". Rationale: it may be >> useful >> to easily discriminate point-like from extended sources > > A word with the description ?stellarity index? already exists. Yes, but "src.starGalaxy" is obviously not general enough for a galactic nebular catalogue: is the value in the table indicating that the object is a star, a non-stellar nebula, or really a galaxy? Thus: "src.pointlike" or "src.resolved" ! >> Finally, there are still two corrections to the descriptions to >> remove narrow applications of general concepts: >> src.morph.type | morphological type, e.g. Hubble (there are >> others!!!) >> src.morph.scLength | scale length, e.g. of disk or bulge in a >> galaxy (there are others!!!) >> src.spType | spectral type, e.g. MK (there are others!!!!) > > Sorry, but I did not study english at school. I studied latin. > When you write: > i.e. = id est, you mean: that is > e.g. = exempli gratia, which means: for example (i.e., of course, > there are > others!!!) Sorry - I obviously meant for you to edit out the "(there are others!!!)" but didn't say so. >> I'm still not enthusiastic about the inconsistant use of contractions >> ("lg" is OK for "local group" but "sg" is not OK for >> "supergalactic"???), > but there are obviously too many of us old >> people who grew up worrying about to get our > data into 4k of >> computer memory... > > Indeed!!! I still feel that changing to ?supergalactic? was a terrible > waste of memory!! :-) XML is a waste of memory in any case, but the point is that it doesn't matter. We're talking about a 5% effect in the size of documents - it's a waste of time to even think about it, so one might as well be explicit. Rick ------------------------------------------------------------------------ ------------------------ NEW ADDRESS!!! ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Institut f?r Astrophysik Tel. +49-551-39-5052 Friedrich-Hund-Platz 1 Fax +49-551-39-5043 37077 Goettingen Room F04-133 http://www.Astro.physik.Uni-Goettingen.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.Uni-Goettingen.de ------------------------------------------------------------------------ -------------------------