Doubts with the facility name term
Paul Harrison
paul.harrison at manchester.ac.uk
Wed Feb 9 13:58:16 CET 2022
Hi,
> On 2022-02 -09, at 10:13, Markus Demleitner <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;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> 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/89ad09d7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2893 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/semantics/attachments/20220209/89ad09d7/attachment.p7s>
More information about the semantics
mailing list