Philosophy of design for Q : yes, a common structure is appropriate and possible. (Was: Re: [QUANTITY] Data Model for Quantity v0.5
brian.thomas at gsfc.nasa.gov
Tue May 11 09:06:07 PDT 2004
On Tuesday 11 May 2004 06:30 am, Martin @ ROE wrote:
> Jonathan McDowell wrote:
> > Martin, at 1538 UTC Monday:
> > In your other message you claim that you don't want the class describing
> > fluxes to be related to the class describing shoes. That's our
> > fundamental disagreement, I firmly believe that a common container class
> > is a very useful thing to promote interoperability.
> Yes sounds like a fundamental disagreement! Rather perversly, common
> container classes make it harder not easier to build anything but the
> simplest subclasses. You can see this already because it seems that all
> the contained objects (Accuracy, etc) are becoming 'optional'. This
> makes it impossible to model subclasses (such as 'Flux') properly
> because we can't describe what is required and what isn't.
In a general CS design sense this may be true, but we are modeling scientific
data here with the Quantity. This is something with a structure that has been
developed over at least 500 years, and has been used extensively and that
is very well understood.
The use of scientific data in computers goes back at least 50 years (and
you might be able to argue further back, even to the limit of Babbage etal
which would make it ~150 years). So we aren't just dreaming up any old
structure here for programming uses.
I think its fairly clear that scientific data, used in computing, have the
following core structure/properties without which, it just isn't scientific
= one or more values
= a data type (scalar:[int/float/string] or vector/tuple)
= units (including "unitless")
= accuracy (measured errors, bin width, resolution, quality flags, etc)
including the statement that it "has no accuracy" (often implied but
rarely explicitly stated) or is "defined, no accuracy is appropriate".
Furthermore, you can extend this basic model to include handling of
equivalent phenomena (flux <==> magnitude) and coordinate systems.
This is the scope, and basis, of the quantity. I really don't understand
how this is controversial at all. It would be amazing to me if a
scientific programmer *couldn't* use this model (as outlined above) as
the basis for the scientific data in their structures.
I also don't accept the argument that the Q is too broad. The example,
that you give of subclassing (flux property needs a restriction) doesn't
make sense (no accuracy for flux??), but lets say that you are making
the statement as a general purpose one.. e.g. the need to create sub-classed
phenomena from Q which are restricted. This *is* possible. In the
schema, you create a "restriction" element (see my example CoordSystem.xsd
for how to do this) and in your API, you either return an empty object,
a null or throw an error when the get/set methods are called (choice depending on
the method and how we as a group wish to proceed on that matter as a standard;
I see no problem that "MethodNotAllowedException" can be thrown from some
of the methods in the interface).
> For interoperability we need to describe *representation*, and we need
> to describe *structure*. It doesn't matter if one service has a Flux
> object subclassed from Quantity and another service has a Flux object
> subclassed from Banana, as long as:
> 1) The representation can be shared
Certainly, you create an interface called "Flux" for your sub-class. Then
the broadness of the Q isn't even a factor as you only see the object
as "Flux" and the methods allowed by that interface. Those Q methods
that return nulls (or throw errors or etc) are unseen and unused by your code.
This is probably the correct long term solution for those components of the higher
level DM that inherit from Q , but don't want to expose certain functionality provided
by the Q as a general rule. Is this not a workable compromise?
* Dr. Brian Thomas
* Dept of Astronomy/University of Maryland-College Park
* Code 630.1/Goddard Space Flight Center-NASA
* fax: (301) 286-1775
* phone: (301) 286-6128 [GSFC]
(301) 405-2312 [UMD]
More information about the dm