SBN does things a little differently than the other nodes, so some of these
comments may not be relevant.



nh-a-lorri-*

data/20210930_049528/lor_0495280202_0x633_eng.lbl & others
- This value is unknown
  TARGET_NAME = "MILKY WAY BULGE RR LYRAE TEST"
If this stays, please provide a catalog file that defines it. If this dataset
will one day migrate to PDS4, this value probably will not pass.



u:n:p:nh_derived:lorri_cob

bundle.xml
- bundle.xml's lid_references to context products should be the union from
the .xml files in the bundle. This file has no lid_references to the targets,
the instrument_host, or the instrumnet.
- These should be consistent. This file has
  <lid_reference>urn:nasa:pds:context:investigation:mission.new_horizons</...>
while the rest of the bundle has
  <lid_reference>urn:nasa:pds:context:investigation:individual.none</...>
- per https://pds.nasa.gov/datastandards/documents/policy/PolicyOnDOI10142020.pdf
bundle.xml needs Citation_Information/doi, obtained via
  https://pds-engineering.jpl.nasa.gov/content/doi
though SBN may have another mechanism

collection.xml
- usually, there is one collection.xml for data/ and one for document/, which
separates the list of data products from document products, and each
collection.xml sits in its respective directory 
- Please replace (this happens 8 times)
  <reference_type>data_to_target</reference_type>
with
  <reference_type>collection_to_target</reference_type>

data/
- Suggestion: with so many files, create subdirs, e.g. by year

data/*.xml
- Nearly half these labels have no lid_reference for the target, presumably
because no context product/LID has been created for these targets:
  <name>(556416) 2014 OE394</name>
  <name>2011 HJ103</name>
  <name>2014 OJ394</name>
  <name>2018 MF13</name>
If desired, EN can create the context products for these LIDs:
  urn:nasa:pds:context:target:trans-neptunian_object.556416_2014_oe394
  urn:nasa:pds:context:target:trans-neptunian_object.2011_hj103
  urn:nasa:pds:context:target:trans-neptunian_object.2014_oj394
  urn:nasa:pds:context:target:trans-neptunian_object.2018_mf13

data/2007_10_06t01_50_05_452.xml & more (all?)
- The offset of the second Header and the second Array_2D seem wrong
based on the values in the .fit file.
  <Header>
    <offset unit="byte">581888</offset>
    <object_length unit="byte">46080</object_length>
  <Array_2D>
    <local_identifier>Image</local_identifier>
    <offset unit="byte">627968</offset>
should probably be
  <Header>
    <offset unit="byte">584640</offset>
    <object_length unit="byte">57600</object_length>
  <Array_2D>
    <local_identifier>Image</local_identifier>
    <offset unit="byte">642240</offset>
- What is the meaning of the second image? This is not so helpful
  <description>Image</description>
- Is this correct?
  <data_type>IEEE754MSBDouble</data_type>
The second image in the .fit file consists entirely of 8 bytes of
0x0000000001 or 0x0000000000, which for an IEEE double would be 5e-324 or 0.

document/nature_preprint.pdfa.xml
- Ideally, for initial submissions, set version to 1.0, not
  <version_id>2.0</version_id>

inventory.csv
- This should be named collection.csv or collection_inventory.csv



u:n:p:gbo-lowell:lowellphot

*.xml
- These LIDs are unknown (shortening urn:nasa:pds:context to u:n:p:c)
  u:n:p:c:telescope:lowell-anderson_mesa.hall_ritchey-chretien_1_1m07
  u:n:p:c:instrument:multi-host.kron_photometer
PDS already has LIDs for 3 telescopes at Lowell:
  u:n:p:c:telescope:lowell.discovery_4m3
  u:n:p:c:telescope:lowell.21in0
  u:n:p:c:telescope:lowell.perkins_warner1m83
So let's change your telescope's LID to:
  u:n:p:c:telescope:lowell.hall_1m07
Or feel free to suggest another, but please conform to
  u:n:c:telescope:lowell.<telescopeID>
Also, is your photometer this one?
  http://www2.lowell.edu/rsch/respage.php?r=kron
"multi-host" in LIDs is more appropriate for generic instruments and/or
instruments that move facilities. Since this is fixed to Lowell, let's use:
  u:n:p:c:instrument:lowell.kron_photometer

bundle.xml
- bundle.xml's lid_references to context products should be the union from
the .xml files in the bundle.  This file has no lid_references to the
investigation or the telescope or the instrument.
- per https://pds.nasa.gov/datastandards/documents/policy/PolicyOnDOI10142020.pdf
bundle.xml needs Citation_Information/doi, obtained via
  https://pds-engineering.jpl.nasa.gov/content/doi
though SBN may have another mechanism

collection.xml
- Usually, this file and its inventory sits in the data directory.

data/lowellphot18may21apr.csv
- This file has many "NaN", which is explicitly disallowed in the PDS4
Standards. The common way to do such things is in the .xml's Field_Delimited
for the fields that might have such values, add
  <Special_Constants>
    <error_constant>-99.999</error_constant>
  </Special_Constants>
and then in the .csv, replace NaN with that value. The value can be anything,
presumably impossible. The allowed *_constant (use as many as desired):
  saturated_constant
  missing_constant
  error_constant
  invalid_constant
  unknown_constant
  not_applicable_constant
  valid_maximum
  high_instrument_saturation
  high_representation_saturation
  valid_minimum
  low_instrument_saturation
  low_representation_saturation

data/lowellphot18may21apr.xml
- The Target_Identification section has no lid_references:
  <Target_Identification>
    <name>Multiple Comets</name>
    <type>Comet</type>
  </Target_Identification>
If desired, EN can provide the LIDs to the comets, e.g.
  urn:nasa:pds:context:target:comet.21p_giacobini-zinner
  urn:nasa:pds:context:target:comet.c2020_r4_atlas
though for most, like C/2020 R4, EN would have to create the context product.

inventory.csv
- This should be named collection.csv or collection_inventory.csv