Re: Shrinking the SSN ontology for Wot/IoT applications

Hello Kerry,

I will gladly accept that SSN being to big is a furphy because it can be
reduced. But doesn't your story illustrate that its complexity makes it
difficult to use? I am not burdened with any practical experience with SSN
(yet), but I can imagine that in order to arrive at an optimal (minimal)
set of semantics for an application it is easier to start with a small core
module and expand that if necessary then to start with something big and
try to reduce it. I can also imagine that having a small core module that
is always used will enhance interoperability between different
implementations in the long term.

Regards,
Frans



2015-11-26 13:02 GMT+01:00 Kerry Taylor <Kerry.Taylor@acm.org>:

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