<div dir="ltr"><div>Markus,<br><br></div>Thanks for the response.. this is good.!<br><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 18, 2017 at 4:35 AM, Markus Demleitner <span dir="ltr"><<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
I'd say the main things I'm currently doing differently include:<br>
<br>
(1) I'd *much* prefer if value+error weren't part of STC and rather<br>
could be pulled out of STC to have a DM of their own (in my example,<br>
that's the fake ivoa:Measurement type).<br>
<br></blockquote><div><br></div><div>I'm getting mixed feedback about this from different parties. <br>The earlier version had separated Measurement (coords) from Frames et al. (coordsys).<br></div><div>Combined makes for easier presentation of the 'domain' extensions.. <br></div><div><br></div><div>I'm open for (and personally lean a bit toward) separation. Some of the other parts (below) may <br></div><div>help sway the organization one way or the other.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
(2) I never liked the separation of frames from the remaining<br>
annotation in STC; I believe the original idea has been that you<br>
could somehow re-use tuples of frames on the various axes, and I<br>
doubt any savings (or functionalities?) possible with this are<br>
proportional to the complication of having to go through references.<br>
Hence, in my draft, the coordinates simply have a frame attribute,<br>
done. I'd even propose that just based on the type of the thing you<br>
find in frame, clients should figure out the nature of the axis, and<br>
you could get rid of verything in coordsys:domain except the frames<br>
themselves.<br>
<br></blockquote><div><br></div><div>couple comments:<br></div><div> a) I don't see the 'frame' connection for your Measurements (mag, df)<br></div><div> ie: the 'value' should be a Coord type.. with relation to 'frame'<br></div><div><br></div><div> b) on Coords and Frame relations<br></div><div> Frame is an ObjectType, so it can only be in Composition or Reference relations to Coord.<br></div><div> Since a Coord does not own the Frame, and multiple Coord-s may be in the same Frame, <br></div><div> the relation is Reference. So, the modeling of this should not change, and I hope this then<br></div><div> becomes a Mapping concern.<br></div><div><br></div><div> What you are doing here is similar to something I did in an early serialization, but changed<br></div><div> because it is not legal annotation. I tried serializing the Reference inline.. since it was only <br></div><div> in one place.<br><br></div> <ATTRIBUTE dmrole="time"><br><div> <INSTANCE ID="ndgtniuabtea" dmtype="stc2:Coord"><br> <ATTRIBUTE dmrole="loc"><br> <COLUMN ref="hjd"/><br> </ATTRIBUTE><br> <REFERENCE dmrole="frame"><br> <INSTANCE ID="ndgtniuabtha" dmtype="stc2:TimeFrame"><br> <ATTRIBUTE dmrole="kind"><br> <LITERAL dmtype="ivoa:string">JD</LITERAL><br> </ATTRIBUTE><br> <ATTRIBUTE dmrole="refPosition"><br> <LITERAL dmtype="ivoa:string">BARYCENTER</LITERAL><br> </ATTRIBUTE><br> <ATTRIBUTE dmrole="timescale"><br> <LITERAL dmtype="ivoa:string">UTC</LITERAL><br> </ATTRIBUTE><br> </INSTANCE><br> </REFERENCE><br> </INSTANCE><br> </ATTRIBUTE><br><br></div><div> Basically saying that the element is a Reference to this thing right here.. rather than that thing over there.<br></div><div> I'm not advocating that this is a good way to go with the annotation, simply stating that I tried a similar thing.<br></div><div><br></div><div> c) on Coords and Frame relations - part 2<br></div><div> This IS a model concern.<br></div><div><br></div><div> I notice that you are linking the Coord to Frame, where the models/examples we've been putting out are <br></div><div> linking each Coord value to it's AXIS in the Frame. Arnold will be happy to see this! However, it presents<br></div><div> two problems (which is why the relation was put on Axis).<br></div><div> 1) a Coord is a value along a particular axis, so this allows you to know which axis the value is.. (x or y for example)<br></div><div> For some applications, they may be more interested in the Frame particulars, but for others, they may be more<br></div><div> interested in knowing what the legal value range is (domainMin/Max). I prefer to keep the relation where it <br></div><div> conceptually belongs, and the user can access the info they want.<br><br></div><div> As reference to Frame, there is no way for the user to really know which is 'RA' and which is 'DEC' in an ICRS<br></div><div> Frame, you can only say there is a value pair associated with an ICRS frame, and assume the ordering.<br></div><div> This may be 'obvious' in this instance, but what if you have CARTESIAN frame [x,y,z] and are only providing<br></div><div> values along a plane [x,z], [y,z], or [x,y]? Or a single 'ra' or 'dec' value without the other? How do you know<br></div><div> which one-s are being provided?<br></div><div><br></div><div> 2) this doesn't play well when we consider Coord-s which are in different domains, but have co-dependent errors.<br></div><div> (eg. [ t, x, y ] with ellipsoid error.)<br></div><div> There is no single frame to point at.<br></div><div> I think this could still be accommodated, but I really think the relation to Axis serves more applications better. <br></div><div><br><br></div><div> d) on "I'd even propose that just based on the type of the thing you find in frame, clients should figure out the nature of the axis, and you could get rid of everything in coordsys:domain except the frames"<br></div><div> From the 'read' point of view, this is probably true.. but for the models, I want to be able to say <br></div><div> This element should be a TimeMeasure ( value associated with Time Frame + error )... which requires the domain specialization.<br></div><div> For the TimeSeries example, don't you want to require that the independent axis is Time related?<br></div><div><br></div><div> Similar for Target.pos .. I really want a spatial Position there... nothing else.<br></div><div><br></div><div> I don't seem to have this as a specific requirement (on the twiki), but have been treating it as one.<br><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
(3) In ndcube:Cube, I'm using sequences of dependent and independent<br>
rather than somehow packing them into Observable instances, and<br>
I'm directly annotating the columns rather than other DM annotations.<br></blockquote><div><br></div><div>We are looking at this bit in the modeling, there is a relation I'm not quite comfortable with, but the <br></div><div>general structure is, I think OK as is.. a collection of DataAxis with attribute for 'dependent' and a value (Measurement).<br></div><div>In your annotation, are you still trying to cross ref information? The in/dependent_axes specify particular columns <br></div><div>which are NOT the Measurement objects.. I'd expect these to BE the Measurement objects, which are <br>composed of >1 COLUMN (value + error)<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
There are quite a few differences in the actual annotation, too (my<br>
most ardent wish is to have dmrole just contain the role name to<br>
preserve readability), but that's for mapping discussions.<br>
<br>
Having said all this, I'm totally in favour of deciding on a "current<br>
version" of STC and the ancillary DMs and putting them up...<br>
somewhere :-) Perhaps one could have a temporary section on the DM<br>
wiki page with links to the current generated HTML docs for the bunch<br>
of the DMs?<br>
<span class="gmail-HOEnZb"><font color="#888888"><br></font></span></blockquote><div>Omar has suggested something similar... and it is a good idea, just something else to maintain.<br></div><div>The URLs have been pretty static, until we start consolidating/cleaning up the 'alternates'.<br></div><div>Will see what we can do.<br><br></div><div>Thanks for all the work! <br>Mark<br><br></div><div><br><br></div></div></div></div></div></div>