Re: Shrinking the SSN ontology for Wot/IoT applications

Dear Kerry,

Thanks for sending this through! I think there was no response yet to your email (beyond the furphy enlightenment, including me ;-)), because the “something.something" imports make it extremely cumbersome to load the ontology to any editor.

I took the liberty to upload all the necessary imported ontologies to a Github repository (should go in our SDW Github repository) and renamed the imports and URIs in all ontologies. I then uploaded your ontology and your instance to WebProtégé  in the following projects:

WoT Ontology:
http://webprotege.stanford.edu/#Edit:projectId=dc983c6a-c144-4d5a-a2a2-1f8d25d1ad54


WoT Instance:
http://webprotege.stanford.edu/#Edit:projectId=5a611de1-44e1-4f2e-ba5a-9072d936b82d


Now, WebProtégé is unfortunately a bit buggy and does not support OWL, but I could not think of a better platform that allows us to see/share ontologies in an SaaS way. If someone owns a Topbraid version that may be a way to host the ontology project as well. In any case, we will need to find a way to easily collaborate on the ontology work so that every group member can look at the ontology without the need of always loading it to their editor of choice. Are there suggestions beyond WebProtégé or Topbraid?

Also, I believe the namespace issue needs to be tackled first, beyond anything else!

Kind regards,
Armin

From: Kerry Taylor <Kerry.Taylor@acm.org<mailto:Kerry.Taylor@acm.org>>
Date: Thursday, 26 November 2015 11:02 pm
To: Public Web of Things IG <public-wot-ig@w3.org<mailto:public-wot-ig@w3.org>>, SDW WG Public List <public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>>
Subject: Shrinking the SSN ontology for Wot/IoT applications
Resent-From: <public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>>
Resent-Date: Thursday, 26 November 2015 11:03 pm

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#<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).