Lucy L'Ralph LEISA Liens ======================== Author name mismatch? --> "Lunsford, A." vs "Lunsford, H." --> --> Instance of "H." in document collection. Documentation ============= file: document/collection_overview.txt --> File is empty. --> The document/collection_overview.txt is empty. The xml file says it is version 1.0, but I would expect it to be version 2.0. The collection.xml reference_list expects a version 2.0 overview file, but the inventory says it is version 1.0. Was including a new collection_overview a mistake? I see no new files, only versioned products. Either (1) include an updated overview file and overview label, and update the LIDVID reference in the collection.xml and collection_inventory.csv files or (2) drop the new overview files, and rely on the copy found in VID 1.0 of this collection. --> author_list entry: "Lunsford, H." => "Lunsford, A." file: calibrated/ollection_overview.txt --> first sentence needs to be updated to say calibrated data from Donaldjohanson encounter, not raw from Dinkinesh, also title --> line 3 says these are "raw images products" but they are calibrated. file: calibration/collection_overview.txt --> Under Bad Pixel Map Heading, “file” should be plural --> Thank you for adding the paragraph (or lines?) describing which space calibration files are for Dinkinesh vs DJ. But they read as if they are one paragraph. Also, they say they are only for space calibration files, but the description could also apply to the Fringe Files. Suggest rewording in such a way to make it a table, or separating out the lines so they don't read as one sentence. file: LRalph_LEISA_activities.pdf --> Typo in word “effective” for details column of Dinkinesh flyby --> Asterisk note on table for temperature notes that T > 103K are off-nominal. So is all data included in these submissions considered off-nominal? file: LRalph_LEISA_PostCalibration.pdf --> Is the algorithm described something that will be included as a tool for users to use, or is it just the description of what should be done? file: calibrated/README.txt --> Says it “contains partially processed images”. Does this just refer to the fact that they haven’t had the post-processing with the fringe flats? file: 'readme.txt' --> The Calibration section only mentions three of the five types, leaving out BPM and Wave map. --> The Calibrated collection sections say they are "partially processed images", but it should say "calibrated". Data ==== --> Data has variety of sizes, reflects different scan strategies? Also seems most are split into short wavelength (1-2.4 microns) and long wavelength (2.4-4 microns) files, except for 607 and 610 --> Discrepancy in object motion. Object moved about 2.0195 pixels per frame, on average; not the ~ 1.53 pixels per integration time, which was stated relevant to Dinkinesh. --> Why do the wavelengths only begin after the bond gap, at 2.7um? --> Size the flatfield (there were two) did not match the size of the image, preventing calibration. --> Tadiometric conversion file missing. Calibrated Data --> Is the overall shape as expected? And is the drop in radiance longward of 3.8um due to saturation? If so, should that be included in the calibrated data? Calibration Data --> Space files seem to have two different appearances and sizes (which alternate), but I think this just reflects the short and long wavelength coverage of the data? directory: 'calibration/' --> The lucy.leisa/calibration collection does not conform with Dinkinesh lien addressed delivery. In the Dinkinesh lien resolved delivery all the fflat and space LIDs had the run version number removed from the LID (example: urn:nasa:pds:lucy.leisa:calibration:lei_0752129330_02298_fflat_03::1.0 to urn:nasa:pds:lucy.leisa:calibration:lei_0752129330_02298_fflat::1.0). This was to conform with standing practice to not include it, but also because the data products referencing these calibration products assumed it didn't either.  But these run version numbers have been reintroduced in the calibration products in this delivery, and the DJ data products cannot properly reference them as a result.  Please fix. SBN-TB used the following mac csh code to fix the files for the peer review: sed -i '' 's#_0[0-9] The Context_Area.Time_Coordinates are only for DJ, not for the entire range of collections (including Dinkinesh). Are the optional Time_Coordinates really appropriate for the bundle? --> Please provide the missing File_Area_Text for the readme.txt file. file: 'calibration/collection.xml' --> Update the Reference_List item for collection_overview VID from 1.0 to 2.0, to match the updated overview file's VID. file: 'calibration/collection_inventory.csv' --> Update the LIDVID item for collection_overview's VID from 1.0 to 2.0, to match the updated overview file's VID. files: 'calibration/lei*.xml' --> [Dinkinesh lien] Provide valid Display_Settings where missing to eliminate PDS4viewer warning about display settings. --> Should the Array_2D_Image objects have a unit? --> Is the "Spectral Cube" really appropriate for a Array_2D_Image? file: 'data_donaldjohanson_*/collection_overview.xml' --> The LID for these files says dinkinesh, but it should be for donaldjohanson. Please correct the logical_identifier. file: 'data_donaldjohanson_raw/lei_*.xml' --> 10 of 28 products reference in their Reference_List a calibrated version of the raw product which does not exist. Assuming the products were not calibrated, please update the pipeline code to check to see if the calibrated product exists before adding a reference. Please remove such references. file: 'data_donaldjohanson_raw/lei_*.xml' --> [Dinkinesh lien] Please add units. This was fixed in the Dinkinesh lien addressed delivery. EN Liens ======== */collection_overview.* - "collection" is a "reserved base name component" in the PDS4 Standards. Suggestion: rename these files to "overview.*". bundle.xml - This has lid_references to collections not in the bundle under review: urn:nasa:pds:lucy.leisa:data_dinkinesh_raw::1.0 urn:nasa:pds:lucy.leisa:data_dinkinesh_calibrated::1.0 Please ensure those collections will still be in the real bundle. - Since readme.txt exists, bundle.xml should point to it, something like readme.txt 0 7-Bit ASCII Text Carriage-Return Line-Feed between Bundle and Bundle_Member_Entry - Within Reference_List (with stuff chopped), these are incorrect: urn:nasa:pds:lucy.mission:document::2.0 bundle_to_document urn:nasa:pds:lucy.leisa:document::2.0 bundle_to_document A bundle_to_document should point to a specific document, not a collection. A Bundle_Member_Entry points to a collection, including documents. This bundle.xml already points to u:n:p:lucy.leisa:document that way. It could also point to the other collection via urn:nasa:pds:lucy.mission:document::2.0 Secondary bundle_has_document_collection calibration/collection.xml - The VID in this lidvid_reference urn:nasa:pds:lucy.leisa:calibration:collection_overview::1.0 doesn't match the calibration/collection_overview.xml's VID, 2.0 - Suggestion: since labels in this collection have them, add lid_references to urn:nasa:pds:context:target:calibration_field.space urn:nasa:pds:context:target:calibrator.flat_field bundle.xml should add these as well calibration/collection_inventory.csv - This contains P,urn:nasa:pds:lucy.leisa:calibration:collection_overview::1.0 but calibration/collection_overview.xml's VID is 2.0 - This contains many LIDs previously delivered but not included in this review. That's fine if those files are available in the real collection. However, 6 such LIDs don't match previously ingested LIDs. In this file: P,urn:nasa:pds:lucy.leisa:calibration:lei_0752129330_02298_fflat::1.0 P,urn:nasa:pds:lucy.leisa:calibration:lei_0752129330_02298_space::1.0 P,urn:nasa:pds:lucy.leisa:calibration:lei_0752129711_02300_fflat::1.0 P,urn:nasa:pds:lucy.leisa:calibration:lei_0752129711_02300_space::1.0 P,urn:nasa:pds:lucy.leisa:calibration:lei_0752129956_02302_fflat::1.0 P,urn:nasa:pds:lucy.leisa:calibration:lei_0752129956_02302_space::1.0 but collection_calibration_inventory.csv, ingested in 2024.10, has P,urn:nasa:pds:lucy.leisa:calibration:lei_0752129330_02298_fflat_03::1.0 P,urn:nasa:pds:lucy.leisa:calibration:lei_0752129711_02300_fflat_02::1.0 P,urn:nasa:pds:lucy.leisa:calibration:lei_0752129956_02302_fflat_03::1.0 P,urn:nasa:pds:lucy.leisa:calibration:lei_0752129330_02298_space_01::1.0 P,urn:nasa:pds:lucy.leisa:calibration:lei_0752129711_02300_space_01::1.0 P,urn:nasa:pds:lucy.leisa:calibration:lei_0752129956_02302_space_01::1.0 data_donaldjohanson_calibrated/collection_overview.xml - Presumably, this file's LID is wrong: urn:nasa:pds:lucy.leisa:data_dinkinesh_calibrated:collection_overview and should be urn:nasa:pds:lucy.leisa:data_donaldjohanson_raw:collection_overview That would solve many missing references in this bundle. data_donaldjohanson_raw/ - This directory file has 27 labels while data_donaldjohanson_calibrated/ has 17. 10 of the files in _raw have lid_references to calibrated labels not in this review, e.g. file lei_0798443091_02608_eng_04.xml references u:n:p:lucy.leisa:data_donaldjohanson_calibrated:lei_0798443091_02608_sci which isn't in this review. This may be an artifcat of selecting files for the review. Please ensure that the delivered products all refer to existing calibrated products. data_donaldjohanson_raw/collection.xml - Suggestion: since a label in this collection has this, add a lid_reference to urn:nasa:pds:context:target:calibrator.internal_source bundle.xml should add this as well data_donaldjohanson_raw/collection_overview.xml - Presumably, this file's LID is wrong: urn:nasa:pds:lucy.leisa:data_dinkinesh_raw:collection_overview and should be urn:nasa:pds:lucy.leisa:data_donaldjohanson_raw:collection_overview That would solve many missing references in this bundle. document/collection_inventory.csv - These LIDs are listed here, but the corresponding docs are missing. P,urn:nasa:pds:lucy.leisa:document:leisa_sis::1.0 P,urn:nasa:pds:lucy.leisa:document:lralph_ssr::1.0 Please ensure they will be available in the bundle. Many labels reference them Lucy Global Liens ================= Any CERTIFIED and released data products (non-PDS4-label parts) should NOT be changed (i.e. checksums remain unchanged) during lien resolution; this includes the headers as well. If there may be any cases (for instance the before mentioned headers), please discuss them with SBN BEFORE release of the review data. Calibration and Document collection's child products appear to be hand edited and so should be checked for each delivery and not relied on for pipeline configuration control. There are errors due to silly hand made mistakes. To what level are these produced in the pipeline? Many of the bundle/collection products (i.e. bundle.xml or collection.xml) appear to have been hand edited. To what level are these produced by the pipeline? Need to determine how best to deliver versioned collections to SBN, which may not contain all products. --> Products that were not updated do not need to be redelivered, but the collection inventory files should still contain a full list of products (best copy usually), not just new products. In the DJ delivery, half the time this appears to have been done, but it was not done for lucy.llorri:calibration::3.0, lucy.mission:document:2.0, and lucy.mvic:document:2.0. issue: Dinkinesh lien edits not carried over into DJ --> Ensure that all versioned product labels (bundle, collection, data, document, etc) found in the Dinkinesh delivery has also been updated in the same way in the DJ delivery. For instance the Modification_History for the Dinkinesh related VID is different in several cases and other edits due to Dinkinesh liens were not applied before updating for the DJ delivery. Most of these affected products include bundle.xml, {calibration,document}/collection.xml, and any calibration/* or document/* products that are now VID 2.0 or 3.0. Sanity check: I see that Brian Enke was added as an editor to the bundles. Should he be added to any of the child collections or products as well? Be sure to include the Funding_Acknowledgement class (it was removed in this delivery). The following collection products do not: -->lucy.leisa/calibration/collection.xml -->lucy.leisa/data_donaldjohanson_calibrated/collection.xml -->lucy.leisa/data_donaldjohanson_raw/collection.xml -->lucy.llorri/calibration/collection.xml -->lucy.llorri/data_didymos_partially_processed/collection.xml -->lucy.llorri/data_didymos_raw/collection.xml -->lucy.llorri/data_donaldjohanson_partially_processed/collection.xml -->lucy.llorri/data_donaldjohanson_raw/collection.xml -->lucy.ltes/data_donaldjohanson_calibrated/collection.xml -->lucy.ltes/data_donaldjohanson_hkraw/collection.xml -->lucy.ltes/data_donaldjohanson_raw/collection.xml -->lucy.mvic/calibration/collection.xml -->lucy.mvic/data_donaldjohanson_calibrated/collection.xml -->lucy.mvic/data_donaldjohanson_raw/collection.xml -->lucy.rss/data_donaldjohanson_ion/collection.xml -->lucy.rss/data_donaldjohanson_sff/collection.xml -->lucy.rss/data_donaldjohanson_skyfreq/collection.xml -->lucy.rss/data_donaldjohanson_trk234/collection.xml -->lucy.ttcam/data_donaldjohanson_calibrated/collection.xml -->lucy.ttcam/data_donaldjohanson_raw/collection.xml issue: In product labels, Reference_List references missing or --> For any product label (bundle, collection, data, etc), please add a (for external_reference) or (for internal_reference) to every reference entry stating very briefly mentioning what they are (and why they are included, which maybe self explanatory in the "what"). The user needs to know what these references are for; the LID/LIDVID may cue an advanced user, but they are not always clear. --> --> For instance, a reference to the SSR paper, might simply say "[instrument] SSR paper" --> --> For instance, a reference to a data product/collection state it is the source raw product or used in calibration, etc. issue: Inconsistent use of value for context objects: --> [Dinkinesh Lien] Observing_System_Component host name "Lucy Spacecraft" vs "Lucy". Currently found in: --> --> lucy.leisa/calibration/collection.xml --> --> lucy.llorri/bundle.xml --> --> lucy.mvic/calibration/collection.xml issue: vague collection (or DOI eligible) product Citation_Information.description --> The Citation_Information.description is used as the abstract for webpage and DOI meta data purposes (think ADS). Having text that gives a brief but uniquely descriptive description will help the user know what the given product contains. We would expect this to be no more than several sentences, but can be as brief as one, depending on the product. --> For the data collections recommend expanding more than simply saying it is ABC processing level data from instrument XYZ from the mission phase abc. --> For versioned collections, it is highly recommended to include at least a sentence explaining the difference from the prior version, for instance recalibrated or reprocessed, or adding additional files related to XZY. The Modification_History note may have some inspiration. Issue: Reference_List LIDVID vs LID usage --> You it is best to use a LID reference when the best version of a given product is sufficient to reference. For instance, you may want to point the user to the calibrated collection from the raw collection or to the instrument document collection or the SIS (assuming it is backwards compatible) for reference. Using LIDVID in these cases is not a problem, but not optimal. --> You should use a LIDVID reference when you need to reference the exact product version, usually when it is a source product. For instance, for when higher order (i.e. calibrated, derived, etc) products are referencing calibration products or source lower order (i.e. raw) product(s), they should be LIDVID references, not LID references since the user needs to know exactly which file was used to produce the product they are looking at. So Calibrated data products should use LIDVID for raw products and calibration products, and Calibrated collections should use LIDVID to reference a raw collection and/or calibration collection. Another common instance is for collection overview documents, were a future document version mostly likely will not directly apply to the current version. When you use a LID reference it assumes the most recent VID of that calibration or raw product, which may not actually be the correct product a few years down the road. --> --> [Dinkinesh Lien reworded] The calibrated and Partially Processed data products for the Reference_List currently use LID instead of LIDVID references to the raw and calibration products. The SIS LID reference may be fine if not dependent on calibration information. The raw data products correctly use LID references. Issue: Reference_List inheritance --> Items listed in a product Reference_List are not inherited up or down (bundle <=> collection <=> child product). If a reference should be cited for a collection, it should be included in the collection product, not assumed to be there if it is referenced in the bundle product. Similarly if an important paper, say the SSR paper is cited in all the data products, it should probably also be cited in the collection product. The same is true for raw & calibrated products with their corresponding collection product (except convert to collection instead of individual data product references). --> For a practical note, please note that SBN-UMD makes the best effort to include all citations (should be found in the Reference_List for automation) in the DOI meta data for each DOIs we publish, but these need to show up at the level the DOI is being produced, which in most cases are at the collection level. This is the same for the other Citation_Information fields. issue: Adding sb:Calibration_Information --> For the calibrated products, I see that the Reference_List includes the data_to_raw/calibration_product. You can also add this information, plus additional information for the user to the "sb:Calibration_Information". I would highly highly encourage this. L’LORRI appears to be the only instrument that uses this. files: 'bundle.xml' --> [Dinkinsh lien] Suggest to remove the PDS4 jargon, "Bundle", from Identification_Area.title and replace with "Archive" or something similar. In the DJ delivery, this has been done for L'LORRI and L'TES already, but for Dinkinesh it was done for LEISA and MVIC, but was reversed in DJ. --> [Dinkinesh lien]: For the instrument bundles, please update the Citation_Information.description to mention that they includes more than just "data products". Many of these bundles include calibration and document products as well. The RSS bundle description is generic enough to encompass all such products where as the others all say "all the operational data products". --> Is the Context_Area.Time_Coordinates is relevant to the bundle? Currently only three bundles contain it (leisa, ltes, mission). Please either remove or add to all bundles. If adding, please ensure all Context_Area.Time_Coordinates values encompass the entire span of all collections in the bundle, not just the current delivery (currently lucy.leisa values are only for DJ, not DJ and Dinkinesh). --> Unlike the other instrument bundles, L'TES, MVIC, and RSS do not have a Reference_List area. The other three contains references I would not expect, like to the mission:document and [instrument]:document collections, but did find the expected the [instrument]_ssr. Recommend replacing the [instrument]:document collection with the [instrument]_sis and replacing the mission:document with lucy.mission:document:lucy_mission_info. In any event, please be consistent between instruments. files: 'data*/collection.xml' --> [Dinkinesh lien] Suggest removing PDS4 jargon, "Collection", from Identification_Area.title. For DJ, this should be done for all but Radio Science. In latest Dinkinesh delivery, only Ralph as was fixed. --> For all data* collections, recommend adding a LID reference to the instrument document collection and external DOI reference and/or internal_reference to the SSR --> For the data*raw collections, suggest adding a LID reference to the corresponding data*{calibrated,partially_processed} collections --> For the data*{calibrated,partially_processed} collections, please add a LIDVID reference to the corresponding data*raw and calibration (if applicable) collections and calibration description document or paper (DOI) (if any). files: Calibrated or Partially Processed data products --> If the SIS does not describe calibration process, an LIDVID reference should be added to said document, or an external/internal reference added to said paper. --> For each File_Area_Observational.Header, please add a name and/or description, to specify which header is associated with which data object. For instance the L'LORRI observational image FITS header, Main File header, or something similar. Currently there is no clue to the user (aside from order and offset) what header goes with which object. files: 'readme.txt' --> Just a suggestion for thought. These files (especially RSS) are only starting to get long. After more target encounters, let along any cruise phases, the list will be almost unwieldy to read. I would suggest finding a way to consolidate it, perhaps by collection types (document, calibration, raw, calibrated, ion, etc). If you make it generic enough (remove mission segments/phases), you may never need to update it again, until there is a new data or collection type, or you can mention at the top there are collections for the following phases, and it will be a small edit to add another phase each bundle version.