MCT - model document delivery.
francois.bonnarel at astro.unistra.fr
Wed Sep 23 15:16:34 CEST 2020
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
> 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
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
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
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.
> Or do you see another solution to this problem?
> -- Markus
More information about the dm