ImageDM: what does extension mean?

[Mireille Louys]

Dear all ,
my comments below.
Mireille.
On 29/10/2013 17:26, CresitelloDittmar, Mark wrote:
>
> On Fri, Oct 25, 2013 at 12:57 PM, Ray Plante <rplante at illinois.edu 
> <mailto:rplante at illinois.edu>> wrote:
>
>
>     My question is, what does it mean technically for ImageDM to "extend"
>     ObsCore?
>
>     One result we might expect is that the ImageDM would not be explicitly
>     "re-defining" the ObsCore metadata and UTypes; rather it would point
>     to the ObsCore document for its definition.  Is there more to it,
>     though?  Is there something implied about the structure of UML models?
>     How about serializations?  Should a client that is only ObsCore-aware
>     be able to interpret the ObsCore portion of an ImageDM serialization?
>     What does it mean for how we define the extension metadata?
>
>
> In my opinion, this is the way to go.
> The composite models (Image, Spectral) should 'refer' to the component 
> models.
> They can include summary or semantic details, but should defer to the 
> original
> for definition and detail.  This reduces the 'bloat' in models and 
> these small variations
> we are struggling with due to migrations and 'simplifications'.
>
I fully agree .
We just need to be aware that the definitions of classes and attributes 
in the Obscore specification are oriented oriented towards generic data 
discovery , and that specific constraints were set on some attributes 
values , e.g.  spectral bounds values in units=meter.
Image DM should reuse the classes without the constraints, and if 
necessary specify its own use restriction.


> For the ObsCore extension, there are some details at the top level which
> need to be resolved (see the 'Convergence' thread). But this question 
> brings
> up a good point w.r.t. serialization.  Serializations include the 
> model 'prefix'.
> For ObsCore serializations, this is 'obs'?, other models will have a 
> different
> prefix.  Optimally, an ObsCore aware application should be able to 
> ignore the
> prefix and recognize the content.  This would probably work, but only 
> because
> it is a TOP level model.
>
> This is similar to discussions which went on for lower level objects, 
> where the
> practice of combining utype strings make it impossible for a generic 
> utility
> to identify the axes (for example) within a model an plot them.
>
More precisely , are you addressing here the problem of ObservableAxis 
vs FluxAxis?
> Mark
thanks, Mireille

-- 
--------------------------------------------------------------
Mireille LOUYS          mailto: mireille.louys at unistra.fr
                                       
L S I I T                       &     CDS,
Ecole Nationale Superieure            Observatoire de Strasbourg
de Physique de Strasbourg,            11, Rue de l'Universite
Boulevard Sébastien Brant, BP 10413   67000 STRASBOURG
67412 ILLKIRCH Cedex       	      Tel: +33 3 68 85 24 34
---------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dm/attachments/20131030/ff8aa04a/attachment.html>