utype for STC region in SIAP query response

[Alberto Micol]

Dear Norman,

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.

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

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.

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?

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?

Thanks,
Alberto


On 16 Dec 2011, at 11:14, Norman Gray wrote:

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