Uploaded image for project: 'Request For Comments'
  1. Request For Comments
  2. RFC-771

Adopt ObsCore facility and instrument strings for the Observatory's data

    XMLWordPrintable

    Details

    • Type: RFC
    • Status: Flagged
    • Resolution: Unresolved
    • Component/s: DM, LSST
    • Labels:
    • Location:
      on this ticket

      Description

      The IVOA ObsCore data model for observation metadata contains facility_name and instrument_name attributes. These are mandatory attributes - a conforming observation metadata service such as ObsTAP or SIAv2 must return them.

      We wish to decide now on the values to be used for the main camera, commissioning camera, and spectrograph.

      The principal question here which is not just a matter of taste is whether the spectrograph will be represented as part of the same facility as the main camera and commissioning camera.

      We propose that they be separate facilities. The motivation is that, in the related CAOM2 data model, this allows the two facilities/telescopes' different physical location in Earth surface coordinates to be represented.

      To forestall a possible concern: ObsTAP and SIAv2 services both have means for querying for all Rubin data, regardless of the split facility_name:

      The proposal, therefore, is to support the following three pairs of (facility_name, instrument_name):

      facility_name instrument_name
      Rubin-SST LSSTCam
      Rubin-SST LSSTComCam (updated)
      Rubin-AuxTel LATISS

      The impact of this RFC is that it will serve as support for implementation of the ObsCore data services to be deployed this year. It is also germane to the work on DM-29600, which relates to how our instrumentation is referred to in other IVOA services (specifically the SVO Filter Profile Service).

      Implementation of the RFC could be as a one-page LDM or LSE document defining the names for the record.

      This RFC doesn't attempt to define instrument names for ancillary instrumentation such as the all-sky camera, but they will be needed in the future and could be added to the above document.

      In addition, we will need to decide, by DP0.2, on the values to be used for simulated LSSTCam data from DC2 and from any future formal service of simulated data from our project.

        Attachments

          Issue Links

            Activity

            Hide
            tjenness Tim Jenness added a comment -

            Ranpal Gill is there a prohibition against using "SST" in this context? The facility names are meant to be short identifiers rather than fully explicit names and "Rubin-SST" seems like it fits that criteria rather than "Rubin Observatory Simonyi Survey Telescope". This is really a unique key into a database rather than a human identifier.

            Show
            tjenness Tim Jenness added a comment - Ranpal Gill is there a prohibition against using "SST" in this context? The facility names are meant to be short identifiers rather than fully explicit names and "Rubin-SST" seems like it fits that criteria rather than "Rubin Observatory Simonyi Survey Telescope". This is really a unique key into a database rather than a human identifier.
            Hide
            rgill Ranpal Gill added a comment - - edited

            I think it makes sense to use it as the unique identifier/key

            Show
            rgill Ranpal Gill added a comment - - edited I think it makes sense to use it as the unique identifier/key
            Hide
            tjenness Tim Jenness added a comment -

            Since this will involve a change, escalating now to allow the process to be complete on a single RFC rather than needing two. Gregory Dubois-Felsmann if you would rather adopt this without CCB approval and then do a second RFC with the specific LDM content change then that also works.

            Show
            tjenness Tim Jenness added a comment - Since this will involve a change, escalating now to allow the process to be complete on a single RFC rather than needing two. Gregory Dubois-Felsmann if you would rather adopt this without CCB approval and then do a second RFC with the specific LDM content change then that also works.
            Hide
            tjenness Tim Jenness added a comment -

            We have agreed that Gregory Dubois-Felsmann will create a draft change in the LDM for review by DMCCB based on the above agreement.

            Show
            tjenness Tim Jenness added a comment - We have agreed that Gregory Dubois-Felsmann will create a draft change in the LDM for review by DMCCB based on the above agreement.
            Hide
            tjenness Tim Jenness added a comment -

            Gregory Dubois-Felsmann do you want to move the planned end out a bit for this RFC?

            Show
            tjenness Tim Jenness added a comment - Gregory Dubois-Felsmann do you want to move the planned end out a bit for this RFC?

              People

              Assignee:
              gpdf Gregory Dubois-Felsmann
              Reporter:
              gpdf Gregory Dubois-Felsmann
              Watchers:
              Gregory Dubois-Felsmann, Kian-Tat Lim, Ranpal Gill, Tim Jenness, Wil O'Mullane
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Dates

                Created:
                Updated:
                Planned End:

                  CI Builds

                  No builds found.