regarding ALTTYPE [was RE: vo-dml in votable]

[gerard.lemson@gmail]

(if you get this multiple times is because I resend it form my gmail account with which I have been registered with the mailing lists, sorry).

Thank you Omar,
So your naïve clients seem to be still more naïve than I described. 
One might argue that do not really care about a data model at all, as they do not care about structure.
What is it they would do with a VOTable annotated with vodml metadata if that happens to be structured?
Do you think we can get some concrete examples of these based on a realistically (vodml-)annotated votable?

Your advanced clients seem to be still naïve by my definition, only thing they can do is understand a data model.
Would they still "need" the multiple VODML/TYPE elements?

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?

Cheers
Gerard

> -----Original Message-----
> From: Laurino, Omar [mailto:olaurino at cfa.harvard.edu]
> Sent: Tuesday, March 10, 2015 3:39 PM
> To: gerard.lemson at gmail
> Cc: Tom Donaldson; IVOA Applications WG; <dm at ivoa.net>
> Subject: Re: regarding ALTTYPE [was RE: vo-dml in votable]
> 
> Hi Gerard,
> 
> 
> On Tue, Mar 10, 2015 at 12:32 PM, gerard.lemson at gmail 
> <gerard.lemson at gmail.com <mailto:gerard.lemson at gmail.com> > wrote:
> 
> 
> 
> 	In this context, some of my questions are:
> 	1) is my characterisation of naive clients above correct, and if not
> 	complete, what does it miss?
> 
> 
> 
> The definitions for so called naive, advanced, and guru clients are in 
> the old Mapping document, i.e. the one we presented in Heidelberg:
> http://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/UTYPEs-
> WD-v.0.x.pdf
> 
> 
> I report them here for convenience:
> 
> This document defines a complete, unambiguous, standard specification 
> that can be used to serialize and de-serialize instances of Data Model 
> types. It was designed to be simple and straightforward to implement 
> by Data Providers and by different kind of clients.
> 
> We can classify clients in terms of how they parse the VOTable in 
> order to harvest its content. Of course, in the real word such 
> distinction is somewhat fuzzy, but this section tries and describe the 
> different levels of usage of this specification.
> 
> Naïve clients
> We say that a client is naïve if:
>   i) it does not parse the VO-DML description file
>   ii) it assumes the a priori knowledge of one or more Data Models
>   iii) it discovers information by looking for a set of predefined 
> UTYPEs in the VOTable In other terms, a naïve client has knowledge of 
> the Data Model it is sensitive to, and simply discovers information 
> useful to its own use cases by traversing the document, seeking the 
> elements it needs by looking at their @utype attribute. Examples of 
> such clients are the DAL service clients that allow users to discover 
> and fetch datasets. They will just inspect the response of a service 
> and present the user with a subset of its metadata. They do not reason 
> on the content, and they are not interested in the structure of the 
> serialized objects. If such clients allow users to download the files 
> that they load into memory, they should make sure to preserve the 
> structure of the metadata, so to be interoperable with other applications that might ingest the same file at a later stage.
> 
> Advanced clients
> We say that a client is advanced if:
>   i) it does not parse the VO-DML description file
>   ii) it is interested in the structure of the serialized instances
>   iii) can follow the mapping patterns defined in this specification, 
> for example collections, references, and inheritance41
> 
> Examples of such clients are science applications that display 
> information to the user in a structured way (e.g. by plotting it, or 
> by displaying its metadata in a user-friendly format), that reason on 
> the serialized instances, perform operations on those instances, and 
> possibly allow the users to save the manipulated version of the 
> serialization. Notice that the fact that an application does not 
> directly use some elements that are out of the scope of its 
> requirements does not mean that the application cannot provide them to 
> the user in a useful way. For example, an application might allow 
> users to build Boolean filters on a table, using a user-friendly tree 
> representing the whole metadata. This exposes all the metadata 
> provided by the Data Provider in a way that might not be meaningful 
> for the application, but that may be meaningful for the user. Notice, 
> also, that advanced clients may be DM-agnostic: for instance, an 
> Advanced Data Discovery application may allow the user to filter the results of a query by using a structured view of its metadata, even though it does not possess any knowledge of Data Models.
> 
> Guru clients
> We say that a client falls into this category if:
>   i) it parses the VO-DML descriptions
>   ii) it does not assume any a priori knowledge of any Data Models.
> 
> Such applications can, for example, dynamically allow users and Data 
> Providers to map their files or databases to the IVOA Data Models in 
> order to make them compliant, or display the content of any file 
> annotated according to this standard. This specification allows the 
> creation of universal validators equivalent to the XML/XSD ones. It 
> also allows the creation of VO-enabled frameworks and universal 
> libraries. For instance, a Python universal I/O library can parse any 
> VOTable according to the Data Models it uses, and dynamically build 
> objects on the fly, so that users can directly interact with those 
> objects or use them in their scripts or in science applications, and 
> then save the results in a VO-compliant format. Java guru clients 
> could automatically generate interfaces for representing Data Models and dynamically implement those interfaces at runtime, maybe building different views of the same file in different contexts.
> Notice that Guru frameworks and libraries can be used to build 
> Advanced or even Naïve applications in a user-friendly way, 
> abstracting the developers from the technical details of the standards 
> and using first class scientific objects instead.
> 
> 
> 
> 
> --
> 
> Omar Laurino
> Smithsonian Astrophysical Observatory
> Harvard-Smithsonian Center for Astrophysics
> 100 Acorn Park Dr. R-377 MS-81
> 02140 Cambridge, MA
> (617) 495-7227