<div dir="ltr"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 17, 2017 at 10:46 AM, CresitelloDittmar, Mark <span dir="ltr"><<a href="mailto:mdittmar@cfa.harvard.edu" target="_blank">mdittmar@cfa.harvard.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Gerard,<br><br></div><br><div><div><div><div class="gmail_extra"><div class="gmail_quote">On Sun, Apr 16, 2017 at 9:41 AM, Gerard Lemson <span dir="ltr"><<a href="mailto:gerard.lemson@gmail.com" target="_blank">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"><br><div dir="ltr"><span class="m_-9162593378744534507gmail-"></span><div class="gmail_extra"><div class="gmail_quote"><span class="m_-9162593378744534507gmail-"><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 class="gmail_extra"><div class="gmail_quote">For example..<br></div> With the recent Coords re-work for the Cube/TimeSeries thread, in order to satisfy the user-end requirements, we need<br></div><div class="gmail_extra"> a 'anyType' parent to the primitives in the ivoa model. Perhaps you could consider this my formal request to add that<br></div><div class="gmail_extra"> since this seems like a much more user-friendly modeling (the annotations are easier to work with from an application<br></div><div class="gmail_extra"> point of view). Whether this is in V1.0, or V1.1, I'm not particularly concerned, but it would need to go forward with the<br></div><div class="gmail_extra"> cube/coords work.<span class="m_-9162593378744534507gmail-m_-8384930201550870450gmail-HOEnZb"><font color="#888888"><br></font></span></div><span class="m_-9162593378744534507gmail-m_-8384930201550870450gmail-HOEnZb"><font color="#888888"><div class="gmail_extra"><br></div></font></span></div></div></blockquote></span><div><div>We had a similar issue in SimDM, where we did not know the property that a measurement value represented, and hence we could not predict the datatype. We did not introduce an anyType there for technical reasons, we actually wanted to work with the data model explicitly. </div></div></div></div></div></blockquote><div><br></div>Yes.. this is similar. We are wanting to go this way so that there is common vo-dml annotation for these base (CoordValue) elements which can be found by generic utilities.<br><br></div><div class="gmail_quote"> <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 class="gmail_quote"><div>The 'ivoa' model used to have a similar such type, namely AtomicValue. Had a UCD only, and was base class of a host of "extended" types, including the Quantity types which added a unit. We removed AtomicValue when we removed the ucd attribute as it seemed to become superfluous. </div><div><br></div><div><div>Note that the AtomicValue was never a super type of all the types, which I am assuming you want anyType to be the supertype of as many of the types as possible. Correct? Would it be sufficient to make anyType be a supertype of the primitive types only? </div><div>If we do so (and even if not) I think we should also change the definitions of rational and complex. ISO modelling these explicitly with numerator/denominator and imaginary/real attributes we'd make them primitive types and leave the representation up to the serializer. So then also these types could be subtypes of the primitive anyType, which as structured types they could not be.</div><div><br></div></div><div>If no one sees a problem with adding anyType as a super type to all primitive types, I see no reason to wait for a version 1.1.<br></div><br></div></div></div></blockquote><div><br></div><div>There are, of course, a couple different solutions.<br></div><div>The proposed modeling is using the anyType here:<br> <a href="https://volute.g-vo.org/svn/trunk/projects/dm/STC-2.0/doc/diagrams/alt/base%20diagram.png" target="_blank">https://volute.g-vo.org/svn/<wbr>trunk/projects/dm/STC-2.0/doc/<wbr>diagrams/alt/base%20diagram.<wbr>png</a><br> <br></div><div>And is resolved to particular types in concrete classes:<br></div><div> <several> => Quantity<br></div><div> PixelIndex => integer<br></div><div> ISOTime => datetime<br> Polarization domain has enumerated value set, but that is outside of this usage as a special type of Discrete.<br><br></div><div> So we went the easy way of putting anyType as parent to all types in ivoa which allows the most flexibility<br> <a href="https://volute.g-vo.org/svn/trunk/projects/dm/STC-2.0/doc/diagrams/alt/ivoa%20types%20diagram.png" target="_blank">https://volute.g-vo.org/svn/<wbr>trunk/projects/dm/STC-2.0/doc/<wbr>diagrams/alt/ivoa%20types%<wbr>20diagram.png</a><br></div><div><br></div><div> But the immediate requirements can be accommodated by adding a DateQuantity with datetime value..<br></div><div> * then PixelIndex (integer value) would be handled separately from the Quantity set.<br></div><div><br></div> Having anyType as super type to all primitives does not support the time domain as we would like<br></div><div class="gmail_quote"> * Quantity and datetime would not have a common ancestor, so we could not define a TimeStamp<br></div><div class="gmail_quote"> which would allow time represented as a RealQuantity OR datetime.<br> <a href="https://volute.g-vo.org/svn/trunk/projects/dm/STC-2.0/doc/diagrams/alt/temporal%20domain%20diagram.png" target="_blank">https://volute.g-vo.org/svn/<wbr>trunk/projects/dm/STC-2.0/doc/<wbr>diagrams/alt/temporal%<wbr>20domain%20diagram.png</a><span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888"><div class="gmail_quote">Mark<br><br></div></font></span></div></div></div></div></div>
</blockquote></div><br></div>