utype for STC region in SIAP query response

[Markus Demleitner]

Hi all,

On Thu, Dec 15, 2011 at 02:42:50PM +0100, Alberto Micol wrote:
> 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.
D'accord -- by the way, even on the server side, not having three
different representations for the same thing is nice once you're
speaking more than one protocol or you're delivering VOTables to,
say, HTML forms and still want to define your STCs.

> 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.
Yes it can, and it should be.  Sorry if I'm getting on your nerves,
but let me again promote the group/fieldref mechanism.

Using it, a single FIELD can fill as many roles as you want; that is,
you can define its role in char *and* whatever fancy data model you
want to support in addition.  In particular, you can have the
generic designation as a footprint, using, say, the char model:

<GROUP utype="char:SpatialAxis">
  <FIELDref utype="char:SpatialAxis.Coverage.Support.Area"
    ref="footprint"/>
</GROUP>

(in reality, I'd say let's agree on obscore types for this kind of
thing, but char would be somewhat more logical) and *at the same
time* use that column to fill some role in another data model, say:

<GROUP utype="stc:CatalogEntryLocation">
  <FIELDref utype="stc:AstroCoordArea.Circle" ref="footprint"/>
</GROUP>

So, both clients that understand char and clients that understand
stc can make sense of that field within what those models give them.
If we just said "if you have an observation, please include a group
linking your data to the obscore model to the extent possible" and
"please include a group defining your coordinate systems whenever
you're talking about coordinates" in some appropriate place (the
VOTable spec?), IMHO we'd have made quite a step towards relatively
simple but useful metadata for a large proportion of the astromonical
data out there.

Sorry to repeat that again -- but I still feel we're trying to solve
something here that's already solved ever since FIELDref and
PARAMref were introduced to VOTable.

Cheers,

      Markus