<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
Hi All,
<div><br>
</div>
<div>I'll state up front that I still have not wrapped my head around all the use cases for VODML elements in VO Tables. There are open questions in my mind about both the semantics and the syntax of these cases, but that's for another day.</div>
<div><br>
</div>
<div>The one case I think I understand at an abstract level is that for a given data type, we want to describe which columns map to which attributes of the type so that some values in a table row can be used to construct an instance of that type. For that
use case, I have a couple of observations:</div>
<div><br>
</div>
<div>
<ul class="MailOutline">
<li>Only a client that understands the semantics of a data type can do anything useful with an instance of that type.</li><li>We cannot express the semantics of a type in the VO Table (or in any reasonably automated way). The table can only describe the data structure into which to put TD values.</li></ul>
</div>
<div>
<div><br>
</div>
</div>
<div>From a practical perspective, there will be basic generic clients that are able to provide some features with only basic knowledge of data types, and there will be more advanced clients that will be intimately familiar with the details of a focused set
of data types. </div>
<div><br>
</div>
<div>For the basic clients, I think it's important to expllicitly support basic data types. To me, this probably means standardizing some *simple* definitions of types like Position, Source and Observation (along with maybe Image, Spectrum and whatever else
we feel is core to *general* interoperability).</div>
<div><br>
</div>
<div>More advanced clients might understand specific subtypes of those simple types along with other random data types. These could be quite specific to particular data sets (e.g., ChandraSource).</div>
<div><br>
</div>
<div>To address those two cases, I think it makes sense to keep the FIELD to data type mappings separate. So a VO Table that contained a ChandraSource would contain a VODML element that described what FIELDs map into that data structure, and it would contain
a completely separate VODML element that would describe what FIELDs map into a simple Source. In that way, basic clients would recognize the type mentioned by basic mapping but be able to freely ignore any VODML elements that described mappings to types with
which they are not familiar.</div>
<div><br>
</div>
<div>So to summarize, with my limited (so far) view of the use cases, I think we'd be best off without ALTTYPE or any other structure that tries to describe a polymorphism. Clients that understand a complex type can infer supertypes all they want since they
understand the data type beyond what is described in the VO Table. Simple clients (most clients!) can use straightforward mappings to the simple types they understand without dealing with excess syntactic complexity.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Tom</div>
<div><br>
</div>
<div>
<div>
<div>On Mar 9, 2015, at 7:39 AM, "Laurino, Omar" <<a href="mailto:olaurino@cfa.harvard.edu">olaurino@cfa.harvard.edu</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div dir="ltr">Hi Markus,
<div><br>
</div>
<div>At this point I believe both solutions have strengths and drawbacks. One solution (only one TYPE) puts less burden on the server side, but more on the client. The other (more than one TYPE allowed) puts less burden on the client and more on the server
side.</div>
<div><br>
</div>
<div>Regarding your questions:</div>
<div> - Where to draw the line? in the old mapping document (the one using UTYPEs) the line was drawn at model boundaries. You did not need to add the multiple types annotations for subtypes of types defined inside the same model. The reason is that if you
assume knowledge of a model, then you don't need more help. However, after my prototyping efforts I suggested we also included explicit declaration of abstract types even within model boundaries, just to simplify discovery of relevant instances (assuming types
are declared abstract for a good reason).</div>
<div><br>
</div>
<div> - How to "compute" the leaf type? I believe in the old mapping document we suggested a specific order for the type declaration. Now that we have a specific element maybe we might add an attribute, e.g. <TYPE leaf="true">?</div>
<div><br>
</div>
<div>In any case, as I said, I don't think you can make a strong case in either direction. Both solutions have Pros and Cons. However, this does argue for 4b over 4a, as 4b can be turned in 4c easily if required.</div>
<div><br>
</div>
<div>Omar.</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Mar 9, 2015 at 6:50 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Omar, dear lists,<br>
<span><br>
On Fri, Mar 06, 2015 at 11:11:48AM -0500, Laurino, Omar wrote:<br>
> I would like to elaborate on the ALTTYPE element and why it was included in<br>
> the design.<br>
<br>
</span>Thanks for the elaboration. Since I'm a big python fan, it is<br>
perhaps not terribly surprinsing that I still prefer duck<br>
typing (and hence a unique type annotation, with naive clients<br>
working on the attribute names/utypes/vodml-ids).<br>
<br>
However, assuming we want explicit annotation of the inheritance<br>
hierarchy, the argument<br>
<span><br>
> Now, a reader can simply look for src:Source and must not rely on any kind<br>
> of type inference. The problem with 4a and ALTTYPE is that readers need to<br>
> explicitly look for two different XML elements to get a single piece of<br>
> information.<br>
<br>
</span>convinces me to prefer<br>
<span><br>
> I would then prefer something like option 4b but with an open multiplicity<br>
> for the TYPE element, so one would have:<br>
><br>
> <GROUP><br>
> <VODML><br>
> <TYPE>sdss:SDSSSource</TYPE><br>
> <TYPE>src:Source</TYPE><br>
> </VODML><br>
> ....<br>
> </GROUP><br>
<br>
</span>over ALTTYPE. *If*, and here I don't see terribly clearly, we're<br>
sure we never need the concept of "actual type" in the VODML context.<br>
The trouble here is that with such a convention, the implementation<br>
of a function<br>
<br>
type(object) -> class-of-object<br>
<br>
would probably require inspecting all VO-DML files mentioned in the<br>
file in order to figure out which is at the leaf of the inheritance<br>
tree, right?<br>
<br>
If we forsee the necessity for the type function, I hence believe we<br>
should have ALTTYPE (if we want multiple types annotated at all).<br>
<span><br>
> There is another interesting use case where alternate types can greatly<br>
> simplify the life of the client implementor: abstract types. Let's say that<br>
<br>
</span>True -- but the attribute names work as abstract types, too (in your<br>
example, you'd be following the pointer to the error role, right?)<br>
<br>
So, the problem, as far as I can see, only exists for root-level,<br>
global objects that are not referenced by any other VO-DML object.<br>
Maybe that's an indication that it's not a problem of type annotation<br>
but of data model declarations? I'm not actually suggesting this at<br>
this point, but something that'd be attractive for many other reasons<br>
(and again wouldn't need VOTable changes) might be an inventory of<br>
root objects for a given data model within each data model<br>
declaration -- for instance, it'd also help applications find these.<br>
<span><br>
<br>
> <VODML><br>
> <ROLE>stc:SkyPosition.error</ROLE><br>
> <TYPE>mydm:MyEllipseError"</TYPE><br>
> <TYPE>stc:EllipseError</TYPE><br>
> <TYPE>stc:SkyError</TYPE><br>
> </VODML><br>
<br>
</span>Hmwell, yes, you see, this is what makes me skeptical. We'll have to<br>
formulate requirements or validity criteria, on what types VOTable<br>
writers will have to put here. What would that be?<br>
<br>
"Writers MUST include one TYPE element for each class in the<br>
inheritance chain"? That would incur a large baggage as you have<br>
fairly long inheritance chains even within a given model, and I'm<br>
quite sure you wouldn't want to dump these every time you write an<br>
annotation.<br>
<br>
"Writers MUST include one TYPE element for each class in the<br>
inheritance chain until an IVOA recommended data model is reached"?<br>
That would fix the worst uglyness, but apart from difficulties while<br>
developing such data models, I'm a bit nervous making the<br>
serialisation dependent on something as volatile as IVOA's set of<br>
standards (which changes roughly five times a year).<br>
<br>
<br>
To sum up: I believe the only thing multiple types give you that<br>
attribute names/utypes don't is allowing easy *top level* DM element<br>
localisation for *naive clients*. If this turns out to be a relevant<br>
use case, I'd say let's look at object directories in the DM<br>
declarations (which can be useful for other things, too) before<br>
futzing with the type calculus.<br>
<br>
Cheers,<br>
<br>
Markus<br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div>
<div dir="ltr">Omar Laurino<br>
Smithsonian Astrophysical Observatory<br>
Harvard-Smithsonian Center for Astrophysics
<div><font color="#999999">100 Acorn Park Dr. R-377 MS-81</font></div>
<div><font color="#999999">02140 Cambridge, MA</font><br>
<span style="color:rgb(153,153,153)"><a value="+16174957227" style="color:rgb(17,85,204)">(617) 495-7227</a></span></div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</body>
</html>