AW: Shrinking the SSN ontology for Wot/IoT applications

Dear Kerry,

I'm very sorry for my very delayed response. Currently, many things are going on... However, in the last few weeks I have already had some exchange with Danh, Darko, and Arne about your mail and your proposal. Let me share with you some points which we have discussed:

 - in general, your ontology tricks and the provided sample look quite well and in that way it would be also feasible to constrained devices. Question: Are there any reasons why some prefixes are listed in the sample which are not used within the triples? Most likely this is an oversight.
- still the SSN contains the DUL ontology which is too big for constrained devices when you want to reason about implicit rdf:type
- currently, we are doing some experiments with the current status of the TD and SSN. Beside the provided information in the TD such as encodings, protocols, interaction models we want to follow the idea to enrich the description with SSN if the developer wants to use it. We will provide samples for this.

I recommend that we have a joined web meeting at the begin of next year. The next WoT TD web meeting will be 13th January, 14 CET. Would it be possible for you to join?

Merry Christmas and a Happy New Year :)

Best wishes
Sebastian




Von: Kerry Taylor [mailto:Kerry.Taylor@acm.org]
Gesendet: Donnerstag, 26. November 2015 13:03
An: Public Web of Things IG; SDW WG Public List
Betreff: 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#<http://www.w3.org/1999/02/22-rdf-syntax-ns>>
PREFIX owl: <http://www.w3.org/2002/07/owl#<http://www.w3.org/2002/07/owl>>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#<http://www.w3.org/2000/01/rdf-schema>>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#<http://www.w3.org/2001/XMLSchema>>
prefix dul: <http://www.loa-cnr.it/ontologies/DUL.owl#<http://www.loa-cnr.it/ontologies/DUL.owl>>
prefix sso: <http://something.something/sso#<http://something.something/sso>>
prefix ssno: <http://something.something/ssno#<http://something.something/ssno>>
prefix ssno_ds: <http://something.something/ssno_ds#<http://something.something/ssno_ds>>
prefix ssno_pd: <http://something.something/ssno_pd#<http://something.something/ssno_pd>>
prefix ssn: <http://something.something/ssno_pd_dul#<http://something.something/ssno_pd_dul>>
prefix wot2: <http://www.semanticweb.org/kerry/ontologies/2015/10/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).