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.
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:
Something like this would work. The SCR as written seems unsuitable to our needs.
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.
Dick SimpsonAddition 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.