<div dir="ltr"><div><div><div><div><div><div>I'm extracting this thread from the other message (Roadmap - checkpoint) since it might generate some discussion.<br><br></div>I'll respond here.. the original is included below for reference.<br><br></div>Markus,<br></div> First.. the bulk of my changes to NDCube w.r.t. STC recently has been to pull out/refine<br></div><div> the relation between the two models.. making it much more generic. I don' t have extensive<br></div><div> stc content in my model which needs to be kept in sync.<br></div><div><br></div><div> Second.. I don't see how I would be able to remove the dependence on STC. We are developing <br></div><div> a set of models, each of which handles a certain area of interest in the big picture. This allows us<br></div><div> to re-use content and increase interoperability. The model we lovingly refer to as "STC (space-time coordinates)"<br></div><div> handles the concepts/patterns for coordinate frames, systems, axes, coordinates, and transforms.<br></div><div> And it handles them <b>for all domains</b>.<br></div><div><br> Currently, this content is broken into 3 sub-models (coordsys, coords, trans) as requested in Trieste.<br> These models define patterns for Frames and Coordinates, and implements that pattern for each of<br></div><div> the primary domains we have seen in existing models and that are required for the example files<br></div><div> in the Cube work.<br></div><div><br></div><div> In your response, you acknowledge that NDCube needs to "define which axes belong together" and <br></div> "describe arrays and sparse arrays" (a.k.a. coordinates).<br><br></div> Those things "axes", "coordinates" are defined in the dependent models.. so Cube must refer to them.<br></div><div><div> <br><div><div><div> As we move to other models, which need additional and/or different domains/coordinates etc, we have a choice<br></div><div> 1) let it implement the patterns defined in the appropriate source model (coordsys, coords) internally<br></div><div> 2) update the source model with the new domain implementation<br></div><div> either one would work, and either would be interoperable because they stem from the same pattern.<br></div><div><div><br></div><div> I look forward to seeing Jiri's proposal.<br><br></div><div>Mark<br><br></div><br><div><br><div><br>Markus wrote:<br></div>======================================================================<br><div><span class="gmail-im">On Mon, Jan 30, 2017 at 12:32:22PM -0500, CresitelloDittmar, Mark wrote:<br>
> + DatasetMetadata/NDCube<br>
> o continued working PR requirements (examples/validation)<br>
> o integrate vo-dml and stc2 changes as needed<br>
<br>
</span>That's another point for why I'm trying to get you to pull out all of<br>
STC (and indeed, other axis metadata) from NDCube -- this thing will<br>
never finish if it depends on these DMs.<br>
<br>
Can't we restrict NDCube to just defining which axes belong together<br>
to form the cube and describe arrays and sparse arrays in a<br>
consistent framework?<br>
<br>
The actual axes would be directly described by extra metadata that<br>
NDcube wouldn't need to worry about.<br>
<br>
Jiri and I have been trying to make that happen for time series based<br>
on NDCube as far as we could work it out, and I hope Jiri will<br>
put out a proposal soon. Meanwhile, the sketch would be, in the<br>
table case (keeping out referencing array axes)<br>
<br>
Table:<br>
<br>
ra dec spectral flux flux_error<br>
<br>
Dataset annotation<br>
pubDid...<br>
<br>
NDCube annotation<br>
axes: [@ra, @dec, @spectral]<br>
dependent_axes: [@flux, @flux_error]<br>
<br>
STC annotation<br>
2dspherical<br>
long: @ra<br>
long_error: 2 mas<br>
lat: @dec<br>
lat_error: 5 mas<br>
frame: ICRS<br>
...<br>
<br>
Spectral annotation<br>
frame: ..<br>
min: 2e-7 m<br>
max: 4e-7 m<br>
value: @spectral<br>
value_error: 1e-10 m<br>
<br>
Photometry annotation (I've not actually looked at PhotDM, so this is fantasy)<br>
flux: @flux<br>
flux_error: @flux_error<br>
spec_window_center: @spectral<br>
spec_window_width: 1e-10<br>
<br>
<br>
-- isn't it nice how it all nicely separates the various DMs? You<br>
could even have annotation of several different versions of a DM in<br>
one file and for one set of columns -- and clients only understanding<br>
photometry without having an idea of NDcube could still use whatever<br>
information it can pull out of the photometry part.<br>
<br>
VO-DML and the new annotation actually lets us pull this scheme off.<br>
Any chance I can move you to adopt this kind of thing and pull the<br>
DMs apart?</div></div></div></div></div></div></div></div>