<div dir="ltr">Hi Gerard,<br><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 10, 2015 at 4:33 PM, glemson1@jhu <span dir="ltr"><<a href="mailto:glemson1@jhu.edu" target="_blank">glemson1@jhu.edu</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
One might argue that do not really care about a data model at all, as they do not care about structure.</blockquote><div><br></div><div>Well, one might argue either way, and probably the definitions in the mapping document would have benefitted from some feedback ;)</div><div><br></div><div>When it says that naive clients are not (necessarily) interested in the structure of the instance, I mean that they may be after a few items in a response that is probably already somewhat flat. One example can be the DAL client that is only interested in a few vodml-ids/utypes. A slightly more complicated case is an STC library that can convert coordinates into different frames: it would not be interested in what the coordinates represent inside the larger data model, and in this sense it is not interested in the structure of the instance in which the STC positions are nested: it just goes after all the coordinates in the file and converts them according to the user's input, ignoring everything else.</div><div><br></div><div>But you are probably right that the way it is phrased makes it seem like a naive client is not interested in any structure at all, and that is not true. At the very least it needs to read the VOTable structure and some (albeit simple) STC structures.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Do you think we can get some concrete examples of these based on a realistically (vodml-)annotated votable?<br></blockquote><div><br></div><div>I think we should definitely reboot the prototyping efforts and validate the suggested VOTable changes. After more than two years of documenting, prototyping, and implementing I am not particularly excited to start everything over, but this is just the way it is. What we learned in the past can still be valuable and it is not like we are starting from scratch.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Your advanced clients seem to be still naïve by my definition, only thing they can do is understand a data model.<br>
Would they still "need" the multiple VODML/TYPE elements?<br></blockquote><div><br></div><div>As I said, and as Pat I believe remarked, multiple TYPEs can be used to optimize the discovery of instances of certains types in a way that is compatible with the extensibility requirement, which is a requirement we decided to support when we started three years ago. We can do without them, but I think dropping them would make the life of naive clients (in the sense described by the mapping document) somewhat less robust.</div><div><br></div><div>We can indeed question the whole Mapping specification again in ways that are not just syntactically different, and explore other solutions. In that case indeed you probably don't even need multiple TYPEs as an optimization prop.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Your guru clients are my meta-clients I think. So you do not have sophisticated clients as I define them. I.e. those that are able to parse VO-DML documents if necessary, but still only interested in a particular data model about which they know the esemantics. Does this mean we need 4 categories In our discussion?<br></blockquote><div><br></div><div>I don't read in your comments anything that seems to require a fourth category. In the introduction to the clients definition it is said that this is a crisp classification but that in real life clients would probably be hybrids. Take Iris as an example: there is no way Iris can assume knowledge of every possible extension of the SED-related Data Model. Iris will use some of the types defined in several data models to provide scientific tools that have to do with SEDs. However, it can still provide the Metadata Browser, that is a DM-agnostic exploration tool the user might find rather useful to filter and manipulate the data. In this sense Iris would probably be a mix of Guru, Advanced, and maybe even Naive code.</div><div><br></div><div>Your comments, to me, seem to fall in between the crisp categories defined in the mapping document, not outside the perimeter they define.</div><div><br></div><div>Omar.</div><div><br></div><div>P.S. In my previous email I might have mixed up the VOTable change proposals, but that should have been clear from what I argued. I believe 4c is the only proposal that does not have ALTTYPE but allows for multiple types. There seems to be consensus that we can do without the multiple TYPEs, so my vote is for a slightly different version of 4c where the TYPE multiplicity is bound to 0..1. This can be turned into an open multiplicity in the future if we think we need multiple TYPEs afterall.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Cheers<br>
Gerard<br>
<span class="im"><br>
> -----Original Message-----<br>
> From: Laurino, Omar [mailto:<a href="mailto:olaurino@cfa.harvard.edu">olaurino@cfa.harvard.edu</a>]<br>
> Sent: Tuesday, March 10, 2015 3:39 PM<br>
> To: gerard.lemson@gmail<br>
> Cc: Tom Donaldson; IVOA Applications WG; <<a href="mailto:dm@ivoa.net">dm@ivoa.net</a>><br>
> Subject: Re: regarding ALTTYPE [was RE: vo-dml in votable]<br>
><br>
> Hi Gerard,<br>
><br>
><br>
> On Tue, Mar 10, 2015 at 12:32 PM, gerard.lemson@gmail<br>
</span><div class=""><div class="h5">> <<a href="mailto:gerard.lemson@gmail.com">gerard.lemson@gmail.com</a> <mailto:<a href="mailto:gerard.lemson@gmail.com">gerard.lemson@gmail.com</a>> > wrote:<br>
><br>
><br>
><br>
> In this context, some of my questions are:<br>
> 1) is my characterisation of naive clients above correct, and if not<br>
> complete, what does it miss?<br>
><br>
><br>
><br>
> The definitions for so called naive, advanced, and guru clients are in the old<br>
> Mapping document, i.e. the one we presented in Heidelberg:<br>
> <a href="http://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/UTYPEs-" target="_blank">http://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/UTYPEs-</a><br>
> WD-v.0.x.pdf<br>
><br>
><br>
> I report them here for convenience:<br>
><br>
> This document defines a complete, unambiguous, standard specification that<br>
> can be used to serialize and de-serialize instances of Data Model types. It was<br>
> designed to be simple and straightforward to implement by Data Providers and<br>
> by different kind of clients.<br>
><br>
> We can classify clients in terms of how they parse the VOTable in order to<br>
> harvest its content. Of course, in the real word such distinction is somewhat<br>
> fuzzy, but this section tries and describe the different levels of usage of this<br>
> specification.<br>
><br>
> Naïve clients<br>
> We say that a client is naïve if:<br>
> i) it does not parse the VO-DML description file<br>
> ii) it assumes the a priori knowledge of one or more Data Models<br>
> iii) it discovers information by looking for a set of predefined UTYPEs in the<br>
> VOTable In other terms, a naïve client has knowledge of the Data Model it is<br>
> sensitive to, and simply discovers information useful to its own use cases by<br>
> traversing the document, seeking the elements it needs by looking at their<br>
> @utype attribute. Examples of such clients are the DAL service clients that allow<br>
> users to discover and fetch datasets. They will just inspect the response of a<br>
> service and present the user with a subset of its metadata. They do not reason<br>
> on the content, and they are not interested in the structure of the serialized<br>
> objects. If such clients allow users to download the files that they load into<br>
> memory, they should make sure to preserve the structure of the metadata, so to<br>
> be interoperable with other applications that might ingest the same file at a<br>
> later stage.<br>
><br>
> Advanced clients<br>
> We say that a client is advanced if:<br>
> i) it does not parse the VO-DML description file<br>
> ii) it is interested in the structure of the serialized instances<br>
> iii) can follow the mapping patterns defined in this specification, for example<br>
> collections, references, and inheritance41<br>
><br>
> Examples of such clients are science applications that display information to the<br>
> user in a structured way (e.g. by plotting it, or by displaying its metadata in a<br>
> user-friendly format), that reason on the serialized instances, perform<br>
> operations on those instances, and possibly allow the users to save the<br>
> manipulated version of the serialization. Notice that the fact that an application<br>
> does not directly use some elements that are out of the scope of its<br>
> requirements does not mean that the application cannot provide them to the<br>
> user in a useful way. For example, an application might allow users to build<br>
> Boolean filters on a table, using a user-friendly tree representing the whole<br>
> metadata. This exposes all the metadata provided by the Data Provider in a way<br>
> that might not be meaningful for the application, but that may be meaningful for<br>
> the user. Notice, also, that advanced clients may be DM-agnostic: for instance,<br>
> an Advanced Data Discovery application may allow the user to filter the results<br>
> of a query by using a structured view of its metadata, even though it does not<br>
> possess any knowledge of Data Models.<br>
><br>
> Guru clients<br>
> We say that a client falls into this category if:<br>
> i) it parses the VO-DML descriptions<br>
> ii) it does not assume any a priori knowledge of any Data Models.<br>
><br>
> Such applications can, for example, dynamically allow users and Data Providers<br>
> to map their files or databases to the IVOA Data Models in order to make them<br>
> compliant, or display the content of any file annotated according to this<br>
> standard. This specification allows the creation of universal validators equivalent<br>
> to the XML/XSD ones. It also allows the creation of VO-enabled frameworks and<br>
> universal libraries. For instance, a Python universal I/O library can parse any<br>
> VOTable according to the Data Models it uses, and dynamically build objects on<br>
> the fly, so that users can directly interact with those objects or use them in their<br>
> scripts or in science applications, and then save the results in a VO-compliant<br>
> format. Java guru clients could automatically generate interfaces for<br>
> representing Data Models and dynamically implement those interfaces at<br>
> runtime, maybe building different views of the same file in different contexts.<br>
> Notice that Guru frameworks and libraries can be used to build Advanced or<br>
> even Naïve applications in a user-friendly way, abstracting the developers from<br>
> the technical details of the standards and using first class scientific objects<br>
> instead.<br>
><br>
><br>
><br>
><br>
> --<br>
><br>
> Omar Laurino<br>
> Smithsonian Astrophysical Observatory<br>
> Harvard-Smithsonian Center for Astrophysics<br>
> 100 Acorn Park Dr. R-377 MS-81<br>
> 02140 Cambridge, MA<br>
> <a href="tel:%28617%29%20495-7227" value="+16174957227">(617) 495-7227</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><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>