The OGC Observations and Measurements Specification & Applicability to TDWG’s Domain Phillip C. Dibner Ecosystem Associates TDWG Annual Meeting Saint Louis, Missouri October 17, 2006

The Observation and Measurements Spec - The O&M spec was developed in the context of the OGC’s Web Services (OWS) initiatives - General and firmly based in theory as well as application requirements - Encoding-neutral (normative descriptions are in UML). (A GML serialization is available, but informative, not normative.) - Current public version: - OGC doc r4 - On - Further elucidation: - vationsAndMeasurements

History and Foundations First version developed in original OWS initiative - ~ Current public draft from OWS-3, completed in April, 2005 Currently undergoing further refinement in OWS-4 Important foundational notions come from Martin Fowler, 1998, Analysis Patterns: reusable object models. Addison Wesley Longman, Menlo Park, CA Also based on other notions from metrology and a variety of scientific disciplines Bottom line: well reviewed, mature. Yet - still room for input into the process if the spec is lacking

Implementations and Applicability - O&M is a foundation to build upon, not an end in itself - XMML (eXploration and Mining Markup Language) Observation is the fundamental datatype served by Sensor Observation Service (SOS). - OGC doc r1 - On - Also under active development in OWS-4. There are a growing number of implementations, support in open-source products, and an increasing number of client applications - If we stay abreast of these developments and serve Observations, they will be broadly accessible. - Also used as information model for other services

The Observation Feature Type (O&M) From Cox, OGC document r3_Observations_and_Measurements Feature of Interest Observation Phenomenon - property we’re observing

How would TDWG apply it? One approach: A General Approach to Domain Modeling (After R. Atkinson and S. Cox, at the TDWG GIG Workshop in Edinburgh, June, 2006) 1. Examine the domain and break up into subdomains If using UML, this is accomplished by grouping related objects into various UML packages. The packages can be distributed for others to use. 2. Decide what doesn’t go in the domain of interest and belongs in someone else’s. In UML, put in a placeholder or stub package, to be replaced later. 3. Identify the common elements that everyone agrees on, and that all implementations will include. - NB: the TDWG Observations Group has done much of this work 4. These form the basis of a conceptual model.

Domain Modeling (Atkinson and Cox) 5. Proceed to identifying points in question or of disagreement. Clarify implications, explore consequences for the model. Observations Group has done a lot of this work as well 5. Develop or bring into the discourse representational views that are of importance to near-term or legacy implementations. These represent the varied and sometimes incompatible viewpoints that different implementors have of the domain. Exercising these helps to clarify the conceptual model. Methodology and tools for mapping representational views to the conceptual model and to each other are still very much under development, but specific exercises yield well to intuition and common sense.

TDWG GIG Practicum - Conceptual Model Taxonomic Data

Representational View Exercise Darwin Core

Additional Points of Interest O&M was developed within the OGC’s Sensor Web Enablement “thread” The notion of a Sensor is also entirely general. (first versions of O&M included an example of quadrat measurements from a grassland survey) SensorML: a language for describing the “sensor.” A quadrat, transect, or grid of quadrats, points, etc. would qualify… Notion of process or procedure for conducting the measurement is fundamental. (In fact there’s talk of calling it “ProcedureML,” but Sensor is too strong a “brand” to abandon…)