Shrinking the SSN ontology for Wot/IoT applications

Dear WoTers and  SDW-ers,
As  Jano mentioned  in the SDW meeting this week when we kicked off our work on the Semantic Sensor Network ontology, SSN is widely used in the context of IoT research.
It is also widely criticised for being "too big" for small devices.  However, this is a furphy.  Because SSN is an OWL ontology it can be  reduced as much or as little as you like by fixing some properties and relationships for particular use cases. This means you can design small fragments very flexibly for all different kinds of devices -- that can then be reassembled as entirely interoperable SSN with an off-the-shelf domain- independent reasoner when you have more resources. For example, the SDW group is also tackling the massive scale of satellite sensing --  and this too requires integration with small-device sensing or even eye-balled ground data  in some of our use cases.

I have developed an example to show what I mean here, based on the little WoT vocabulary I saw demonstrated at Sapporo. Please do not think I am suggesting I have the right vocabulary here -- I only wanted to demonstrate how it can be done with a few OWL tricks. 

I have shown my examples in turtle and SPARQL -- although SDW is more likely to be talking JSON-LD and maybe WoT will be even smaller (noting even a CSV format can be interpreted as an ontology with some middle-layer processing). I have also used the "modularised" form of SSN for this (SDW people have heard of that), which in this case makes it a bit more complicated and lots of sparql prefixes than are needed for the monolithic ssn -- but dealing with this is very much MUST DO on the SDW agenda.

What I have done is to create a small SSN extract  by a number of ontology tricks such as fixing property values of subclasses by restrictions and adding property chains to skip over concepts along paths between a wanted class and another wanted class. This is far from perfect,  it is just meant to show it is possible. I have not done a good job with datatypes which is a particular requirement for the Wot group and needs a little more thought.  Renaming classes and properties to suit a different audience is also  easy.
SSN has a placeholder to describe "devices" which was intended for things like protocols that do not relate to sensing per se. This is an area that could be extended in SDW work for WoT demands -- you can see I made a new protocol property here.

The attached file wot2.ttl is an ontology intended to look like a  small web of things vocab, that imports SSN. This would be used with reasoning installed on a server that can interoperate over devices of all sizes.  myregistryentry.ttl is a little ontology that describes a couple of sensors in terms of Wot2. Each of these  might be what a little device declares to a server, or uses to interoperate with another little  device. I have described the two sensors in different ways just to demonstrate the flexibility of the approach -- I am not saying that either is a good design. 
I  also have below  attached some sparql queries over the (reasoned) Wot2+SSN server that show how  "missing bits", kind-of defaults for a sensor type,  that the device itself may not even know about,  can be filled in from the ontology. A server might query the ontology this way to populate a "registry".  The WoT people demonstrated a "registry" with not much more than this in it in sapporo -- going really tiny.

This approach allows arbitrary numbers of small or very small vocabularies to be developed that have no idea about reasoning or ontologies, but can also deliver their little payload in a way that is highly interoperable with bigger things.
No-one will ever make one ontology of the right size for arbitrary  Things, but this approach allows you to define families of ontologies that are quite trivially stitched back together by off-the-shelf domain-independent reasoning. That has to be a Good Thing!

Discussion very welcome.

Regards,
Kerry
------------
SPARQL queries:

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
prefix dul: <http://www.loa-cnr.it/ontologies/DUL.owl#> 
prefix sso: <http://something.something/sso#> 
prefix ssno: <http://something.something/ssno#> 
prefix ssno_ds: <http://something.something/ssno_ds#> 
prefix ssno_pd: <http://something.something/ssno_pd#> 
prefix ssn: <http://something.something/ssno_pd_dul#> 
prefix wot2: <http://www.semanticweb.org/kerry/ontologies/2015/10/wot2#> 
prefix :  <http://www.example.org#> 

# check reasoning happened - there are 2 sensors #
 
Select * where { ?s a sso:Sensor }

# Retrieve first example 
Select * where { ?s  a wot2:temperature-wot;
		wot2:hasCurrentValue ?y .
		?y  dul:hasDataValue ?z }

# Retrieve second example 
Select * where { 	?s a wot2:wot ;
		wot2:hasProtocol ?p;
		ssno:observes wot2:pressure;
		wot2:hasCurrentValue ?z .
		?z a wot2:Floatvalue }

##get the datatype of the second   example - note you get "named individual" as well which
#can  be cleaned out with a filter in the SPARQL 
Select * where { ?s a wot2:wot ;
		wot2:hasCurrentValue ?z .
		?z a ?t  }
## find out what each sensor observes and its protocol- note this was defined in the wot 

#ontology for the first sensor (and so for all sensors of its type)  but in the registry 

#declaration of the second (showing that you get complete flexibility about what you ask the 
# sensing device to provide of its own description  at run-time vs design-time

Select * where
	{ ?s a wot2:wot;
		wot2:hasProtocol ?p;
		ssno:observes ?o
	}	 	

#Warning: don't get put off by all the namespaces -- I have deliberately done this
#the hard way to explore an alternative version of the ssn (for SDWWG work).