utype for STC region in SIAP query response
Arnold Rots
arots at head.cfa.harvard.edu
Fri Dec 16 07:18:11 PST 2011
I think I want to get back into this conversation.
The summary of my argument is:
- IVOA has a standard for describing regions: STC's Region
- That is precisely the kind of beast that a footprint is
- The STC-S serialization of STC Regions is eminently suited to describe
footprints since it is a (fairly) simple string that includes all
relevant information and provides a complete description in most
circumstances (and I don't intend to get into the exceptions here)
Yes, Alberto is correct, it should be:
stc:ObservationLocation.AstroCoordArea.Region
Although an earlier post from Markus provided the more genreal
version for a VOTable context:
<GROUP utype="stc:CatalogEntryLocation">
<FIELDref utype="stc:AstroCoordArea.Region" ref="footprint"/>
</GROUP>
The AstroCoordArea.Region could be a companent of a
CatalogEntryLocation, an ObservationLocations, etc.
These parent elements tell one what the footprint pertains to.
One would definitely not want to make it AstroCoordArea.Circle, since
the Circle specification would be provided in the STC-S value.
This scheme is simple, unambiguous, and based on an existing standard.
The STC-S strings are being used for footprint specifications in
various applications and have turned out to provide a mechanism that
is perfectly adequate for this task, as it has teh flexibility to
describe any footprint one can think of.
The remaining question might be whether one needs to identify a
particular instance of a Region as a footprint. I would argue that, in
a way, every region is a footprint of some kind. If it is a member of
an ObservationLocation, it is the footprint of an observation; if it
is a member of a CatalogEntryLocation, it is a catalog footprint.
One might reinforce the point with the FIELD's name, but that does not
change the nature of the item as defined by the utype.
Cheers,
- Arnold
Alberto Micol wrote:
>
> 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
> >
>
--------------------------------------------------------------------------
Arnold H. Rots Chandra X-ray Science Center
Smithsonian Astrophysical Observatory tel: +1 617 496 7701
60 Garden Street, MS 67 fax: +1 617 495 7356
Cambridge, MA 02138 arots at head.cfa.harvard.edu
USA http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------
More information about the dal
mailing list