Re: T0 : extensions to em, obs, spect, instr

From: Pierre Didelon <pdidelon-at-cea.fr>
Date: Wed, 01 Jun 2005 11:02:43 +0200


Hi Rick,

(apologies for cross posting, i will try to avoid it in the future ;-) )

Frederic V. "Rick" Hessman wrote:

> On 31 May 2005, at 3:09 pm, Pierre Didelon wrote:
>

>> Frederic V. "Rick" Hessman wrote:
>>
SNIP

>> UCD must define preferentially concept I suppose, isn't it?
>> Enumerated lists must be handle with other mechanisms!
>> Keyword (<=>UCD) and the corresponding values...Y/N?

>
>
> I'm not sure what you mean....

I will try to explain what I mean with two or three examples... if I have time, in an other mail. ;-)
It is related with the pb of describing things (not really naming them!?) (for bandpass see http://www.ivoa.net/forum/ucd/0505/0197.htm) and how precise UCD must be (http://www.ivoa.net/forum/ucd/0505/0202.htm). The two mails of P.Ortiz give a clear insight of the basic pb. To make it brief, if we can perhaps admit to have bandpass "names" in UCD vocabulary it become very very difficult to have solar system object names, and certainly inacceptable to have all astronomical object names... I hope :-D This last purpose is handle by name resolvers : NED,SIMBAD...

>

>>>         ...?
>>> 2. I suggest we add UCD's for describing calibration observations.    
>>> Presently, they are
>>>     few mentions of calibrations at all in the official list:
>>>         instr.calib                (calibration parameter)
>>>         phot.calib                (photometric calibration)
>>>     and they are sorely needed for things like VOEvent and RTML.
>>>     It's trivial to say that there's a big different between  
>>> calibrations  (see above) and calibration
>>>     observations, so new UCD's are needed and it seems the likely   
>>> candidates would be:
>>>         obs.calib                (calibration observation)
>>>         obs.calib.dome-flat        (dome-flat observation)
>>>         obs.calib.flux            (flux calibration observation)
>>>         obs.calib.freq            (frequency calibration observation)
>>>         obs.calib.guide-star        (guide-star observation, e.g. 
>>> for  intial setup)
>>>         obs.calib.phot            (photometric calibration  observation)
>>>         obs.calib.pos            (astrometric calibration observation
>>>         obs.calib.sky-flat        (sky-flat observation)
>>>         obs.calib.slit-mask        (slit-mask calibration observation)
>>>         obs.calib.spect            (spectral type calibration  
>>> observation)
>>>         obs.calib.veloc            (radial velocity calibration  
>>> observation, e.g.  standard star)
>>>         obs.calib.wl            (wavelength calibration observation)
>>
>> Looks like you are trying to define a data model for observation
>> and data reduction with UCD... which is perhaps not the best way to go?

>
>
> Absolutely NOT!!!! I just want to be able to say what something is,
Not only!
For example obs.calib.dome-flat is certainly an image (or may be a spectra?) which have been obtained under specific conditions and used in a precise context to derive reduced data. It describe only a "personnal" point of view of the way a piece of data can be used!
But take an image obs.calib.sky-flat (sky-flat observation), although its main usage will be calibration nobody can assert that some project can use these data for other purposes, even scientific ones : variability event follow up, historical tracing back, proper motion detection... or whatever else we are not already thinking or aware of.

obs.calib.freq or obs.calib.spectcan certainly be better defined with another syntax, and first of all what is the kind of observed data concerned, image, spectra, linelist...?

...

> just like the original
> VOTable types who wanted to describe their catalogue entries. There's
> nothing fundamentally
> different in a VO sense between a calibration image (say, an
> obs.calib.phot) and a table entry
> of the resulting calibration (say, phot.calib). Right now, UCD is
> mainly (some but not me might
> say only) useful for tables, which is why it needs to be extended to
> non-table standard VO uses.

Yes but it is not the goal of the SCI-Board, at least from the point of view of the structure, it is only concern by the content, and I am not sure that all the UCD problems can be resolve only by content "handling". Worthwhile for ucd-at-ivoa.net perhaps not for ucd-sci-at-ivoa.net.
>
> A "data model for observation and data reduction" looks very different
> indeed, though it must
> ultimately use elements for which the VO has a primitive description.
> UCD is our VO dictionary

But dictionnary of what?
All the words in astronomy (so it is related to ontology and semantic I suppose) or a dictionary of concepts, these ones beeing able to "take" values or can be instanciate in more precise description. UCD is only a part (conceptuel one AFAI understand) of a "parameter" description which can be more precisely define by "values" (restricted by enumerated lists, obtained from name resolver....), others "attributes" or even others "parameters".

> and data/observation/reduction models are VO prose or poetry: do you
> want us to write a VO poem
> using words no one (i.e. no app) understands?
>

>>>     For completeness, one should then also add
>>>         phot.calib.flux            (photometric flux calibration)
>>>         phot.calib.mag            (photometric magnitude calibration)
>>>         pos.calib                (astrometric calibration)
>>>         spect.calib            (spectroscopic calibration)
>>>         spect.calib.wl            (" " in wavelength)
>>>         spect.calib.freq            (" " in frequency)
>>> 3. Suggested addition to spect (Spectroscopy)
>>>         spect.cont                (spectral continuum)
>>
>> I like it (personnaly), but why not then spect.background....

>
>
> If it's needed, why not? Your favorite VO app should be able to know the
> difference between a spectral line and a spectral contiinuum and, in the
> real world, between the spectrum in the background (sky). Again, we have
> spect.line right now only because there are spectral line catalogues
> out there but
> few spectral continuum catalogues.
>
> No, I'm not trying to get a VO ontology through the back door:
> ontologies tell us
> what the intimate relations between objects are, whereas UCD simply
> gives us
> the ability to name things.

Hmmm. Same comments as above concerning concepts vs things.
> We're still in the VO Neadertaler age where we've
> only agreed that "Ugga" means "rock". I'm worrying about how we
> ultimately
> want to transmit the knowledge of turning a rock into a spear. I hope
> that the problem now isn't going to be getting our colleagues to agree
> that we
> need a word for "stick"....
>
> Rick

SY
PiR Received on 2005-06-01Z09:03:21