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

[Laurino, Omar]

Hi Gerard,



On Tue, Mar 10, 2015 at 4:33 PM, glemson1 at jhu <glemson1 at jhu.edu> wrote:
>
> One might argue that do not really care about a data model at all, as they
> do not care about structure.


Well, one might argue either way, and probably the definitions in the
mapping document would have benefitted from some feedback ;)

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.

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.


Do you think we can get some concrete examples of these based on a
> realistically (vodml-)annotated votable?
>

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.


>
> 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?
>

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.

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.


>
> 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?
>

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.

Your comments, to me, seem to fall in between the crisp categories defined
in the mapping document, not outside the perimeter they define.

Omar.

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.



>
> 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
>
>


-- 
Omar Laurino
Smithsonian Astrophysical Observatory
Harvard-Smithsonian Center for Astrophysics
100 Acorn Park Dr. R-377 MS-81
02140 Cambridge, MA
(617) 495-7227
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20150310/83eab51f/attachment.html>