utype for STC region in SIAP query response

[Alberto Micol]

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

Yes!

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

No, you are not getting onto my nerves, I hope you will say the same  
after
reading this email...

Yes, what you proposed and propose is a possible solution, but
it is not elegant, nor efficient.
Instead of unifying concepts, you propose to multiply FIELDrefs.

One would have to potentially introduce a FIELDref as many times as  
there are data models.

And that should happen for all the fields that are potentially in common
among the selected data models.

Quite a useless and inefficient multiplication of FIELDrefs.
And a multiplication that is bound to grow in the future when
e.g. SIAP2 will be out, and then will come the SED thingy,
and so on and so forth.

Basically my super-duper archive service will have to know about all  
possible models,
and will have to change every time a new model comes out.

My point is that a footprint is a footprint,
no matter which protocol is used. The concept "footprint" is super  
partes.

And definitively I want my service to also be super partes
to reduce maintenance, and because simpler is better.

Alberto



On 15 Dec 2011, at 17:59, Markus Demleitner wrote:


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