Presentation is loading. Please wait.

Presentation is loading. Please wait.

Waves Formalize data dictionaries QC What is required to formalize? Defining quality assurance requirements Validating sensors In situ Currents Start data.

Similar presentations


Presentation on theme: "Waves Formalize data dictionaries QC What is required to formalize? Defining quality assurance requirements Validating sensors In situ Currents Start data."— 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


Download ppt "Waves Formalize data dictionaries QC What is required to formalize? Defining quality assurance requirements Validating sensors In situ Currents Start data."

Similar presentations


Ads by Google