[Obscore1.1] WD comments
CresitelloDittmar, Mark
mdittmar at cfa.harvard.edu
Wed Jun 24 22:07:25 CEST 2015
Mireille,
Thank you for your efforts on this document!
I gave it a full re-read on the plane back from Sesto.
Below are some comments for discussion, in 2 groups
1) about the additions for 1.1
2) about the original content
1: New content
============
First, I agree with Marcus'? comment in Sesto, that the document should
have specific new use-case(s) added for the new content.
pg 7: "This effort (version 1)"...
Perhaps some rephrase/rearrangement
Version 1.0 was focused on public data. ...
Version 1.1 adds information on ..
pg 8:
The two paragraphs; 'The first version of this model, ..." and "This
effort (version 1).." are repeated from pg 7.
pg 9:
Is the architecture diagram accurate?
pg 25: Axes dimensions
Outside of the pixelated image context, what values do these hold?
For example, the sparse cube (ie: event list). do each of these hold
the #events? or are s_dim1,s_dim2 == the span along that axis? and
if so, in what frame?
It seems that #events is closest to the description as the number of
samples.
pg 40: Utypes
the 'numBins' node in the utype confuses me in conjunction with the
'number of samples' description. 'Bins' implies pixelated axes, while
'Samples' is more a number of measurements thing, which MAY correspond to
image pixels or MAY be individual measurements (events).
B3.5: creation date
Shouldn't we update this to clarify that this is not strictly ISO 8601,
but rather, the FITS standard which is 8601 without the "Z" tag. There
was a discussion on this some time ago, and that is the language folded
into the DatasetMetadata model (Section 6.4.1.1).
B5: Data Access
Refers to SSA for the Access object content. Which document is supposed
to be the 'parent' in the Access standard hierarchy?
B6.1.1:
The description seems very pixelated data specific.
2: Original content
===============
One of the challenges in doing the DatasetMetadata/Cube work was in
determining exactly what ObsCore was in relation to the other models
(Spectral/Char/STC). It seems that we have an opportunity to clarify that
relation while we have the document open... so long as that work does not
delay the delivery of the primary purpose of the update.
I think it would be beneficial to add/change language to emphasize that
ObsCore is a 'flattened view' of an Observation/Dataset model.
example: pg 10
".. the purpose of this document is twofold: 1) to define a simple data
model to describe observational data, "
could be rephrased to clarify this point.
example: pg 11; second paragraph of section 3 can better clarify the
relation of ObsCore to these other models.
The diagrams/UML in the document are to illustrate the mapping of this view
to the corresponding IVOA standard model(s). Ultimately, I think it would
be more clear if there were 2 sides to the diagram, with some indicator
matching the respective elements:
on the left: ObsCore table column element
on the right: corresponding model element
ivoa.ObsCore.table_name ---- ObsDataset -> Target -> Name
ivoa.ObsCore.s_resolution_min ---- ObsDataset -> Char -> SpatialAxis ->
Resolution -> Bounds -> Limits -> LoLimit
I'm not sure how that would be shown graphically, and may be more work than
benefit.
If Section 3 is representing the 'placeholder' model which ObsCore views,
this could be made more clear. ie: if Section 3 is fulfilling the same
purpose as the upcoming DatasetMetadata document.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20150624/1082f4cb/attachment.html>
More information about the dm
mailing list