[Requests] SOS 2.0 request: nonstandard Offering properties

I-Lin Kuo ilinkuo at usgs.gov
Tue Nov 30 17:29:18 EST 2010

Part A to be completed once.  Iterate Part B as needed.


1. Evaluator:
        David Blodgett <dblodgett at usgs.gov>
        I-Lin Kuo                       <ilinkuo at usgs.gov>

2. Submission: OGC 10-037 SOS 2.0 Candidate standard


1. Requirement: Allow SOS GetCapabilities Offering to advertise additional 
"procedure"-related properties and adjust search parameters appropriately.

        One of the major changes from SOS 1 to SOS 2 was the elimination 
of multiple procedures per Offering to just a single procedure per 
Offering. Another was the clarification of the ambiguity in SOS 1.0's 
usage of procedure "often an instrument or sensor [NRC1995] but may be a 
process chain, human observer, an algorithm, a computation or simulator" 
to an unambiguous "Pointer to a sensor system for which observations are 
requested. It defines a filter for the procedure property of the 
observations". This is a vast improvement from the point of view of 
        However, this restriction also removes the ability for the 
Offering to advertise other important properties such as method (for 
example, "stratified sampling"), instrument class (for example, "stream 
gauge"), or algorithm (for example, "Monte Carlo") that was possible in 
SOS 1. 
        Also, the current design seems to lack consideration for the 
situation when the observations dataset is a large system consisting of 
tens of thousands of sensors/sites such as NWIS. In that case, how should 
the dataset be advertised? There seem to be two alternatives given the 
current specification, neither of which are satisfactory:
                1) Advertise as a single ObservationOffering and use the 
name of the sensor system, "NWIS", as the procedure.
                2) Advertise as tens of thousands of ObservationOfferings, 
one for each sensor/site, using the site id as the procedure value.
        Alternative 1 renders the procedure parameter useless in 
operations such as GetObservation, GetResult, and GetFeature because all 
observations have the same value of procedure. Alternative 2 creates an 
enormous GetCapabilities document.
        In our ideal scenario, we'd like to advertise NWIS as one or two 
ObservationOffering with many methods that would allow queries of the 
following type:
        "Get all observations of water level from NWIS that were measured 
using a velocimeter on a stream"
        "Get all NWIS observations of atrazine in water from a well via 
gas chromatography"
        Implicit in these two examples are sampledMedium (water), method 
(velocimeter, gas chromatography), siteType (well, stream) that are 
important metadata associated to an observation that currently do not fit 
in ObservationOffering but clearly serve to characterize it. There are a 
number of alternatives to handle this:
                1) Add these properties as named children of 
                2) Add these properties as children of procedure
                3) Provide an extensible mechanism to add 
community-defined properties to ObservationOffering and add a way to query 
these properties to the GetXXX operations.
                The approach of 1 is unsatisfactory because while some of 
these properties are general enough to be added to the list of named 
properties of ObservationOffering, others are not. Also, this approach is 
likely to open a Pandora's box of change requests to add elements to 
                The approach of 2 is unsatisfactory because these 
properties are multiple and do not logically belong as children of 
"procedure" = sensor system. These are properties of the 
ObservationOffering. Also, this approach doesn't really solve the problem 
but rather just moves the problem elsewhere into specifying an 
implementation specific schema for "procedure", subject to the same danger 
of Pandora's box above. Most importantly, the procedure parameter in 
GetObservation and other similar observations do not allow querying on the 
children of the "procedure" -- they only allow querying on exact match of 
"procedure". That is a fatal problem when the sensor system is large.
                Thus, our implementation proposal below is based on 
approach 3

2. Implementation Specification Section number: [General, #]

        i) Add a <PropertyGroups> child to ObservationOffering
        ii) The <PropertyGroups> element has <PropertyGroup> children
        iii) The <PropertyGroup> element has a @name attribute
        iv) The <PropertyGroup> element has either 
                a) <Value> children, or 
                b) it has an xlink:href attribute with a resolvable http 
url to point to an xml document consisting of <PropertyGroup> with <Value> 
children, and an human-readable descriptive xlink:title. This xlink:href 
mechanism is preferred when the list of property values is long and 
impractical to include in the GetCapabilities document directly
name="sampledMedium" xlink:title="media types" xlink:href="
http://cida.usgs.gov/nwis/mediaTypes.xml" />
                                        <PropertyGroup name="siteType">
        v) Add an <offeringProperty> element to the request for SOS 
operations GetObservation, GetResult, GetFeatureOfInterest which takes 
multiple parameters of name-value pairs.
                        <sos:GetObservation version="1.0.0" service="SOS" 

3. Criticality: [Major, Minor, Editorial, etc.]


4. Comments/justifications for changes: [Comments]

I-Lin Kuo
IT Specialist, Center for Data Analytics (CIDA)
USGS WI Water Science Center
Phone: 608-821-3895
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/requests/attachments/20101130/f751694d/attachment-0001.htm>

More information about the Requests mailing list