utype for STC region in SIAP query response

[Norman Gray]

Greetings, all.

On 2011 Dec 15, at 13:42, Alberto Micol wrote:

> On 2 Sep 2011, at 01:40, Douglas Tody wrote:
> 
>> This would be a fine solution, considering only STC; however it is
>> perfectly legal for a DM to be based upon other models (in a way
>> defined
>> by the new model such as Char or SIA) and define new, more
>> application-specific Utypes.  There is an especially strong argument
>> for
>> this for essential elements of the new model so that we have a well
>> defined and self consistent model.  "Falling through" to reference
>> arbitrary elements of another model, with its own externally defined
>> namespace, is fine for extension but could significantly expand the
>> complexity of the new model as a client application might then need to
>> fully understand multiple models to be able to deal with the data.
> 
> There are two kinds of clients: it seems to me that Doug here above
> refers to client applications that deal with a specific data model,
> while what I'm going to describe is the case of a generic client.

[use-cases snipped]

> What is the magic bit that will allow Aladin to recognise a given
> FIELD as a footprint?
> 
> It cannot be the UTYPE, if every data model uses a different UTYPE for
> a footprint.

It can be, and I think it should be (I'm being a broken record, here...)

To pick up Markus's example, you want to indicate that a particular FIELD is a char:SpatialAxis.Coverage.Support.Area, without excluding clients who only understand another data model.  They can understand stc:AstroCoordArea.Circle, but not the char ones.

Markus describes a way in which a VOTable can indicate that a particular FIELD can be associated with more than one utype.  However, if I'm understanding Markus's example correctly, that depends on the author_of_that_VOTable making the multiple associations, and they could (a) be mistaken, or (b) forget one.

(This situation becomes more extreme if some data provider wants or needs to extend the notion of footprint to some more precise notion, and wants to be able to distribute data using that data model.)

What would be preferable is for the author_of_the_utype to say that ...Support.Area is a ...AstroCoordArea.Circle.  The advantages of this are:

  * The group which created the utype can be authoritative about what this utype means.

  * This doesn't rely on the authors of VOTables remembering to include all of the other data models that a FIELD can be regarded as referring to.

Such a mechanism is technically feasible, and straightforward to implement and use.  If you do the equivalent of 

    % curl char:SpatialAxis.Coverage.Support.Area
    char:SpatialAxis.Coverage.Support.Area is a stc:AstroCoordArea.Circle
    %

or 

    % curl http://example.org/resolver?char:SpatialAxis.Coverage.Support.Area
    stc:AstroCoordArea.Circle
    %

...then any type of client which sees the char:SpatialAxis.Coverage.Support.Area can know that it can treat this as a stc:AstroCoordArea.Circle with the blessing of the char authors.

This doesn't have to be done dynamically (shudder), but could be cached aggressively, or done at 'compile' time.

This mechanism requires minimal standardisation, requires no major complication to clients, but provides significant interoperability.

This mechanism is worked out in precise detail in <http://www.ivoa.net/Documents/Notes/UTypes/utype-uri-20070302.html#utype-rdf>.  I did implement the resolver service that document describes, and found no problems.

Markus again:

> The only logical possibilities I see, with different levels of
> technical or political difficulty to implement,
> are:
> 
> 1.- to standardise the footprint UTYPE across all data models
> 2.- to standardise the FIELD name of a footprint field, a la ObsTAP
> 3.- to create a new UCD for a footprint
> 4.- to use xtype="adql:Region" (is that acceptable? xtype is really
> meant to represent the storage units)

The fifth possibility is to get a UType to itself explain what it is.  That requires no syntactical changes, no new standardised utypes, no standarised FIELD names, and no new UCDs.

If you as a client are asked to do something with a Utype you don't recognise, you look it up, and are told "char:SpatialAxis.Coverage.Support.Area is like stc:AstroCoordArea.Circle".  You don't have to ask again.

All the best,

Norman


-- 
Norman Gray  :  http://nxg.me.uk
SUPA School of Physics and Astronomy, University of Glasgow, UK