Doubts with the facility name term
Anne Catherine Raugh
araugh at umd.edu
Wed Feb 9 15:52:09 CET 2022
Well, I can speak to the PDS case, although I'm fairly certain this will
not clarify anything - and not only because PDS is not very good at
describing non-spacecraft data.
First, the word "facility" has an implication of a physical location where
something happens. So when the PDS Standards refer to a "facility" the
expectation is that it is in reference to a building, or set of buildings,
that are in a specific, permanent, geographic location. This is why PDS
uses it to refer to things like laboratories and "observatories" - whatever
that means.
For PDS, the basic ground-based observing system is composed of a
facility (the "observatory"), the telescope, and the instrument that
recorded the data. Each of these elements gets its own identification,
because telescopes are built, renamed, and decommissioned, instruments may
move from telescope to telescope (even across facilities), and facilities
tend to be very long-lived and host multiple telescopes and instruments.
For any particular data product, you specify the observing system by
listing the pieces. The PDS "context object" system exists to document the
permanent relationships among these classes of things.
Seems easy, but then there are many cases where there are variations on the
"basic ground-based observatory" and significant ambiguity about what
should be in labels. Some examples:
- Observations made from balloons, suborbital rockets, and aircraft.
- Observations made by mobile telescopes that are not associated with
any "facility".
- Confusion between the organization that calls itself an "Observatory",
but is located in the middle of an urban area, and the place where the
actual observations are made, typically from a dome sitting on a distant
mountain top.
- Confusion between the telescope mount point (typically a dome) that
calls itself an "Observatory", and the administrative organization that
oversees the geographic location where multiple such "observatories" are
located, and also calls itself an "Observatory" (as is the case at Mauna
Kea, to name an important example).
- Organizations that run multiple telescopes at vastly different
physical locations, and call themselves "Observatories" (Las Cumbres, for
example).
The problems come mainly from the overburdened word "observatory", and it
seems to be the reason why every context I've explored so far just assigns
identifiers to the combinations of "observatory", telescope, and instrument
that are relevant for their purposes, and ignores everything else.
A general solution is difficult - to put it mildly - because what you
consider to be the correct answer for "Observatory?" depends on your goals:
- If you are an observatory site administrator, you want credit for
hosting unique and productive observing facilities.
- If you are an organizational observatory, you want credit for any
observations made at any of your physical locations.
- If you are a site administrator for a dome, you want credit for any
observations made with your telescopes.
- If you are doing astrometry, you want to know the precise surface
coordinates of the location where the photons were collected.
- If you are looking for groundbased observations of water in comets,
you want observations taken by telescopes located above a certain altitude.
- If you want observations taken by a specific telescope that does not
have a commonly-known name, you want to find it by knowing its
site "Observatory" or administrative "Observatory" or organizational
"Observatory".
- If you are trying to supply metadata for your observations, you just
want any plausible answer so you can get on with your life.
If you are a user looking for data, being able to search for an
"observatory" depends on whether or not what you think of as the
"observatory" is included in the metadata, and whether you know the correct
reference for the context. PDS has completely and utterly failed to address
this problem for non-spacecraft data. I yell at them about it twice a year.
But no one else has solved the problem either. The general approach seems
to be to either leave it up to the data suppliers, which leads to confusion
and incomplete search results; or define a code system that is managed by
an authority for the project and expanded as needed for the specific task
in hand. The MPC, for example, is primarily concerned with astrometry, and
so their "observatory code" (
https://www.minorplanetcenter.net/iau/lists/ObsCodesF.html) refers most
often to an "observatory" site, sometimes to a site + telescope, and
sometimes to a spacecraft. Their primary concern is the physical
coordinates of the observation, so this information is sufficient. Also,
the MPC doesn't offer much in the way of non-specialist access to its
database, so there is no impetus to provide comprehensive metadata for
searching.
I suspect the ultimate answer lies in being able to define atomic
identities like "The Mauna Kea Observatories", "Las Cumbres Observatory",
"Faulkes Telescope North", etc., and then defining the aggregate
associations between them. You could do this with a SKOS sort of vocabulary
if you can define a loose hierarchy that can be expanded to encompass all
the various interpretations of "observatory" that might be applicable in
any single case. (It would have to be SKOS if you want to include
instruments, which move around, or if you want to associate telescopes
directly to both a physical site and an organizational authority.)
Building such a vocabulary from the ground up based on what observers
typically supply in FITS headers or search boxes is, I very strongly
suspect, unlikely to yield consistent/predictable metadata. Worse, if a
better system is developed, trying to back-fill metadata based on fields
defined at the complete discretion of the metadata authors is at best an
onerous slog. That's basically what the PDS3-PDS4 migration process is.
It becomes a bit easier if you limit the problem to ground-based
astrophysical observatories and space telescopes, but still probably not as
easy as you'd like.
-Anne.
On Wed, Feb 9, 2022 at 7:58 AM 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> 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)
> 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
>
> and interestingly facility is here
>
>
> 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/a238313e/attachment-0001.html>
More information about the semantics
mailing list