ImageDM/ObsCore - Dataset

[Jesus Salgado]

Hi all,

I fully agree that the first step is to obtain a real/consistent UML model where we can see clearly if 
ImageDM is really extending ObsCore or what is needed to be modified in ObsCore to really do this extension
(ImageDM is extending something for sure, maybe not the current ObsCore but this is exactly one of the things
to be obtained from this exercise in the preliminary steps.

Then, about the question of what is an extension... extension is s extension. It is true that inheritance has
not be fully reflected in the past in DMs (probably due to the complexity of thsi process) and we have only tried
to reuse components (what is, in my view, a different thing)
That means, if we do it properly, we do not need to redefine the attributes of the mother class again in the 
definition of a child. How good we can do it is still something to be seen but we should try to it the best as
we can.

Then, we have the question about utypes. We have used in the past ways to define utypes for child classes that 
are against UML design. VO/DML is trying to do it better by defining utypes at class level, adding documentation, 
declaring inheritance in a proper way and some tricks that allows us to really represent complex data models. 

For the time being, our effort should point to the UML generation with the proper inheritance rules.
How to represent/create utypes and/or paths and where (DMs or protocols) will be a next step.

Cheers,
Jesus

----- Original Message -----
From: "Omar Laurino" <olaurino at head.cfa.harvard.edu>
To: "Mark CresitelloDittmar" <mdittmar at cfa.harvard.edu>
Cc: "Data Models mailing list" <dm at ivoa.net>
Sent: Thursday, October 31, 2013 4:49:31 PM
Subject: Re: ImageDM/ObsCore - Dataset


Hi Mark, 


this is a good, practical example that making strings drive the data modeling is a bad idea. As Mireille stated, we should do the proper data modeling, then worry about UTYPEs later. UTYPEs are strings, they are not meant to be parsed, and they should be derived from the models, not the other way around. 


That being said, I find it odd that a class called SpectralDataset, which extends a class called ObservationDataset, adds a Dataset attribute to its parent. It would make sense if the attribute was describing a different dataset, but in this case the attribute is describing its owner. So, it seems to me that the Dataset's attributes should be the SpectralDataset's attributes, and we don't need the additional complexity of a new class. 


Do you agree? 


Omar. 


P.S. If the argument against proper modeling is that we need to make UTYPEs look the same in different models, I will be forced to repeat the mantra that a Data Model is not a list of strings :) 


But even in that case, if we lay out a sensitive extension mechanism (as VODML does), UTYPEs imported from an existing data model remain unchanged, so the need to make UTYPEs consistent among data models disappears. You don't need to fix the tag names of an XML schema that is properly "imported" by another schema, right? by the same token you shouldn't need to fix UTYPEs that you are importing from a different model. 





On Thu, Oct 31, 2013 at 7:52 AM, CresitelloDittmar, Mark < mdittmar at cfa.harvard.edu > wrote: 




All, 

I thought that I would elaborate on a point in the diagram I sent out 
the other day: 


ImageDM - ObsCore Convergence thread. 
http://www.ivoa.net/pipermail/dm/2013-October/004778.html 


In that diagram, Observation contains 'dataset specific' metadata such as dataProductType and calibLevel. In the extension, those items move into a 'Dataset' object. 


I did this to resolve, what seems to be a disconnect between the model description (text), and mapping (utypes). 


>From the description, it seems clear that the intent is that an Image or Spectrum *is* a Dataset.. with particular characteristics (dataProductType, dataProductSubType, Length). 


In Observation, those items are attributes of the top level object "Observation" 

- but the utypes contain a "Obs" node 



The Observation object also *has* a Curation, DataID, Target. 

- none of those have a 'Obs' node in their utypes. 

In the old "Spectrum" model, some of these were at the top level too "Spectrum.Length". When we removed 'Spectrum' node, these went to a Dataset object to avoid "Length" for a utype. 

So to keep the mapping and model consistent, it seems necessary to have the top 

level object be a container of objects at the same level covering the different topics. And so, we have a Dataset object containing dataset specific metadata. 



Mark 






-- 

Omar Laurino 
Smithsonian Astrophysical Observatory 
Harvard-Smithsonian Center for Astrophysics 
100 Acorn Park Dr. R-377 MS-81 
02140 Cambridge, MA 
(617) 495-7227 

This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.