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

[gerard.lemson@gmail]

Hi all

I think that this whole discussion thread on ALTTYPE and its variants
assumes the existence and a certain nature of so called "naive vodml
clients". It assumes that we need to cater to such clients and that a
VODML/ALTTYPE element added to the VODML annotation would resolve the issues
these clients would have if such an element would not exist.
I think it would be good if we could define this "naive client" use case in
a bit more detail AND to get concrete and realistic examples for them. This
will allow us to decide how important it is to support them, whether to do
this now rather than at a later time and it allows us to discuss possible
alternative solutions that might not require the ALTTYPE feature that most
find rather ugly.

To set the stage, I think a naive client is assumed to *understand* at least
one data model. In this context, "understand" means that it can perform
specific actions and/or provide specific functions based on meta-data
("vodml annotations") representing elements from that data model. I.e. naive
clients understand the semantics of one or more data models. An example may
be metadata representing STC information, allowing an appropriate client to
plot something on an image, or perform a cross match. Or a client
understanding the photometry model can use metadata to create SEDs, or color
magnitude diagrams.

This does not make these clients naive by themselves; also "sophisticated
clients" will generally be tailored to (understand the semantics of) only
certain data models and provide corresponding functionality. What (I think)
distinguishes sophisticated clients from naive ones is that they can do
inference on unknown vodml annotations to find out whether they might have
some known components. I.e. whether they can understand (parts of) the
unknown model.
For example sophisticated clients can at runtime download and parse a
VO-DML/XML document indicated by a Model annotation in a VOTable, and can
infer that a certain vodml annotation identifies an unknown type that
extends a type that it *does* understand in the above sense. I.e.
sophisticated clients can infer something useful about the semantics of
other models that they have not been explicitly coded for. I think naive
clients, by definition, cannot do that. (*)

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?
2) how do we assume such naive clients will actually use vodml-annotated
votables? parse+infer? query using XPath/XSLT?
Here it would be good/imperative to have concrete and realistic examples.
3) what prevents these tools from being more sophisticated?
4) can we build tools/libraries/access patterns that make it easier to turn
a naive tool into a sophisticated one, or is something like the ALTTYPE
proposal (in some form) the only solution?
Can we learn here from the way ontology frameworks handle such matters?
5) is it a very bad thing that tools that are unwilling to be a bit more
sophisticated may not be able to deal with each annotated votable? As a
somewhat similar issue, if I write a "naive" stc tool that can only deal
with equatorial coordinates, does that mean that all data providers have to
provide such data? 
Or can I be expected to include some libraries that can transform between
coordinate systems and if I do not do that I will just not be able to handle
data coming with galactic coordinates for example? 
6) might there be inherent disadvantages in using naive tools that could
lead us to not spend too much time/effort in trying to accomodate our
standards to them? E.g. as an admittedly silly example, I think it would be
dangerous for a cross-match tool to rely on knowing only stc. 
You don't want it to start cross matching positions of sources with
positions of the left-lower pixel in an image, or the position of a source
in a mock catalogue. 

Waiting for your comments.

Cheers
Gerard

(*)
Note, "sophisticated clients" are still different from what one could call
meta-clients.
Those are defined to understand VO-DML models in a generic, "meta" sense.
In general such tools will not understand the semantics of the models, only
their structure.
Examples are tools that generate "physical representations" from a VO-DML
data model (e.g. XML schema, java class definitions, relational tables);
tools that can validate the vodml annotation of votables [Note, this is a
motivation for having the explicit VODML/TYPE element at all]; tools that
translate these to such instances of the above physical representations
(e.g. XML documents, Java objects in memeory); or a tool such as the "VO-DML
Mapper" tool I built and presented at interops that allow generic VO-DML
models to be mapped to votables or tap schema.
The fact that we can write such tools at all is of course because we have a
(proposal for a) formal data modelling language and a (proposal for a)
mapping language.