[CubeDM] - comments on new diagrams

[CresitelloDittmar, Mark]

All,

This is a summary of some discussion I've had with Gerard offline regarding
the new diagrams..
I hope this is presentable format-wise.  I am paraphrasing much of the
content, and there are some technical details related to some modeling
concepts that I've left out.  Any errors in representation are mine.


*IVOA Types:*
  Q: Why do you extend anyURI with URL and URI?

   A:  Only URI extends from anyURI, and I'll admit, this is just because I
wanted the pseudonym.  The name 'anyURI' seems overly specific.. and would
not be correct for a URL element.. so I added the URL type to clarify the
distinction.

  This is a fine point, since all URLs are URIs, but not the other way
around.. do we want a specific datatype for URL, or only have URIs and
leave it as a restriction in the attribute description to specify that it
must be a URL.  Either way works, I (Mark) prefer the different type.


*Dataset Types:*
   C: Position types should NOT extend AtomicValue.. they are, by
definition, not "atomic" since it contains 2 values.  Why not have
Position1 and Position2 "use" RealQuantity for the variables.

   A: I wanted to re-visit this object.  This reasoning makes sense.  The
current (historical) structure of that Position is that there is 1 UCD and
Unit for the pair of values ( pos.eq;src , 'deg' ).  Using Quantity would
change that to 2 independent values.. which was actually requested, and is
probably more correct.

   ------------------------
   Q: Why do we need the Position base class?

   A:  For cases (even maybe Target.pos) where the Position may be
1D,2D,3D.. so want need the base class to allow this.  (ra,dec) vs (x,y,z).

   ------------------------
   C: Contact should not be a DataType.. doing so denormalizes the concept
of a person/party, identified by a name/email.

   A: Yeah.. I agree.
     This was an ObjectType in the previous doc (everything was),  I can
restore that.

   ------------------------
   C: Same for Redshift... and isn't this concept a bit specific
(astronomical) for a generic Dataset namespace?

   A:  The Redshift object/type is used in the ObservationDataset Derived
object.
     I am not completely comfortable with that object.  I like having the
concept of 'Derived Metadata' on the ObservationDataset, but I think that
each flavor of dataset may/would want to define its own set of Derived
content.  The set given, are from the SpectralDataset, and probably should
be there..  along with the datatype.  It is a discussion point I want to
bring up on the list


*Dataset Overview:*
   C: <I'm paraphrasing a lot here>
         The Dataset contains groups "DataID" and "Curation", which hold
many attributes that can (should?) be directly associated with the
Dataset.. essentially the Dublin Core type items.  Do we need to keep the
groupings?

   A:   These groupings stem from the Resource Metadata document and have
been a part of the ObsCore and Spectrum models from the start.  I think the
access protocols also expect them.  My feeling is that this level of
structure is essentially 'sacred' and would require a broad consensus in
the group to change that.

   ------------------------
   C: What is the purpose of the DataModel object?  The concepts don't make
sense..

   A: This will go away when there is a replacement for the service it
provides.  I feel there needs to be a standardized means of determining
what type of dataset an instance is.  I can view an instance as a generic
Dataset, and poll the DataModel object to find out.  This should be covered
by serialization conventions, but is not.

   R1: In SimDM (I think) we have the concept of ObjectType (not to be
confused with the vo-dml concept!), which is more precise than a DataModel
I'd think.  But it needs explicit definition in the model itself, but that
definition can include a skos concept label.

   ------------------------
  Q: What is the "Data" ObjectType good for? Should DataSet have a
collection of Data? And should then subtypes of DataSet "subset" this
composition relation?

   A:  Dataset metadata, by itself is not very useful.. most of it provides
context and identification for the 'data'
        A particular Dataset (e.g. SpectrumDataset or ImageDataset ) MUST
define an extension of Data and the relation between it and the Data.  I
think "subsetting" would work, but I don't think I can represent that in my
Modelio tool..  also, the multiplicity of the relation changes (see
Spectrum vs PhotometryPoint), and I'm not sure how that is handled.




*HyperCube Dataset:*
    C:  I think the ***AxisCoordinate types in stcmod should be DataType-s,
and hence the relations composition right now) from NDPoint should be
attributes.

   A:  I think one could argue for these to be datatypes, (they seem rather
complex for that to me), but the STC Coordinates which they replace are NOT
datatypes.  Doing it this way, allows them to be used were stc:Coordinates
are used, but with the desired content and common datatypes used throughout.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dm/attachments/20140402/94885277/attachment-0001.html>