Hi,
First a precision.
It was only my point of view (friendly i assume, at least when writing it)
and certainly not "THE" UCD-SCI board pov, and I didn't want to hurt you,
just express a (my?) difficulty when defining new UCD (similar to the one we had
when trying to define UCD for planetology) which is related to the
definition of the "good level of abstraction" to be enoughly high to
be widely re-usable but at the same time enoughly precise to be usable at all!
Some small comments... only to try to precise "my" pov.
Frederic V. "Rick" Hessman wrote:
>
> On 1 Jun 2005, at 11:02 am, Pierre Didelon wrote:
>
>>>> 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...
>
>
> Let's leave the solar system out of the way at first. If we just take
> stellar+extragalactic
> astronomy, then - of course - NOBODY wants a UCD which says
>
> src.class.galaxy.spiral.virgocluster.northern-part.opt.name.NGC12345
>
> What VOEvent DOES needs, however, is something generic like (ignore the
> actual XML tag names!)
>
> <src ucd="src.class.galaxy.spiral" name="NGC12345"/>
>
> This use is ENTIRELY EQUIVALENT in its VO meaning, scope, and
> usefulness to having a VOTable
> which contains some entry identified as meaning some physical property.
> This is totally different
> from having a DM/ontology which says what it means to have a spiral
> galaxy or what properties are
> associated with a spiral galaxy or whether the name makes any sense.
> Of course UCD isn't a name
> resolver, but if isn't a concept resolver, what is it? Why are some
> concepts more equal than others?
>
> What we have now is the possibility
>
> <src name="NGC12345">
> <type ucd="src.class">spiral galaxy</type>
> </src>
>
> and who says what "spiral galaxy" means? Who has to parse a different
> object where the type is
> "galaxy, spiral" or "galaxy of type spiral" or "spiralgalaxy" or....
> Wouldn't life be so easy if we could just
> say that there is a UCD "src.class.galaxy.spiral"?
OK! But do/must UCD be the solution to (all?) natural langage parsing?
It seems to be a general pb of enumerated lists and classifications.
must UCD integrate all the existing ones of every astro fields?
>
> To say that UCD should NOT do the first (say that something is a spiral
> galaxy) but should do the latter
> (say that a table entry is a radial velocity) means that UCD is only
> intended to be
> used for tables and catalogues.
Why?
Using already existing terms and definitions we could write
as you begin to do
<src name="NGC12345">
<automatedObjType ucd="src.class">galaxy</automatedObjType>
<supervisedMorphType ucd="src.morph">spiral</supervisedMorphType>
</src>
The nice part of this view is that as NGC12345 can be resolved by simbad/ned...
galaxy and spiral can be handle by separated services, living their own
live and evolutionary track. Unfortunately, it does not resolve "immediatly"
the nomenclature and parsing problem... I agree.
And may be it is not the good way? Once again... only "my" pov.
> If this is the foundation of this
> list, then please remove me.
Perhaps it's me who must be removed! ;-)
>
> Yes, we shouldn't throw together a list of random concepts and declare
> our work done. So, please
> complain if you don't like my suggestions.
> But isn't the whole point
> of ucd-sci to determine what astronomical
> concepts need to be expressable?
>
>>>> 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 the point is that the original purpose of the observation has been
> expressed.
> Whether it's an image, a spectrum, or simply a number can be extracted
> from all the
> other metadata. If you don't have "obs.calib.dome-flat", then you're
> left with scanning
> the FITS header for OBJECT="DOMEFLT", OBJECT="DFLAT", OBJECT="DOMFLAT",
> OBJECT="FLAT-DOME", ....
Same remarks as above!
all this is related with DM Observation definition and may be utype
will perhaps be of some help?
>
>> 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.
>
>
> Ah, but if I'm looking for a bright GRB in daytime observations,
> knowing that the image
> is an obs.calib.sky-flat makes tremendous difference: it could have
> been an
> obs.calib.dome-flat (which wouldn't be of any use)!
>
>> 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...?
>
>
> Since UCDs can be concatenated, this isn't important: the role of the
> observation has
> been named as a concept - the rest comes from the data and metadata.
>
> A trivial example of how useful this could be would be in a data
> pipeline: if all the images
> had things attached like obs.calib.dome-flat, obs.calib.wl then there
> would be a universal
> and trivial method for determining just what the data are, independent
> of FITS keywords
> and local systems (e.g. ESO.DET.CCD.PAR.TEMP......).
Yes certainly!
But perhaps another organizing way with a UCD defining a data kind and/or purpose
and then the corresponding parameters (not FIELD ;-), so not restricted to VOTable)
can take the desired values.
I don't think that UCD purpose is to solve nomenclature pb or definitions
but I am perhaps (certainly?) wrong.
>
>>> 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.
>
>
> I disagree: the WHOLE point of ucd-sci is to make high-level decisions
> of what is needed scientifically.
> Otherwise, what's the "sci" in ucd-sci for?
>
>>> 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".
>
>
> This is a particularly VOTable-ish view of the VO and of the role of
> UCDs.
I don't catch the point!
> You want to have
> instr.bandwidth in order to identify that the number in a table
or anywhere else!
> is the
> instrumental bandwidth. I want to
> have src.class.galaxy.spiral in order to be able to identify that the
> VOEvent happened next to a spiral
> galaxy. Where's the difference? What one calls "values",
> "attributes" and "parameters" is just
> a question of semantics.
and corresponding level of abstraction.
> Why do I have to use
>
> <concept>spiral galaxy</concept>
>
> rather than src.class.galaxy.spiral but you don't have to use
>
> <concept>instrumental bandwidth</concept>
>
> instead of instr.bandwidth?
From my pov ( once again :-( ), instr.bandwidth is a concept realised in a lot of diff items
(all existing filters) while spiral galaxy is a classification schema realisation.
But I may be wrong, and the usefullness of some usage requires perhaps
the introduction of at least some classification schema!
including MK spectral type for stars?
>
> Rick
>
> ------------------------------------------------------------------------
> ------------------------
> Dr. Frederic V. Hessman Hessman-at-Astro.physik.Uni-Goettingen.DE
> Universitaets-Sternwarte Tel. +49-551-39-5052
> Geismarlandstr. 11 Fax +49-551-39-5043
> 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman
> ------------------------------------------------------------------------
> -------------------------
> MONET: a MOnitoring NEtwork of Telescopes
> http://monet.uni-goettingen.de
> ------------------------------------------------------------------------
> -------------------------
>
--
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/
------------------------------------------------------------------
Seule compte la démarche. Car c'est elle qui dure et non le but
qui n'est qu'illusion du voyageur... Saint Exupery - Citadelle
------------------------------------------------------------------
Received on 2005-06-01Z13:57:20