This wiki has been archived and is now read-only.

SSN core modules

From Spatial Data on the Web Working Group
Jump to: navigation, search

Update 23 Feb 2017: visit [1] for an overview of options that integrate SOSA with SSN.

SSN Core and Modules

This is a proposal for a horizontal and vertical modularization of the SSN with a tiny core ontology (pattern) in a schema.org-style that only makes use of a subset of the OWL2 expressivity. Horizontal modules should then add more classes and relations (e.g., for deployment, sampling,...) and vertical modules should add more expressivity (beyond a simple surface semantics) and further ontological commitments. This proposal also includes removing the entire DUL alignment and replacing it with a deeper axiomatization as discussed wrt action-155 (as well as a closer alignment to O&M).

SSN Core

An outline for the SSN core consisting merely key classes such as Sensor, Observation, Result, ObservedProperty, FeatureOfInterest, and Procedure. Note that the original SSO Stimulus class is gone. With respect to the proposed roles, I kept their labels as simple as possible, we can later agree on a certain naming schema such as hasResult instead of result and so forth. I also left out many potentially important properties that should go into other modules but IMHO not into SSN core such as phenomenonTime (while resultTime is present). I also have not added any domain and range restrictions and would prefer to add them as guarded restrictions in a vertical module together with role chains and so forth. All these clearly go beyond a simple axiomatization. I have not included classes such as Platform for now but we may decide that they should be part of SSN Core.

<http://ssncoreexample.com/1.0/> rdf:type owl:Ontology .


    Object Properties


>>>  http://ssncoreexample.com/1.0/featureOfInterest

                  :featureOfInterest rdf:type owl:ObjectProperty .

>>>  http://ssncoreexample.com/1.0/observation

                  :observation rdf:type owl:ObjectProperty ;
             rdfs:subPropertyOf owl:topObjectProperty .

>>>  http://ssncoreexample.com/1.0/observedProperty

                  :observedProperty rdf:type owl:ObjectProperty ;
                  rdfs:subPropertyOf owl:topObjectProperty .

>>>  http://ssncoreexample.com/1.0/procedure

                  :procedure rdf:type owl:ObjectProperty .

>>>  http://ssncoreexample.com/1.0/result

                  :result rdf:type owl:ObjectProperty ;
        rdfs:subPropertyOf owl:topObjectProperty .

>>>  http://ssncoreexample.com/1.0/resultTime

                  :resultTime rdf:type owl:ObjectProperty ;
            rdfs:subPropertyOf owl:topObjectProperty .




>>>  http://ssncoreexample.com/1.0/FeatureOfInterest

                  :FeatureOfInterest rdf:type owl:Class .

>>>  http://ssncoreexample.com/1.0/Observation

                  :Observation rdf:type owl:Class .

>>>  http://ssncoreexample.com/1.0/ObservedProperty

                  :ObservedProperty rdf:type owl:Class .

>>>  http://ssncoreexample.com/1.0/Procedure

                  :Procedure rdf:type owl:Class .

>>>  http://ssncoreexample.com/1.0/Result

                  :Result rdf:type owl:Class .

>>>  http://ssncoreexample.com/1.0/Sensor

                  :Sensor rdf:type owl:Class .

SSN Vertical Modules

These could introduce (guarded) domain and range restrictions for the classes/roles defined above, property chains, disjointness axioms, and so on.

Here is one example:

                 :Observation rdf:type owl:Class ; owl:disjointWith :Sensor .

As a side remark, I would not declare Sensor and FeatureOfInterest to be disjoint but this is certainly up for discussion. With respect to property chains, we could state that if an observation produced by a certain sensor is about a feature of interest than this feature has been observed by said sensor.

                :observation \circ :featureOfInterest \sqsubseteq :observed  // Assuming we have guarded domain and range restrictions in place.

I think this mediawiki is missing the math extension :-(.

SSN Horizontal Modules

Examples for horizontal modules (which could have vertical modules on their own) could include a SamplingFeature module (see http://semantic-web-journal.net/system/files/swj1237.pdf), a Deployment and Platform module, and of course the Sensor module that handles many of the SSN classes and properties such as MeasurementRange, ResponseTime, and so forth. Finally, we would need to decide on how to deal with nomenclature issues but this is simpler than most people expect; see http://geog.ucsb.edu/~jano/owled15.pdf .


I believe that such a modularization would only require modest changes to the SSN and the inclusion of om-lite. A schema.org-style SSN core will potentially be the most impactful part of our work.