Ontology for observations and sampling features, with alignments to existing models

Tracking #: 1138-2350

Authors: 
Simon Cox

Responsible editor: 
Mark Gahegan

Submission type: 
Ontology Description
Abstract: 
We introduce new OWL ontologies for observations and sampling features, based on the O&M conceptual model from OGC and ISO 19156. Previous efforts, (a) through the W3C SSN project, and (b) following ISO rules for conversion from UML, had dependencies on elaborate pre-existing ontologies and frameworks. The new ontologies, known as om-lite and sam-lite, remove such dependencies, and can therefore be used with minimal ontological commitment beyond the O&M conceptual model. Time and space concepts, for which there are multiple existing solutions, are implemented as stub-classes, and patterns for linking to the existing ontologies are described. PROV is used to support certain requirements for the description of specimens. A more general alignment of both obser-vation and sampling feature ontologies with PROV is described, as well as mappings to some other observation models and ontologies.
Full PDF Version: 
Tags: 
Reviewed

Decision/Status: 
Minor Revision

Solicited Reviews:
Click to Expand/Collapse
Review #1
Anonymous submitted on 15/Sep/2015
Suggestion:
Minor Revision
Review Comment:

This is a substantial vastly improved version of the paper. The responses to reviewer comments are excellent. I have a few minor comments, and suggest a paper be excepted after very minor corrections.

My comments are as follows:
I support getting rid of upper-level dependencies, mostly for reasons of acceptability. However, the arguments given in the paper remain weak. Talking off commitment conflicts in general is not good enough, we need specific examples. The example given in the discussion , Regarding the two sentences of the term observation, appears silly to me. It does not matter how a term is used as long as Long as its use is consistent and clear. Furthermore, DOLCE Does certainly not impose a particular world view and has not been designed in any particular context. These mistaken claims should be removed.

The handling of time, asymmetric with respect to the handling of space, should be better explained. In particular, it is not stated why location is delegated to the feature of interest, but time is treated explicitly. The two different time concepts should be related to those of temporal databases.

A few minor language issues:
- what does They refer to in "They are almost ubiquitous"
- "cartographic applications" is too narrow an expression for what location information supports
- figure 4 has a disconnected location box
- The idea of stubs should be explained the first time the term is used only once
- insert "done" into "this is typically by"