<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi,<div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 2022-02 -09, at 10:13, Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de" class="">msdemlei@ari.uni-heidelberg.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Dear Semantics folks,<br class=""><br class="">On Thu, Feb 03, 2022 at 02:20:46PM +0100, Tamara Civera wrote:<br class=""><blockquote type="cite" class="">I am writing to this group, because trying to unify the facility name in the<br class="">different VO services offered by my observatory (SIAP, Obscore,...) the<br class="">following doubt has arisen: *Should the facility name describe only the<br class="">facility or observatory, the telescope or both?*<br class=""><br class="">According to the different VO protocols documentation:<br class=""><br class="">Obscore: "B7.1 The Facility class codes information about the observatory or<br class="">facility used to collect the data."<br class=""><br class="">Obscore: "C.3 <FIELDname="facility_name"datatype="char"ucd="<a href="http://meta.id" class="">meta.id</a>;instr.tel"utype="obscore:Provenance.ObsConfig.Facility.name"xtype="adql:VARCHAR"arraysize="128*"><DESCRIPTION>telescope<br class="">name</DESCRIPTION></FIELD>"<br class=""><br class="">SIAP 2.0: "2.1.12 The FACILITY parameter is a string-valued parameter that<br class="">specifies the name of the facility (usually telescope) where the data was<br class="">acquired. The value is compared with the facility_name from the ObsCore [7]<br class="">data model"<br class=""><br class="">VoDataService: "3.1.1 The observatory or facility used to collect the data<br class="">contained or managed by this resource."<br class=""></blockquote></div></div></blockquote><div><blockquote type="cite" class=""><br class="">Tamara raises a very valid point here, one that I've often briefly<br class="">puzzled over only to just move on and ignore the problem. <br class=""></blockquote><br class=""></div><div>I would like to point out that this area is also a central issue for the ProposalDM (<a href="https://github.com/ivoa/ProposalDM" class="">https://github.com/ivoa/ProposalDM</a>)</div><div>that is currently in development. It is wrestling with the distinctions between telescopes, instruments and backends and</div><div>what combinations of them constitute and “observing system” (which might be the same thing as a Facility </div><div>if that is to be a useful separate concept…). </div><div><br class=""></div><div>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</div><div>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.</div><div><br class=""></div><div>As well as working out the relations between these concepts, it is also important as you point out to</div><div>have a way of making naming aliases for instances.</div><div><br class=""></div><div>I am not too convinced that a vocabulary is necessarily the best way to solve this - my feeling that some sort of</div><div>dynamic service that allows observatories to curate their offerings might be better. It might be that this is </div><div>doable within the registry, but it does depend on the complexity of the model that is required.</div><blockquote type="cite" class=""><div class=""><div class=""><br class="">I think that if we want these fields to be reliably usable, we ought<br class="">to make up our minds (and then perhaps clarify the various standards<br class="">using errata).<br class=""></div></div></blockquote><div><br class=""></div>It does seem that facility is not well enough defined to be useful, so I think that it is essential to clarify with errata.<br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">As usual, I'd suggest we start by working out what functionality<br class="">should be enabled by the feature; historically: what motivated the<br class="">addition of facility_name in Obscore and VODataService (and,<br class="">conversely, what made the SSAP authors to only have instrument). If<br class="">anyone reading this remembers, please chime in.<br class=""></div></div></blockquote><div><br class=""></div>I suspect it was just a combination of lack of coordination of a global solution rather than any actual intent.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class=""><br class="">Which reminds me: The FITS standard<br class=""><<a href="https://heasarc.gsfc.nasa.gov/docs/fcg/standard_dict.html" class="">https://heasarc.gsfc.nasa.gov/docs/fcg/standard_dict.html</a>> has the<br class="">TELESCOP keyword for pretty much this -- does anyone remember why we<br class="">didn't just take that over? Was it because we wanted to cover<br class="">devices that don't feel like telescopes at all like, perhaps the GBM<br class="">aboard Fermi, the Icecube-like neutrino detectors, or LIGO/Virgo?)<br class=""><br class=""><br class="">After this, I'm frankly tempted to try and clearly state that<br class="">"facility" should be, to first order, the telescope, and we ought to<br class="">explictly link it to FITS' TELESCOP. Which, by the way, is defined<br class="">as<br class=""><br class=""></div></div></blockquote>I think that this would be a good pragmatic step</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""> The value field shall contain a character string identifying the<br class=""> telescope used to acquire the data associated with the header.<br class=""><br class="">I can't say I'm too happy with using "telescope" in this definition<br class="">as our "collectors" are becoming more diverse and exotic. In a way,<br class="">I'd be tempted to try and separate facility_name and instrument into<br class="">"device that collects/concentrates messenger particles" and "device<br class="">that detects messenger particles". For Icecube-like devices, that<br class="">would happen to coincide, but that's perhaps not problematic.<br class=""></div></div></blockquote><div><br class=""></div>I think that your definitions here are probably good enough - where there is some blurring of the concepts, what is really important is the </div><div>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</div><div>is why I feel that some sort of service where these things are discoverable for each observatory might be the best solution.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">Well, having said all this: I suspect there's a bit of prior art on<br class="">this. If you have pointers, by all means share them. And would<br class="">anyone volunteer to run a discussion on this problem at the Interop?<br class=""></div></div></blockquote><div><br class=""></div></div>The PDS from NASA is an attempt to provide a comprehensive data description that shamefully I have only recently become aware of</div><div class=""><a href="https://pds.nasa.gov/datastandards/documents/current-version.shtml" class="">https://pds.nasa.gov/datastandards/documents/current-version.shtml</a></div><div class=""><br class=""></div><div class="">and interestingly facility is here</div><div class=""><br class=""></div><div class=""><a href="https://pds.nasa.gov/datastandards/documents/dd/current/PDS4_PDS_DD_1H00.html#d5e9395" class="">https://pds.nasa.gov/datastandards/documents/dd/current/PDS4_PDS_DD_1H00.html#d5e9395</a></div><div class=""><br class=""></div><div class="">which they restrict to being a terrestrial laboratory or observatory.</div><div class=""><br class=""></div><div class="">Paul</div></body></html>