utype for STC region in SIAP query response

[Markus Demleitner]

Dear list,

On Thu, Dec 15, 2011 at 06:28:59PM +0100, Alberto Micol wrote:
> >>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
Phew!  Thanks...

> 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.
Frankly, I don't think that's surprising: If you want to "support a
data model", you will have to link whatever data you deliver with
this data model.  If what you're delivering really contains instances
of seven data models, then you'll have seven such linkages.

I wouldn't be worried too much about efficiency -- we're only talking
about a few kilobytes, for all such linkages combined.  Doing the
mapping can be messier, but the effort to do that probably doesn't
change by orders of magnitude for different techniques of declaring
the pairs of data model elements and instance values.

As to elegance -- well, that's a different issue.  I sure don't
claim I'd build such a system if I could start from scratch....

> And that should happen for all the fields that are potentially in common
> among the selected data models.
There could be a solution to this, but it's probably too intrusive to
prescribe at this point.  Still, since the topic comes up I guess
there's no harm mentioning my little group references-as-utype values
scheme; the idea would be to write stuff like

<GROUP id="fp1" utype="stc:AstroCoordArea">    
  <PARAM name="href" datatype="char" arraysize="*"
     utype="stc:AstroCoordSystem.href"
     value="ivo://STClib/CoordSys#TT-ICRS-TOPO"/>
   <PARAM name="URI" datatype="char" arraysize="*"
     utype="stc:DataModel.URI"
     value="http://www.ivoa.net/xml/STC/stc-v1.30.xsd"/>
  <FIELDref ref="region" utype="stc:AstroCoordArea.Circle"/>
</GROUP>

to define, say, an area.  This could be picked up by anything
that understands STC; such a client would know there's an area, it
would work out the coordinate system, etc.

To actually say it's the footprint of an observation, you'd have,
say, an obscore group:

<GROUP utype="obscore:char.SpatialAxis">
  <PARAM name="u" datatype="char" arraysize="*"
    utype="obscore:char.spatialaxis.coverage"
    value="#fp1"/>
</GROUP>

(I'm not completely sold to the idea of using the #-syntax to say
"this value is a reference", but since it looks nicely familiar, I
think it's a start).

This would save you repeating all the information on, say, coordinate
systems, the STC DM used (and possibly much more) in the obscore
group.  I'd like that, but it makes parsing these things harder to
clients just wanting to handle obscore.  So, again it's a tradeoff
whether we want to design to make things simple for generic clients
or for consumers of specific data models.

If people think this whole referencing thing is worthwhile, *now* is
the time to say so, since the utypes document is being worked on, and
that would be the place to specify it.

> 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.
...*if* you want to support that data model.  But that's to be
expected, isn't it?

> 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.
Definitely.  And that's why I suggest to just say: If what you have
is remotely like an observation, include a group mapping it to
obscore types.  Same thing for photometric fields, STC fields,
whatever.

Generic clients would use that, and if fancier, more expressive data
models come along, servers and clients that *choose* to support them
can do so without clobbering their obscore, phot, whatever
declarations.  Thus the generic clients and servers will just
continue to work.  Wouldn't that be nice?

Cheers,

           Markus