Lucy L'Ralph MVIC Liens ======================= Documentation ============= --> Add explanation for why differences exist in labels between between img:exposure_duration, the delta of start_date_time and stop_date_time, lucy:mvic_observation_allocation, and lucy:mvic_tdi_row_integration_time. file: overview.txt --> Include a short explanation of the 2D calibration coefficient (the 6 x 5024 arrays in the calibrated image bundles) for users, e.g., clarifying what the rows and columns represent. Same suggestion applies to the Background Table. --> Include simple equations in the overview showing how the background & calibration coefficients are applied during calibration to produce the final calibrated outputs. file: 'readme.txt' --> The Calibrated collection sections say they are "partially processed images", but it should say "calibrated". Data ==== --> In raw and calibrated data, a half-and-half pattern and clusters of negative pixels are see on the right side in Bands 3, 5, and 6, but are not shown in the corresponding calibration files. Explain source of issue in documentation. --> Explain image selection reasoning (why only five images were calibrated) in documentation OR add missing data. --> --> The Lucy team has generated and provided the five missing calibrated products. However, the instrument team says: These data are point source observations, so although they possibly could be used for light curve analysis, they suffer from the bimodal noise, so they are not overly useful in current form. Labels ====== file: *.xml --> Typo in Lucy LDD attribute: mce_start_postion -> mce_start_position, mce_end_postion -> mce_end_position. Discuss with dictionary stewards and SBN personnel as to how/whether to fix. --> Add units of radiance for calibrated data. --> For raw data labels without corresponding calibrated data, remove the data_to_calibrated_product internal reference. file: 'bundle.xml' --> Missing the File_Area_Text class for the readme.txt file. file: 'calibration/collection.xml' --> The Modification_Detail date and description for version 1.0 has changed to match that of version 2.0, but it should be for the Dinkinesh delivery. Please fix. --> values were added to the internal_references in the Reference_List in Dinkinesh, but removed here. Please add back. files: '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/collection_inventory.csv' --> The LID for the overview document is misspelled. "collection_ovrview" => "collection_overview" file: 'document/collection.xml' --> Update the from 2024 to be 2025. --> The Citation_Information.doi is for the prior version of this collection. It should be replaced with a new DOI value. --> The inventory file is incomplete, only containing the updated product, not including the non-versioned products. file: 'document/collection_inventory.csv' --> When versioning a collection, the collection inventory files should contain a full list of products (best copy usually), not just new or updated products. Please add back all the products from v1.0 of this collection. EN Liens ======== *.xml - The document/ dir and any associated SIS were not part of this review, but many files have a lid_ or lidvid_reference to urn:nasa:pds:lucy.mvic:document:mvic_sis Please ensure this will be available in the real bundle. bundle.xml - This has lid_references to collections not in the bundle under review: urn:nasa:pds:lucy.ltes:data_dinkinesh_calibrated::1.0 urn:nasa:pds:lucy.ltes:data_dinkinesh_raw::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 - Suggestion: since labels in this bundle have them, add lid_references to urn:nasa:pds:context:target:asteroid.52246_donaldjohanson urn:nasa:pds:context:target:calibration_field.space calibration/collection.xml - Suggestion: since labels in this collection have it, add lid_reference to urn:nasa:pds:context:target:calibration_field.space - This lidvid_reference has no corresponding label: urn:nasa:pds:lucy.mvic:calibration:collection_overview::1.0 The LID is also listed in calibration/collection_inventory.csv collection/collection_inventory.csv - This lists many LIDs not available in this review: urn:nasa:pds:lucy.mvic:calibration:mvi_0752129246_02297_space::1.0 urn:nasa:pds:lucy.mvic:calibration:mvi_0752129547_02299_space::1.0 urn:nasa:pds:lucy.mvic:calibration:mvi_0752129862_02301_space::1.0 urn:nasa:pds:lucy.mvic:calibration:mvic_radcal_tdi16::1.0 urn:nasa:pds:lucy.mvic:calibration:mvic_radcal_tdi32::1.0 urn:nasa:pds:lucy.mvic:calibration:mvic_radcal_tdi4::1.0 urn:nasa:pds:lucy.mvic:calibration:mvic_radcal_tdi64::1.0 urn:nasa:pds:lucy.mvic:calibration:mvic_radcal_tdi8::1.0 Please ensure they'll exist in the delivered bundle, or modify this file. data_donaldjohanson_calibrated/collection_overview.xml - This file's LID is ...:data_dinkinesh_calibrated:... instead of ...:data_donaldjohanson_calibrated:... data_donaldjohanson_raw/collection_overview.xml - This file's LID is ...:data_dinkinesh_calibrated:... instead of ...:data_donaldjohanson_calibrated:... data_donaldjohanson_raw/mvi_0798391044_02539_eng_03.xml & 4 more - These have no equivalent in directory data_donaldjohanson_calibrated/, and each of these five labels has a (missing) lid_reference to the equivalent, e.g. urn:nasa:pds:lucy.mvic:data_donaldjohanson_calibrated:mvi_0798391044_02539_sci Please ensure those labels and data files will be in the real bundle. document/ - Many labels have lid_references to urn:nasa:pds:lucy.mvic:document:mvic_sis which is neither provided nor listed in collection_inventory.csv in this review. Please ensure that it exists in the delivered version. document/collection.xml - This lidvid_reference has no corresponding label: urn:nasa:pds:lucy.mvic:document:collection_overview::1.0 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.