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

From: Miguel Cerviņo <mcs-at-iaa.es>
Date: Thu, 2 Jun 2005 10:48:01 +0200


Hello all,

I give you my opinion in the present discussion from a naif point of view :)

Something that has been rounding my mind when I think about UCDs is how much "detailed" it must be and what are the implications for others "fields" (I mean, value, units, datatype, etc...) in a "param" tag. I post some cases and latter my opinion below.

         <param ucd="phot.mag" value="12.3" />

     Implies that this UCD has a value with datatype="float". It means that only in cases

     where it will be ambiguity the datatype should be defined?

          obs.image.uncalibrated that defines by itself a property of the image, what would be the

              "value" in that case? Yes, No?
         src.class.galaxy.spiral is a similar situation.

         phy.abund.X means implicitly abundance by mass or by number? It has sense phys.abund.X.byMass?

         Would a UDC distinguish between log Luminosity or Luminosity? (phot.flux and pho.mag have sense if

         this distinction is the work to do by the UCD; they are redundant if such a work must be done by "units")

Well, now comes my point of view:

I think that UDCs words are only valid if they do imply NO inference in the other possible "fileds", a ucd-tag have sense only as a complement of "value" or "datatype" fields (sometimes also units etc..., I am not compltly sure about "name")

  As an example which would be the UDC in a VOtable with this line:

       <description>My Eliptical (E0) galaxies</description>
       <field ucd="..." datatype="character*" name="Galaxy name">
            ...........

     ??

In this case I am not sure it it would be required an UDC of It would more useful a line with
<PARAM ucd="gal.sp" dataype="char" value="Elliptical">

Any casee I aggre that there is a problem in how the "value" is spelling (Elliptical, E0,....) that would difficult any direct search, I think that it is a un-soluble problem: Each astronomer/VO developer etc has their own
preferences (that is great, by the way).... and any machine program will have the preferences of its "owner" etc...

Summing up. If we agree that every possible "field" in a "tag" must do their own job, I think that the UCDs definition becomes more simple (and in some way most useful)..... I do not know.... but maybe asked to each UCDs which range of values they my have would be useful....

Now, for practical issues :)
I think that most of the discussion has been focus in the UCD "length": Or, UCD words-like vs. UCD-sentence-like. Here comes My suggestion.

May be we can began in an atomized way:

    1- Are all the "1st-atoms" in the list valid? (or it is needed more?, or less?)

    2- Are the present words that contain two atoms valid?

            .........

In this case, I think, most of the present discussion would be related with the lower levels (words with many atoms), and whatever the final result we will have at least a list of really valid words :)

     cheers

         Miguel Received on 2005-06-02Z10:48:06