Doubts with the facility name term

[Carlo Maria Zwölf]

Dear All, 

This is very interesting discussion indeed. 

I am not sure we may define a rigorous hierarchy between the terms “Telescope”, “Facility”, “Instrument” and “detector”. Depending on the context and on people, some terms may overlap. I’m not sure we can reach easily a consensus vocabulary.

Some recent output from the Research Data Alliance are in line with the Paul’s suggestion that the observatory choses to label its data products and the distinctions they make, rather than some globally agreed definition: the RDA produced a recommendation on the persistent identification of Instrument https://rda-pidinst.readthedocs.io/en/latest/white-paper/index.html# <https://rda-pidinst.readthedocs.io/en/latest/white-paper/index.html#> . 
They are agnostic about what an instrument is, but they provide rules & mechanisms to identify it with all the required granularity and metadata. Those metadata values (cf. Par. 5.1 of the linked doc) may be free texts or coming from controlled vocabularies. 

The RDA approach solve the aspects about the non-ambiguous identification of the entity producing data. But this not tell how to make easily queries like “give me all data from HST”, since we have to map somehow the generic human understandable “HST” term to the set of all PIDs corresponding to the instruments on the HST. 
For this last need the solution proposed by Markus seems reasonable. 

In addition, should we think at adding a field like “Instrument PID” to achieve the unique identification? 

Best, 

Carlo.

 
> On 09 Feb 2022, at 13:58, Paul Harrison <paul.harrison at manchester.ac.uk> wrote:
> 
> Hi,
> 
>> On 2022-02 -09, at 10:13, Markus Demleitner <msdemlei at ari.uni-heidelberg.de <mailto:msdemlei at ari.uni-heidelberg.de>> wrote:
>> 
>> 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 <http://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 would like to point out that this area is also a central issue for the ProposalDM (https://github.com/ivoa/ProposalDM <https://github.com/ivoa/ProposalDM>)
> that is currently in development. It is wrestling with the distinctions between telescopes, instruments and backends and
> what combinations of them constitute and “observing system”  (which might be the same thing as a Facility 
> if that is to be a useful separate concept…). 
> 
> My feeling from general english language usage that facility is a sort of “collective noun” used in the plural e.g. sports facilities and when used in the
> sigular tends to relate to a building e.g. the nuclear research facility, and feels more like it would apply to more than just a telescope.
> 
> As well as working out the relations between these concepts, it is also important as you point out to
> have a way of making naming aliases for instances.
> 
> I am not too convinced that a vocabulary is necessarily the best way to solve this - my feeling that some sort of
> dynamic service that allows observatories to curate their offerings might be better. It might be that this is 
> doable within the registry, but it does depend on the complexity of the model that is required.
>> 
>> 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).
> 
> It does seem that facility is not well enough defined to be useful, so I think that it is essential to clarify with 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.
> 
> I suspect it was just a combination of lack of coordination of a global solution rather than any actual intent.
> 
>> 
>> Which reminds me: The FITS standard
>> <https://heasarc.gsfc.nasa.gov/docs/fcg/standard_dict.html <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?)
>> 
>> 
>> 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
>> 
> I think that this would be a good pragmatic step
> 
>>  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.
> 
> I think that your definitions here are probably good enough - where there is some blurring of the concepts, what is really important is the 
> way that the observatory choses to label its data products and the distinctions they make, rather than some globally agreed definition (although you would hope that each observatory would try to follow the spirit of the definitions) - which again
> is why I feel that some sort of service where these things are discoverable for each observatory might be the best solution.
> 
>> 
>> 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?
> 
> The PDS from NASA is an attempt to provide a comprehensive data description that shamefully I have only recently become aware of
> https://pds.nasa.gov/datastandards/documents/current-version.shtml <https://pds.nasa.gov/datastandards/documents/current-version.shtml>
> 
> and interestingly facility is here
> 
> https://pds.nasa.gov/datastandards/documents/dd/current/PDS4_PDS_DD_1H00.html#d5e9395 <https://pds.nasa.gov/datastandards/documents/dd/current/PDS4_PDS_DD_1H00.html#d5e9395>
> 
> which they restrict to being a terrestrial laboratory or observatory.
> 
> Paul

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/semantics/attachments/20220209/7edab86c/attachment.html>