Revised ImageDM-ObsCore architecture

[François Bonnarel]

Hi all,
Le 14/11/2013 17:27, CresitelloDittmar, Mark a écrit :
> All,
>
> Such uniform agreement!
>
> I'd like to summarize what I think I'm hearing.
>
> 1)  The diagram illustrates the state of the relationships "as they 
> are", with Spectral/Image using an Observation model which is an 
> extension of the ObsCore model recommendation.  This is so, because 
> the ObsCore model does not define the larger Observation model to 
> which it refers.
>
Yes, but as Mireille stated yesterday Char in Spectral and Image should 
also be extensions of Char in OBscore.
> 2) There is another diagram to be done, which is the relationships "as 
> they should be".
>     This would:
>     a) be an update/replacement of the ObsCore REC
Probably the list of individual attributes will not change. Only some 
little changes in the names and the low level classes they belong to. 
This for better consistency.
When I speak of attributes names I really speak of attributes names in 
the UML (and hence from the utypes whatever representation we adopt 
eventually), not about the column names in the TAP Schema which will 
remain unchanged I guess
>     b) be a separate effort from what we are doing now with Image/Spectral
>     c) modify the relationships as follows
>         - make the Left box "ObservationDM" the primary Observation 
> model..
>           i.e. ObservationDataset becomes Observation
>         - the associations to Char and the Provenance classes would 
> relocate to that class.
Yes but Obscore in that case only has a partial view of Char and a very 
partial view of Provenance. This is fine but probably had to be 
explicitly written.
>         - ?? Not sure about "Access"
>         - ObsCore would be described as a 'view', or subset, of this 
> model, specifically in support of ObsTap.
>           (it is already described as that, but I mean formally modeled).
Ok, fine.
>     Doing so would not change the content of ObsCore at all, merely 
> the representation, and would provide a larger Observation model to 
> support other use cases.
>
> 3) It is clear that there is a relationship between "Observation" and 
> a more generic "Dataset".  This "Dataset" would contain elements such 
> as the dataProductType, and dataProductSubtype, presumably others.  
> This object has not been formally defined.  There is an implied 
> relationship to Observation as an Extension of Dataset in the location 
> of these attributes.  So, I have always interpreted that Observation 
> "is" a Dataset.  This is reflected in my choice of the name 
> "ObservationDataset" in the left hand package of my diagram.  It 
> implies that it is a Dataset extendend for Observation purposes.
>
> Recent discussion brings this relationship into question, with 
> assertions that an Observation can be associated with 0 or more Datasets.
> I think this warrants some discussion as it effects the Image/Spectral 
> model content.  I'd like to start a thread on that topic.
>
Observation can be simple (one dataset) or composed/complex (several 
datasets). I understand that a Dataset can also be made by compoosition 
of several different observations. So the whole landscape is probably a 
n to n relationship.
> 4) There is a bit of confusion about "Provenance", which we should 
> make a statement about.
>     I'll start a thread on that too.
>
I agree with people who say that Provenance is a model in itself. There 
has been a lot of attempts to propose mechanisms to describe observation 
configuration, observation ambiant conditions and processings "freely" 
discussed in all recent IVOA meetings (not in Hawai, but in Heidelberg, 
Sao Paulo, Urbana, etc ...)

Best regards
François
> Mark
>
>