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
Received on 2003-10-22Z18:38:35