=============================================== NOTE: (1) Tags added: REVIEW_DISCUSS: Discuss this at the peer review meeting (2) Things confirmed: Collection DOIs correct Targets in collection vs data products Primary_Result_Summary Referenced DOIs exist (except for the PDS collection's DOIs which have not been published yet) =============================================== Datasets Validated: urn:nasa:pds:lucy.llorri::2.0 urn:nasa:pds:lucy.llorri:data_dinkinesh_partially_processed::1.0 urn:nasa:pds:lucy.llorri:data_dinkinesh_raw::1.0 urn:nasa:pds:lucy.llorri:calibration::2.0 urn:nasa:pds:lucy.llorri:document::2.0 urn:nasa:pds:lucy.llorri:document::2.0 urn:nasa:pds:lucy.ltes:data_dinkinesh_hkraw::1.0 urn:nasa:pds:lucy.ltes:data_dinkinesh_raw::1.0 urn:nasa:pds:lucy.ltes:data_dinkinesh_calibrated::1.0 urn:nasa:pds:lucy.ltes:document::1.0 urn:nasa:pds:lucy.mission:document::1.0 urn:nasa:pds:lucy.leisa:data_dinkinesh_raw::1.0 urn:nasa:pds:lucy.leisa:data_dinkinesh_calibrated::1.0 urn:nasa:pds:lucy.leisa:calibration::1.0 urn:nasa:pds:lucy.leisa:document::1.0 urn:nasa:pds:lucy.mvic:document::1.0 urn:nasa:pds:lucy.mvic:data_dinkinesh_raw::1.0 urn:nasa:pds:lucy.mvic:data_dinkinesh_calibrated::1.0 urn:nasa:pds:lucy.mvic:calibration::1.0 urn:nasa:pds:lucy.rss:data_dinkinesh_ion::1.0 urn:nasa:pds:lucy.rss:data_dinkinesh_trk234::1.0 urn:nasa:pds:lucy.rss:data_dinkinesh_skyfreq::1.0 urn:nasa:pds:lucy.rss:data_dinkinesh_sff::1.0 urn:nasa:pds:lucy.rss:document::1.0 urn:nasa:pds:lucy.ttcam:data_dinkinesh_calibrated::1.0 urn:nasa:pds:lucy.ttcam:calibration::1.0 urn:nasa:pds:lucy.ttcam:data_dinkinesh_raw::1.0 urn:nasa:pds:lucy.ttcam:document::1.0 =============================================== Errors for: GLOBAL (all datasets) issue: There are no subdirectory structure, with all products placed at the root of the collection directories. --> TB: Strongly suggest adding some structure for the user that may browse the collection, so as to not overwhelm them with number of files, perhaps unrelated, mixed together. issue: Label Context Reference Mismatch --> The 'name' values associated with internal references to context objects do not match the Context_Area.*.name values as found in the context object file referenced. For targets, it is probably fine to be different if it conforms to SBN formatting. Many of these context files were provided by the Lucy mission, and so it is expected to match. Note, usages are not consistent across all bundles or even files within a bundle or collection (correct in some labels, not in others). Those unique to a particular bundle will be mentioned with that bundle. Lastly, please note that the PDS validate tool will identify all instances of these if you need a complete list of what and where. Examples common across all bundles: --> --> "Lucy Mission" vs "Lucy" (urn:nasa:pds:context:investigation:mission.lucy) --> --> "Lucy Spacecraft" vs "Lucy" (urn:nasa:pds:context:instrument_host:spacecraft.lucy) --> --> "Dinkinesh" or "DINKINESH" vs "(152830) Dinkinesh" (urn:nasa:pds:context:target:asteroid.152830_dinkinesh) issue: Repetitive name when resolving acronyms? --> REVIEW_DISCUSS: The term "Lucy's L'LORRI" or "Lucy L'LORRI" is used in various places (labels and text). But this translate to "Lucy's Lucy LOng ..." or "Lucy Lucy LOng ...". Is this okay? There are similar cases for "L'Ralph" and "L'TES". --> --> TB: I can personally go both ways with this, and see how it could be correct as is: "[spacecraft_name] [instrument_name]" => "[Lucy] [Lucy LOng ...]" --> --> There is one noted exception to this with the LEISA document collection title "Lucy Ralph LEISA Document Collection" --> --> Also note that when we populate DOI meta data, we may expand the acronym out, so it may look odd saying "Lucy Lucy". issue: Copies of published papers in PDS --> Identification_Area.Citation_Information.doi should not be for the published paper. PDS should never produce a DOI for a paper primarly published elsewhere. --> Add to the Identification_Area.Citation_Information.description the fact these papers of exact copy of open access documents. --> Add to the an to the published paper and add a description mentioning the relation between the PDS copy and the publish copy. Ex: "Original published source of this Open Access document." --> For any other label referencing these PDS copies in their Reference_List, we should include the external paper doi reference along side the internal reference to the internal copy. issue: Reference_List references missing or , or not being necessary. --> Whenever you reference a paper in a data product, please add a (for external_reference) or (for internal_reference) stating very briefly why this paper is being referenced. This can be as simple as saying it is the "SSR paper" or "description of the mission". An example is where the Calibration paper is being referenced; we should add a Calibration paper. For internal references to data products, usually the is clear enough, but this is not the case when referencing documents. If the referenced paper is not considered essential to either understanding or using the product, it should not be referenced. --> --> Example: lucy.leisa/data_dinkinesh_calibrated/lei_0752129330_02298_sci_04.xml (lines 1042-1049, two references) issue: Mission Phase --> Is the mission_phase_name keyword going to be in any of the labels? Suggest adding this to the Lucy LDD, with a standard list of values to validate against. You can use the New Horizons LDD (nh:mission_phase_name) as an example. 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. files: '*/bundle.xml' --> Suggest removing PDS4 jargon, "Bundle", from Identification_Area.title and replace with "Archive" or something similar. --> Suggest clarifying in the Identification_Area.Citation_Information.description that there are more than just "data products" in these bundles. There are also document products for instance; also Calibration products, though this is a usually a data product of one sort or another. --> REVIEW_DISCUSS: Why does each bundle (except mission and rss) have a Reference_List that includes the mission:document, [instrument]:document (which is found within the bundle), and [instrument] SSR paper (found within the bundle)? Are these necessary for the generation of the bundle? If so, why are they not included in the collection.xml files? files: '*/*/collection.xml' --> For the Identification_Area and Citation_Information sub-area, we take these values as what we would want to use for reference and citation information for the PDS product (collection in this case), like titles, authors, editors, and abstract (pds:description). We use these to populate DOI meta data, for assigned DOIs. Please have these values reflect what you would want to see in the DOI meta data, and by consequence at the ADS. --> --> Note that first occurrences of acronyms will be spelled out with the acronym being in parentheses. Ex: "L'LORRI" => "Lucy LOng Range Reconnaissance Imager (L'LORRI)". I would recommend doing this in your bundle/collection labels, in the abstract (pds:description) and/or title. --> Suggest removing PDS4 jargon, "Collection", from Identification_Area.title --> Strongly (on verge of requiring for active missions) suggest adding Funding_Acknowledgement to Identification_Area.Citation_Information. --> entries are not consistent. Please confirm these are correct. In general there is an internal reference to a copy of Levison et al. (2021) paper and an internal reference to the instrument SIS. Exceptions noted below: --> --> urn:nasa:pds:lucy.llorri:calibration::1.0 (only lists SIS) --> --> urn:nasa:pds:lucy.ltes:document::1.0 lists the instrument SSR paper as well --> --> urn:nasa:pds:lucy.mvic:document::1.0 lists the instrument SSR paper as well --> --> urn:nasa:pds:lucy.mission:document::1.0 lists no references (probably correct) --> Please add to the Reference_List an internal link to the collection_overview product. files: '*/readme.txt' --> REVIEW_DISCUSS: At the end of this file it suggests questions can go to "https://pds-smallbodies.astro.umd.edu/about/contact_info.shtml or pds-operator@jpl.nasa.gov". Using this url and/or email sounds like a bad idea. SBN website may move, or the pds-operator may change address. =============================================== Errors for: lucy.leisa issue: Label Context Reference Mismatch --> The 'name' values associated with internal references to context objects do not match the Context_Area.*.name values as found in the context object file referenced. For targets, it is probably fine to be different if it conforms to SBN formatting. Many of these context files were provided by the Lucy mission, and so it is expected to match. Note, usages are not uniform across all labels in this bundle (correct in some labels, not in others). Lastly, please note that the PDS validate tool will identify all instances of these if you need a complete list of what and where. All known problem instances for this bundle are below: --> --> "DINKINESH" vs "(152830) Dinkinesh" (urn:nasa:pds:context:target:asteroid.152830_dinkinesh) [6 instances] --> --> "LEISA" vs "Lucy Ralph Linear Etalon Imaging Spectral Array (LEISA)" (urn:nasa:pds:context:instrument:lucy.leisa) [19 instances] --> --> "Lucy Mission" vs "Lucy" (urn:nasa:pds:context:investigation:mission.lucy) [9 instances] --> --> "Lucy Spacecraft" vs "Lucy" (urn:nasa:pds:context:instrument_host:spacecraft.lucy) [14 instances] --> REVIEW_DISCUSS: Should double check the following Label Context Reference Mismatches, if they are using the correct target reference LID. Note there is always the option to not use a reference LID when none other is appropriate, or one may be created if it makes sense: --> --> 'Fringe Flat' vs 'Flat Field' (urn:nasa:pds:context:target:calibrator.flat_field) (note this is a migration for PDS3, description is lacking....) --> --> --> Affected files: 'calibration/*_fflat_0*.xml' --> --> 'Space Stare' vs 'SPACE' (urn:nasa:pds:context:target:calibration_field.space) --> --> --> Affected files: 'calibration/*_space_01.xml' --> --> --> Note that L'TES uses 'SPACE_CAL' instead. issue: Image orientation --> Highly recommend adding the Display_2D_Image (or disp:Display_Settings) for the 'calibration/*.xml' files to make it explicity clear how the bytes are being read and where (0,0) is; currently no where is this defined, and so assumed. files: 'calibration/[BLWl]*.xml' (data products) --> Should any of these data objects have units? I don't see any specified. file: 'calibration/collection_overview.txt' --> There are mentioned three major types of files, but not the Wavemap and BPM products. files: 'data_dinkinesh_calibrated/lei*.xml' --> Should the Array_3D and Array_2D objects have a unit? The raw data specifies in the label "DN" as expected. file: 'document/collection_overview.txt' --> The Documents section mentions that documents are named in one of two ways, the first descriptive, the second being based on Open Access DOI. This second is not the case for filename, nor document title. It then starts to describe what a descriptive case might be, but ends up describing a single case in detail. Then finally mentions "two additional documents", which reads as if they should not conform to the prior methods, but they kind of do. Please clarify or correct this whole paragraph. file: 'document/lralph_ssr.xml' --> line 60 typo: The Context_Area.Observing_System_Component.Internal_Reference.lid_reference for the MVIC instrument, points to LEISA instead of MVIC. It should be 'urn:nasa:pds:context:instrument:lucy.mvic'. =============================================== Errors for: lucy.llorri issue: Label Context Reference Mismatch --> The 'name' values associated with internal references to context objects do not match the Context_Area.*.name values as found in the context object file referenced. For targets, it is probably fine to be different if it conforms to SBN formatting. Many of these context files were provided by the Lucy mission, and so it is expected to match. Note, usages are not uniform across all labels in this bundle (correct in some labels, not in others). Lastly, please note that the PDS validate tool will identify all instances of these if you need a complete list of what and where. All known problem instances for this bundle are below: --> --> "DINKINESH" vs "(152830) Dinkinesh" (urn:nasa:pds:context:target:asteroid.152830_dinkinesh) [4898 instances] --> --> "L'LORRI" vs "Lucy Long Range Reconnaissance Imager (L'LORRI)" (urn:nasa:pds:context:instrument:lucy.llorri) [2 instances] --> --> --> found in: calibration/default_config.xml and document/collection.xml --> --> "Lucy Mission" vs "Lucy" (urn:nasa:pds:context:investigation:mission.lucy) [8 instances] --> --> "Lucy Spacecraft" vs "Lucy" (urn:nasa:pds:context:instrument_host:spacecraft.lucy) [13 instances] file: 'bundle.xml' --> Need to add back the Modification_History for Version 1.0. directory: 'calibration/' --> For the v1.0 files, it is recommended to update the labels from IM 1.18.0.0 to 1.20.0.0 to match the rest of the collection. In theses cases the label version would change to v1.1 from v1.0. file: 'calibration/collection_overview.txt' --> This file describes what was in the V1.0 of the collection (now we are V2.0) and neglects to describe any of the new files, as if they did not exist. Should this be the case? files: 'calibration/*.xml' (data products) --> Should any of these data objects have units? I don't see any specified. directory: 'document/' --> For the v1.0 files, it is recommended to update the labels from IM 1.18.0.0 to 1.20.0.0 to match the rest of the collection. In theses cases the label version would change to v1.1 from v1.0. file: 'document/collection_overview.txt' --> The Documents section mentions that documents are named in one of two ways, the first descriptive, the second being based on Open Access DOI. This second is not the case for filename, nor document title. It then starts to describe what a descriptive case might be, but ends up describing a single case in detail. Please clarify or correct this whole paragraph. =============================================== Errors for: lucy.ltes issue: Label Context Reference Mismatch --> The 'name' values associated with internal references to context objects do not match the Context_Area.*.name values as found in the context object file referenced. For targets, it is probably fine to be different if it conforms to SBN formatting. Many of these context files were provided by the Lucy mission, and so it is expected to match. Note, usages are not uniform across all labels in this bundle (correct in some labels, not in others). Lastly, please note that the PDS validate tool will identify all instances of these if you need a complete list of what and where. All known problem instances for this bundle are below: --> --> "DINKINESH" vs "(152830) Dinkinesh" (urn:nasa:pds:context:target:asteroid.152830_dinkinesh) [9 instances] --> --> "Lucy Mission" vs "Lucy" (urn:nasa:pds:context:investigation:mission.lucy) [6 instances] --> --> "Lucy Spacecraft" vs "Lucy" (urn:nasa:pds:context:instrument_host:spacecraft.lucy) [11 instances] --> --> "Lucy Thermal Emission Sepctrometer (LTES)" vs "Lucy Thermal Emission Spectrometer (L'TES)" [14 instances] --> --> --> note "LTES" vs "L'TES" and "Sepctrometer" vs "Spectrometer" --> --> "Lucy Thermal Emission Spectrometer (LTES)" vs "Lucy Thermal Emission Spectrometer (L'TES)" [1 instance] --> --> --> note "LTES" vs "L'TES" --> --> --> found in: 'document/collection_document_overview.xml' --> --> "The Lucy Thermal Emission Spectrometer (L'TES)" vs "Lucy Thermal Emission Spectrometer (L'TES)" [1 instance] --> --> --> drop the "The" --> --> --> found in: 'data_dinkinesh_hkraw/collection_overview.xml' --> REVIEW_DISCUSS: Should double check the following Label Context Reference Mismatches, if they are using the correct target reference LID. Note there is always the option to not use a reference LID when none other is appropriate, or one may be created if it makes sense: --> --> "INT_CAL" vs "INTERNAL SOURCE" (urn:nasa:pds:context:target:calibrator.internal_source) --> --> --> affected files: 'data_dinkinesh_raw/tes_0752123094_02098_eng_03.xml' and 'data_dinkinesh_raw/tes_0752136681_02115_eng_03.xml' --> --> "SPACE_CAL" vs "SPACE" for urn:nasa:pds:context:target:calibration_field.space (urn:nasa:pds:context:target:calibration_field.space) [2 instances] --> --> --> affected files: 'data_dinkinesh_raw/tes_0752123018_02097_eng_03.xml' and 'data_dinkinesh_raw/tes_0752136759_02116_eng_03.xml' --> --> --> Note that LEISA and MVIC uses the value 'Space Stare' instead. --> --> "UNKNOWN" vs "TEST IMAGE" for urn:nasa:pds:context:target:calibrator.test_image --> --> --> This may be a case where we drop the LID. --> --> --> Why is this labeled as a 'Calibrator' type? --> --> --> affected file: 'data_dinkinesh_hkraw/tes_0751610627_00000_eng_02.xml' file: 'data_dinkinesh_hkraw/collection.xml' --> Add Identification_Area.Citation_Information.doi = "10.26007/5svc-pd48" --> typo in Identification_Area.Citation_Information.description: "intiation" => "initiation" files: 'data_dinkinesh_raw/tes*xml' --> There are instances of Element_Array.unit having a number in it (ex: "s/65536"). This is unexpected. Would the number better be identified as a Element_Array.scaling_factor in this particular case? file: 'document/collection.xml' --> suggest updating Identification_Area.Citation_Information.description to spell out the "L'TES" instrument and/or state "Lucy L'TES" file: 'document/ltes_ssr.xml' --> The Identification_Area.Citation_Information.description says this paper is the "(L'TES) data products explanation" but isn't this an instrument description? For other SSR papers, they either state it is the SSR of the instrument or describes the instrument. =============================================== Errors for: lucy.mission issue: Label Context Reference Mismatch --> The 'name' values associated with internal references to context objects do not match the Context_Area.*.name values as found in the context object file referenced. Note, usages are not uniform across all labels in this bundle (correct in some labels, not in others). Lastly, please note that the PDS validate tool will identify all instances of these if you need a complete list of what and where. All known problem instances for this bundle are below: --> --> "Lucy Mission" vs "Lucy" (urn:nasa:pds:context:investigation:mission.lucy) [4 instances] --> --> "Lucy Spacecraft" vs "Lucy" (urn:nasa:pds:context:instrument_host:spacecraft.lucy) [6 instances] file: 'document/collection.xml' --> REVIEW_DISCUSS: Consider having SBN create a DOI for this collection. But since this collection only contains copies of other papers external to PDS, perhaps not. file: 'document/olkin_et_al_2021.{xml,pdf}' --> The Identification_Area.Citation_Information.description should be an abstract, but currently it just says "This paper" which is not helpful to a user or what is expected. --> The filename and label implies that this is Olkin et al. (2021) paper, but when I open the PDF, it is an exact copy downloaded from the https://doi.org/10.1007/s11214-024-01082-1, which is Olkin et al. (2024) paper with a different set of authors, title, etc than specified in the PDS label. Are we missing the correct PDF or does the label need to be corrected and renamed? Or do we need both? =============================================== Errors for: lucy.mvic issue: Label Context Reference Mismatch --> The 'name' values associated with internal references to context objects do not match the Context_Area.*.name values as found in the context object file referenced. For targets, it is probably fine to be different if it conforms to SBN formatting. Many of these context files were provided by the Lucy mission, and so it is expected to match. Note, usages are not uniform across all labels in this bundle (correct in some labels, not in others). Lastly, please note that the PDS validate tool will identify all instances of these if you need a complete list of what and where. All known problem instances for this bundle are below: --> --> "DINKINESH" vs "(152830) Dinkinesh" (urn:nasa:pds:context:target:asteroid.152830_dinkinesh) [6 instances] --> --> "Lucy Mission" vs "Lucy" (urn:nasa:pds:context:investigation:mission.lucy) [7 instances] --> --> "Lucy Spacecraft" vs "Lucy" (urn:nasa:pds:context:instrument_host:spacecraft.lucy) [12 instances] --> --> "MVIC" vs "Lucy Ralph Multispectral Visible Imaging Camera (MVIC)" (urn:nasa:pds:context:instrument:lucy.mvic) [8 instances] --> --> --> Affected files: 'calibration/[Mm]*.xml' --> REVIEW_DISCUSS: Should double check the following Label Context Reference Mismatches, if they are using the correct target reference LID. Note there is always the option to not use a reference LID when none other is appropriate, or one may be created if it makes sense: --> --> 'Space Stare' vs 'SPACE' (urn:nasa:pds:context:target:calibration_field.space) --> --> --> Affected files: 'calibration/*_space_01.xml' --> --> --> Note that L'TES uses 'SPACE_CAL' instead. issue: Image orientation --> Highly recommend adding the Display_2D_Image (or disp:Display_Settings) for the 'calibration/*.xml' files to make it explicity clear how the bytes are being read and where (0,0) is; currently no where is this defined, and so assumed. files: 'calibration/*.xml' (data products) --> Should any of these data objects have units? I don't see any specified. files: 'data_dinkinesh_calibrated/lei*.xml' --> Should the Array_3D_Image, Array_3D, and Array_2D objects have a unit? The raw data specifies in the label "DN" as expected. --> For the second extension "background", should this be a 3D_Array_Image instead of 3D_Array? file: 'document/collection_overview.txt' --> The Documents section mentions that documents are named in one of two ways, the first descriptive, the second being based on Open Access DOI. This second is not the case for filename, nor document title. It then starts to describe what a descriptive case might be, but ends up describing a single case in detail. Please clarify or correct this whole paragraph. =============================================== Errors for: lucy.rss issue: Label Context Reference Mismatch --> The 'name' values associated with internal references to context objects do not match the Context_Area.*.name values as found in the context object file referenced. For targets, it is probably fine to be different if it conforms to SBN formatting. Many of these context files were provided by the Lucy mission, and so it is expected to match. Note, usages are not uniform across all labels in this bundle (correct in some labels, not in others). Lastly, please note that the PDS validate tool will identify all instances of these if you need a complete list of what and where. All known problem instances for this bundle are below: --> --> "Global Positioning System" vs "Deep Space Station Media Calibration Subsystem" (urn:nasa:pds:context:instrument:dsn.media) [28 instances] --> --> --> Sanity check that this is the intended LID; from the context object description it appears to be the same thing. --> --> "Lucy Mission" vs "Lucy" (urn:nasa:pds:context:investigation:mission.lucy) [195 instances] --> --> "Lucy RSS", "Lucy Radio Science Subsystem", "Lucy Radio Science System", "Radio Science", and "Lucy Telecom System" vs "Lucy Radio Science" (urn:nasa:pds:context:instrument:lucy.rss) [289 instances] --> --> --> I would highly recommend updating the lucy.rss context object Instrument.name value to be changed to "Lucy Radio Science Subsystem" or "Lucy Radio Science System" from "Lucy Radio Science" to match the RSS acronym being used. SBN can submit this change if this is acceptable. --> --> "Lucy Spacecraft" vs "Lucy" (urn:nasa:pds:context:instrument_host:spacecraft.lucy) [50 instances] --> --> "NASA Deep Space Network Media Calibration" vs "DSN Media Calibration" (urn:nasa:pds:context:investigation:other_investigation.media.dsn) [28 instances] --> --> "NASA Deep Space Network" vs "Deep Space Network" (urn:nasa:pds:context:facility:observatory.dsn) (3 instances) --> FYI: Validate says there is a Target_Type mismatch when target is lucy.rss or spacecraft.lucy, the labels say the type is "Equipment", which is similar to what has been done in the past, and is correct per the 1K00 IM. But validate claims it expected the value "N/A" or "Spacecraft" respectively. Please keep using "Equipment". --> --> Ex: lucy.rss/data_dinkinesh_trk234/lucy_2023_245_001950_2023_245_010950_35.xml (line 120) --> --> Ex: lucy.rss/data_dinkinesh_sff/lcy_r_230829_230904_v01.xml (line 68) --> --> TB: I don't know why validate is doing this, since "Spacecraft" is not a valid value for Target_Identification.type. I submitted a ticket: https://github.com/NASA-PDS/validate/issues/995 issue: Lucy RSS name inconsistency --> Sometimes this instrument is called "Lucy's Radio Science instrument" or "Lucy Radio Science Subsystem" or "Lucy Radio Science System" or etc. Please consider trying to be more consistent, where appropriate. I saw these inconsistencies in collection descriptions, titles, names, etc., within the labels. I did not look thru any other text to see there. Please double check the value in the lucy.rss context object is correct. issue: Primary_Result_Summary --> Sanity check the value: --> --> All ion and sff products say "Calibration" but the collection.xml says "Science". I would not expect this mismatch. --> --> Are the TRK234 products supposed to be Science? --> --> Note here is a good list of possible values and their definition per the PDS: https://pds.nasa.gov/datastandards/documents/dd/v1/PDS4_PDS_DD_1K00/webhelp/all/#ch05s714.html#N760331470 files: '*/collection.xml' --> Sanity check: is the Identification_Area.Citation_Information.description for skyfreq collection supposed to be "calibrated data products" and for ion collection supposed to be "raw data products". --> The following Identification_Area.title values differ from what was submitted in the past. The new values do not make sense. I recommend combining the two values (old/new). Note three of them are now exactly the same, which should never be the case. [collection: OLD => CURRENT] --> --> ion collection: "Lucy Radio Science Mission Dependent Ionosphere Data Collection" ==> "Lucy Radio Science Dinkinesh Raw Data Collection" --> --> sff collection: "Lucy Radio Science Small Forces File Data Collection" ==> "Lucy Radio Science Dinkinesh Raw Data Collection" --> --> skyfreq collection: "Lucy Radio Science Sky Frequency Data Collection" ==> "Lucy Radio Science Dinkinesh Calibrated Data Collection" --> --> trk234 collection: "Lucy Radio Science Tracking Data Collection" ==> "Lucy Radio Science Dinkinesh Raw Data Collection" --> REVIEW_DISCUSS: Is "(152830) Dinkinesh" really the target of these data collections or correctly reflecting the target? What should the target really be, what would be useful for the user looking for this data? The data files reflect the following as the target: --> --> ion collection: "Earth" --> --> sff collection: "Lucy Spacecraft" --> --> skyfreq collection: "Lucy Spacecraft" --> --> trk234 collection: "Lucy RSS" file: 'data_dinkinesh_ion/collection.xml' --> REVIEW_DISCUSS: The authors of this collection are listed as "Pätzold, M.; Hahn, M.", but all of the data products list the author as "NASA Deep Space Network". Who should get authorship for this collection? files: 'data_dinkinesh_ion/gimacl*xml' --> REVIEW_DISCUSS: These describe the CSP files as streamed text only. Is this a problem, or only thing possible? --> Should any of these data objects have units? I don't see any specified. file: 'data_dinkinesh_sff/collection.xml' --> REVIEW_DISCUSS: If this collection was produced by NAIF, as the Identification_Area.Citation_Information.description and all of the data product labels states, than shouldn't they be one of the authors, if not the only author? --> The Identification_Area.Citation_Information.description typo: "NAvigation" vs "Navigation" file: 'data_dinkinesh_sff/collection_inventory.csv' --> typo in the first row LIDVID, "colection" should be "collection", so the correct value should be "urn:nasa:pds:lucy.rss:data_dinkinesh_sff:collection_overview::1.0" files: 'data_dinkinesh_skyfreq/L*.xml' --> The values used should be updated to conform to PDS standards. Ex: "DAY" => "day" or "HERTZ PER SECOND" => "Hz/s" --> --> Here is a quick reference: https://sbnwiki.asteroiddata.org/Units_of_Measure.html file: 'data_dinkinesh_trk234/collection.xml' --> REVIEW_DISCUSS: The authors of this collection are listed as "Pätzold, M.; Hahn, M.", but all of the data products list the author as "NASA Deep Space Network". Who should get authorship for this collection? --> REVIEW_DISCUSS: The Identification_Area.Citation_Information.description states that the data products were produced by the Lucy's Radio Science team, but the data labels say "NASA Deep Space Network" is the author, and Lucy SOC members are the editors. Please resolve this discrepancy. file: 'data_dinkinesh_trk234/collection_inventory.csv' --> The first LIDVID in this should be changed from "urn:nasa:pds:lucy.rss:data_dinkinesh_trk234:collectin_inventory::1.0" to "urn:nasa:pds:lucy.rss:data_dinkinesh_trk234:collection_overview::1.0". Note the "inventory" vs "overview". files: 'data_dinkinesh_trk234/lucy*xml' --> REVIEW_DISCUSS: The Identification_Area.Citation_Information.description of the collection.xml states that these data products were produced by the Lucy's Radio Science team, but these labels say "NASA Deep Space Network" is the author, and Lucy SOC members are the editors. --> Should any of these data objects have units? I don't see any specified. =============================================== Errors for: lucy.ttcam issue: Label Context Reference Mismatch --> The 'name' values associated with internal references to context objects do not match the Context_Area.*.name values as found in the context object file referenced. For targets, it is probably fine to be different if it conforms to SBN formatting. Many of these context files were provided by the Lucy mission, and so it is expected to match. Note, usages are not uniform across all labels in this bundle (correct in some labels, not in others). Lastly, please note that the PDS validate tool will identify all instances of these if you need a complete list of what and where. All known problem instances for this bundle are below: --> --> "DINKINESH" vs "(152830) Dinkinesh" (urn:nasa:pds:context:target:asteroid.152830_dinkinesh) [348 instances] --> --> "Lucy Mission" vs "Lucy" (urn:nasa:pds:context:investigation:mission.lucy) [6 instances] --> --> "Lucy Spacecraft" vs "Lucy" (urn:nasa:pds:context:instrument_host:spacecraft.lucy) [13 instances] --> --> "TTCam", "Lucy Terminal Tracking Cameras (TTCams)", or "Lucy Terminal Tracking Camera (TTCAm)" vs "Lucy Terminal Tracking Cameras (TTCAM)" (urn:nasa:pds:context:instrument:lucy.ttcam) [10 instances] --> --> --> Note the "Camera" vs "Cameras" and "TTCams" vs "TTCam" (plural in both cases) and that case is not sensitive for validation. --> REVIEW_DISCUSS: Should double check the following Label Context Reference Mismatches, if they are using the correct target reference LID. Note there is always the option to not use a reference LID when none other is appropriate, or one may be created if it makes sense: --> --> "Master Flat" vs "Flat Field" (urn:nasa:pds:context:target:calibrator.flat_field) [2 instances] issue: Image orientation --> Highly recommend adding the Display_2D_Image (or disp:Display_Settings) for the 'calibration/*.xml' files to make it explicity clear how the bytes are being read and where (0,0) is; currently no where is this defined, and so assumed. file: 'bundle.xml' --> The Identification_Area.Citation_Information.description says the bundle contains data from the "Tracking Camera(s)". Do you not know if it is plural or not or is this still in question? file: 'calibration/collection_overview.txt' --> Suggest resolving any paper references in the body text at the end of the document. Ex: "Zhao et al. (2024)" (which there is an internal copy for) files: 'data_dinkinesh_calibrated/tt*.xml --> I see the "none". If "none" is the case, I would recommend removing the keyword. file: 'document/collection.xml' --> The Identification_Area.title says "Lucy Terminal Tracking Camera System TTCam", which is the only time I see TTCam separate among the collection.xml files for TTCam. Is this okay? Should it be "Lucy Terminal Tracking Camera (TTCam) System"? file: 'document/collection_overview.txt' --> The Documents section mentions that documents are named in one of two ways, the first descriptive, the second being based on Open Access DOI. This second is not the case for filename, nor document title. It then starts to describe what a descriptive case might be, but ends up describing a single case in detail. There is no mention of the user guide (as with other instruments). Please clarify or correct this whole paragraph.