1 / 5

Waves Formalize data dictionaries QC What is required to formalize?

Waves Formalize data dictionaries QC What is required to formalize? Defining quality assurance requirements Validating sensors. In situ Currents Start data dictionaries for QC for current QARTOD recommendations Extend QA/QC to other current sensors

beck
Download Presentation

Waves Formalize data dictionaries QC What is required to formalize?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Waves • Formalize data dictionaries QC • What is required to formalize? • Defining quality assurance requirements • Validating sensors • In situ Currents • Start data dictionaries for QC for current QARTOD recommendations • Extend QA/QC to other current sensors • Incorporate extension of QA/QC into formalized data dictionaries

  2. CTD • Revisit and finalize QA and QC (QARTOD) • Develop data dictionary from QA/QC • DO • Identify and recruit community to participate in QA and QC (QARTOD) • Formalize QA and QC (QARTOD) • Develop data dictionary from QA/QC

  3. Additional items to consider How ADCP mounted (e.g. side-, cage-, well-mounted)? Use of duplicate sensors (e.g. on CTDs)

  4. Need for Term Definitions used in SensorML and SWE • Observable properties / phenomena / deriveable properties (“urn:ogc:def:property:*) • temperature, radiance, species , exceedingOfThreshold, earthquake, etc. • rotation angles, spectral curve, histogram, etc. • Capabilities, Characteristics, Interfaces, etc. (“urn:ogc:def:property:*”) • Width, height, material composition, etc. • Ground resolution, dynamic range, peak wavelength, etc. • RS-232, USB-2, bitSize, baud rate, base64, etc. • Sensor and process terms (“urn:ogc:def:property:*”) • IFOV, focal length, slant angle, etc. • Polynomial coefficients, matrix, image, etc. • Identifiers and classifiers (“urn:ogc:def:identifierType:*; urn:ogc:def:identifier:*” ) • Identifiers – longName, shortName, model number, serial number, wingID, missionID, etc. • Classifiers – sensorType, intendedApplication, processType, etc. • Role types (“urn:ogc:def:role:*”) • Expert, manufacturer, integrator, etc. • Specification document, productImage, algorithm, etc. • Sensor and process events (“urn:ogc:def:classifier:eventType:*”) • Deployment, decommissioning, calibration, etc.

  5. Help, Help, Help • We need authoritative bodies with access to subject-matter-experts (SME) to step forward to establish resolvable term dictionaries for sensors, processes, and observations • Potential authoritative bodies • IC community – GIG, MASINT WG, Multi-INT Interoperability Lab ?? • Civilian satellite community – Committee for Earth Observation Satellites (CEOS) • Others - ??? • Way forward • Create namespace for terms • Develop web interface for submitting term (Wikipedia perhaps, XML-based?) • Term • Definition • References • Relationship (?) – or allow separate ontologies to provide this • Level of authorization • Set up web services for resolving and getting filtered list of terms • Set up authentication process and authentication levels (e.g. submitted, under review, approved, rejected) • Accepting SensorML and SWE without creating authorized terms won’t accept interoperability

More Related