UCD changes on top of McGlynn's changes

[Thomas McGlynn]

Hi Ed,

Most of this ounds reasonable to me...
Some short (just to show I can do it) comments.
	Tom

Ed Shaya wrote:

...
> I think this is pretty good but it is missing something.  The modifiers 
> are in effect extending the hierarchicial tree of basic concepts into 
> the virtual tree of full concepts.   This is not mentioned and probably 
> should be. But, if it is true then sometimes the order of the modifiers 
> should make a difference.   I don't have an example but I am worried 
> that there will be concepts that require A;B;C and other concepts that 
> are A;C;B but they are not the same.  I don't see how to ensure that 
> that never happens.

I just haven't seen where it happens...  So I'm crossing my fingers!
> --------------------------------------
> Why is there a meas.error and a stat.erro, and one is a concept and one 
> is an attribute?
> Perhaps this was suppose to be a stat:max?
> 
> 1        x1:experimental.quantity;x2:new.modifier;stat.error
> 

Probably just missed it when I introduced the meas tree.

> 
> Why not have a different symbol to separate the attributes from the base 
> and modifiers?
> pos.eq;phys.electron#value;vector
> pos.eq;phys.electron#stat.error;vector

Bob and you both suggested that.  Sounds good to me.  I'd probably
have written the first as just
    pos.eq;phys.electron#vector

> ---------------------------
> 
> Why not allow a namespaced term to reuse existing term?  That is what 
> namespace is for!

Talk to Ray and Sebastien.  I think they feel that it's best
for UCDs to be highly controlled so that namespaces are only
used for experimental terms before they are introduced to the
standard namespace.  Both approaches seem reasonable to me.
> ------------------------------------------------------------
> I don't buy the idea that the main pos is always in the least indented 
> or grouped column.  This is a extremely fragile and restrictive way to 
> go.  There are many ways that the targets are in a  more groups than the 
> plate positions or the guide stars.

I don't want to suggest that one cannot build tables that would break
the proposal.  But I was unable to find a circumstance
where I couldn't use structure to make the main elements clear.
I.e., I'm not trying to cater to every reasonable structure for
tables, but trying to see if the proposal allows sufficient flexibility
for tables to express mainness assuming they are written by friends.
I tried to allude to that with the sense that we'll need templates
for how to use structures.
   What if the target stars have
> position groups
> and so one wants a second grouping of
> 
> <group name="position" ucd="position">
>           <group name="positionEquatorial" ucd="pos.eq">
>                          ra, dec
>          </group>
>          <group name="positionGalactic" ucd="position.galactic">
>                         l,b
>            </group>
> </group>
> or what if the grouping of stars is by cluster or by spectral type or 
> by  accuracy of measurements  etc?

In these examples it would be the responsibility of the
table writer to think about how the table could be written
to express what readers need to know.  If we're allowed the
full flexibility of the VOTable grouping structures, then
we might have the same fields referenced more than once:
near the root so that they are seen to be main, and within some
more nested structures.  This would use the reference capability.
However I'd be interested if we have any actual instances
of tables where this is needed or whether it's something that's
possible but not very likely.

> That is not to say that I like the idea of a main UCD.
> Rather, the best way is to ensure that the structural container of the 
> data has a way of refering the properties to the objects that has these 
> properties.  A quanitty needs to have a isPropertyOf attribute that 
> refers to the object.  So, a positional property column should have 
> isPropertyOf="column(starName)".  The default could be 
> isPropertyOf=column(1).

With references to virtual columns I suspect this is equivalent to
what I suggest, but it might be cleaner.

> ---------------------------------------------------------
> Finally.  I find it curious that this system makes no descrimination 
> between
> properties of objects (color, brightness, distance, size) and objects 
> (electrons,
> atoms, planets, stars, galaxies).  Every time one uses a UCD-property there
> must be implicitly a UCD-object that has been left off.  A brightness is
> always of a star or a planet or a human.  A query system must then be 
> able to
> infer this from other metadata in the dataset. Therefore one needs to 
> ensure that every data set has somewhere atleast one UCD-object.  This 
> will be hard to do if they are
> not somehow separated out  I just wanted to point that out.
> It may or may not be a fatal flaw.
> 
I guess this is what I'm typically indicting as the table UCD. E.g.,
the table UCD is the source, but the column UCDs are the properties
of the sources.