Revised ImageDM-ObsCore architecture

[Douglas Tody]

Hi Omar -

I am not suggesting that this is all about Utypes or that we don't need
a formal class hierarchy as the basis for the data model.  I suggest
that what I posted over the weekend is a valid, even simple, data model
architecture basing Image on Observation as we agreed to do in the
interop.  Have you actually look at this?

While a data model is more than just Utypes, we do have a problem with
Utypes in the current ObsCore/ImageDM/SpectralDM/Char2.  The problem is
relatively minor (e.g., "Calib" vs "Calibration", Coord as an array
value vs separated .C1, and .C2 attributes, and the like), however it
will require an update to ObsCore synchronized with Image/Spectral to
fix the problem.  Otherwise we will have to propagate stuff from ObsCore
1.0 which the authors now agree is invalid.

I don't have any problem with proceeding with (or at least
investigating) a more rigorous approach based upon VO-DML - what Gerard
posted earlier was quite promising.  However I doubt very much if we can
complete that this week, and we need a stable update to the ImageDM by
the end of the week (or at least end of Nov at the latest) to support
cube project development.

The main thing is that the data model *architecture* must not change
greatly.  Hence if we really want to integrate Image/Spectral and
Observation (Image formally extending Observation as agreed in the
interop) then we need a usable first cut at that *now*.  Some changes at
the detail level are ok next spring or summer so long as the basic
architecture is established now.  We are very close at this point.  Yes,
it does require more extensive changes - that is why we did not propose
it earlier.  But the IVOA consensus to move in this direction was very
clear.

 	- Doug


On Tue, 12 Nov 2013, Laurino, Omar wrote:
>> The consensus earlier is that an update to ObsCore *is* required, as
>> there are issues with a number of the Utypes in that version of the
>> model.
>
> No, no, and no :)
>
> You fix the model if you need to fix the model. And models are not list of
> UTYPEs.
> Ergo, you don't fix a model if you don't like the UTYPEs. And we don't
> "model by UTYPEs" anymore.
> That's the consensus.
>
> On the other hand, if what you are saying is true, you are suggesting that
> we *need* to redefine almost all of the IVOA Data Models in order to create
> SIAPv2, for one reason or the other.
>
> I hope this is not true (and I am sure this was not the consensus, anyway).
> But if it is, then let's get it really right this time. Which means: we
> don't "model by UTYPEs".
>
>
>> Then the ImageDM
>> architecture is much simpler, as most of it is just ObsCore and Char.
>>
>
> This is a non-sequitur. Assuming that by architecture you refer to the
> class diagram, the class diagram does not need to be simple: it needs to
> meet the requirements in the most efficient way, which is different.
>
> Also, Mark's diagram doesn't seem complicated, so you cannot use Occam's
> razor in this case.
>
> Actually, Mark's diagram doesn't require to review ObsCore, ergo it is
> simpler.
>
>
>>
>> This should be more clear in the revised DM spreadsheet; I hope to post
>> that later today.
>
>
> I don't think anybody cares about the list of UTYPEs, at this point, as
> Mireille suggested.
>
> Let's figure out how the model needs to look like, then I am sure we will
> find a solution for the UTYPEs (which, as you have always been adamant, are
> not to be parsed).
> Unless you want to "model by UTYPES", which is something that the DM WG
> doesn't do anymore.
>
> There is a difference in what you and Mark are suggesting. Unless you
> provide some actual arguments showing why your approach is better
> (arguments that would have nothing to do with UTYPEs), I suggest that we
> adopt Mark's approach, which is simpler and is backed up by sound data
> modeling reasoning.
>
>
>
>> I need to review your new figures but I think the obvious class names
>> are Observation, Characterisation, Image, etc.  Mireille suggested
>> earlier that the "Obs.x" element in Observation (containing
>> dataProductType etc.) could be replaced by the more general Dataset.x.
>>
>>
> How can a name be more general than another?
>
> "What's in a name? That which we call a rose by any other name would smell
> as sweet."
>
> Cheers,
>
> Omar.
>
>
>
> --
> Omar Laurino
> Smithsonian Astrophysical Observatory
> Harvard-Smithsonian Center for Astrophysics
> 100 Acorn Park Dr. R-377 MS-81
> 02140 Cambridge, MA
> (617) 495-7227
>