[QUANTITY] and [OBSERVATION] data models: new drafts - comments on Quantity

Martin Hill 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 
Quantities themselves.

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:

<quantity>
    <array>
       <values axes="y">
         <values axes="x">
           <value>A</value>
           <value>B</value>
           <value>C</value>
         </values>
           <value>D</value>
           <value>E</value>
           <value>F</value>
         </value>
       </value>
     </array>
  </quantity>

or similar

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>

or:

<Photometry ucd="phot.opt">
    <Observer>Alex Szalay</Observer>
    <Exposure>
         <units>s</units>
         <float/>
         <value>1480.2</value>
    <Exposure>
    <Instrument>
        <ChipIDs>
           <value>2</value>
           <value>7</value>
           <value>9</value>
        <ChipIDs>
    </Instrument>
etc?

Cheers, will come back on Observation later...

Thanks!

Martin

-- 
Martin Hill
Software Engineer
AstroGrid @ ROE
Tel: +44 7901 55 24 66
www.astrogrid.org




More information about the dm mailing list