Philosophy of design for Q : yes, a common structure is appropriate and possible. (Was: Re: [QUANTITY] Data Model for Quantity v0.5

[Brian Thomas]

On Tuesday 11 May 2004 06:30 am, Martin @ ROE wrote:
> Jonathan McDowell wrote:
> > Martin, at 1538 UTC Monday:
> 
> [snip]
>
> > 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
	data :

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

	Regards,

	=b.t.

-- 

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