<div dir="ltr">Gerard,<br><br><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 18, 2017 at 1:27 PM, Gerard Lemson <span dir="ltr"><<a target="_blank" href="mailto:gerard.lemson@gmail.com">gerard.lemson@gmail.com</a>></span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div dir="ltr">HI Mark<br><div class="gmail_extra"><br><div class="gmail_quote"><span class="gmail-">On Tue, Apr 18, 2017 at 12:23 PM, CresitelloDittmar, Mark <span dir="ltr"><<a target="_blank" href="mailto:mdittmar@cfa.harvard.edu">mdittmar@cfa.harvard.edu</a>></span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div dir="ltr"><div><div><div><div><div>Gerard,<br><br></div>I was thinking about this more on the way home yesterday.. I don't think datetime can handle all three cases.<br></div><div> + it certainly handles DATE-OBS, as an instant in time (date+time)<br></div> + it may handle MJDREF, as it could be considered different representation of a date+time as 'MJD' date.<br></div><br></div></div></div></blockquote><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div dir="ltr"><div><div> + TSTART (TIMEOFFSET) requires additional information (the time0 of the frame) to determine, and can have a variety of units [ms, s, d, m, y, ... ] which the others don't.<br></div> while the first two represent an instant in time, this is really a span of time, which can be converted to an instant if you know the start point.<br></div><div> Yes.. that is the same as MJDREF, but MJD has a fixed, known start point while this one is arbitrary and cannot be internalized to the type.<br></div></div></blockquote><div><br></div></span><div>Seems to me your are trying to model a more complex concept here, something that could (should?) be captured using a custom DataType with two attributes, a time0 (ivoa:datetime) and a time span (ivoa:RealQuantity).</div><div>According to STC, any observation of some property such as a datetime, or a position etc needs quite some information for interpretation. I.e. a position is not just a realquantity or group of such quantites, it needs a zero-point, a reference frame, whatnot. Same with time. <br></div><div>I am sure there are lots of models where a simple ivoa:datetime, serialized for example to '2017-05-01 13:00:00 cet' , would be ok. E.g. to "model" the start time of a telecon. This is I guess why a datetime-like type exists in databases, programming languages and XML schema for example.</div></div></div></div></blockquote><div><br>??? <br><div>I'm not sure I follow the above, it sounds just like what we are doing. <br></div><div>This IS for the coords model (a.k.a STC).<br></div><div>The
TimeOffset IS a custom DataType and part of a more complex structure, where the time0 is in
the associated Frame along with the other stuff you mention and
illustrated in the UML diagram referenced at the top of the thread.<br><br></div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div dir="ltr"><div class="gmail_extra"><div>For astronomical observations one may(?:) often need the more involved machinery of STC. But then probably one would use realquantity in most places and one would not want to add all of this to the basic set of primitive types or even quantities.</div></div></div></blockquote><div><br>Yes.. exactly.. we're not asking to add 'all this' to the basic set, just that it help us enable the 'more involved machinery'. <br></div><div><br>In the time domain, we want to enable users (TimeSeries, Cube, etc..) to provide Time Data as EITHER a datetime OR a TimeOffset.. aka TimeStamp.<br></div><div>Since they have access to the full complex structure, this is both possible and reasonable.<br><br>In the provided diagram, we have an abstract TimeStamp with sub-classes for the 2 flavors, but this does not satisfy the additional requirements we are folding in for 'finding Coords with minimal domain specific knowledge'.. which spawned this restructure and request for ivoa:anyType.<br><br>To satisfy both requirements, we need a common ancestor for both RealQuantity and datetime..<br><br></div><div>The question is where does this get defined:<br></div><div> 1) as ivoa:anyType base type.. which you've explained would require restructuring the vo-dml types, so is sub-optimal<br></div><div> 2) as ivoa:DateQuantity base type <br></div><div> 3) as coords:DateQuantity type.. local extension to ivoa:Quantity which doesn't feel like playing nice with the base types<br></div><div> 4) do you have another proposal?<br></div><div><br></div><div>Mark<br><br></div><div><br></div></div></div></div></div>