ImageDM: what does extension mean?

[François Bonnarel]

Hi all,
    Like Ray I also agree with this approach

    Any kind of representation doesn't prevent us to think what amount 
of metadata we need for our various use cases:
       data discovery, description, and all the stuff needed for 
interpretation and processing.
    Let's then organize it with classes, association roles and attributes.
Cheers
François

Le 30/10/2013 12:42, Mireille Louys a écrit :
> Dear Ray , Dear all,
>
>
> On 25/10/2013 18:57, Ray Plante wrote:
>> Hi DMers,
>>
>> If you were at the IVOA Interop meeting, then you know that image cube
>> access was a big topic, and the ImageDM is one of the key standards
>> targetted to support it.  We also resolved to get greater
>> participation in and discussion of these specs going forward, and I
>> was hoping I might inspire a bit of that with a question about
>> ImageDM.
>>
>> At the Interop, there was a resolution to make the ImageDM be an
>> extension of ObsCore.  The purpose of this is to provide greater
>> interoperability SIAv2 and ObsTAP:  that is, you might discover data
>> cubes with either one, and you're query results would be based on a
>> common data model.
>>
>> 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?
> The work is to be done at the level of the definition of the classes: 
> the core Classes already defined in ObsCore , the particular classes 
> necessary to cover Image and cubes descriptions.
> The design work and definition is at the level of classes and UML .
> VOdml and Utype strings , old style or new style are only derivations 
> of this logical human brain elaboration.
>
> From my point of view we need : UML graphs (as started by Mark) and 
> description text to clarify the goal, scope and details of the classes.
> from this we can derive :
> - the VO-DML representation of these models providing an XML document 
> encoding the models
> - a utype list derived from this XML representation
>
> The argument a la "ancients against moderns" about utype syntax should 
> not prevent us to do good job in object oriented design , that is at 
> the UML level.
> Note that from a VO-DML data model file : PhotDM.xsd , or another DM, 
> VO-urp the precursor of VO-DML , used to extract full xpath Utypes.
>
> Let's resolve the classes re-use first and then adjust the Utypes 
> syntax with the benefits of the two approaches in a second run.
>
> Cheers , Mireille
>