Doubts with the facility name term

[Mireille LOUYS]

Hi Semantics,

Thank you Tamara for bringing up this issue .

In the semantics WG,  we  have been involved in some work for describing 
and normalizing metadata about telescopes and instruments, also in 
collaboration with the community of librarians at astronomical data 
centers .

There are various levels of information for describing  the acquisition 
chain providing an observation.
instrument name and telescope name are usually not enough, because , 
they are not uniquely defined , and depend on more context information : 
ground observing systems versus satellite systems , etc.
So the information is spread in various notions .
May be this presentation given at interop meeting in Paris gives an idea :
https://wiki.ivoa.net/internal/IVOA/InterOpMay2019Semantics/telInstrepo-ParisInterop19-EM-ML.pdf
<https://wiki.ivoa.net/internal/IVOA/InterOpMay2019Semantics/telInstrepo-ParisInterop19-EM-ML.pdf>
The approach was from very general to specific to be able to sketch out 
a data model for the necessary metadata.
In this exercise,  we have been able to identify many situations where 
the name of an instrument/telescope  does not suffice or is ambiguous.

Together with B. Cecconni we also conducted some work on merging lists 
of names and properties for telescope, instruments, spacecratfs, etc. in 
order to resolve duplicates and build master lists.
The first steps have been  hard due to missing or incomplete 
information, ambiguity on names, change of locations for some 
instruments, etc.

As Stephane mentionned earlier, and also inspired from the PDS 4 
Information system,
what helps to determine the minimum instrumental identification is the link
/instrument <----> instrument_host //
/so a PID for each would help to uniquely identify the instrumental 
combination/.

/I think /instrument_host /is more appropriate than /facility/ , it can 
tackle more situations.

If we are able to mint a PID for each /instrument_host/ and for 
each/instrument
/the ObsCore spec could evolve to support also:
/instrument_pid/ in addition to instead of the ambiguous instrument 
name, and
/instr_host_pid /instead of facility name.

Some work started recently to homogeneize lists of instruments and 
instruments hosts at Paris Observatory.

Taxonomy is involved for the definition of instrument types, and host 
types as well.
If we would like this to be defined as IVOA vocabularies, we could get 
inspired by the PDS4 instrument type list , for instance .

https://pds.nasa.gov/datastandards/documents/im/current/index_1H00.html#class_pds_instrument


best wishes, Mireille

Le 10/02/2022 à 13:18, Stéphane Erard a écrit :
> Hello
>
> As you know, in EPNCore we use a simple system to facilitate data search:
>
> Instrument_host_name : is an observatory, spacecraft, or facility ( = lab) - by observatory here, we really mean: telescope
> Instrument_name : is an instrument, either spatial, accommodated on the telescope, or in the lab
>
> Since EPNCore parameters support list of values, indications broader than a single telescope (observatory site) can also be included here.
>
> We can also provide a finer structure with:
> detector_name to specify a single detector in complex instruments, typically a channel in a space borne instrument.
> opt_elem for optional optical elements (grating, etc)
>
> E.g.:
> I find HST data with Instrument_host_name  LIKE ‘%HST%’
> 	or ivo_hashlist_has(Instrument_host_name, ‘HST') = 1
>
> And I’ll use the same query to look for data from Paranal or ESO (with little chance of success I must say).
> - Same for Rosetta Orbiter and Rosetta - they would both share the same parameter if provided
> But I see little reasons to search for ESO (or ESA), at least for users with EPNCore (although it makes sense when querying the registry, but I expect the data origin to be specified there).
>
> There may be a missing parameter in EPNcore, but we all know that describing a hierarchy of things with 10 keywords is always counterproductive — the user never knows where the search value has to be located, and data providers got it wrong half the time (e.g., mineral descriptions in lab databases are living nightmares - here we decided to put everything in a single parameter with no special order).
>
>
> I must add that what makes the system work is really to use limited lists of possible values, simple names with no fancy variations (lesson learnt from PDS3).
>
> Hope this helps,
> Stéphane
>
>
>> Le 9 févr. 2022 à 11:13, Markus Demleitner<msdemlei at ari.uni-heidelberg.de>  a écrit :
>>
>> Dear Semantics folks,
>>
>> On Thu, Feb 03, 2022 at 02:20:46PM +0100, Tamara Civera wrote:
>>> I am writing to this group, because trying to unify the facility name in the
>>> different VO services offered by my observatory (SIAP, Obscore,...) the
>>> following doubt has arisen: *Should the facility name describe only the
>>> facility or observatory, the telescope or both?*
>>>
>>> According to the different VO protocols documentation:
>>>
>>> Obscore: "B7.1 The Facility class codes information about the observatory or
>>> facility used to collect the data."
>>>
>>> Obscore: "C.3 <FIELDname="facility_name"datatype="char"ucd="meta.id;instr.tel"utype="obscore:Provenance.ObsConfig.Facility.name"xtype="adql:VARCHAR"arraysize="128*"><DESCRIPTION>telescope
>>> name</DESCRIPTION></FIELD>"
>>>
>>> SIAP 2.0: "2.1.12 The FACILITY parameter is a string-valued parameter that
>>> specifies the name of the facility (usually telescope) where the data was
>>> acquired. The value is compared with the facility_name from the ObsCore [7]
>>> data model"
>>>
>>> VoDataService: "3.1.1 The observatory or facility used to collect the data
>>> contained or managed by this resource."
>> Tamara raises a very valid point here, one that I've often briefly
>> puzzled over only to just move on and ignore the problem.
>>
>> I think that if we want these fields to be reliably usable, we ought
>> to make up our minds (and then perhaps clarify the various standards
>> using errata).
>>
>> As usual, I'd suggest we start by working out what functionality
>> should be enabled by the feature; historically: what motivated the
>> addition of facility_name in Obscore and VODataService (and,
>> conversely, what made the SSAP authors to only have instrument).  If
>> anyone reading this remembers, please chime in.
>>
>> If you ask me, I'd say the main conceivable use case would be queries
>> -- whether for data sets as in obscore or for data collections in the
>> Registry -- of the type "Give me data from the HST" (which then would
>> include any sort of detector; my impression is that there's
>> relatively wide consensus that that would be in the instrument
>> field).  This, however, gets more complicated when there are multiple
>> telescopes at one site (facility?).  Let's take ESO's La Silla as an
>> example, where (I think) there are about a dozen individual
>> telescopes (or telescope-like... things, to avoid the term
>> "instrument" that we've just used for detectors).
>>
>> Which reminds me: The FITS standard
>> <https://heasarc.gsfc.nasa.gov/docs/fcg/standard_dict.html>  has the
>> TELESCOP keyword for pretty much this -- does anyone remember why we
>> didn't just take that over?  Was it because we wanted to cover
>> devices that don't feel like telescopes at all like, perhaps the GBM
>> aboard Fermi, the Icecube-like neutrino detectors, or LIGO/Virgo?)
>>
>> Resuming the La Silla example, I'd venture giving the concrete
>> telescope ("ESO 3.6 m", "NTT", ...) will more likely be useful for
>> actual searches than the generic "La Silla", as the individual
>> telescopes have so different properties that it seems unlikely to me
>> that a scientifically relevant question could use them in grouped
>> form.
>>
>> Against that could be a situation in which someone remembers that
>> some data set they've seen, say, at a conference, was "taken
>> somewhere at La Silla".  That, for one, seems a less likely scenario
>> to me; also, if and when we have usable
>> dictionary/vocabulary/taxonomy of "instruments" (now in the general
>> meaning), it would be fairly straightforward to translate such
>> a query into a query based on the individual telescope names.
>>
>> After this, I'm frankly tempted to try and clearly state that
>> "facility" should be, to first order, the telescope, and we ought to
>> explictly link it to FITS' TELESCOP.  Which, by the way, is defined
>> as
>>
>>   The value field shall contain a character string identifying the
>>   telescope used to acquire the data associated with the header.
>>
>> I can't say I'm too happy with using "telescope" in this definition
>> as our "collectors" are becoming more diverse and exotic.  In a way,
>> I'd be tempted to try and separate facility_name and instrument into
>> "device that collects/concentrates messenger particles" and "device
>> that detects messenger particles".  For Icecube-like devices, that
>> would happen to coincide, but that's perhaps not problematic.
>>
>> Well, having said all this: I suspect there's a bit of prior art on
>> this.  If you have pointers, by all means share them.  And would
>> anyone volunteer to run a discussion on this problem at the Interop?
>>
>>             -- Markus

-- 
--
Mireille Louys,  MCF (Associate Professor)
Centre de données CDS		IPSEO, Images, Laboratoire Icube
Observatoire de Strasbourg	Telecom Physique Strasbourg
11 rue de l'Université		300, Bd Sebastien Brandt CS 10413
F- 67000-STRASBOURG		F-67412 ILLKIRCH Cedex
Tel: +33 3 68 85 24 34
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/semantics/attachments/20220224/f81d1736/attachment.html>