Revised ImageDM-ObsCore architecture

[Laurino, Omar]

Hi Doug,


> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dm/attachments/20131112/9935526a/attachment.html>