RE: SSN/O&M RE: [Minutes] 2016-02-09 F2F Day 2

Hi Simon, Kerry, Raúl and others,

Kerry sent me along this thread and wondered if I'd like have input on the discussions about the ontology.  (for those who don't know me, I was the editor of the original SSNO)  I'd very much like to participate in the development of the ontology, but new work commitments probably preclude me spending too much time in the group, but I am developing a tool that will be based around the ontology so I'm very keen to observe, make input, and definitely use the outputs.

Firstly, I think I'm in agreement with Simon's last comment and we, similarly, included such stubs in the original SSN ontology (or inherited them from DUL) to mark places where we needed to have the existence of some concept to complete the model, but saw it as not the group's goal to define such things further.  The imports and inheritance mechanisms of OWL works really nicely for such stubs.

In general with SSN modularisation, and indeed with the modules I made and with Krzystof and my work on the SSO pattern, the point wasn't to allow users to opt in for some other model of, say, deployments (though there is nothing to stop them), but more to allow them to opt out of that part of the model.  The SSO being (or so the idea goes) some sort of minimal model in which you can say many interesting things about sensors and observations, but with only committing to a very minimal model - perhaps because not wanting to make ontological commitments beyond those required, or perhaps for wanting a simple model with simple semantics and reasoning.

My own feeling is that a simpler ontology encourages use far more than a 'complete' axiomatization - and that simple ontologies are really very useful..  Maybe aiming for something like that the simplest module to grab works for most uses most of the time, but that a more complete semantics is available when required.

Michael






From: <Simon.Cox@csiro.au>
Date: Wed, 10 Feb 2016 23:51:18 +0000
To: <kerry.taylor@anu.edu.au>, <rgarcia@fi.upm.es>, <public-sdw-wg@w3.org>
Message-ID: <2A7346E8D9F62D4CA8D78387173A054A6035E9BE@exmbx04-cdc.nexus.csiro.au>
In O&M we used 'stub' classes to bridge. I.e. we recognised the need for a class for sensors and sensor systems, but didn't include any properties. Then in an actual use situation, an assertion would be made that [insert your favorite sensor class here] is a subclass of the stub class.

I guess my suggestion is that 'skeleton' would have a number of stub classes, and these could then be fleshed out in modules, which wouldn't necessarily point back up to the skeleton, except at run time.

Simon

-----Original Message-----
From: Kerry Taylor [mailto:kerry.taylor@anu.edu.au]
Sent: Thursday, 11 February 2016 10:33 AM
To: Raúl García Castro <rgarcia@fi.upm.es>; public-sdw-wg@w3.org
Subject: RE: SSN/O&M RE: [Minutes] 2016-02-09 F2F Day 2

I think the modularisation is more driven by a desire to support use of just a "bit" of the ontology. Deployment, for example, may not be of interest to many people so it is better being easily separated. On the other hand some uses may want deployment but have no interest in the sensing mechanism nor data.

Separating sensors and observations could  obviously be done -- but  would break the "skeleton" (SSO) design that closely links sensors to observations.  I'd like to hear Krzystof's view on this.

Kerry



-----Original Message-----
From: Raúl García Castro [mailto:rgarcia@fi.upm.es]
Sent: Thursday, 11 February 2016 4:07 AM
To: public-sdw-wg@w3.org
Subject: Re: SSN/O&M RE: [Minutes] 2016-02-09 F2F Day 2

El 10/2/16 a las 0:25, Simon.Cox@csiro.au escribió:
>
>> <trackbot> action-140 -- Armin Haller to Clearly separate
> observation, sensor, and deployment parts of ssn -- due 2016-02-16 --
> OPEN
>
> Relating to this, not sure if y'all noticed my suggestion at the
> bottom of my posting on Friday. I pointed out that for modularization
> we could also consider the concern that is reflected in the OGC's
> modularization - sensor descriptions (SensorML) vs observations (O&M)
> - aka producer vs consumer viewpoints. Is that what Action-140 is
> about ?

Hi,

Regarding modularisation, I think that it is good since if supports usability and facilitates ontology evolution.

But I would go for a few modules. Simons' distinction between sensors
(providers) and observations (users) makes sense.

I'm not sure yet about also modularizing other things (such as deployment, as the SSN Tasks page/ACTION 140 says). I see the potential benefit but we are also inviting people to use only one (or several) of our modules and using their own modules for other parts of their data (e.g., using myDeploymentOntology instead of the SSNDeployment module), which would go a bit against the idea of standardization.

Kind regards,

--

Dr. Raúl García Castro
http://www.garcia-castro.com/


Ontology Engineering Group
Departamento de Inteligencia Artificial
Escuela Técnica Superior de Ingenieros Informáticos Universidad Politécnica de Madrid Campus de Montegancedo, s/n - Boadilla del Monte - 28660 Madrid
Phone: +34 91 336 65 96 - Fax: +34 91 352 48 19