W3C home > Mailing lists > Public > public-sdw-wg@w3.org > July 2016

RE: Updated SOSA core RE: SOSA core - procedures vs devices

From: Kerry Taylor <kerry.taylor@anu.edu.au>
Date: Wed, 27 Jul 2016 02:11:12 +0000
To: Rob Atkinson <rob@metalinkage.com.au>
CC: "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
Message-ID: <PS1PR06MB1740E9ADF908B3CE0EDD65B8A40F0@PS1PR06MB1740.apcprd06.prod.outlook.com>
So I understood the  “core” was to be comprised of essential Iot-driven terms and was also semantically-simple ie RDF-alone or RDFS but always ensuring compatibility with  OWL-DL. I’d be happy to have no subclass axioms, too.   And in only one file. I am not sure whether we agreed , or whether I just assumed the one-file part..

For the non-core modules I was expecting “horizontal” –style expressivity – ie OWL DL is fine as appropriate.  Furthermore,  the non-core modules (or module?) would aim to separate concerns insofar as this increases usability.


Ø  - or another supporting diagram that has the same underlying module structure, but shows the extensions (OWL axioms) etc attached to each concept-defining module in the main hierarchy.

I agree  this is essential, when  the terms are new and independent of the old ssn, (which they appear to be to me in the sosa proposal).  If they are ssn terms, on the other hand,  I don’t need such a diagram as the horizontal/non-core ssn modules will do that alignment properly anyway, and will also provide the documentation you ask for. I think such a  diagram aimed at users of the core alone might be useful for users at publication time, then, but is not  essential for the team’s internal use where we are now. Not that it would hurt.

Kerry

From: Rob Atkinson [mailto:rob@metalinkage.com.au]
Sent: Wednesday, 27 July 2016 11:50 AM
To: Kerry Taylor <kerry.taylor@anu.edu.au>; Rob Atkinson <rob@metalinkage.com.au>
Cc: public-sdw-wg@w3.org
Subject: Re: Updated SOSA core RE: SOSA core - procedures vs devices

Personally i do find it approaching K's proposal - but the roles of modules a little blurred. The implication is even more modules at this level of granularity - or another supporting diagram that has the same underlying module structure, but shows the extensions (OWL axioms) etc attached to each concept-defining module in the main hierarchy.


On Wed, 27 Jul 2016 at 10:18 Kerry Taylor <kerry.taylor@anu.edu.au<mailto:kerry.taylor@anu.edu.au>> wrote:
Agreed! This looks to me very little like K’s proposal as  I understood it. Am in the middle of composing a longer version of something like this.

>“But if we really have a tabula rasa,”
We do not – refer to the charter please.

From: Rob Atkinson [mailto:rob@metalinkage.com.au<mailto:rob@metalinkage.com.au>]
Sent: Wednesday, 27 July 2016 10:08 AM
To: Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>; Armin Haller <armin.haller@anu.edu.au<mailto:armin.haller@anu.edu.au>>; janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>; jlieberman@tumblingwalls.com<mailto:jlieberman@tumblingwalls.com>

Cc: danh.lephuoc@tu-berlin.de<mailto:danh.lephuoc@tu-berlin.de>; public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>; Kerry Taylor <kerry.taylor@anu.edu.au<mailto:kerry.taylor@anu.edu.au>>
Subject: Re: Updated SOSA core RE: SOSA core - procedures vs devices


Hi - whilst I'm not as familiar with the details the amount of modules and the logical structure fit my expectation.  I think however that the explanations of these will need some work to make them accessible. In particular sosa-om and sosa-sam explanations only help if you are intimately familiar with these. It would help even at this early stage to perhaps describe what these contain, and why they are not part of the core. If what they are is an extension of sosa-core that does not define new entities, but uses additional expressivity available in a language then perhaps we can come up with a naming convention that reflects the role of each module? eg sosa-ssn-align ?

If modules are doing multiple things - like extending scope, adding axioms and performing alignments (declaring equivalent classes) then this is a departure from Krzysztof's proposal - which may not be a bad thing but means that the modularisation strategy needs to be re-articulated and taken into account.

Rob

On Wed, 27 Jul 2016 at 08:28 <Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>> wrote:
Currently Sensing is a subclass of Observing (or Observation), which is a subclass of Activity. That was my proposed ordering – seeing ‘sensing’ as a subset of ‘observing’ to be consistent with OGC usage, where ‘Observation’ covers not only sensing but also forecasting, simulation, human-observing (which is a combination of sensing and application of knowledge).

But if we really have a tabula rasa, then we should consider the best terminology and correct hierarchy – maybe ‘estimating’ is a more general term.

But definitely the order in that hierarchy should be resolved.

Simon

From: Armin Haller [mailto:armin.haller@anu.edu.au<mailto:armin.haller@anu.edu.au>]
Sent: Wednesday, 27 July 2016 7:58 AM
To: janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>; Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>>; jlieberman@tumblingwalls.com<mailto:jlieberman@tumblingwalls.com>
Cc: danh.lephuoc@tu-berlin.de<mailto:danh.lephuoc@tu-berlin.de>; public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>; Kerry Taylor <kerry.taylor@anu.edu.au<mailto:kerry.taylor@anu.edu.au>>

Subject: Re: Updated SOSA core RE: SOSA core - procedures vs devices

The proposal we arrived to now looks good to me.

The only change, where I second Simon is, that we should rename Actuation to Actuating. That is then aligned to Sensing and also implies an Activity. The same applies to Observation which I would rename Observing. Although, I am not sure if we need the Observing class in the core if we have Sensing anyway.

From: Krzysztof Janowicz <janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>>
Reply-To: "janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>" <janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>>
Date: Wednesday, 27 July 2016 6:34 am
To: "Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>" <Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>>, Armin Haller <armin.haller@anu.edu.au<mailto:armin.haller@anu.edu.au>>, "jlieberman@tumblingwalls.com<mailto:jlieberman@tumblingwalls.com>" <jlieberman@tumblingwalls.com<mailto:jlieberman@tumblingwalls.com>>
Cc: "danh.lephuoc@tu-berlin.de<mailto:danh.lephuoc@tu-berlin.de>" <danh.lephuoc@tu-berlin.de<mailto:danh.lephuoc@tu-berlin.de>>, "public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>" <public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>>, Kerry Taylor <kerry.taylor@anu.edu.au<mailto:kerry.taylor@anu.edu.au>>
Subject: Re: Updated SOSA core RE: SOSA core - procedures vs devices

I made some cosmetic changes and pushed them to github. I am going to make another series of changes that are a bit bigger and thus will leave them in https://github.com/w3c/sdw/blob/kjanowicz-ssn/ssn/rdf/sosa.ttl for now until we agree on them. Most of this is from our last discussion about procedures and platforms.

Jano

On 07/18/2016 10:01 PM, Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au> wrote:
I’ve just pushed an update to the SOSA Core ontology
https://github.com/w3c/sdw/tree/simon-ssn/ssn/rdf

in particular https://github.com/w3c/sdw/blob/simon-ssn/ssn/rdf/sosa.ttl


This includes the hierarchy shown on the wiki page https://www.w3.org/2015/spatial/wiki/SOSA_Ontology


I’ve cleaned up the class names a bit, and added documentation on all elements.

Simon




--

Krzysztof Janowicz



Geography Department, University of California, Santa Barbara

4830 Ellison Hall, Santa Barbara, CA 93106-4060



Email: jano@geog.ucsb.edu<mailto:jano@geog.ucsb.edu>

Webpage: http://geog.ucsb.edu/~jano/


Semantic Web Journal: http://www.semantic-web-journal.net

Received on Wednesday, 27 July 2016 02:11:50 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:23 UTC