The data management system for the VENUS and NEPTUNE cabled observatories
Bibliographic record
Abstract
The VENUS (http://venus.uvic.ca/) and NEPTUNE Canada (http://neptunecanada.ca/) cabled ocean observatories have been envisioned from their inception as underwater extensions of the Internet. Having sensors connected to a network opens up tremendous opportunities, from realtime access to sensor measurements to the interactive control of remote assets. Moreover, with a software system in control, data from all sensors can be managed, archived and made available to the wider community. Finally, a data management system can also offer features that are unique to centrally managed instrumentation: thanks to communication standards, autonomous event detection and reaction becomes a very powerful possibility. This talk will summarize the salient features of DMAS (Data Management and Archiving System) that have been implemented over the past four years as well as the planned features to be delivered soon. DMAS consists of two main components: the Data Acquisition Framework (DAF) takes care of the interaction with instruments in terms of control, monitoring as well as data acquisition and storage. The framework also contains operation control tools. The user interaction features include data search and retrieval, data distribution. Current developments in the Web 2.0 area will provide a complete research environment where users will have the ability to work and interact on-line with colleagues, process and visualize data, establish observation schedules and pre-program autonomous, event detection and reaction. We call this environment "Oceans 2.0". The architecture of DMAS is focused on limiting the amount of data loss and maximizing up time. It is a service oriented architecture, making use of some of the more advanced tools available. The code is written in Java and makes use of an enterprise service bus and of the publish-and-subscribe paradigm. The paper also describes the management approaches that were adopted to build DMAS. Good code quality, the continuous support of VENUS and the need for flexibility in dealing with rapidly changing requirements were the drivers behind the adoption of in-house development, the Agile development methodology and the creation of three teams. The development team deals with requirement collection, analysis, design, coding and unit testing; the QA/QC team performs software tests and regression in a production-like environment. The systems/operations team focuses on the hardware and system software preparation and support, receives and installs new code releases after QA approval and monitors systems operations. We are vying to perform new code releases twice a month. The method has worked well during the four years of the system development phase and has allowed for a constant support of VENUS. DMAS will be completed well under budget.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.003 | 0.005 |
| Meta-epidemiology (narrow) | 0.001 | 0.001 |
| Meta-epidemiology (broad) | 0.001 | 0.001 |
| Bibliometrics | 0.003 | 0.003 |
| Science and technology studies | 0.002 | 0.001 |
| Scholarly communication | 0.005 | 0.003 |
| Open science | 0.002 | 0.003 |
| Research integrity | 0.001 | 0.003 |
| Insufficient payload (model declined to judge) | 0.032 | 0.029 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".