[QUANTITY] and [OBSERVATION] data models: new drafts - comments on Quantity
mchill at dial.pipex.com
Mon May 3 10:58:56 PDT 2004
I confess I hadn't taken a good look at these, partly because (as you are no
doubt tired of hearing) I think making a one-size-fits-all Quantity is a Bad
Thing - almost as bad as trying to get a one-size-fits-one VOTable to fit all.
Ahem :-). Having got that in at the beginning:
Phenomenon: Perhaps a bit more clarity here. Does a 'phenomenon' embrace value,
name, error etc all in one lump? Or is it just the name/identifier of a
property? Can we just call it 'property' if that's the commonly used term?
Value: There's something a bit contradictory about 'value is the core of any
quantity model' and then 'there are use cases ...of context without the value'.
Perhaps we could remove the first sentence :->
Quality: I think you are right to separate this from Accuracy; let's just leave
it as a place holder and *not* handle it as a kind of Accuracy, as this will
make it harder to deal with later.
Coordinates: Are you saying that a Coordinate is a Quantity of quantities? Is
this just a general case of Array Axes? If not, let's leave out the references
Array Axes as it just confuses me! Could we also separate out enumerated
types? Conceptually (to me!) an enumeration is a simple type. There may be
enumerations of Quantities, but it's not clear to me that these should be
4.13 Data Type: I don't understand sufficiently how Quantities and their
internals can be arranged to give the examples at the bottom of the page. Could
this be written more explicitly? eg, how can a Quantity of array of 2 doubles
*not* be of type "array of 2 doubles" ?!
p9 typo: "staring wit" :-)
5 BasicQuantity Model: For clarity, could the diagram list the properties of
BasicQuantity, not the methods? I'd also suggest that BasicQuantity should be
(largely) immutable (ie users cannot arbitrarily change individual properties).
Allowing users of it to change, for example, the coordinate system of an
existing BasicQuantity does not make sense (because either the value was wrong
before, or it will be afterwards), and will cause problems when other users have
a handle on it. Similarly units, and data types. Out of curiosity, why do the
set methods return boolean?
p18-19 - before doing the difficult example, can you include a simple one? So
we can see how a straightforward mapping might work for example? In the more
complex example - what will V1 and V2 represent? ie after all that work, what
are we getting?
7.1 (8) - Can we use XPointer as our referece to other quantities elsewhere in
the XML document?
7.2 (7) - Please no space-separated values. It makes high level parsing more
awkward if some might be space separated and some not - and we're working in XML
so filesize is already not an issue.
7.3 (8) - Positional dependencies like this are bug prone and many standared XML
tools will not 'understand' them. Let's be explicit and use soemthing like this:
7.4 - pedantic point end of para 3; I believe the text should refer to the
'superclass', rather than the owning 'parent', unless I've misunderstood a lot!
In general however I feel the XML shows up one of the problems of using Quantity
to represent data types that are naturally different. We can't, for example,
validate that a quantity is a correct observation.
I don't think we need a 'metadata' section - by this I mean the values should
not be lumped under such a heading. Some quantities will be considered metadata
by some people but not others, so can they not just go in as peer elements?
We could do this if we map our model onto different explicit representations
that are schema validatable. eg (from p25)
<Observer>Johannes H Kepler</Observer>
Cheers, will come back on Observation later...
AstroGrid @ ROE
Tel: +44 7901 55 24 66
More information about the dm