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

[glemson1@jhu]

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