SOR

The Sensor Observable Registry (SOR) is a web service interface for managing the definitions of phenomena measured by sensors as well as exploring semantic relationships between these phenomena. The current implementation is based on the OGC discussion paper 09-112 ( download) and presents a pragmatic solution that may serve as the basis for further discussion and development.

The specification

SOR is currently a discussion paper with the OGC and can be downloaded from the OGC website. The paper contains extensive descriptions of the service operations (requests and responses) for GET, POST, and RESTful methods.

Data

... about the data, where it comes from and what is actually there ...

Schemata

The schema files (one for each operation) are located in the repository folder SOR/schemas/sor. An ant build-file to create XML Beans can be found at SOR/schemas/build.xml, it copies the sorXBs.jar directly into the folder .../WEB-INF/lib.

The schemas are available online for validation at http://52north.org/schema/sor/ and the namespace is http://52north.org/sor/0.3.1. You can use these schemas for direct validation by including the root schema document into the XML documents, e.g. xsi:schemaLocation="http://52north.org/sor/0.3.1 http://52north.org/schema/sor/0.3.1/sorAll.xsd".

Installation

As the 52°North SOR does currently not utilize any kind of database, so you only need to deploy the attached .war file to a Tomcat of your choice. If you make changes to the code, you can easily use the Eclipse functionality File > Export > Export to WAR file to create it.

Build Process

The build process has been moved to Maven - please contact the developers directly until this page is updated.

If new properties are added to the configuration file, the must be added to both the one in .../WebContent and the one in .../build, as the former is used for builds within Eclipse (and running the service locally from within Eclipse) and the latter for the build via Ant.

Furthermore, the build-folder contains an adapted log configuration (default level warn), a sample properties file, and a file buildinfo.properties which is autmatically updated if the build script is run and saves information about build time and number, which is included in the element display-name in web.xml file.

Requirements for Installation

• Tomcat, Version >= 6
• Text editor for changing settings (see section below).

Settings

The location of the main config file is .../WEB-INF/conf/sor.config. Here you find all important settings for the service. At the current state, you only (!) need to set SERVICEURL (and possibly the service endpoints) to the correct URL. This is for client requests and the capabilities document, and it has to match the settings in web.xml and the name of the web application in the Tomcat.

All (other) settings should be handled with care.

Check the debug configuration in the file .../WEB-INF/classes/log4j.xml, because a high priority mode (e.g. debug) can considerably slow down the service!

You can change the content of the capabilities document in the file .../WEB-INF/conf/sorCapabilitiesSkeleten.xml. Apart from the URLs, keywords, application domain, ontology URL, and the sor:Contents section, which will both be replaced/created during runtime using the settings in sor.config and the actual values of the used data set, all information remains unprocessed. So unprocessed information really boils down to contact information.

Development

Changelog

• 0.4.0
  • Switched to Maven build process
  • Changed logging to slf4j
• 0.5
  • development continued as part of OpenSensorSearch

Architecture

See SensorObservableRegistryArchitecture.

Development Instructions

SOR is a Maven module in the OpenSensorSearch project. Please make sure to check the project out as a Maven project or use "File > Import > Import existing Maven projects into workspace" if you checked out the project without Maven.

Please follow the internal guidelines: DeveloperInformation and QualityManagement.

Roadmap and Tasks

Roadmap

A coarse list of possible directions for future development and features for the implementation is as follows:

• XML database
• Implement more features of OWS common (i.e. the update sequence parameter)
• Implement test which checks the content of responses ( Is the inserted/deleted definition really (not) there (anymore)?)
• ... (please feel free to continue)

Tasks

• Implementation
  • Support for multiple data files
  • Base identifiers on URLs instead of URNs (AirBase SOS compatible)
• Content (SJ)
  • SWE Dictionary (SWSL user survey?)
  • Environmental Noise Dictionary (Italian guys)
  • Synchronise contents with existing SOS, SES, SPS instances
  • Dictionary für EEA AirBase data on the basis of ..._measurement_configurations.csv