UCD changes on top of McGlynn's changes

[Ed Shaya]

I have made numerous tracked changes in the 1-9.9b of McGlynn and 
created a 1-9.9c.
So if one has a recent version of Word one can accept or reject these 
changes as seen fit. I think someone will need to post this to the UCD 
and dal lists cause I am not on them. Here are some "highlights"
--------------------------------------------------------------------------

The term property was used in a confusing manner.  Everything was at 
some point in the specification referred to as a property including the 
basic concept as well as the attribute and modifier.  So, I changed  
attribute property to attribute and modifier property to modifier.

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.
------------------------------------------------------------
Word and atom were a bit confused. Atoms looked like words to me and 
Words were
clearly composed of several words (not good).  There was no atom in the 
Backus-Naur notation. But there were examples of atoms of the physics 
type (yikes).
So I made the following simplification.
atom -> word
word -> term
word-component -> word

-----------------------------------
I changed a few occurrence of "column" to "contents" so that it did not 
seem that this
was for tables only.  And so the Contents in "UCD" would be meaningful.
--------------------------------------
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


----------------------------------------------------

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
This is clearer.  It says, if you are looking for instances of the 
concept  of a positional measure of electrons, here it is.  By the way 
it is in vector format and there is an error associate with it, you  may 
need to transform this format.  Queries will be keying on the concept 
and so it should be cleanly separated.  If the query finds additional 
attribute information  it may  grab them  for completeness even if they 
were not specificied in the query.

---------------------------

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


1        phot.flux;x1:meas.error       Namespace reuses existing 
term--------------------------
In the Group of pos.eq.ra and pos.eq.dec the UCD of the group should be 
pos.eq, not pos.instance.  The "eq" is there because one should be as 
specifying as possible.  The instance should not be there since this is 
a table level term and is redundant here.
------------------------------------------------------------
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.  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?
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). 

---------------------------------------------------------
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.

Ed

 
               

 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: UCD-1.9.9c.doc
Type: application/msword
Size: 387584 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/dal/attachments/20031022/205dbe03/attachment-0001.doc>