utype for STC region in SIAP query response
Alberto Micol
amicol.ivoa at googlemail.com
Thu Dec 15 05:42:50 PST 2011
Dear All,
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.
Let me consider a well known client application (Aladin), and four quite
common use cases:
- As a user, I want to take the VOTable generated by a ObsTAP service
and display the contained footprints.
- As a user, I want to take the VOTable generated by a SIAP service
and display the contained footprints.
- As a user, I want to take the VOTable generated by a CharDM
compliant service,
and display the contained footprints.
- As a user, I want to take the VOTable generated by an archive query
form
and display the therein contained footprints
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 cannot be the FIELD name, given that only one of the three services
above (ObsTAP)
guarantees the name to always be "s_region".
Could it be a new UCD?
(Btw, when is that a client should look for a UCD, and when for a
UTYPE, to know what to do?)
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)
Would you suggest other ways, or the "good enough" way is already
listed above?
Note: In the years we have had the same discussion again and again,
this is just
the first time it happens for footprints. It would be nice to solve
the originating problem
not just the footprint problem.
Alberto
PS: I would love to suggest a 5th possibility, that is, to create a
new FIELD attribute, called stdname,
which hosts an IVOA standard name for all those quantities that
are really common across
all data models, e.g. "footprint", "telescope", "instrument", etc.,
as in <FIELD name="myFootprint" stdname="footprint"
utype="u.name.it" xtype="adql:Region">,
but I won't,
unless asked.
;-)
> In
> the case here, Char defines strong and consistent concepts for the
> measurement axes, Coverage, Support, etc. which are important to the
> Char model, and merely uses STC-S to represent the datum in question.
>
> Regarding UCDs for representing footprints in SIA-1, this can only be
> done by extension and there is no standard way to do it at present.
> We
> really need SIAV2 to address this sort of concern.
>
> - Doug
>
>
> On Thu, 1 Sep 2011, Arnold Rots wrote:
>
>> Here is what, in my view, is the correct utype for a footprint
>> region:
>>
>> stc:ObservationLocation.AstroCoordArea.Region
>>
>> Pretty simple; though one might quibble whether it should be:
>>
>> stc:ObsDataLocation.ObservationLocation.AstroCoordArea.Region
>>
>>
>> - Arnold
>>
>>
>> Francois Bonnarel wrote:
>> [ Charset ISO-8859-1 unsupported, converting... ]
>>> Hi Thomas,
>>> To complete my answer to Markus
>>> we could have something like
>>>
>>> <FIELD name="fov" unit="deg" xtype="STC-s" datatype="char"
>>> arraysize="*" utype="sia:Char.SpatialAxis.Coverage.Support.Area" >
>>>
>>> I think something like this can be proposed (if not yet the
>>> case)
>>> in SIA2...
>>> this will be consistent with ObsTap... and could also be
>>> included
>>> in the next version of SSA et al.
>>>
>>> For current SIA services, maybe we could have a short
>>> recommendation or note to propose using
>>> the same as an additional field in the SIA1 Query response
>>> Cheers
>>> Fran?ois
>>>> To illustrate my request, here is is how the STC-S FIELD is
>>>> described
>>>> in the query response of three different SIAP services :
>>>>
>>>> Service 1 : <FIELD name="position_bounds" unit="deg"
>>>> xtype="adql:REGION" datatype="char" arraysize="*">
>>>>
>>>> Service 2 : <FIELD name="stcs" datatype="char" arraysize="*"
>>>> ucd="phys.area;obs.field" unit="deg">
>>>>
>>>> Service 3 : <FIELD ID="regionSTCS" name="regionSTCS"
>>>> datatype="char"
>>>> arraysize="*">
>>>>
>>>> 3 different services, 3 different ways to express the same thing.
>>>> Having a unique unambiguous way to detect the STC-S field would be
>>>> very helpful for client consuming these services.
>>>> Cheers,
>>>>
>>>> Thomas
>>>>
>>>> Thomas Boch wrote:
>>>>> Fran?ois,
>>>>>
>>>>> I wish this is something that could be standardized in a
>>>>> forecoming
>>>>> revision of the SIAP document, so that clients can easily find out
>>>>> which FIELD support the STC-S description.
>>>>>
>>>>> Thomas
>>>>>
>>>>> Fran?ois Bonnarel wrote:
>>>>>> Hi Thomas,
>>>>>> Obstap has obs:Char.SpatialAxis.Coverage.Support.Area
>>>>>> for this . We have something similar in the SIA2 prototypes
>>>>>> I guess eventually for sia we will have something like
>>>>>> sia:Char.SpatialAxis.Coverage.Support.Area
>>>>>> although the problem of the name space is still to be
>>>>>> discussed...
>>>>>> By the way you can write this field as an STC-S feature ...
>>>>>> Cheers
>>>>>> Fran?ois
>>>>>> Le 29/08/2011 12:02, Thomas Boch a ?crit :
>>>>>>> Hi,
>>>>>>>
>>>>>>> Embedding a STC region in the SIAP query response is becoming
>>>>>>> more
>>>>>>> and more widespread, and we would like to support this feature
>>>>>>> in
>>>>>>> Aladin.
>>>>>>> I would like to know if there is a standard (or de facto
>>>>>>> standard)
>>>>>>> utype to characterize the FIELD holding the STC region
>>>>>>> description.
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Thomas
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> To illustrate my request, here is is how the STC-S FIELD is
>>>> described
>>>> in the query response of three different SIAP services :
>>>>
>>>> Service 1 : <FIELD name="position_bounds" unit="deg"
>>>> xtype="adql:REGION" datatype="char" arraysize="*">
>>>>
>>>> Service 2 : <FIELD name="stcs" datatype="char" arraysize="*"
>>>> ucd="phys.area;obs.field" unit="deg">
>>>>
>>>> Service 3 : <FIELD ID="regionSTCS" name="regionSTCS"
>>>> datatype="char"
>>>> arraysize="*">
>>>>
>>>> 3 different services, 3 different ways to express the same thing.
>>>> Having a unique unambiguous way to detect the STC-S field would be
>>>> very helpful for client consuming these services.
>>>> Cheers,
>>>>
>>>> Thomas
>>>>
>>>> Thomas Boch wrote:
>>>>> Fran?ois,
>>>>>
>>>>> I wish this is something that could be standardized in a
>>>>> forecoming
>>>>> revision of the SIAP document, so that clients can easily find out
>>>>> which FIELD support the STC-S description.
>>>>>
>>>>> Thomas
>>>>>
>>>>> Fran?ois Bonnarel wrote:
>>>>>> Hi Thomas,
>>>>>> Obstap has obs:Char.SpatialAxis.Coverage.Support.Area
>>>>>> for this . We have something similar in the SIA2 prototypes
>>>>>> I guess eventually for sia we will have something like
>>>>>> sia:Char.SpatialAxis.Coverage.Support.Area
>>>>>> although the problem of the name space is still to be
>>>>>> discussed...
>>>>>> By the way you can write this field as an STC-S feature ...
>>>>>> Cheers
>>>>>> Fran?ois
>>>>>> Le 29/08/2011 12:02, Thomas Boch a ?crit :
>>>>>>> Hi,
>>>>>>>
>>>>>>> Embedding a STC region in the SIAP query response is becoming
>>>>>>> more
>>>>>>> and more widespread, and we would like to support this feature
>>>>>>> in
>>>>>>> Aladin.
>>>>>>> I would like to know if there is a standard (or de facto
>>>>>>> standard)
>>>>>>> utype to characterize the FIELD holding the STC region
>>>>>>> description.
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Thomas
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>> Thomas Boch a ?crit :
>>>> To illustrate my request, here is is how the STC-S FIELD is
>>>> described
>>>> in the query response of three different SIAP services :
>>>>
>>>> Service 1 : <FIELD name="position_bounds" unit="deg"
>>>> xtype="adql:REGION" datatype="char" arraysize="*">
>>>>
>>>> Service 2 : <FIELD name="stcs" datatype="char" arraysize="*"
>>>> ucd="phys.area;obs.field" unit="deg">
>>>>
>>>> Service 3 : <FIELD ID="regionSTCS" name="regionSTCS"
>>>> datatype="char"
>>>> arraysize="*">
>>>>
>>>> 3 different services, 3 different ways to express the same thing.
>>>> Having a unique unambiguous way to detect the STC-S field would be
>>>> very helpful for client consuming these services.
>>>> Cheers,
>>>>
>>>> Thomas
>>>>
>>>> Thomas Boch wrote:
>>>>> Fran?ois,
>>>>>
>>>>> I wish this is something that could be standardized in a
>>>>> forecoming
>>>>> revision of the SIAP document, so that clients can easily find out
>>>>> which FIELD support the STC-S description.
>>>>>
>>>>> Thomas
>>>>>
>>>>> Fran?ois Bonnarel wrote:
>>>>>> Hi Thomas,
>>>>>> Obstap has obs:Char.SpatialAxis.Coverage.Support.Area
>>>>>> for this . We have something similar in the SIA2 prototypes
>>>>>> I guess eventually for sia we will have something like
>>>>>> sia:Char.SpatialAxis.Coverage.Support.Area
>>>>>> although the problem of the name space is still to be
>>>>>> discussed...
>>>>>> By the way you can write this field as an STC-S feature ...
>>>>>> Cheers
>>>>>> Fran?ois
>>>>>> Le 29/08/2011 12:02, Thomas Boch a ?crit :
>>>>>>> Hi,
>>>>>>>
>>>>>>> Embedding a STC region in the SIAP query response is becoming
>>>>>>> more
>>>>>>> and more widespread, and we would like to support this feature
>>>>>>> in
>>>>>>> Aladin.
>>>>>>> I would like to know if there is a standard (or de facto
>>>>>>> standard)
>>>>>>> utype to characterize the FIELD holding the STC region
>>>>>>> description.
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Thomas
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> =
>>> ====================================================================
>>> Fran?ois Bonnarel Observatoire Astronomique de
>>> Strasbourg
>>> CDS (Centre de donn?es 11, rue de l'Universit?
>>> astronomiques de Strasbourg) F--67000 Strasbourg (France)
>>>
>>> Tel: +33-(0)3 68 85 24 11 WWW: http://cdsweb.u-strasbg.fr/people/fb.html
>>> Fax: +33-(0)3 68 85 24 25 E-mail: francois.bonnarel at astro.unistra.fr
>>> ---------------------------------------------------------------------
>>>
>> --------------------------------------------------------------------------
>> 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