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

[Brian Thomas]

> > 	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 has nothing to do with tomorrow, yesterday or even now,
> nor with dinosaurs or whatever else, it has nothing to do with skillness or
> intelligence but it concern the way we work TOGETHER.

	Are we not working together then?!? The point of our model is
	to present our integrated point of view of how the data model might
	be build from quantities, and what that gains you in terms of the
	functioning of the VO (specifically searching for data/metadata and
	transfer of information).

	The quantity is an atom out of which other documents may be built.
	Its for the community to decide what the important concepts and 
	document structures will be. For example, the VO community could
	adopt to create some 'catalog' document which all data repositories
	should follow. This document would be based on the quantity data
	model and would be easily queryable as its a ridgid structure. Optionally,
	the community could adopt an approach whereby a set of concepts
	are defined, then each repository arranges them so they closely match
	the ordering/structure of their archive. Briding ontologies would be needed
	to translate a universal query into the local catalog structure, but this
	could be done.

	Hopefully you can better see my point of view here. Im trying to provide
	a basic building block from which a number of realities *could* be built.
	I've not tried to specify the whole future, nor ignored the ideas about
	quantities that the community, and I, have already publically discussed.
	Rather Ed and I have tried to integrate them together to give a robust
	basic model.
	
> Data structure concerning hyperspectral data, complex radio data
> or other domains are certainly not yet integrated in VO.
> Things will not be separated but conceived jointly, perhaps by two diff.
> groups even not containing the same people. Every body can not do or be
> implied in every thing, so keeping domain separated, but with intrefaces is
> the goal of DM.

	I guess I disagree. These complex data types, if looked at as a whole, have
	many commonalities. Why not try to leverage these to make a simpler, more
	robust and powerfull data model?

 The general study and the glu is forseen to be the global
> view on data [OBSERVATION] on which I tried to initiate a discussion
> (http://www.ivoa.net/forum/dm/0061.htm,
> http://www.ivoa.net/forum/dm/0107.htm). There I tried to introduce one
> major aspect at least for VO, concerning data tracability and history,
> which must be introduces at the root (or top depend on the kind of diag you
> draw) of the design.

	Traceabilty and history are important but Im not sure they belong in the
	basic data model. Rather these are concepts which are created out of
	the quantity, and inserted in some kind of structure that the community
	wants to pass around, for example, VO:Table or VO:Image (which are 
	concepts too.. just complex ones build, again, from the basic quanity DM).

>
> > 	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?
>
> Why linking things in ONE BIG TOOL FOR EVERY THING,
> where certainly reusability will be difficult if not impossible.

	I disagree that designers cant see the big picture, nor that
	a general purpose, reusable tool is impossible to create.

> > > 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.
>
> NO! you need only the interface class or even the class interface!

	I disagree with the premise that we should be passing around 'interfaces'
	in the programming sense.. e.g. a Java interface or C++ class. These are
	no more exact than using UML or ontological diagrams which give a broader 
	sense of what is happening, and what information is related to what.

> > 	Data format is simply how you store/reference the data. We agree with
> > you that
>
> SIMPLY?

	Yes. Simply. What is your point here?

>
> > 	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
>
> I am fine with that, but some people (one of them beeing clive Page if I am
> not missing something http://www.ivoa.net/forum/dm/0086.htm)
> saw in quantity a more primordial thing (like value + error) immediatly
> usable.

	Im not sure we really differ. We see quantity as a basic atom out of which
	concepts, simple or complex, might be built. 

> How many of us are familiar with ontology and his specific diag. Even less
> than the one familiar with UML diag... so try to speek to the largest
> audience possible, and even the one willing to read UML diag is not
> sufficient to integrate all needed inputs and we certainly needs
> additional translation/explanation to agregate all
> info/metadata/ontology...

	Im not sure how to answer this. UML is used by modern software designers
	and has shown to be very effective in communicating complex ideas in software.
	The same could be said for Ontologies to show the relationship between information/ideas.
	They both seem the best vehicle for most precise, but  quick communication of 
	our ideas. But I understand that not all information can go into either of these, so
	I wrote the writepaper with Ed. Perhaps some things you find confusing may be cleared
	up by taking a look at it.


> I hope that my english is at least understandable.
> See you perhaps at VO meeting,

	Your english is fine.

	I would very much like to talk with you too. I think, perhaps Im wrong, that we 
	really arent that far apart. Please seek me out if I dont find you first.


				Regards,

					-b.t.

> sincerely yours,
> 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
> ---------------------------------------------------------------------------
>----

-- 

  * Dr. Brian Thomas 

  * Code 630.1 
  * Goddard Space Flight Center NASA

  *   fax: (301) 286-1775
  * phone: (301) 286-6128