[QUANTITY] moving on

[Guy Rixon]

On Thu, 13 May 2004, Jonathan McDowell wrote:

>
> [...]
> In the Quantity approach  I
> propose we would store the bandpass and SB as metadata BasicQs within
> the diameter Q, and rely on a generic rule to say that two Qs are
> equivalent if they have the same UCD *and* if their metadata agree in
> value.
>
> <Quantity name="IsophotalDiameter" ucd="Pos.diam.isophotal">
>  <Quantity name="Bandpass" ucd="em.bandpass">V</Quantity>
>  <Quantity name="SurfaceBrightness" ucd="flux.sb" unit="mag/arcsec^2">24</Quantity>
>  <Value>3.8</Value>
> </Quantity>

When Utype was introduced to VOTable at the Strasbourg meeting, it was
claimed to be a necessary alternative to UCDs.  The argument went something
like "UCDs are fuzzy; UCDs are for humans; machines need something more
precise in order to understand (meta)data; Utypes are separate from UCDs and
support machine understanding; Utypes are references into the data model".

Johnathan's structure above doesn't seem to fit this description. The
schema-defined content of Quantity includes aritrary other quantities and
doesn't seem to guarantee that a bandpass and surface-brightness Q will be
included; therefore the isophotal-diameter thing isn't really defined by the
model.   If the necessary bits _are_ included, then the only way for s/w to
find them is to look up the UCDs.  So Utype is different from UCDs because it
depends on data model which depends on UCDs.  We've got lost somewhere...

I _think_ that if our data structures are all <Quantity ucd="..."...> then we
need something like XPath to recognise each one: //Quantity[@ucd="..."] . It
would be hard to recognise a bit of data model with SAX, say: you'd need to
detect Quantity and then have a vast switch statement in the callback, listing
all the UCDs, in order to find what it really was.

If we use JAXB or similar on a data model made of these Qs, then we'd get one
class Quantity with a property "ucd". We wouldn't be able to add much
behaviour as the class would be so general. Programmers would immediately
subclass Quantity in order to have somewhere to put phenomenon-specific
behaviour...

...which suggest that we should subclass Quantity in the data model.  I would
first refactor Johnathan's code as

<IsophotalDiameter" ucd="Pos.diam.isophotal">
  <Bandpass" ucd="em.bandpass">V</Quantity>
  <SurfaceBrightness" ucd="flux.sb" unit="mag/arcsec^2">24</Quantity>
  <Value>3.8</Value>
</IsophotalDiameter>

in which IsophotalDiameter, Bandpass and SurfaceBrightness are subclasses of
Quantity; they are types-formed-by-restriction in XML. I'd make Bandpass and
SurfaceBrightness mandatory but nillable, since I think that better expresses
unknown values than leaving out the elements.

We now have specific entities to drive the parsing and binding, but we still
have Quantity aspects when we want to do maths on the entities.

Second, I'd eliminate the mixed content:

<IsophotalDiameter" ucd="Pos.diam.isophotal">
  <Bandpass" ucd="em.bandpass">
    <Value>V</Value>
  </Bandpass>
  <SurfaceBrightness" ucd="flux.sb" unit="mag/arcsec^2">
    <Value>24</Value>
  </SurfaceBrightness>
  <Value>3.8</Value>
</IsophotalDiameter>

I'm guessing that mixed content model makes it harder to parse.

Thirdly, I'd make Bandpass something other than a subclass of Quantity, since
it's clearly not numeric as used here. Quality = string + ucd attribute,
maybe?

Finally, I'd put in the missing accuracy metadata (or nil them out), and make
sure that the schema required these to be present or nil'd.

Guy Rixon 				        gtr at ast.cam.ac.uk
Institute of Astronomy   	                Tel: +44-1223-337542
Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523