Radio Science Liens =================== These liens are for the entire bundle and all collections therein. Liens may not apply or be relevant in all places. Documentation ============= file: document/rss_sis.pdf --> Page 2 Table 1-1. Recommend adding DSN SIS documents (TRK-2-34, TRK-2-24, TRK-2-25) --> Are the antenna phase center locations avaiable (Table 2-4)? --> Was the transponder delay measured or have a requirement (Section 2.1.3.1)? --> 2.3.2 The skyfreq files are not a standard DSN product and thus aren't documented in the radio science documentation bundle. Some description of how they are produced would be helpful. Similary, TRK-2-34 files as delivered by the DSN are not really PDS compliant as the radio science documentation bundle points out. Recommend a statement for pre-processing before archival stating the records were sorted by data type to improve PDS4 labeling. These are all stated below in Section 3 but a brief statement here would be helpful, or at least refer the reader to Section 3. --> 2.3.2.1 Calibrated Data product generation. this seems like a leftover section from a template since there are no calibrated data products. Remove? --> 2.3.3 Data flow. This section is empty, is it intended to be removed or have some content? --> 3.2.2 Small Forces. Text states there is a SIS provided in the documentation bundle, but it is missing. The collection refers to OREX SFF SIS. This SIS does not mention Lucy in it, and that SIS has multiple formats depending on the spacecraft. The data labels themselves specify that the format is the same as ORX and the labels appear to properly describe the data. However, the Lucy files have 31 columns yet the ORX SFF SIS specifies 47 columns and ORX data have 47 columns. This should be explained somehow. --> Section 2.4.4 states that ASCII files generally end in line feed. SFF and ION files, which do not have the .TAB extension, actually end in in new-line. Perhaps call this out more clearly. --> 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”. (Ideally, we do not want URLs in archival products. Is there a more permanent reference to this page?) --> 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. [kahan@chiron data_dinkinesh_skyfreq]$ head L14TNFXL02_DPX_233051830_00.TAB 00000001 2023-11-01T18:30:06.497 305.77090853 752135475.680000 2.264122 2023-11-01T17:36:27.801 7188358000.631005 -999.999999 8445908395.101487 8445908394.902000 0.002762 0.199487 -126.0 0.000000 -99999.999999 -999.9 -999.9 00000002 2023-11-01T18:30:07.497 305.77092010 752135476.680000 2.264122 2023-11-01T17:36:28.801 7188358001.192585 -999.999999 8445908394.358078 8445908394.229759 0.002762 0.128319 49.0 0.000000 -99999.999999 -999.9 -999.9 --> 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 Minor editorial corrections (correct version appears): --> (2.1) Lucy will encounter a Main Belt asteroid in 2025, visit its first Trojan asteroid in 2027, and accomplish its remarkable succession of encounters by 2033, --> (2.1.1.1) For SPE angle less than 14 degrees --> (2.1.1.1) For SPE angles between 14 and 53 degrees --> (2.1.1.1) The LGA is used for SPE angles greater than 53 degrees. --> (2.1.1.1) when SPE angle is less than 60 degrees --> (2.1.2) Note that the Lucy project has been approved to use 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 has a unique naming convention --> (2.3.4.1) The naming convention for the tracking data products (trk-2-34) products is --> Naming Conventions. Please clarify the use of “TNF” throughout the document. It is the extension for TRK-2-34 files, assumed to mean “Tracking and Navigation File” (though that is not stated). It is also included in the naming for sky frequency files, presumably meaning the same thing. However, if so, how is it known from “TNFX” that the data are two-way? “rrrr = receiver system; TNFX = Trac-2-34 two-way single X-band.” Perhaps only 2-way data were used in the creation of the sky frequency files. If so, no need to mention 2-way in the naming convention. Just reserve discussion for section 3.2.3 describing the sky frequency files. file: data_dinkinesh_trk234/collection_overview.txt --> refers to .tnf text files but trk-2-34 files are not text. Data ==== data_dinkinesh_ion/ --> there are multiple files that cover the same months, but with updated data. I don't see a strong reason to have archived multiple versions of the same coverage window, only the latest ones should be archived. Leaving all versions in would lead to confusion. If data providers want to archive multiple of the same data coverage window I would recommend adding a statement into the SIS to only use the latest delivery date file. data_dinkinesh_skyfreq/ --> 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. --> 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? --> column DISTANCE doesn't seem correct (2.26 km?) --> column DIFFERENTIAL DOPPLER states that if invalid it will be -999.999999 yet the value is actually zero in the files Labels ====== file: data_dinkinesh_trk234/collection_inventory.csv --> Collection CSV has a typo - P,urn:nasa:pds:lucy.rss:data_dinkinesh_trk234:collectin_inventory::1.0. (This should probably refer to the collection_overview product.) file: data_dinkinesh_skyfreq/L14TNFXL02_DPX_233051830_00.xml --> 1. “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? file: data_dinkinesh_sff/lcy_r_230829_230904_v01.xml --> 1. DMASS – it isn’t defined what this variable actually is. Like the missions listed, will it always be zero for Lucy? 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" --> 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' --> 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' --> 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' --> 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" 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' --> 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? --> 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. files: 'data_dinkinesh_trk234/lucy*xml' --> 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. EN Review ========= lucy.rss:data_dinkinesh_ion *.xml - Suggestion: to match the context products, change Lucy Mission NASA Deep Space Network Media Calibration Global Positioning System to Lucy DSN Media Calibration Deep Space Station Media Calibration Subsystem - Suggestion: add lid_reference to DSN facility urn:nasa:pds:context:facility:observatory.dsn collection*.xml - Suggestion: to match the context products, change Lucy Spacecraft to Lucy - Suggestion: add the union of the children lid_references, i.e. add urn:nasa:pds:context:target:planet.earth Should that replace urn:nasa:pds:context:target:asteroid.152830_dinkinesh, which no child product has. collection.xml - The product in this lid_reference isn't given here. Verify the LID is correct urn:nasa:pds:lucy.mission:document:lucy_mission_info In the 2023.05 review, many collection.xml had a lid_reference to urn:nasa:pds:lucy.mission:document:lucymissioninfo - Suggestion: add the union of the children lid_references, i.e. add urn:nasa:pds:context:instrument:dsn.media urn:nasa:pds:context:investigation:other_investigation.media.dsn urn:nasa:pds:context:target:planet.earth lucy.rss:data_dinkinesh_sff *.xml - Suggestion: for Target_Identification, though the spacecraft acts as equipment here, still try to match the context product, so change Lucy Spacecraft Equipment to Lucy Spacecraft - Suggestion: for Observing_System_Component and Investigation_Area, to match the context products, change Lucy Mission Lucy Spacecraft to Lucy Lucy collection.xml - The product in this lid_reference isn't given here. Verify the LID is correct urn:nasa:pds:lucy.mission:document:lucy_mission_info In the 2023.05 review, many collection.xml had a lid_reference to urn:nasa:pds:lucy.mission:document:lucymissioninfo collection_inventory.csv - Typo on line 1: P,urn:nasa:pds:lucy.rss:data_dinkinesh_sff:colection_overview::1.0 should be P,urn:nasa:pds:lucy.rss:data_dinkinesh_sff:collection_overview::1.0 lucy.rss:data_dinkinesh_skyfreq *.xml - Suggestion: use a calibrator target instead of the spacecraft, e.g. one of urn:nasa:pds:context:target:calibrator.flat_field urn:nasa:pds:context:target:calibrator.internal_source urn:nasa:pds:context:target:calibrator.non_science urn:nasa:pds:context:target:calibrator.spacecraft_deck ... If you stay with the spacecraft, still match the context product's name and type, so change Lucy Spacecraft Equipment to Lucy Spacecraft - Suggestion: for Observing_System_Component and Investigation_Area, to match the context products, change Lucy Mission Lucy Spacecraft Lucy Radio Science System NASA Deep Space Network to Lucy Lucy Lucy Radio Science Deep Space Network collection.xml - The product in this lid_reference isn't given here. Verify the LID is correct urn:nasa:pds:lucy.mission:document:lucy_mission_info In the 2023.05 review, many collection.xml had a lid_reference to urn:nasa:pds:lucy.mission:document:lucymissioninfo - Suggestion: add the union of the children lid_references, i.e. add urn:nasa:pds:context:facility:observatory.dsn L*.xml - Many fields' descriptions describe special values. Add Special_Constants to those fields to allow automated handling of those. Examples: TRANSMIT FREQUENCY - CONSTANT TERM: -999999999.999999 TRANSMIT FREQUENCY - LINEAR TERM: -99999.999999 OBSERVED X-BAND ANTENNA FREQUENCY: -999999999.999999 SIGNAL LEVEL: -999.9 DIFFERENTIAL DOPPLER: -999.999999 SIGMA OBSERVED ANTENNA FREQUENCY: -99999.999999 SIGNAL QUALITY: -999.9 SIGMA SIGNAL LEVEL: -999.9 lucy.rss:data_dinkinesh_trk234 *.xml - Suggestion: use a calibrator target instead of the instrument, e.g. one of urn:nasa:pds:context:target:calibrator.flat_field urn:nasa:pds:context:target:calibrator.internal_source urn:nasa:pds:context:target:calibrator.non_science urn:nasa:pds:context:target:calibrator.spacecraft_deck ... If not, use the spacecraft as the RSS skyfreq bundle does, i.e. change Lucy RSS urn:nasa:pds:context:instrument:lucy.rss to Lucy Spacecraft urn:nasa:pds:context:instrument_host:spacecraft.lucy If not, then match the context product's name, i.e. change Lucy RSS to Lucy Radio Science System - Suggestion: add lid_reference to DSN facility urn:nasa:pds:context:facility:observatory.dsn - Suggestion: for Observing_System_Component and Investigation_Area, to match the context products, change Lucy Mission Lucy Telecom System to Lucy Lucy Radio Science collection*.xml - Suggestion: to match the context products, change Lucy Spacecraft Lucy Mission Radio Science to Lucy Lucy Lucy Radio Science collection.xml - The product in this lid_reference isn't given here. Verify the LID is correct urn:nasa:pds:lucy.mission:document:lucy_mission_info In the 2023.05 review, many collection.xml had a lid_reference to urn:nasa:pds:lucy.mission:document:lucymissioninfo - Suggestion: add the union of the children lid_references, i.e. add urn:nasa:pds:context:instrument:dsn.rss collection_inventory.csv - the LID of the Product_Collection itself does not go in this file, plus it's mistyped. collection_overview is missing. So change line 1 from P,urn:nasa:pds:lucy.rss:data_dinkinesh_trk234:collectin_inventory::1.0 to P,urn:nasa:pds:lucy.rss:data_dinkinesh_trk234:collection_overview::1.0 lucy_2023_*.xml - The descriptions for fields ul_zheight_corr and dl_zheight_corr in many tables describe -99.0 as a special value. Add Special_Constants to those fields to allow automated handling of those. lucy.rss:document collection*.xml - Suggestion: to match the context products, change Lucy Spacecraft Lucy Mission Lucy Radio Science Subsystem to Lucy Lucy Lucy Radio Science collection.xml - The product in this lid_reference isn't given here. Verify the LID is correct urn:nasa:pds:lucy.mission:document:lucy_mission_info In the 2023.05 review, many collection.xml had a lid_reference to urn:nasa:pds:lucy.mission:document:lucymissioninfo rss.pdf - section 2.3.4.1, typo: Where: gimcal = always gimcal gc = spacecraft number, for Lucy always 49 The last line should be "sc =", not "gc =" Global Liens ============ 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: 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. --> 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' --> 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. Remove contact info.