SCR 3-1128 Vote Comments
EN
Elizabeth Rye
(This comment reflects the consensus of Elizabeth, Ron, and Steve.)
We understand that there is a fair amount of controversy surrounding this keyword. However, we want to be responsive to the needs of ESA/PSA and are therefore voting “yes”. We recommend a follow-up SCR to address the possibility of adding some additional standard values to the keyword that will meet the needs of the other missions and their teams. Furthermore, we believe that the relationship between data products and their browse products raised by this SCR needs to be formally modeled by the PDS and included in our overall data model.
RINGS
Mitch Gordon
(From Mitch)
Like Dick we find the standard values less useful than they might be. We are also going to have to deal with the concept of multiple browse products per data product. The key example is CIRS, where our thumbnails will be: (1) a scatter plot of target points on a ring diagram; (2) a scatter plot of points on a planetary surface; or (3) a spectrum. We are not archiving our thumbnails/previews, so we are not bound by the PDSDD, but it would still be good if our development paralleled the PDS standards.
I would like a freer-form field:BROWSE_TYPE = SPECTRUM_PLOTBROWSE_TYPE = RING_SCATTER_PLOTBROWSE_TYPE = BODY_SCATTER_PLOTBROWSE_TYPE = CONTEXT_DIAGRAMBROWSE_TYPE = THUMBNAIL_IMAGE etc. Then we can also specify which is the most importantBROWSE_USAGE_TYPE = PRIMARYBROWSE_USAGE_TYPE = SECONDARY
Something like this would work. The SCR as written seems unsuitable to our needs.
Mitch
(From Mark)
Mitch and I echo some of the concerns expressed by Dick and Anne. We also note that the Rings Node will eventually have need to support multiple browse products per data product, and a keyword along the lines of BROWSE_USAGE_TYPE has the potential to solve our problem too. For example, a CIRS browse products might include a line plot of a spectrum and also a scatter plot of observation footprints atop a planet or moon. We suggest that the working group investigate a general solution to the problem.
Rings votes no.
Sorry, Mark
RS
Dick Simpson
Addition of the keyword ties PDS into a complex sub-structure for PSA browse products which PDS is never likely to adopt (see the 39-page specification document listed under Supplementary Material).
The standard values remain ambiguous – what if a browse product is both PRIMARY and OVERVIEW? And PSA requires the value “N/A” when there is a one-to-one relationship between source products and browse products, which is not mentioned in this SCR and is not intuitive (why not PRIMARY?).
The PSA deadline is real, and maintaining good terms with our PSA colleagues is a worthy goal. But this is an addition which will only cause us problems down the road.
SBN
Anne Raugh
We concur with the comments made by Dick Simpson. In addition, the third paragraph of the proposed definition is problematic. A keyword should not be able to declare itself optional, for example. Optional vs required status should be determined by the object context. Neither is it the usual role of PSDD definitions to suggest how keywords might be used in conjunction for one or more purposes. If that much explanation is required to use this keyword, then the Standards Reference should be updated to include this information where users are likely to find it during the early stages of browser design.