[QUANTITY]Re: Quantity.owl

[DIDELON Pierre]

> From Edward.J.Shaya.1 at gsfc.nasa.gov Thu Oct  9 20:55:10 2003
> 
> DIDELON Pierre wrote:
> 
> >Hi,
> >
> >is this the simple quantity class/concept that Ray want to subclass?
> >I must admit I am afraid, and for me it seems more related to
> >the analysis of a global structure concerning the more general
> >concept of VOData, related to [OBSERVATIONS] theme.
> >  
> >
> There was indeed a choice to be made on the design of this.  We could 
> have started with a very simple Quantity, ie very few attributes 
> (properties in OWL) and then subclass these with more fully featured 
> specialized Quantities.  For example start with a Quanitity that can 
> only be single valued and has no error and no units.  Then subclass this 
> into an Array and then into ArraywithError and then to 
> ArraywithErrorandUnits, etc.  So one builds things up slowly so one can 
> associate specific astronomical UCD with specific QuantityTypes.
> 
> The other way is to create a fully featured Quantity and then, as 
> needed, one defines subclasses as restrictions on the general case.  For 
> instance a VectorQuantity can be defined as a Quantity that takes a 
> DataFormat of VectorDeclaration  only.  Then each of its components are 
> ScalarQuantities which can take DataFormat of Float only.
> 
I Feel that the scope of Quantity working group is to deal with Quantity,
Units and Accuracy (I prefer this more general concept than Error
which can be misleading) and eventually with related things; 
QuantitySet, Index...(a propos what is the meaning of mapping? 
does it have relations with [TRANSFORMATIONS])
But everything concerning data structure, format or representation
is out of the scope. It needs only to handle a pointer (like your
"hasValues") to a package handling all these pb, related to the more 
general concept of a general VOformat for data. Only the interface 
needs to be defined.

I feel very unconfortable to mix all in one (see
http://www.ivoa.net/forum/dm/0111.htm) and  would prefer to 
formalise the separation between structure format and data  (see 
http://www.ivoa.net/twiki/bin/view/IVOA/IVOADMObservationsWP/data.ps
announce in http://www.ivoa.net/forum/dm/0111.htm).
So can we let the pb of structure and format aside for the moment.

> >
> >Marginally; repeating data member inhereted from the parent class
> >overload the schema without bringing in any add. information.  
> >
> Are you referring to QuantitySet? 

But also to the format presentation.
In UML it is more or less expected that the data member inherited from
the parent class are not repeated in the child (for clarity and class
behavior definition). It disturb me a lot to see IdRef, name, Id,
description and hasProperty repeated everywhere. 

Moreover I don't understand why all relations/associations
are materialised in the class with a corresponding data member.
Does it means something more than the UML association concept?
For example, why do we have  hasAccuracy link between
Quantity an Accuracy and hasAccuracy data member in Quantity,
does they cover diff. things/concepts?

 
> We have the particular case that a 
> Quantity (say a density map) will be a data hypercube with Argument 
> Quantities (x,y,z say) and a QuantitySet (say a table) is also a 
> dataCube with Argument Quantities (row, column, perhaps a 3 dimension).  
> So it makes sense for the Set of Quantities to be a Quantity itself.  
> Perhaps QuantitySet should
> inherit from a VO:Set and a QuantityType to make this clearer.  However, 
> you make a good point in that the QuantitySet is not exactly like a 
> Quantity because it does not make sense to put Units or Values on it, so 
> perhaps Quantity and QuantitySet should inherit from a QuantityType 
> without those things.  I will make this change.
> 
> >--
> >Pierre
> >-------------------------------------------------------------------------------
> >DIDELON                               e-mail : pdidelon_at_cea.fr
> >CEA SACLAY - Service d'Astrophysique  W3 : http://www-dapnia.cea.fr/Sap/
> >91191 Gif-Sur-Yvette Cedex            Phone : 33 (0)1 69 08 58 89
> >-------------------------------------------------------------------------------
> >
> >
> >
> >  
> >
> 
> 
>