Lucy L'LORRI Liens ================== Documentation ============= --> The User’s Guide explains the file naming scheme, but differs from the SIS. Must include the image_counter and image_format parts in the file names. file: readme.txt --> Wrong mission phase for the Donaldjohanson sets. Dinkinesh -> Donaldjohanson. file: 'data_didymos_partially_processed/collection_overview.txt' --> First line and first overview paragraph describe Dinkinesh, not Didymos. Please correct. --> Second overview paragraph describes the DonaldJohanson closest approach, which should be removed. Perhaps you may want to add the approximate distance to Didymos. file: 'data_didymos_raw/collection_overview.txt' --> First paragraph mentions "Lucy Mission Didymos Encounter". Can this really be described as an encounter or is it remote observations. --> First paragraph typo: citing a document title, "LLORRI" => "L'LORRI", per pdf document title (unfortunately, the archived xml title for this pdf document is not quite correct, not even mentioning Didymos) --> Second overview paragraph describes the DonaldJohanson closest approach, which should be removed. Perhaps you may want to add the approximate distance to Didymos. file: data_didymos_partially_processed/Collection_overview.txt --> Entire text refers to Dinkinesh encounter, but this file is supposed to describe Didymos observations. Needs full mission context correction. --> “Closest Approach occurred at 17:51:16 UT April 20, 2025 at a distance of 962 km. All tCA calculations (time of closest approach) are calculated from this date.” unrelated. --> Wrong reference paper --> Add bundle context --> Add usage guidance of this data Data ==== Didymos Data --> Appears as if every other frame of the dataset has strange saturation issues. Flatfield does not show the same pattern. There was either no mention of this phenomenon is the User’s Guide, or it was unclear. Labels ====== --> Target name for DJ should be "(52246) Donaldjohanson". --> Add the target NAIF ID attribute () if applicable. --> lucy:dinkinesh_constant attribute is present. Requires Lucy DD update. --> In both raw and calibrated data labels, the ebt:AP_ORDER and ebt:BP_ORDER classes are missing s that appear in the FITS headers. --> It was unclear where to find spacecraft health data contained in the Image Header/Descriptor headers… are they included with the raw images somewhere? Represented in label files/FITS headers? --> Can the time before/after DART impact be included in the metadata? files: 'data_*/l*.xml' --> [Dinkinesh lien] Add the target NAIF ID if applicable. For example, (152830) Dinkinesh it is 920152830 (TARGETID in the FITS header). // --> Please add the sb:Quality_Map class to help describe the meaning of each value in the quality map which is not described in the xml labels. file: 'bundle.xml' --> typo in Modification_Detail "theDonaldjohanson" => "the Donaldjohanson" file: collection_inventory.csv --> LIDs must be full LIDVIDs. file: 'lucy.llorri/data_didymos_*/collection.xml' --> For the raw colleciton, the Reference_List reference to the overview document is malformed ("overview" mispelled and missing double colons before VID). Please fix from "urn:nasa:pds:lucy.llorri:data_didymos_raw:collection_ovrview:1.0" to "urn:nasa:pds:lucy.llorri:data_didymos_raw:collection_overview::1.0". --> Why was the target urn:nasa:pds:context:target:satellite.65803_didymos.dimorphos added? It was not listed in version 1.0 of the collection and is not found in any of the data product labels. --> The collection overview document (at least for the raw, pp has issues), mentions a description of the LLORRI DART observations being in the User's Guide V2.0. I would highly recommend adding a LIDVID reference to this document in the Reference_List of each of the two Didymos data collection products. --> Please add a single sentence to the Citation_Information.description explaining the major difference between V1.0 and V2.0 of the collection; something similar to the modification history entry should be sufficient. We want to differentiate this data collection version from the prior one. file: 'lucy.llorri/data_donaldjohanson_*/collection.xml' --> [Dinkinesh lien] You have the purpose Science but Navigation in the PDS4 XML data labels. Multiple purposes can be added if applicable. This was fixed in Dinkinesh, but the same situation is for the data_donaldjohanson collections, but not fixed here as well. Test Images. See lor_0798446314_04697_00001_1x1_sci_03.xml --> should not be Science. --> Target name "TEST_IMAGE" does not match test image context object. --> Remove empty geom:Orbiter_Identification. Raw Data --> Either include calibration files specific to this dataset in Reference_List (dj_auto_flat_1x1.xml and dj_auto_flat_4x4.xml) or remove because this is the raw collection. --> Unit for histogram as DN. It’s a count too, but should not mix with DN. --> --> Confirmed with Lucy team that the unit of DN is correct. The x-axis is labeled with a unit of DN, but the y-axis has an implicit unit for histograms of either frequency or something like count/bin or pixels/bin. Partially Processed Data --> All partially processed image extension unit, image, error and quality flag are DN/s, but this is different from the SIS. --> --> Confirmed with the Lucy team that the SIS is correct and the error is in the labels. The units should be in DN for the image and error extension data, and no units for the quality flag extension data. --> Change "calibrated" to "partially processed" in Citation_Information description. --> Add time offset corrections from the sb:Calibration_Applied class in the Small Bodies LDD. --> Remove duplidate urn:nasa:pds:lucy.llorri:calibration:llorri_superbias_1x1 reference. --> Remove duplidate urn:nasa:pds:lucy.llorri:calibration:llorri_toffsets_1x1 reference. --> Only dj_auto_flat_1x1 is listed as a calibration reference file in the Small Bodies dictionary, even though llorri_flat_1x1 is referenced elsewhere. Include both or remove superfluous reference. --> For references to calibration files, use LIDVID instead of LID. Calibration files described in the SB LDD do not need to be included as general Reference_List entries. Calibration Data files: dj_auto_flat_1x1.xml, dj_auto_flat_4x4.xml --> Start and stop date time should be more specific than just a year. --> In the PDS4 XML label the exposure time is 30 s. And in the files llorri_toffsets_1x1.txt and llorri_toffsets_4x4.txt the exposure time is in ms with a max exposure of 999ms. file: 'calibration/collection.xml' --> Please add back the Citation_Information.description from prior versions as it was more verbose and useful. --> Funding_Acknowledgement removed? --> changed from Derived to Raw. Is this correct? --> The number of for the inventory should be updated from 2 to the correct number. --> The inventory file needs to include all v1.0 products. Missing the collection_overview, default_config, and two dinky_flat LIDVIDs. file: 'calibration/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 v2.0 of this collection. file: 'calibration/collection_overview.txt' --> This file should be versioned (from dinkinesh) to include mention of the new dj_auto_flat files and update the statements about the flats being valid thru dinkinesh. Don't forget to update any VID references in the collection label and inventory file. file: 'lucy.llorri/calibration/dj_auto_flat_1x1.xml' --> The has the text ".xml" in it that should be removed. EN Liens ======== *.xml - Most (all?) labels have a lid_reference to urn:nasa:pds:lucy.llorri:document:llorri_sis but this delivery doesn't have this file or even a directory document/. Please ensure that label will be availabe in the bundle. calibration/collection_inventory.csv - The labels for the first 8 LIDs listed aren't provided in this review, but many labels in this review have lid_references to them. Please ensure they will be availabe in the real bundle. data_*/ - All four directories have too many files at the top level. Is there a natural split into subdirectories, perhaps by lucy:observation_id? data_didymos_partially_processed/collection.xml - Suggestion: change type from Asteroid to Satellite for <name>(65803) Didymos I (Dimorphos)</...> <type>Asteroid</...> <Internal_Reference> <lid_reference>urn:nasa:pds:context:target:satellite.65803_didymos.dimorphos</...> "Asteroid" matches the currect value in the context product, but that should be corrected to "Satellite" data_didymos_raw/collection.xml - typo in lidvid_reference urn:nasa:pds:lucy.llorri:data_didymos_raw:collection_ovrview:1.0 should be urn:nasa:pds:lucy.llorri:data_didymos_raw:collection_overview:1.0 - Suggestion: change type from Asteroid to Satellite for <name>(65803) Didymos I (Dimorphos)</...> <type>Asteroid</...> <Internal_Reference> <lid_reference>urn:nasa:pds:context:target:satellite.65803_didymos.dimorphos</...> "Asteroid" matches the currect value in the context product, but that should be corrected to "Satellite" 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 <comment> or <description> --> For any product label (bundle, collection, data, etc), please add a <description> (for external_reference) or <comment> (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 <name> 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.