[QUANTITY] moving on

[Guy Rixon]

And, to play devil's advocate, we could factor out the inheritence too:

 <IsophotalDiameter" ucd="Pos.diam.isophotal">
   <BandpassName" ucd="em.bandpass">V</Bandpassname>
   <SurfaceBrightness" ucd="flux.sb">
     <Quantity>
       <Value>24</Value>
       <unit>mag/arcsec^2</unit>
       <accuracy nil="true"/>
     </Quantity>
   </SurfaceBrightness>
   <Quantity>
     <Value>3.8</Value>
     <Unit>arcsec</Unit>
   </Quantity>
 </IsophotalDiameter>

in IsophotalDiameter and SurfaceBrightness each have a quantity instead of
being subclasses of Quantity. The Quantity entity is then defined to be
non-recursive.


On Mon, 17 May 2004, Guy Rixon wrote:

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

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