utype for STC region in SIAP query response
François Bonnarel
francois.bonnarel at astro.unistra.fr
Thu Dec 15 13:10:56 PST 2011
Hi Alberto, all
Le 15/12/2011 14:42, Alberto Micol a écrit :
>
> 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
> enerated by a CharDM compliant 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.
Well I think the utype for footprint in ObsTAp , ie
"obscore:Char.SpatialAxis.Coverage.Support.Area" will be
"sia:Char.SpatialAxis.Coverage.Support.Area" in SIA2...
same classes and attribute in different namespaces ...
>
> - As a user, I want to take the VOTable generated by a CharDM
> compliant service,
> and display the contained footprints.
>
A VOTABLE generated by a CharDM compliant service should have
"Char.SpatialAxis.Coverage.Support.Area" as a name space for a
footprint. Actually the Obstap utype is a char utype in that case no ?
> - 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.
>
In that case IVOA model should not use different utypes. See current
discussion on utypes ....
> It cannot be the FIELD name, given that only one of the three services
> above (ObsTAP)
> guarantees the name to always be "s_region".
>
yes
> 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?)
>
I dont' think so UCD is too fuzzy in general...
> 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
Yes, basically that's the direction we are going to.
>
> 2.- to standardise the FIELD name of a footprint field, a la ObsTAP
two much constraint on non-ObsTAP services
>
> 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.
Yes, see the utype current restart and finalizing effort (started in Pune)
>
> Alberto
Regards
François
>
> 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