utype for STC region in SIAP query response

[François Bonnarel]

Dear all,
      This discussion is really interesting but I think we should avoid 
being to theoretic and generic and do as we didn't have any material yet.

      a ) As far as I understand  the problem adressed by Alberto (and 
previously by Thomas ) is : "do we have a single utype for OBSERVATION 
footprints?"
and this whatever DAL protocol we are using: Obstap, SIA2, SSA, and 
maybe SED and Time series (as mentionned by Doug and Norman)... In that 
case the utype explicitly defined  by the Obscore/Obstap recommendation 
"obscore:Char.SpatialAxis.Coverage.Support.Area" is the most generic and 
should be reused in all the more precise and derived models of the 
specific protocols such as SIA2, SSA, etc ... Check the first SIA2 draft 
there 
http://www.ivoa.net/internal/IVOA/SiaInterface/WD-SIAP-2.0-20091104.pdf 
and you will discover the SAME utype for the same context allready more 
than 2 years ago...
       b ) stc is both a model and a structure definition ...for 
coordinates, regions in general and coordinate systems. Several possible 
structures (stc-X, stc-S) are defined for the same model attributes...
The full char/obs model defines Char.SpatialAxis.Coverage.Support.Area 
as an stc:AstroCoordArea structure... In this very specific case the use 
of an STC-S structure in the VOTABLE FIELD identified by the correct 
Obs/Char utype will be qualified by the   xtype="Stc-S" attribute of the 
FIELD and this will allow to INFER accuratly  the stc utype if 
needed...  All this is possible there because we are not talking of 
something generic but of using stc structures in the context of 
observation footprints...
       c ) The problem     of other kind of footprints, for example 
catalog or survey footprints  may require other combinations of stc 
structures or utypes with other models such as a catalog data model if 
it  exists some day. STC is generic for geometric regions and can 
require combination with other models for adding semantics as suggested 
by Norman... The actual combination mode is use-case dependant . 
References to STC-X structures may be possible or needed sometimes.
      d )  The solutions proposed by Norman and Markus are very generic 
and maybe really usefull in the case of other combinations of models 
than the one adressed by Thoams and Alberto . I have in mind 
Observation/provenance and simulation data model, or characterisation 
and simulation data models... BUt in the case of the obtsap and simple 
DAL  protocols,  I think the utype/xtype combination provides all what 
we need and is unambiguous...
Cheers
François

Le 19/12/2011 13:18, Norman Gray a écrit :
> Doug, hello.
>
> On 2011 Dec 19, at 01:33, Douglas Tody wrote:
>
>>> It cannot be the UTYPE, if every data model uses a different UTYPE for a
>>> footprint.
>> Well this is the key point; yes we can standardize the core model and
>> the UTYPE used for this purpose and they do not need to be different
>> despite being included in different models.  Yes the namespace (dataset
>> class or context) may be different for different classes of data, but
>> the UTYPE, minus the namespace prefix defining the context where it
>> used, can be the same and can be defined to meant the same thing.  This
>> is how UTYPEs have historically been used up to now, and we can
>> formalize this further in the UTYPE spec (hopefully without
>> over-complicating the mechanism).
> What would this achieve?
>
> Say an application comes across a UTYPE
>
>      foo:SpatialAxis.Coverage.Support.Area,
>
> and suppose that the 'foo' namespace was standardised after the application itself was written, or since it was last updated.  Should that application treat this as a footprint?
>
> I presume the answer is 'no'.  In that case, the application is stuck -- it has no idea what to do with this UTYPE, and cannot have any idea, until the application author reads the relevant standard and encodes it in an update of the application, which is then released and distributed.
>
> If the answer is 'yes', because 'SpatialAxis.Coverage.Support.Area' is expected to mean the same thing everywhere, then it is clear that there is no point in having namespaces, and people should stop talking about them.
>
> Best wishes,
>
> Norman
>
>