Lucy Radio Science Liens ======================== Documentation ============= file: rss_sis.pdf --> Section 2.4.4 states that ASCII files generally end in line feed. However, SFF and ION files, two of the three text type files, actually end in in new-line. The simplest resolution would be to simply delete the second sentence, which is grammatically incorrect anyway. “ASCII or UTF-8 text file generally, line endings are line-feed.” --> Section 3.2.1 correct the link to https://pds-geosciences.wustl.edu/radiosciencedocs/urn-nasa-pds-jpl_dsn_mmm/ (missing a hyphen at “pdsjpl” --> Items 4-6 are based on the originally posted SIS. The newly posted SIS, 22668.07-RSS-SIS-01 R0 C1, no longer contains the sky frequency data format description table, which is good to have. --> 3.2.3 Columns 6 and 7 are declared as not used in closed loop mode. However, the data files contain values other than 0000-00-00T00:00:00.000 or -999999999.999999, respectively. Perhaps the data were collected in “open loop” mode? Please clarify. --> 3.2.3 Column 8 designated as -99999.999999 but data files contain -999.999999 --> 3.2.3 Column 14 designated as -999.999999 but data files contain 0.000000 --> Acronym List contains several entries that don’t appear in the document. --> Some entries that should be included in the acronym list are TNF and SFF --> (2.1) Lucy will encounter a Main Belt asteroid in 2025, and (REMOVE "and") visit its first Trojan asteroid in 2027, and accomplish its remarkable succession of encounters by 2033, --> (2.1.1.1) For SPE (ADD "angle") less than 14 degrees --> (2.1.1.1) For SPEs(CHANGE "SPEs" -> "SPE angle") between 14 and 53 degrees --> (2.1.1.1) The LGA is used for SPEs (CHANGE "SPEs" -> "SPE angle") greater than 53 degrees. --> (2.1.1.1) when SPE (ADD "angle") is less than 60 degrees --> (2.1.2) Note that the Lucy project has been approved to use of (REMOVE "of") the uplink and downlink X-band frequencies/channels assigned to the OSIRIS-REx and MAVEN projects. --> (2.3.4.1) Each of the radio science data products have (CHANGE "have" -> "has") a unique naming convention --> (2.3.4.1) The naming convention for the tracking data products (trk-2-34) products are (CHANGE "are" -> "is") Data ==== --> Small forces are only present on 2025-04-20 to 2025-04-21. Either document why there are missing small forces files OR provide them. --> --> Per the Lucy team: The submitted and reviewed SFF file (lcy_r_250420_250421_v05.sff) covers the time period near the Donaldjohanson encounter, and there are no relevant missing data. A data gap before and after that time period is intentional since, per plan, there is no thruster activity around any encounter in order to optimize mass determination. Data outside of the time range of this file do not scientifically improve this dataset, are not necessary for interpretation for the flyby, and will be archived later as cruise data. --> --> Adjusting lien to document this in the data collection overview file. --> Skyfreq data only cover 9 passes near the Flyby on DOY 110, whereas TNF data cover DOYs 100 to 117. Either document why there are missing skyfreq files OR provide them. --> --> Per the Lucy team: The submitted and reviewed sky frequency data covers the time period near the Donaldjohanson encounter, and there are no relevant missing data. Data outside of the time range of these files do not scientifically improve this dataset, are not necessary for interpretation for the flyby, and will be archived later as cruise data. --> --> Adjusting lien to document this in the data collection overview file. --> "The SOURCE_PRODUCT_ID mentioned in the label header above links to the different data files used for processing of the DOPPLER output file." Where is this? Labels ====== Issue: Context object name mismatch --> The lucy.rss context object should include the alternate name of "Lucy Radio Science Subsystem" or change the delivered product labels' value to "Lucy Radio Science". Ask PDS-EN for including this alternate name if desired to use it, but submitting a GetHub ticket. SBN can support making this request. issue: processing_level --> There appears to be confusion about what the correct processing level for each data collection and data product is, based on the last review Dinkinesh delivery, lien addressed delivery and the current DJ delivery. During Dinkinesh lien resolution, the review response to a similar lien said that ion data should be raw. Please confirm what is correct and fix if necessary. DJ Dinkinesh (data labels) ion Calibrated Raw (Partially Processed) sff Derived Raw (Derived) skyfreq Calibrated Calibrated trk234 Raw Raw issue: inconsistent Observing_System_Component --> The Observing_System_Component does not match between the collection.xml file and the data product labels in the collection. --> Please note you can have more than one Observing_System, one for Lucy and one for DSN. --> Sometimes there is an Observing_System that says Lucy is the host with lucy.rss and dsn.rss as its instruments (like in the skyfreq collection). But the dsn.rss is not an instrument for Lucy. --> Sometimes only the Lucy spacecraft is listed as the only observing system. file: 'data_donaldjohanson_*/collection.xml' --> [Dinkinish Lien reworded] The Target_Identification should not be DJ. In general these should reflect the primary target(s) or targets of note, observed and listed in the data product labels. This was fixed in Dinkinesh, but appears again here. --> All but the Ion collection has a reference in the Reference_List to urn:nasa:pds:lucy.rss:document:rss_info::1.0. But this LID is unknown. --> --> Joel suspects it is for the SIS, urn:nasa:pds:lucy.rss:document:rss_sis files: 'data_donaldjohanson_skyfreq/L*.xml' --> [Dinkinesh lien] labels contain internal reference to small forces. i think this is an oversight and actually belongs in the SFF labels. urn:nasa:pds:orex.radioscience:document:naf018 data_to_document Although this document does not explicitly pertain to Lucy, its content is still applicable. Until a new version of this document is created for Lucy, this reference will have to suffice. --> [Dinkinesh Lien] label makes reference to a SOURCE_PRODUCT_ID but I can't find that anywhere else in the label. the description also makes reference to S-band which Lucy is not capable of. Can the description be updated? --> [Dinkinesh Lien] The Primary_Result_Summary.description states "The SOURCE_PRODUCT_ID mentioned in the label header above links to the different data files used for processing of the DOPPLER output file. ..." Where is this? --> --> This appears to be PDS3 jargon and text from a PDS3 label. Please correct this for the PDS4 environment. EN Liens ======== - Add lid_references to any context LIDs its collections have, i.e.: urn:nasa:pds:context:instrument:dsn.media urn:nasa:pds:context:instrument:dsn.rss 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.