Answers to questions/issues you raise & white paper (Was: Re: [QUANTITY]Re: Quantity.owl)

[Brian Thomas]

On Friday 10 October 2003 03:57 am, DIDELON Pierre wrote:
> > From Edward.J.Shaya.1 at gsfc.nasa.gov Thu Oct  9 20:55:10 2003
> > [snip]
>
> 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])

	I think in order to to create real working solutions you cant develop
	in an isolated box. Just because yesterday's insight was to keep
	certain things separated doesnt mean that it is the right way to do
	it today.

	It appeared to us that a number of threads between quantities, 
	transformations, meta-data could be tied together. Why not state so?
	 If not now, when?

	Nevertheless, we havent given any specifics in our model as to
	how the *internal* storage of the data should be. The interface is all
	that is being defined (for the moment). As for mapping, that is a 
	connection between the model and its forseen relationship to transformation.
	But we havent given any specifics here either other than to suggest
	how they might be related. 

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

	Data structure is directly related to the model, it must be specified,
	even in an 'inteface only' type of design you need to show how the
	classes relate to one another. 

	Data format is simply how you store/reference the data. We agree with you that
	a pointer may be used (we use the XML term "href") that locates a 
	resource and we have suggested some meta-data that might be needed 
	for this in the "data" class. We forsee that the data model should both
	hold data on its own and be able to wrap local files/data bases as well
	much in the way XDF can. Binary data should also be supported. But
	we havent done this work (although it would pretty trival for me to put
	the XDF code in place), again, its in our model to show what can be
	done.

	So, in summary to the gist of this section of comments, we have spent
	the majority of our time defining an interface. Its fleshed out in terms of
	the ontology, but also the theory of how we see the quantity class operating
	as a whole in theory. There is a white paper, which while not all the symbols
	from star office appear to want to translate to MS/HTML, is available here:

	http://nvo.gsfc.nasa.gov/QuantityDataModel	(QuantityDataModelPaper.html)

	If you have open office 1.0+ its best to read the .sxw document. I will
	bring hard copies to the ADASS for those who may want them.
 
>
> 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.

	I disagree. These things have to come together at some point. Keeping
	your eyes only on the horizon, _or_ only on whats immediately in front
	of you are both losing strategies for design. How you can actually 
	create something in software will impact the theory and vice-versa.

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

	Thats simply the way Ed's ontology tool protege works. Its not a 
	big deal I think. Id/Idref are needed in order to produce a reasonable
	XML represenation of the model. Now, you may argue that this isnt
	needed, but I disagree. Ultimately, we (at least) feel the data model
	*is* the format of exchange between the data repositories. That 
	exchange will most likely take place in XML, hence the XML 
	meta-data.


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

	I think you are confusing the UML notation with that of an ontology
	which differ slightly. I originally prepared some UML diagrams from 
	which Ed made the ontology. You may find this more helpfull, I refer 
	you to the paper online for the easiest look at them, e.g.

	http://nvo.gsfc.nasa.gov/QuantityDataModel/paper.html

	(look in appendix 2)

			Regards,


				-b.t.