Argo R24/R26 Tables: ADMT19 Decision And SENSOR_MAKER

by Pedro Alvarez 54 views

Introduction

Hey guys! Today, we're diving into a critical discussion about the implementation of the ADMT19 decision concerning the R24 (PLATFORM_MAKER) and R26 (SENSOR_MAKER) reference tables within the OneArgo and ArgoVocabs frameworks. This discussion is super important for maintaining consistency and clarity in our data management practices. Currently, there's a discrepancy between the implementation in the FileChecker and the documentation, specifically the user manual and the NVS table description. Let's break down the issue, explore the concerns, and figure out the best way forward. Our goal is to ensure that our data is accurate, well-documented, and easy for everyone to understand and use. So, grab your coffee, and let's get started!

Current Implementation and Discrepancies

Currently, the FileChecker includes the following statement: / ..append platform_maker entries to sensor_maker table // ..ADMT-19 confirmed this as a requirment. This statement indicates that all entries listed under PLATFORM_MAKER (R24) can also be considered valid entries for SENSOR_MAKER. Essentially, this means that the FileChecker is designed to recognize platform manufacturers as potential sensor manufacturers, which can be a useful feature for data processing. However, this implementation isn't clearly reflected in our existing documentation. The user manual only mentions that valid SENSOR_MAKER entries are listed in reference table R26, available at https://vocab.nerc.ac.uk/collection/R26/. Similarly, the NVS table description specifies that the Argo netCDF variable SENSOR_MAKER is populated using the altLabel from R26. This creates a disconnect because users relying on the documentation might not be aware that PLATFORM_MAKER entries are also valid for SENSOR_MAKER.

This lack of clarity can lead to confusion and potential errors in data processing. For example, if a user is manually validating data against the user manual or NVS table description, they might incorrectly flag a valid entry from the PLATFORM_MAKER table as invalid. Therefore, it’s essential to address this discrepancy to maintain the integrity and usability of our data. We need to ensure that the documentation accurately reflects the current implementation in the FileChecker. This involves updating both the user manual and the NVS table description to include information about the relationship between PLATFORM_MAKER and SENSOR_MAKER. The next step is to seek confirmation from subject matter experts, like @apswong or @mscanderbeg, regarding the ADMT-19 conclusion to validate the current approach. Once confirmed, we can proceed with updating the documentation and addressing the broader implications of this decision.

Confirmation of ADMT-19 Conclusion

Before we proceed with any updates, it's crucial to confirm the ADMT-19 conclusion. Specifically, we need to verify whether the decision to include PLATFORM_MAKER entries as valid SENSOR_MAKER entries is indeed the intended and correct approach. This confirmation is necessary to ensure that we're aligning with the original intent of the decision-makers and that we're not introducing any unintended consequences. To do this, we need input from individuals who were involved in the ADMT-19 decision-making process. People like @apswong or @mscanderbeg, who have direct knowledge of the discussions and outcomes, can provide valuable insights. Their confirmation will serve as a solid foundation for our subsequent actions.

Once we have their confirmation, we can confidently move forward with updating the documentation and addressing any outstanding questions or concerns. This step is vital because it ensures that our actions are based on a clear understanding of the ADMT-19 decision. Without this confirmation, we risk perpetuating the existing discrepancies or introducing new ones. Therefore, reaching out to the relevant experts is a critical step in our process. It's not just about making changes; it's about making informed and accurate changes that align with the overall goals of the Argo program. By seeking confirmation, we're demonstrating a commitment to data integrity and transparency, which are fundamental principles in scientific data management. This collaborative approach ensures that we're all on the same page and working towards the common goal of maintaining high-quality data.

Concerns and Potential Solutions

One of the main concerns arising from this implementation is the **