UTYPEs for SIAP

[Jonathan McDowell]

Hi Tom,

> reading Jonathan's proposal.  Basically I don't see how it
> advances what we can do already.  I just need to look in a
> different field for a different set of strings to do the
> same operations that I'm doing today.

I agree for the purposes of SIAP; this is more an exercise
for mapping VOTABLEs to DM objects in general.

In the telecon, the usual split appeared between 'simple VOTABLE with
UCDs is all we need' and 'don't make VOTABLEs, just return structured
XML documents'. The UTYPE proposal I made gives a recipe for mapping the
SIAP VOTABLE to a structured object. I am agnostic about whether such a
recipe should be implemented in automated software (teach the VO how to
map arbitrary VOTABLEs to  astronomical object classes),  or just seen
as a spec for how you replace that VOTABLE with object-based XML by hand.

> can be done with a given data element.  If data models are so
> specific that they are directly tied directly to columns  of
> a table, then what is their utility?

I don't entirely understand this point...

> The discussion of data models in SIAP needs first to identify
> the generic concepts that we want the SIAP to support.   Here's
> a very hastily put together concept more to illustrate the approach
> than a serious suggestion.
> [.....]

What you give here is a model for the SIA protocol, which is fine
but not what I am about here.
What I am doing is mapping the *response* from the protocol
to the model for images.

> [...] was more explicitly tied to images.  Ideally the
>   getResource() method would return an object that satisfied some
> Image data model.  

And that is essentially what the entries in the SIAP VOTable are, and
lo, behold,  they can be mapped to elements in the Image (Observation)
data model.

> As you may see this is completely different in approach.
> We haven't even begun to discuss the VOTable.   First we have

Right, and that's a fine approach - but we *have* a VOTable, and
I think it will help VOTable users understand data models if
we see where it sits in the currently defined
`high level abstract data models which the data can satisfy.'
Your complaint is that we have done SIA backwards, creating the
serialization before creating the data model. I agree, but that's
what we did, (and we had to, for speed)
- I don't see this as an argument against discussing
how it maps to the model.

> The association
> of quicklook data with non-quicklook data involves multiple rows, i.e., 
> rows that
> have the same logical name value but different formats.  So the data 

Eventually true, but a distinction that we can ignore for now.


> The user doesn't (and shouldn't care) about the internal organization of 
> the spectrum
> they just use the the public method.    So this single abstract data 
> model has
> at least two different concrete representations.   In the second case, 

Yes, but I think the different representations themselves have
data models - 'concrete data models' if you like, and one of them
is almost identical to the abstract one. Then we break down the
problem to: (1) map the serialization to the concrete data model
(a very direct process using utype type things in the case
of non-object-structured formats like votable), and (2) map
the concrete data model to the abstract data model, a predefined
software method on the concrete model. [For Votable fans: you do need
this second step in general, since you might have in your protocol
things that are combinations of the things you want out in the end.
If the abstract data model element required is 'B-V color', and you have
only 'B' and 'V', what is the utype? There isn't one in that data model
for B and V separately. So you use an intermediate data model which
talks in terms of B and V, and has corresponding utypes, and then map it
later. Lousy example but hopefully you get the idea.]


> - Data models are interfaces  (in JavaSpeak) that define what we can do 
> with the data.
Yes

> - Data models need to be instantiated as concrete objects. 
by 'concrete', you mean software objects.

> - The transformation between a serialization (e.g., an SIA VOTable response)
> and a concrete instantiation of a data model can be complex and cannot be reduced
> to a purely structural transformation (i.e., the data model can only be realized by
> an object which may have methods that operate on the fields defined in the
> serialization).

I would say rather that a serialization-specific data model (e.g. for SIA
VOTable response) would map to a general VO data model for images via
a transformation that is not purely structural (not just a rearrangement
but needed algorithmic calculations).

> -  Attempts to define a one-to-one correspondence between elements of the
> public data model and serialization of the data model are pointless (or 
> at least they will often fail).
Irrelevant for reason given above.

> -  A given concrete object may satisfy multiple data models (e.g., 
>   events lists).

Yes, but I think it is more useful to think of concrete serializations
as representing a data model that is close to their actual structure.
In other words, an event list "satisfies the image array data model"
via a transformation that bins the list on the fly, and it "satisfies
the event catalog model". But I think it is far from meaningless to 
work in terms of specific models that reflect the data storage structure,
as well as in terms of higher level models that are just interfaces.

> - Defining the high level interfaces for spectra, images and time series.
> - Defining the high level interfaces for basic transactions between VO 
> entities.

I think these are essentially the Observation and Quantity model documents
respectively.

 - Jonathan