From andrea.preitemartinez at iasf-roma.inaf.it Sat Jun 23 05:07:45 2007 From: andrea.preitemartinez at iasf-roma.inaf.it (Andrea Preite Martinez) Date: Sat, 23 Jun 2007 14:07:45 +0200 Subject: UCDs in SpectrumDM Message-ID: <20070623140745.3fqqb37iv4w4ko08@webmail.sic.rm.cnr.it> Hi all, there is an interesting discussion going on in the RFC page http://www.ivoa.net/twiki/bin/view/IVOA/SpectrumDataModelRFC on the use of UCDs in the Spectrum Data Model. You can find the Spectrum DM document at http://www.ivoa.net/Documents/latest/SpectrumDM.html Your comments and your opinion on the discussion is very welcome Andrea =================================================================================== Andrea Preite Martinez andrea.preitemartinez at iasf-roma.inaf.it IASF Tel.IASF:+39.06.4993.4641 Via del Fosso del Cavaliere 100 Tel.CDS :+33.3.90242452 I-00133 Roma Cell. :+39.320.43.15.383 Skype :andrea.preite.martinez =================================================================================== From andrea.preitemartinez at iasf-roma.inaf.it Sat Jun 23 05:07:45 2007 From: andrea.preitemartinez at iasf-roma.inaf.it (Andrea Preite Martinez) Date: Sat, 23 Jun 2007 14:07:45 +0200 Subject: UCDs in SpectrumDM Message-ID: <20070623140745.3fqqb37iv4w4ko08@webmail.sic.rm.cnr.it> Hi all, there is an interesting discussion going on in the RFC page http://www.ivoa.net/twiki/bin/view/IVOA/SpectrumDataModelRFC on the use of UCDs in the Spectrum Data Model. You can find the Spectrum DM document at http://www.ivoa.net/Documents/latest/SpectrumDM.html Your comments and your opinion on the discussion is very welcome Andrea =================================================================================== Andrea Preite Martinez andrea.preitemartinez at iasf-roma.inaf.it IASF Tel.IASF:+39.06.4993.4641 Via del Fosso del Cavaliere 100 Tel.CDS :+33.3.90242452 I-00133 Roma Cell. :+39.320.43.15.383 Skype :andrea.preite.martinez =================================================================================== From jcm at head.cfa.harvard.edu Sat Jun 23 11:52:33 2007 From: jcm at head.cfa.harvard.edu (Jonathan McDowell) Date: Sat, 23 Jun 2007 14:52:33 -0400 Subject: UCDs in SpectrumDM Message-ID: <200706231852.l5NIqXQj009297@urania.cfa.harvard.edu> Andrea, I guess I don't feel that phot.flux.density;em.wl,stat.max (and similar) are 'cumbersome' - I find them much easier to understand than extra custom-crafted UCDs like ..perWave. I feel that em.wl, em.freq, etc. are naturally adjectives as well as nouns; since they are 'Q' and not 'P', what I have done seems perfectly legal, and I guess I would like a reason based on the standard that it's not right, rather than just 'Andrea doesn't like it'... I accept the proposal to add stat.error.lower, stat.error.upper, em.wl.air as new UCDs. But I'm a bit concerned that you give me all this input now at/after the end of the RFC period, we were hoping to get approval for Spectrum at the July 15 exec - if we need to add all these new UCDs, does this mean we have to wait for a new update to the words list to be approved before Spectrum can go to approval? (Plus, of course, the time required for all the implementers to change their implementation, since we've published essentially the current list of Spectrum UCDs over a year ago and everyone is using them - this mostly is important for the Flux.Value cases). For polarized flux: yes, a data provider could choose to separate it out into (total flux vs wavelength) and (fraction of polarized flux vs wavelength), but I believe it's fairly common (certainly in AGN work) to show the product of these two things as the 'polarized flux', and I want a UCD for that. Since phys.polarization is an 'E' word, I believe that phot.flux.density;em.wl,phys.polarization is a reasonably unambiguous UCD for this? For em.*: in the context of the doc, this is a shorthand for (EITHER em.wl OR em.freq OR em.energy). I hope other sci-ucd members will comment. - Jonathan Andrea wrote: > 1) first of all, a general consideration: if we miss an ucd-word for > expressing a given quantity, then let?s create the corresponding new > ucd-word. > > 2) as an alternative, we can agree that e.g. phot.flux.density;em.wl > (or freq or energy) indicates the flux density per unit wavelength (or > frequency, or energy) : no syntax problem (valid syntax ), but > cumbersome if you want to add other modifiers/qualifiers (em.opt, > stat.max,...). What I do not like in the form phot.flux.density;em.wl > is the use of a quantity (em.wl) as a modifier/qualifier of the first > quantity (phot.flux.density). In this case I prefer going to point (1) > above, and re-present the proposal (see Victoria 2006) of adding: > > > phot.flux.density.perFreq, > phot.flux.density.perWave, > phot.flux.density.perEnergy, .. > phot.flux.photon.per*, .. > phot.flux.brTemperature, .. > phot.intensity.perWave .. > > So, phot.flux.density;em.wl;spect.continuum will become > phot.flux.density.perWave;spect.continuum > > About Polarized Flux: I don?t understand the problem. I would have added > an additional attribute for the degree of polarization or the fraction > of polarized flux. > > the same concern applies to phys.area;phys.transmission: let?s go to > phys.area.effective > > src.amplitude;arith.ratio : you are right > > Spectrum.Char.SpatialAxis.ucd, unit: I took out meta.ucd, meta.unit for uniformity with the other axes. You can replace them, adding them also to TimeAxis . > > stat.error;em : yes, if a * is legal in your context, you can write stat.error;em* (but not meaning all the em-word branch! ) > > em.wl;obs.atmos: I prefer em.wl.air. > > > 3) in order to avoid confusion in multi-word ucds, I suggest also to introduce > > stat.error.lower instead of stat.error;stat.min > > stat.error.upper instead of stat.error;stat.max > > Ciao, Andrea > > From jcm at head.cfa.harvard.edu Sat Jun 23 11:52:33 2007 From: jcm at head.cfa.harvard.edu (Jonathan McDowell) Date: Sat, 23 Jun 2007 14:52:33 -0400 Subject: UCDs in SpectrumDM Message-ID: <200706231852.l5NIqXQj009297@urania.cfa.harvard.edu> Andrea, I guess I don't feel that phot.flux.density;em.wl,stat.max (and similar) are 'cumbersome' - I find them much easier to understand than extra custom-crafted UCDs like ..perWave. I feel that em.wl, em.freq, etc. are naturally adjectives as well as nouns; since they are 'Q' and not 'P', what I have done seems perfectly legal, and I guess I would like a reason based on the standard that it's not right, rather than just 'Andrea doesn't like it'... I accept the proposal to add stat.error.lower, stat.error.upper, em.wl.air as new UCDs. But I'm a bit concerned that you give me all this input now at/after the end of the RFC period, we were hoping to get approval for Spectrum at the July 15 exec - if we need to add all these new UCDs, does this mean we have to wait for a new update to the words list to be approved before Spectrum can go to approval? (Plus, of course, the time required for all the implementers to change their implementation, since we've published essentially the current list of Spectrum UCDs over a year ago and everyone is using them - this mostly is important for the Flux.Value cases). For polarized flux: yes, a data provider could choose to separate it out into (total flux vs wavelength) and (fraction of polarized flux vs wavelength), but I believe it's fairly common (certainly in AGN work) to show the product of these two things as the 'polarized flux', and I want a UCD for that. Since phys.polarization is an 'E' word, I believe that phot.flux.density;em.wl,phys.polarization is a reasonably unambiguous UCD for this? For em.*: in the context of the doc, this is a shorthand for (EITHER em.wl OR em.freq OR em.energy). I hope other sci-ucd members will comment. - Jonathan Andrea wrote: > 1) first of all, a general consideration: if we miss an ucd-word for > expressing a given quantity, then let?s create the corresponding new > ucd-word. > > 2) as an alternative, we can agree that e.g. phot.flux.density;em.wl > (or freq or energy) indicates the flux density per unit wavelength (or > frequency, or energy) : no syntax problem (valid syntax ), but > cumbersome if you want to add other modifiers/qualifiers (em.opt, > stat.max,...). What I do not like in the form phot.flux.density;em.wl > is the use of a quantity (em.wl) as a modifier/qualifier of the first > quantity (phot.flux.density). In this case I prefer going to point (1) > above, and re-present the proposal (see Victoria 2006) of adding: > > > phot.flux.density.perFreq, > phot.flux.density.perWave, > phot.flux.density.perEnergy, .. > phot.flux.photon.per*, .. > phot.flux.brTemperature, .. > phot.intensity.perWave .. > > So, phot.flux.density;em.wl;spect.continuum will become > phot.flux.density.perWave;spect.continuum > > About Polarized Flux: I don?t understand the problem. I would have added > an additional attribute for the degree of polarization or the fraction > of polarized flux. > > the same concern applies to phys.area;phys.transmission: let?s go to > phys.area.effective > > src.amplitude;arith.ratio : you are right > > Spectrum.Char.SpatialAxis.ucd, unit: I took out meta.ucd, meta.unit for uniformity with the other axes. You can replace them, adding them also to TimeAxis . > > stat.error;em : yes, if a * is legal in your context, you can write stat.error;em* (but not meaning all the em-word branch! ) > > em.wl;obs.atmos: I prefer em.wl.air. > > > 3) in order to avoid confusion in multi-word ucds, I suggest also to introduce > > stat.error.lower instead of stat.error;stat.min > > stat.error.upper instead of stat.error;stat.max > > Ciao, Andrea > > From andrea.preitemartinez at iasf-roma.inaf.it Sat Jun 23 13:19:31 2007 From: andrea.preitemartinez at iasf-roma.inaf.it (Andrea Preite Martinez) Date: Sat, 23 Jun 2007 22:19:31 +0200 Subject: UCDs in SpectrumDM In-Reply-To: <200706231852.l5NIqXQj009297@urania.cfa.harvard.edu> References: <200706231852.l5NIqXQj009297@urania.cfa.harvard.edu> Message-ID: <20070623221931.11p4oithsc4sgkoc@webmail.sic.rm.cnr.it> Jonathan, as you have the right to say: > I guess I don't feel that > phot.flux.density;em.wl,stat.max > (and similar) are 'cumbersome' - I find them much easier > to understand than extra custom-crafted UCDs like ..perWave. > I guess I would like a reason based on the standard that it's not right, > rather than just 'Andrea doesn't like it'... I think I have the same right to say what I said: that, although perfectly legal, I see the risk of building a cumbersome expression if one adds other qualifiers/modifiers. > I'm a bit concerned that you give me all this input now > at/after the end of the RFC period, we were hoping to get approval > for Spectrum > at the July 15 exec - if we need to add all these new UCDs, does this > mean we have to wait for a new update to the words list to be approved > before Spectrum can go to approval? (Plus, of course, the time required > for all the implementers to change their implementation, since > we've published > essentially the current list of Spectrum UCDs over a year ago and > everyone is using > them - this mostly is important for the Flux.Value cases). > No, my personal point of view is that the DM WG does not have to wait for a new update to the word list. Remember that the present version of the doc (at pag.23) already proposes some (+ the change of role of pos.eq, not yet standard!). I don't se why the EXEC should not approve a Rec proposing some modifications/additions to the current version of another standard: btw, they are going to approve Search-by-Cone, where old UCD1 are still used, based on a motivation similar to what you are expressing above (implementers should change their implementations). > I hope other sci-ucd members will comment. I agree with you! Andrea =================================================================================== Andrea Preite Martinez andrea.preitemartinez at iasf-roma.inaf.it IASF Tel.IASF:+39.06.4993.4641 Via del Fosso del Cavaliere 100 Tel.CDS :+33.3.90242452 I-00133 Roma Cell. :+39.320.43.15.383 Skype :andrea.preite.martinez =================================================================================== From andrea.preitemartinez at iasf-roma.inaf.it Sat Jun 23 13:19:31 2007 From: andrea.preitemartinez at iasf-roma.inaf.it (Andrea Preite Martinez) Date: Sat, 23 Jun 2007 22:19:31 +0200 Subject: UCDs in SpectrumDM In-Reply-To: <200706231852.l5NIqXQj009297@urania.cfa.harvard.edu> References: <200706231852.l5NIqXQj009297@urania.cfa.harvard.edu> Message-ID: <20070623221931.11p4oithsc4sgkoc@webmail.sic.rm.cnr.it> Jonathan, as you have the right to say: > I guess I don't feel that > phot.flux.density;em.wl,stat.max > (and similar) are 'cumbersome' - I find them much easier > to understand than extra custom-crafted UCDs like ..perWave. > I guess I would like a reason based on the standard that it's not right, > rather than just 'Andrea doesn't like it'... I think I have the same right to say what I said: that, although perfectly legal, I see the risk of building a cumbersome expression if one adds other qualifiers/modifiers. > I'm a bit concerned that you give me all this input now > at/after the end of the RFC period, we were hoping to get approval > for Spectrum > at the July 15 exec - if we need to add all these new UCDs, does this > mean we have to wait for a new update to the words list to be approved > before Spectrum can go to approval? (Plus, of course, the time required > for all the implementers to change their implementation, since > we've published > essentially the current list of Spectrum UCDs over a year ago and > everyone is using > them - this mostly is important for the Flux.Value cases). > No, my personal point of view is that the DM WG does not have to wait for a new update to the word list. Remember that the present version of the doc (at pag.23) already proposes some (+ the change of role of pos.eq, not yet standard!). I don't se why the EXEC should not approve a Rec proposing some modifications/additions to the current version of another standard: btw, they are going to approve Search-by-Cone, where old UCD1 are still used, based on a motivation similar to what you are expressing above (implementers should change their implementations). > I hope other sci-ucd members will comment. I agree with you! Andrea =================================================================================== Andrea Preite Martinez andrea.preitemartinez at iasf-roma.inaf.it IASF Tel.IASF:+39.06.4993.4641 Via del Fosso del Cavaliere 100 Tel.CDS :+33.3.90242452 I-00133 Roma Cell. :+39.320.43.15.383 Skype :andrea.preite.martinez =================================================================================== From hessman at Astro.physik.Uni-Goettingen.DE Mon Jun 25 00:59:15 2007 From: hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. Hessman) Date: Mon, 25 Jun 2007 09:59:15 +0200 Subject: UCDs in SpectrumDM In-Reply-To: <200706231852.l5NIqXQj009297@urania.cfa.harvard.edu> References: <200706231852.l5NIqXQj009297@urania.cfa.harvard.edu> Message-ID: <645A8B10-8996-4B02-92AE-0E895145F5A7@astro.physik.uni-goettingen.de> On 23 Jun 2007, at 8:52 pm, Jonathan McDowell wrote: > > Andrea, > > I guess I don't feel that > phot.flux.density;em.wl,stat.max > (and similar) are 'cumbersome' - I find them much easier > to understand than extra custom-crafted UCDs like ..perWave. > I feel that em.wl, em.freq, etc. are naturally adjectives as well as > nouns > For em.*: in the context of the doc, this is a shorthand for > (EITHER em.wl OR em.freq OR em.energy). I confess that I have a hard time with all of these solutions, since they are workable only if the assumptions behind them are clearly defined (and who is going to garantee that someone teaches a computer correctly?). In order to manipulate the numbers, the VO apps are going to have to deal with the units anyway, so I'd prefer one of two extreme solutions: 1. em.flux THAT'S IT! Whether it's W/m^2/micron or Jy or photons/ cm^2 .... can only be known by looking at the units. or 2. Pendanticism, e.g. W/m^2/micron = em.energy;stat.perSqrMeter;stat.perTime;stat.perWavelength I know these comments are late - so you can promptly delete this email - but these seem much more workable solutions. Rick ------------------------------------------------------------------------ ------------------------ 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 ------------------------------------------------------------------------ ------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hessman at astro.physik.uni-goettingen.de Mon Jun 25 00:59:15 2007 From: hessman at astro.physik.uni-goettingen.de (Frederic V. Hessman) Date: Mon, 25 Jun 2007 09:59:15 +0200 Subject: UCDs in SpectrumDM In-Reply-To: <200706231852.l5NIqXQj009297@urania.cfa.harvard.edu> References: <200706231852.l5NIqXQj009297@urania.cfa.harvard.edu> Message-ID: <645A8B10-8996-4B02-92AE-0E895145F5A7@astro.physik.uni-goettingen.de> On 23 Jun 2007, at 8:52 pm, Jonathan McDowell wrote: > > Andrea, > > I guess I don't feel that > phot.flux.density;em.wl,stat.max > (and similar) are 'cumbersome' - I find them much easier > to understand than extra custom-crafted UCDs like ..perWave. > I feel that em.wl, em.freq, etc. are naturally adjectives as well as > nouns > For em.*: in the context of the doc, this is a shorthand for > (EITHER em.wl OR em.freq OR em.energy). I confess that I have a hard time with all of these solutions, since they are workable only if the assumptions behind them are clearly defined (and who is going to garantee that someone teaches a computer correctly?). In order to manipulate the numbers, the VO apps are going to have to deal with the units anyway, so I'd prefer one of two extreme solutions: 1. em.flux THAT'S IT! Whether it's W/m^2/micron or Jy or photons/ cm^2 .... can only be known by looking at the units. or 2. Pendanticism, e.g. W/m^2/micron = em.energy;stat.perSqrMeter;stat.perTime;stat.perWavelength I know these comments are late - so you can promptly delete this email - but these seem much more workable solutions. Rick ------------------------------------------------------------------------ ------------------------ 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 ------------------------------------------------------------------------ ------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrea.preitemartinez at iasf-roma.inaf.it Sat Jun 23 05:07:45 2007 From: andrea.preitemartinez at iasf-roma.inaf.it (Andrea Preite Martinez) Date: Sat, 23 Jun 2007 14:07:45 +0200 Subject: UCDs in SpectrumDM Message-ID: <20070623140745.3fqqb37iv4w4ko08@webmail.sic.rm.cnr.it> Hi all, there is an interesting discussion going on in the RFC page http://www.ivoa.net/twiki/bin/view/IVOA/SpectrumDataModelRFC on the use of UCDs in the Spectrum Data Model. You can find the Spectrum DM document at http://www.ivoa.net/Documents/latest/SpectrumDM.html Your comments and your opinion on the discussion is very welcome Andrea =================================================================================== Andrea Preite Martinez andrea.preitemartinez at iasf-roma.inaf.it IASF Tel.IASF:+39.06.4993.4641 Via del Fosso del Cavaliere 100 Tel.CDS :+33.3.90242452 I-00133 Roma Cell. :+39.320.43.15.383 Skype :andrea.preite.martinez =================================================================================== From andrea.preitemartinez at iasf-roma.inaf.it Sat Jun 23 05:07:45 2007 From: andrea.preitemartinez at iasf-roma.inaf.it (Andrea Preite Martinez) Date: Sat, 23 Jun 2007 14:07:45 +0200 Subject: UCDs in SpectrumDM Message-ID: <20070623140745.3fqqb37iv4w4ko08@webmail.sic.rm.cnr.it> Hi all, there is an interesting discussion going on in the RFC page http://www.ivoa.net/twiki/bin/view/IVOA/SpectrumDataModelRFC on the use of UCDs in the Spectrum Data Model. You can find the Spectrum DM document at http://www.ivoa.net/Documents/latest/SpectrumDM.html Your comments and your opinion on the discussion is very welcome Andrea =================================================================================== Andrea Preite Martinez andrea.preitemartinez at iasf-roma.inaf.it IASF Tel.IASF:+39.06.4993.4641 Via del Fosso del Cavaliere 100 Tel.CDS :+33.3.90242452 I-00133 Roma Cell. :+39.320.43.15.383 Skype :andrea.preite.martinez =================================================================================== From jcm at head.cfa.harvard.edu Sat Jun 23 11:52:33 2007 From: jcm at head.cfa.harvard.edu (Jonathan McDowell) Date: Sat, 23 Jun 2007 14:52:33 -0400 Subject: UCDs in SpectrumDM Message-ID: <200706231852.l5NIqXQj009297@urania.cfa.harvard.edu> Andrea, I guess I don't feel that phot.flux.density;em.wl,stat.max (and similar) are 'cumbersome' - I find them much easier to understand than extra custom-crafted UCDs like ..perWave. I feel that em.wl, em.freq, etc. are naturally adjectives as well as nouns; since they are 'Q' and not 'P', what I have done seems perfectly legal, and I guess I would like a reason based on the standard that it's not right, rather than just 'Andrea doesn't like it'... I accept the proposal to add stat.error.lower, stat.error.upper, em.wl.air as new UCDs. But I'm a bit concerned that you give me all this input now at/after the end of the RFC period, we were hoping to get approval for Spectrum at the July 15 exec - if we need to add all these new UCDs, does this mean we have to wait for a new update to the words list to be approved before Spectrum can go to approval? (Plus, of course, the time required for all the implementers to change their implementation, since we've published essentially the current list of Spectrum UCDs over a year ago and everyone is using them - this mostly is important for the Flux.Value cases). For polarized flux: yes, a data provider could choose to separate it out into (total flux vs wavelength) and (fraction of polarized flux vs wavelength), but I believe it's fairly common (certainly in AGN work) to show the product of these two things as the 'polarized flux', and I want a UCD for that. Since phys.polarization is an 'E' word, I believe that phot.flux.density;em.wl,phys.polarization is a reasonably unambiguous UCD for this? For em.*: in the context of the doc, this is a shorthand for (EITHER em.wl OR em.freq OR em.energy). I hope other sci-ucd members will comment. - Jonathan Andrea wrote: > 1) first of all, a general consideration: if we miss an ucd-word for > expressing a given quantity, then let?s create the corresponding new > ucd-word. > > 2) as an alternative, we can agree that e.g. phot.flux.density;em.wl > (or freq or energy) indicates the flux density per unit wavelength (or > frequency, or energy) : no syntax problem (valid syntax ), but > cumbersome if you want to add other modifiers/qualifiers (em.opt, > stat.max,...). What I do not like in the form phot.flux.density;em.wl > is the use of a quantity (em.wl) as a modifier/qualifier of the first > quantity (phot.flux.density). In this case I prefer going to point (1) > above, and re-present the proposal (see Victoria 2006) of adding: > > > phot.flux.density.perFreq, > phot.flux.density.perWave, > phot.flux.density.perEnergy, .. > phot.flux.photon.per*, .. > phot.flux.brTemperature, .. > phot.intensity.perWave .. > > So, phot.flux.density;em.wl;spect.continuum will become > phot.flux.density.perWave;spect.continuum > > About Polarized Flux: I don?t understand the problem. I would have added > an additional attribute for the degree of polarization or the fraction > of polarized flux. > > the same concern applies to phys.area;phys.transmission: let?s go to > phys.area.effective > > src.amplitude;arith.ratio : you are right > > Spectrum.Char.SpatialAxis.ucd, unit: I took out meta.ucd, meta.unit for uniformity with the other axes. You can replace them, adding them also to TimeAxis . > > stat.error;em : yes, if a * is legal in your context, you can write stat.error;em* (but not meaning all the em-word branch! ) > > em.wl;obs.atmos: I prefer em.wl.air. > > > 3) in order to avoid confusion in multi-word ucds, I suggest also to introduce > > stat.error.lower instead of stat.error;stat.min > > stat.error.upper instead of stat.error;stat.max > > Ciao, Andrea > > From jcm at head.cfa.harvard.edu Sat Jun 23 11:52:33 2007 From: jcm at head.cfa.harvard.edu (Jonathan McDowell) Date: Sat, 23 Jun 2007 14:52:33 -0400 Subject: UCDs in SpectrumDM Message-ID: <200706231852.l5NIqXQj009297@urania.cfa.harvard.edu> Andrea, I guess I don't feel that phot.flux.density;em.wl,stat.max (and similar) are 'cumbersome' - I find them much easier to understand than extra custom-crafted UCDs like ..perWave. I feel that em.wl, em.freq, etc. are naturally adjectives as well as nouns; since they are 'Q' and not 'P', what I have done seems perfectly legal, and I guess I would like a reason based on the standard that it's not right, rather than just 'Andrea doesn't like it'... I accept the proposal to add stat.error.lower, stat.error.upper, em.wl.air as new UCDs. But I'm a bit concerned that you give me all this input now at/after the end of the RFC period, we were hoping to get approval for Spectrum at the July 15 exec - if we need to add all these new UCDs, does this mean we have to wait for a new update to the words list to be approved before Spectrum can go to approval? (Plus, of course, the time required for all the implementers to change their implementation, since we've published essentially the current list of Spectrum UCDs over a year ago and everyone is using them - this mostly is important for the Flux.Value cases). For polarized flux: yes, a data provider could choose to separate it out into (total flux vs wavelength) and (fraction of polarized flux vs wavelength), but I believe it's fairly common (certainly in AGN work) to show the product of these two things as the 'polarized flux', and I want a UCD for that. Since phys.polarization is an 'E' word, I believe that phot.flux.density;em.wl,phys.polarization is a reasonably unambiguous UCD for this? For em.*: in the context of the doc, this is a shorthand for (EITHER em.wl OR em.freq OR em.energy). I hope other sci-ucd members will comment. - Jonathan Andrea wrote: > 1) first of all, a general consideration: if we miss an ucd-word for > expressing a given quantity, then let?s create the corresponding new > ucd-word. > > 2) as an alternative, we can agree that e.g. phot.flux.density;em.wl > (or freq or energy) indicates the flux density per unit wavelength (or > frequency, or energy) : no syntax problem (valid syntax ), but > cumbersome if you want to add other modifiers/qualifiers (em.opt, > stat.max,...). What I do not like in the form phot.flux.density;em.wl > is the use of a quantity (em.wl) as a modifier/qualifier of the first > quantity (phot.flux.density). In this case I prefer going to point (1) > above, and re-present the proposal (see Victoria 2006) of adding: > > > phot.flux.density.perFreq, > phot.flux.density.perWave, > phot.flux.density.perEnergy, .. > phot.flux.photon.per*, .. > phot.flux.brTemperature, .. > phot.intensity.perWave .. > > So, phot.flux.density;em.wl;spect.continuum will become > phot.flux.density.perWave;spect.continuum > > About Polarized Flux: I don?t understand the problem. I would have added > an additional attribute for the degree of polarization or the fraction > of polarized flux. > > the same concern applies to phys.area;phys.transmission: let?s go to > phys.area.effective > > src.amplitude;arith.ratio : you are right > > Spectrum.Char.SpatialAxis.ucd, unit: I took out meta.ucd, meta.unit for uniformity with the other axes. You can replace them, adding them also to TimeAxis . > > stat.error;em : yes, if a * is legal in your context, you can write stat.error;em* (but not meaning all the em-word branch! ) > > em.wl;obs.atmos: I prefer em.wl.air. > > > 3) in order to avoid confusion in multi-word ucds, I suggest also to introduce > > stat.error.lower instead of stat.error;stat.min > > stat.error.upper instead of stat.error;stat.max > > Ciao, Andrea > > From andrea.preitemartinez at iasf-roma.inaf.it Sat Jun 23 13:19:31 2007 From: andrea.preitemartinez at iasf-roma.inaf.it (Andrea Preite Martinez) Date: Sat, 23 Jun 2007 22:19:31 +0200 Subject: UCDs in SpectrumDM In-Reply-To: <200706231852.l5NIqXQj009297@urania.cfa.harvard.edu> References: <200706231852.l5NIqXQj009297@urania.cfa.harvard.edu> Message-ID: <20070623221931.11p4oithsc4sgkoc@webmail.sic.rm.cnr.it> Jonathan, as you have the right to say: > I guess I don't feel that > phot.flux.density;em.wl,stat.max > (and similar) are 'cumbersome' - I find them much easier > to understand than extra custom-crafted UCDs like ..perWave. > I guess I would like a reason based on the standard that it's not right, > rather than just 'Andrea doesn't like it'... I think I have the same right to say what I said: that, although perfectly legal, I see the risk of building a cumbersome expression if one adds other qualifiers/modifiers. > I'm a bit concerned that you give me all this input now > at/after the end of the RFC period, we were hoping to get approval > for Spectrum > at the July 15 exec - if we need to add all these new UCDs, does this > mean we have to wait for a new update to the words list to be approved > before Spectrum can go to approval? (Plus, of course, the time required > for all the implementers to change their implementation, since > we've published > essentially the current list of Spectrum UCDs over a year ago and > everyone is using > them - this mostly is important for the Flux.Value cases). > No, my personal point of view is that the DM WG does not have to wait for a new update to the word list. Remember that the present version of the doc (at pag.23) already proposes some (+ the change of role of pos.eq, not yet standard!). I don't se why the EXEC should not approve a Rec proposing some modifications/additions to the current version of another standard: btw, they are going to approve Search-by-Cone, where old UCD1 are still used, based on a motivation similar to what you are expressing above (implementers should change their implementations). > I hope other sci-ucd members will comment. I agree with you! Andrea =================================================================================== Andrea Preite Martinez andrea.preitemartinez at iasf-roma.inaf.it IASF Tel.IASF:+39.06.4993.4641 Via del Fosso del Cavaliere 100 Tel.CDS :+33.3.90242452 I-00133 Roma Cell. :+39.320.43.15.383 Skype :andrea.preite.martinez =================================================================================== From andrea.preitemartinez at iasf-roma.inaf.it Sat Jun 23 13:19:31 2007 From: andrea.preitemartinez at iasf-roma.inaf.it (Andrea Preite Martinez) Date: Sat, 23 Jun 2007 22:19:31 +0200 Subject: UCDs in SpectrumDM In-Reply-To: <200706231852.l5NIqXQj009297@urania.cfa.harvard.edu> References: <200706231852.l5NIqXQj009297@urania.cfa.harvard.edu> Message-ID: <20070623221931.11p4oithsc4sgkoc@webmail.sic.rm.cnr.it> Jonathan, as you have the right to say: > I guess I don't feel that > phot.flux.density;em.wl,stat.max > (and similar) are 'cumbersome' - I find them much easier > to understand than extra custom-crafted UCDs like ..perWave. > I guess I would like a reason based on the standard that it's not right, > rather than just 'Andrea doesn't like it'... I think I have the same right to say what I said: that, although perfectly legal, I see the risk of building a cumbersome expression if one adds other qualifiers/modifiers. > I'm a bit concerned that you give me all this input now > at/after the end of the RFC period, we were hoping to get approval > for Spectrum > at the July 15 exec - if we need to add all these new UCDs, does this > mean we have to wait for a new update to the words list to be approved > before Spectrum can go to approval? (Plus, of course, the time required > for all the implementers to change their implementation, since > we've published > essentially the current list of Spectrum UCDs over a year ago and > everyone is using > them - this mostly is important for the Flux.Value cases). > No, my personal point of view is that the DM WG does not have to wait for a new update to the word list. Remember that the present version of the doc (at pag.23) already proposes some (+ the change of role of pos.eq, not yet standard!). I don't se why the EXEC should not approve a Rec proposing some modifications/additions to the current version of another standard: btw, they are going to approve Search-by-Cone, where old UCD1 are still used, based on a motivation similar to what you are expressing above (implementers should change their implementations). > I hope other sci-ucd members will comment. I agree with you! Andrea =================================================================================== Andrea Preite Martinez andrea.preitemartinez at iasf-roma.inaf.it IASF Tel.IASF:+39.06.4993.4641 Via del Fosso del Cavaliere 100 Tel.CDS :+33.3.90242452 I-00133 Roma Cell. :+39.320.43.15.383 Skype :andrea.preite.martinez =================================================================================== From hessman at Astro.physik.Uni-Goettingen.DE Mon Jun 25 00:59:15 2007 From: hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. Hessman) Date: Mon, 25 Jun 2007 09:59:15 +0200 Subject: UCDs in SpectrumDM In-Reply-To: <200706231852.l5NIqXQj009297@urania.cfa.harvard.edu> References: <200706231852.l5NIqXQj009297@urania.cfa.harvard.edu> Message-ID: <645A8B10-8996-4B02-92AE-0E895145F5A7@astro.physik.uni-goettingen.de> On 23 Jun 2007, at 8:52 pm, Jonathan McDowell wrote: > > Andrea, > > I guess I don't feel that > phot.flux.density;em.wl,stat.max > (and similar) are 'cumbersome' - I find them much easier > to understand than extra custom-crafted UCDs like ..perWave. > I feel that em.wl, em.freq, etc. are naturally adjectives as well as > nouns > For em.*: in the context of the doc, this is a shorthand for > (EITHER em.wl OR em.freq OR em.energy). I confess that I have a hard time with all of these solutions, since they are workable only if the assumptions behind them are clearly defined (and who is going to garantee that someone teaches a computer correctly?). In order to manipulate the numbers, the VO apps are going to have to deal with the units anyway, so I'd prefer one of two extreme solutions: 1. em.flux THAT'S IT! Whether it's W/m^2/micron or Jy or photons/ cm^2 .... can only be known by looking at the units. or 2. Pendanticism, e.g. W/m^2/micron = em.energy;stat.perSqrMeter;stat.perTime;stat.perWavelength I know these comments are late - so you can promptly delete this email - but these seem much more workable solutions. Rick ------------------------------------------------------------------------ ------------------------ 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 ------------------------------------------------------------------------ ------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hessman at astro.physik.uni-goettingen.de Mon Jun 25 00:59:15 2007 From: hessman at astro.physik.uni-goettingen.de (Frederic V. Hessman) Date: Mon, 25 Jun 2007 09:59:15 +0200 Subject: UCDs in SpectrumDM In-Reply-To: <200706231852.l5NIqXQj009297@urania.cfa.harvard.edu> References: <200706231852.l5NIqXQj009297@urania.cfa.harvard.edu> Message-ID: <645A8B10-8996-4B02-92AE-0E895145F5A7@astro.physik.uni-goettingen.de> On 23 Jun 2007, at 8:52 pm, Jonathan McDowell wrote: > > Andrea, > > I guess I don't feel that > phot.flux.density;em.wl,stat.max > (and similar) are 'cumbersome' - I find them much easier > to understand than extra custom-crafted UCDs like ..perWave. > I feel that em.wl, em.freq, etc. are naturally adjectives as well as > nouns > For em.*: in the context of the doc, this is a shorthand for > (EITHER em.wl OR em.freq OR em.energy). I confess that I have a hard time with all of these solutions, since they are workable only if the assumptions behind them are clearly defined (and who is going to garantee that someone teaches a computer correctly?). In order to manipulate the numbers, the VO apps are going to have to deal with the units anyway, so I'd prefer one of two extreme solutions: 1. em.flux THAT'S IT! Whether it's W/m^2/micron or Jy or photons/ cm^2 .... can only be known by looking at the units. or 2. Pendanticism, e.g. W/m^2/micron = em.energy;stat.perSqrMeter;stat.perTime;stat.perWavelength I know these comments are late - so you can promptly delete this email - but these seem much more workable solutions. Rick ------------------------------------------------------------------------ ------------------------ 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 ------------------------------------------------------------------------ ------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: