Entangled Models [Was: MCT - model document delivery.]

[Laurent MICHEL]

Hello,

I totally support the Mark's point of view.
In my message from Sept 17, I insisted on the role of the models which 
is to describe things.

As Mark said, annotating data is one of model uses, we can imagine some 
others such as e.g. designing data views as Obscore did.

In the VO framework, the top level models give formal descriptions of 
specific dataset classes (e.g. Spectrum DM, ...) or processing (SimDM 
Provenance).
These top level models use (or not) component models such as MCT that 
are designed for this purpose.

The question here is to know how to use models for interoperability:
-------------------------------------------------------------------

The answer is rather simple, if a client knows a model, it can process 
any data sets whatever their origins are, as long as they are mapped on 
that model.

The subsidiary question is how to map data sets on one model:
-----------------------------------------------------------
There are different proposals but all with a common 1-1 feature which is 
to map one data-set on one. The idea remains to provide the client with 
anything it needs to re-construct a model instance populated with real data.

This is very important to ensure the interoperability .

If the mapping allows to freely mix components from different models, we 
are pretty sure to miss the interoperability target:

Saying
     "this is a mixture of Energy with a bit of magnitude plus a few
      positions, some URLs and detector positions"

instead of
     "this a spectrum",

is clearly not enough to consider a data set as a spectrum without doing 
assumptions. The role of the models is exactly to avoid clients to do 
assumptions.
This sort of things can already be done with GROUPs furthermore.

LM




Le 30/09/2020 à 19:43, CresitelloDittmar, Mark a écrit :
> Markus,
> 
> Your arguments always seem to boil down to how it will look/work when 
> annotated in a VOTable.
> The models serve a broader audience than that.
> 
> To define isolated models, and then tell providers that
>    * If you annotate model A, you must also annotate to models B and C
>   is
>    * impossible to validate that you have a usable instance of A.
>    * not going to facilitate interoperability very well
> 
> But more importantly, the isolated model approach, especially where 
> Coords/Meas is concerned, goes against the expressed goal/direction that 
> the data model working group has been working toward for over 10 years.
> 
> IVOA Architecture Document: 
> <http://www.ivoa.net/documents/Notes/IVOAArchitecture/20101123/IVOAArchitecture-1.0-20101123.pdf> 
> (2010) - Section 6
>     "Some of the VO Data Models are specific to a type of data 
> collection (e.g. Spectrum DM, SSLDM, ObsCoreDM, ObsProvDM, PhotDM, 
> SimDM), while others (e.g. *STC,* Units, Utypes, CharDM)*are more 
> foundational and are components of the more specific Data Models*. In 
> general, each Data Model can be considered as a building block which can 
> be referred from some other Data Models."
> 
> and reflected in the working group twiki 
> <https://wiki.ivoa.net/twiki/bin/view/IVOA/IvoaDataModel#Standards_and_Documents> model 
> framework diagram since 2011 (I checked the history).
> 
> So, in my opinion, this whole discussion is rather moot, unless the TCG 
> has decided to abandon this direction and the work done toward realizing 
> it, to adopt a different approach.
> I say TCG because the models support the other groups.. and so affects 
> them as well.
> Given this, I will try to refrain from further contributions to this 
> thread.. unless I'm told that we are, in fact, seriously considering a 
> change in approach.
> 
> Mark
> 
> 

-- 
---- English version:
      https://www.deepl.com/

---- Laurent MICHEL              Tel  (33 0) 3 68 85 24 37
      Observatoire de Strasbourg  Fax  (33 0) 3 68 85 24 32
      11 Rue de l'Universite      Mail laurent.michel at astro.unistra.fr
      67000 Strasbourg (France)   Web  http://astro.u-strasbg.fr/~michel
---