ImageDM/ObsCore - Dataset

[Laurino, Omar]

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