Answers to questions/issues you raise & white paper (Was: Re: [QUANTITY]Re: Quantity.owl)
DIDELON Pierre
dide at discovery.saclay.cea.fr
Fri Oct 10 09:04:32 PDT 2003
> From brian.thomas at gsfc.nasa.gov Fri Oct 10 14:33:31 2003
> From: Brian Thomas <brian.thomas at gsfc.nasa.gov>
> To: DIDELON Pierre <dide at discovery.saclay.cea.fr>
> Subject: Answers to questions/issues you raise & white paper (Was: Re: [QUANTITY]Re: Quantity.owl)
> Date: Fri, 10 Oct 2003 08:40:08 -0400
> User-Agent: KMail/1.5
> Cc: dm at ivoa.net
>
> 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 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.
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.
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.
>
> 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.
>
> 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.
That's fine.
>
> > 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!
>
> Data format is simply how you store/reference the data. We agree with you that
SIMPLY?
> 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.
> 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.
>
We need also aside winning strategies, immediat functionalities, concerning small
blocs/stones and operationnal scenario playing with these small utilities.
> > >
> > > 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
Are people in charge of registry in agreement with that?
Whatever can be the verbosity of whatever data model conceived?
> 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)
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...
>
> Regards,
>
>
> -b.t.
>
I hope that my english is at least understandable.
See you perhaps at VO meeting,
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
-------------------------------------------------------------------------------
More information about the dm
mailing list