<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
Hi Semantics, <br>
<br>
Thank you Tamara for bringing up this issue .<br>
<br>
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 . <br>
<br>
There are various levels of information for describing the
acquisition chain providing an observation.<br>
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. <br>
So the information is spread in various notions .<br>
May be this presentation given at interop meeting in Paris gives an
idea : <br>
<a moz-do-not-send="true"
href="https://wiki.ivoa.net/internal/IVOA/InterOpMay2019Semantics/telInstrepo-ParisInterop19-EM-ML.pdf">https://wiki.ivoa.net/internal/IVOA/InterOpMay2019Semantics/telInstrepo-ParisInterop19-EM-ML.pdf<br>
</a><br>
The approach was from very general to specific to be able to sketch
out a data model for the necessary metadata.<br>
In this exercise, we have been able to identify many situations
where the name of an instrument/telescope does not suffice or is
ambiguous. <br>
<br>
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.<br>
The first steps have been hard due to missing or incomplete
information, ambiguity on names, change of locations for some
instruments, etc. <br>
<br>
As Stephane mentionned earlier, and also inspired from the PDS 4
Information system, <br>
what helps to determine the minimum instrumental identification is
the link<br>
<i>instrument <----> instrument_host </i><i><br>
</i>so a PID for each would help to uniquely identify the
instrumental combination<i>.<br>
<br>
</i>I think <i>instrument_host </i>is more appropriate than <i>facility</i>
, it can tackle more situations. <br>
<br>
If we are able to mint a PID for each <i>instrument_host</i> and
for each<i> instrument<br>
</i>the ObsCore spec could evolve to support also: <br>
<i>instrument_pid</i> in addition to instead of the ambiguous
instrument name, and <br>
<i>instr_host_pid </i>instead of facility name.<br>
<br>
Some work started recently to homogeneize lists of instruments and
instruments hosts at Paris Observatory. <br>
<br>
Taxonomy is involved for the definition of instrument types, and
host types as well.<br>
If we would like this to be defined as IVOA vocabularies, we could
get inspired by the PDS4 instrument type list , for instance .<br>
<br>
<a moz-do-not-send="true"
href="https://pds.nasa.gov/datastandards/documents/im/current/index_1H00.html#class_pds_instrument"
class="moz-txt-link-freetext">https://pds.nasa.gov/datastandards/documents/im/current/index_1H00.html#class_pds_instrument</a><br>
<br>
<br>
best wishes, Mireille<br>
<br>
<div class="moz-cite-prefix">Le 10/02/2022 à 13:18, Stéphane Erard a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:3485736B-CDE2-493A-B6C6-BCBFBE6E0171@obspm.fr">
<pre class="moz-quote-pre" wrap="">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
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Le 9 févr. 2022 à 11:13, Markus Demleitner <a class="moz-txt-link-rfc2396E" href="mailto:msdemlei@ari.uni-heidelberg.de"><msdemlei@ari.uni-heidelberg.de></a> a écrit :
Dear Semantics folks,
On Thu, Feb 03, 2022 at 02:20:46PM +0100, Tamara Civera wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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."
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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
<a class="moz-txt-link-rfc2396E" href="https://heasarc.gsfc.nasa.gov/docs/fcg/standard_dict.html"><https://heasarc.gsfc.nasa.gov/docs/fcg/standard_dict.html></a> 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
</pre>
</blockquote>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
--
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</pre>
</body>
</html>