utype for STC region in SIAP query response

[Norman Gray]

Alberto, hello.

On 2011 Dec 16, at 11:36, Alberto Micol wrote:

> Little note: I think you meant not stc:AstroCoordArea.Circle
> but stc:ObservationLocation.AstroCoordArea.Region instead.
> At least, I read your email with this in mind.

Quite possibly -- I confess to not having all of STC comfortably in my head.

> Presumably, your utype resolver service will return multiple answers,
> not just one:  Shouldn't it return all the possible associations?

The resolver I wrote did return all the things which were 'more general' than the utype it was asked to explain.  One can be more precise than this, but the resolver was intended to act as a bare-bones help to a client-in-a-hurry.

> I think so, unless you tell me that there is, for any concept,
> one UTYPE that is better than any other one, that is meant to be
> the progenitor, and defined to be the "standard" utype for that concept.

No, there's no implicit idea that there's one utype which is better than all others in a particular context.

The paradigmatic case is where someone (or some application) wants to use a utype such as ...AstroCoordArea.Region _but_ it's not quite right.  For example the Char notion of 'footprint' isn't just a _region_, but is instead a region where there is coverage, to which the Char data model gives the more precise name char:SpatialAxis.Coverage.Support.Area.

Any application which knows what a ...Coverage.Support.Area is, will presumably be familiar with the IVOA's blessed Char semantics for this.  A more generic application which doesn't have to care about footprints, but which _is_ able to display regions, will presumably know what an ...AstroCoordArea.Region is, and so can be useful here, as long as it can be told that the ...Coverage.Support.Area is more or less the same thing.

One can imagine other relationships between utypes; the resolver I mentioned is intended to help with the simplest and commonest case of 'more specific than'.

> If you really meant that one and only one utype, the best one, is  
> returned,
> well, then we would need a standardisation process for this, isn't it?

There would be no standardisation required, beyond the requirement that, if IVOA data models (ie utype sets) want to play well with this mechanism, they document their relationship with other data models using the mechanism described in <http://www.ivoa.net/Documents/Notes/UTypes/utype-uri-20070302.html> (which means putting onto the web a file in an already-standardised syntax).  Those relationships could very naturally be included in the existing definitions of those data models.

> And wouldn't that be equivalent to the (tiring) standardisation
> process already happening, as mentioned by Francois Bonnarel,
> whereby a new data model does not invent new utypes, but
> reuse them?

In this picture, a data model consists of a set of coherent concepts (such as in the Char model).  Often, some of those concepts will be the same as, or similar to, concepts in other data models.  This can be handled either by importing (which can become complicated), or by description: "newmodel:A is the same as popularmodel:X, but newmodel:B is a refinement of concept popularmodel:Y".

If a client already knows how to deal with popularmodel:X and popularmodel:Y, then it can already deal with newmodel:A and newmodel:B.  Interoperability is achieved!

This sounds exotic, but it's not.  The way of doing this is already standardised and already deployed all over the web.

Best wishes,

Norman


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