MCT - model document delivery.

[François Bonnarel]

Dear Markus

Le 22/09/2020 à 22:09, Markus Demleitner a écrit :
> Dear François,
>
> before I'm off to a few days of vacation...
>
> On Tue, Sep 22, 2020 at 06:24:56PM +0200, François Bonnarel wrote:
>>                   But  to go a little further if we want to introduce a time
>> or spectral "support" made of a list of intervals beside the coarse-grained
>> "bounds" : em_min/em_max, t_min/t_max we will end with a lot of spectral
>> coordinates and time slots which only a structured datamodel can allow to
>> describe.
> I'd still say the options I showed the other day would let us
> disentangle the data models even in this stuation (and we can reflect
> that on the model level, too),

As far as I understood in your serialization , for a given FIELD the 
client has to check all the "annotation features" refering to it, which 
may become complex and does not provide a unified view of the 
succession  of intervals (exempli gratia)


>   but be that as it may:
>
>>                  Any annotation would have to map this complex structuration
>> of the (meta)data.
> Does this mean you are arguing that we will just have to deal with
> the fact that we can never have a new major version on the
> fundamental data models without pushing up everything else up another
> major version, they way things ended up in Registry (see my other
> mail)?

For the model itself and its vodml derscription : yes.

For the serializations it depends :

if we fully serialize instances form scratch and populate them from some 
data processing, each version of the model would have to be reflected in 
a new serialisation. But this would be the case for any kind of data 
model also outside IVOA or astronomy.

If we are annotating existing datasets (existing tables for example) I 
think any annotation mechanism should be in a separated block. In the 
case of "ModelInstanceInVot" changes in one version of the model will 
not affect the data and will affect only some parts of the annotation 
block.

I think in a GROUP/utypes based annotation it would be the same as long 
as the utypes are set on  the GROUPs FIELDrefs and not added in the  
original data.

In the case of Obscore extension it could be an intermediate situation 
because the actual list of FIELDS is fixed by the model but the external 
annoation could be added to highlight the complexity of the structure.

Cheers

François

>
> Or do you see another solution to this problem?
>
>         -- Markus