MétaCan
Menu
← Retour à la cohorte
Enregistrement W7085131319 · doi:10.5281/zenodo.15858297

2025 U.S. NSF CI Compass Virtual Workshop Report - Data Management: From Instrument to First Storage

2025· report· en· W7085131319 sur OpenAlexaff

Notice bibliographique

RevueZenodo (CERN European Organization for Nuclear Research) · 2025
Typereport
Langueen
DomaineBiochemistry, Genetics and Molecular Biology
ThématiqueBioinformatics and Genomic Networks
Établissements canadiensOcean Networks Canada Society
Organismes subventionnairesNational Science Foundation
Mots-clésCyberinfrastructureBlueprintTerabyteCompassCompendiumPetabyteCitizen scienceGrand Challenges

Résumé

récupéré en direct d'OpenAlex

The 2025 Virtual Workshop on "Data Management: From Instrument to First Storage", organized by the U.S. National Science Foundation (NSF) CI Compass [1], the NSF Cyberinfrastructure Center of Excellence, brought together cyberinfrastructure (CI) professionals from the NSF Major and Midscale research facilities along with participants from the broader CI ecosystem to discuss issues of critical importance to the success of these facilities. The workshop focused on the crucial initial step of the data lifecycle for the NSF Major and Mid-scale Facilities - the step involving data acquisition and capture from scientific instrument(s). Speakers from a diverse range of facilities presented their unique challenges, best practices, and innovative solutions, which were then analyzed to identify common trends and future directions. This executive summary encapsulates the key insights and findings from the invited talks and subsequent discussions at the virtual workshop. The presentations at the workshop emphasized the immense data volumes and velocity of the data coming off the different kinds of instruments, and described the challenges and evolving best practices of managing petabyte-scale scientific data. Most of the scientific facilities represented at the workshop, e.g. the NSF/DOE Vera C. Rubin Observatory [2], NSF NEON [3], NSF NSO [4], NSF OOI [5], NSF LIGO [6], and NSF EarthScope [7], are generating and managing petabytes of data, with daily ingest rates often exceeding terabytes and billions of data points. The User Facilities like NSF MagLab [8], NSF NAN [9], and NSF ZEUS [10] have to not only collect and curate data from their instruments, but also help their users manage their specific experimental data. This immense scale and complexity demands robust, scalable infrastructure and sophisticated data management strategies. Initial data acquisition and storage is often the first critical stage with data collection typically beginning with direct instrument readout and on-site buffering. Facilities use both real-time streaming (for time-critical data, e.g., OOI, LIGO) and batch transfers (for larger, less urgent datasets). In some remote or high-volume cases, physical shipment of storage media is still used. Data formats are highly diverse, ranging from specialized scientific formats (e.g. FITS [11]) to common standards (e.g. NetCDF [12], CSV, MP4). The high volume and velocity of the data acquisition often requires automation and rapid processing. Automation is essential for data movement/streaming, pipeline orchestration, and ingestion into appropriate data stores. Real-time processing and low-latency alerts are critical for many facilities (e.g., Rubin Observatory’s sub-2-minute alerts, LIGO’s transient event discovery). Automated quality control (QC), quality assurance (QA) and validation are often integrated early and close to the data capture time. Middleware (e.g. Kafka [13]) and orchestration (e.g. Kubernetes [14]) are widely used for managing streams, queues, and scalable services. Facilities balance on-premise and cloud storage, often using multi-tiered strategies to optimize cost, performance, and accessibility. There is a strong trend toward adoption of cloud technologies (e.g., EarthScope on Amazon AWS [15], NEON on Google GCP [16]) for scalability and managed services. A variety of database technologies are used: PostgreSQL [17] for metadata, Cassandra [18] and MongoDB [19] for raw data and inventory. A majority of the presentations emphasized the importance of metadata annotation, data curation, and effective data dissemination, while preserving data security. Rich, high-quality metadata is essential for findability, usability, and adherence to FAIR (Findable, Accessible, Interoperable, Reusable) [20] principles. Comprehensive QA/QC processes span the data lifecycle. Cybersecurity is a major concern, addressed via zero-trust architectures, VPN/SSO, and infrastructure-as-code. It was also noted that system-wide observability and monitoring (e.g., Grafana [21]) are critical for operational continuity. Facilities provide data through web portals, JupyterLab environments, and robust APIs (REST, GraphQL [22]). Persistent identifiers (DOIs) ensure data can be reliably found and cited. The facilities strongly promote open data policies, and making certain datasets and alert streams immediately available to the public. The workshop talks and discussions illuminated some key current challenges, which include managing ever-increasing data volumes and complexity, meeting low-latency demands, generating and curating metadata, enabling increased FAIR-ness of the data, addressing technical debt, and coping with staffing and funding limitations. Ensuring cybersecurity and data integrity as access expands needs to be an ongoing effort. Looking ahead, the community is embracing cloud-native solutions, expanding automation and machine learning for data processing, developing advanced data portals and APIs, and improving data discoverability across federated systems. The overarching goal the facilities are striving for is to build a connected, FAIR-aligned information ecosystem where scientific data is not only stored, but is discoverable, accessible, interoperable, and reusable for the global research community.

Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.

Comment cette classification a été obtenuedéplier

Prédiction machine sur la base complète

Imitation des enseignants

Ni prévalence calibrée, ni vérité terrain. Validation humaine à venir. Le volet Gemma est une étiquette directe du modèle pour chaque travail de la base, lue sur la notice réduite au titre. Le volet Codex est un classifieur appris des 10 348 étiquettes directes de Codex et calibré sur les taux pondérés de l'échantillon; les champs sans appui suffisant ne portent aucun appel Codex. Le mode candidate est l'union des deux volets; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont pas des étiquettes humaines.

score de la tête « metaresearch » (Codex)0,010
score de la tête « metaresearch » (Gemma)0,009
Version: metacan-v3-hybrid-931329e0061cStatut de validation: machine_predicted_unvalidated
Catégories candidatesaucune
Catégories consensuellesaucune
DomaineSignal candidat: aucune · Signal consensuel: aucune
Devis d'étudeSignal candidat: Sans objet · Signal consensuel: Sans objet
GenreSignal candidat: Autre · Signal consensuel: Autre
Score de désaccord entre enseignants0,150
Score d'incertitude au seuil0,503

Scores du classifieur distillé par catégorie (deux têtes)

CatégorieCodexGemma
Métarecherche0,0100,009
Méta-épidémiologie (sens strict)0,0020,001
Méta-épidémiologie (sens large)0,0010,001
Bibliométrie0,0020,004
Études des sciences et des technologies0,0050,002
Communication savante0,0140,007
Science ouverte0,0040,008
Intégrité de la recherche0,0060,004
Charge utile insuffisante (le modèle a refusé de juger)0,1500,072

Scores machine (provisoires)

Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.

Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.

Tête enseignante Opus0,052
Tête enseignante GPT0,280
Écart entre enseignants0,229 · la distance entre les deux têtes enseignantes sur ce seul travail
Statut de validationscore_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découle

Classification

machine, non validée

Prédiction automatique; un appel candidat d’une seule source (Gemma direct ou Codex distillé), pas un consensus.

Les modèles n’ont appliqué aucune catégorie : rien dans la taxonomie ne correspondait à ce travail.
Devis d'étudeSans objet
Domainenon disponible
GenreAutre

Le détail, modèle par modèle et score par score, se trouve en fin de page sous « Comment cette classification a été obtenue ».

En bref

Citations0
Publié2025
Routes d'admission1
Résumé présentoui

Explorer davantage

Même revueZenodo (CERN European Organization for Nuclear Research)→Même sujetBioinformatics and Genomic Networks→Travaux en français237 207→