How many cores? - was Re: ssn: lost something?

Thanks Rob. Insightful, and challenging, as usual.

Jumping to the bottom, I think you are suggesting that the Observation viewpoint should be the core.
I’m not sure this works, as there are at least three key viewpoints, which emphasize different primary concerns

-          Provider/sensor – sensor, platform, sensor network, observed property

-          Provider/sampling – site, station, specimen, feature of interest

-          Consumer – observed property, result, feature of interest
The first two are not addressed by the O&M Observation schema.
These three cores would correspond approximately to one axis of Jano’s vertical/horizontal modularization idea [1].

As you are probably aware, I created om-lite and sam-lite [2] as a strawmen for two cores, with the expectation that there would be a third core, dealing with the sensor side.
(Sensors are deliberately and explicitly delegated elsewhere in both O&M and om-lite - they both only have a stub/abstract class for the range of the procedure property.)
The primary goal in om-lite was a more idiomatic OWL version of O&M than following the ISO 19105-2 rules produce [3], also with fewer dependencies and thus fewer semantic commitments.  (It is a lot more than “pure RDFS”.)

Subsequent discussion on the SDWWG lists suggests that there may still be too much semantics in om-lite/sam-lite for a core –

-          there are explicit domains and ranges in some places, and lots of local (guarded) restrictions, and some properties are declared functional

-          while these ontologies are mostly self-contained, sam-lite has a dependency on PROV

-          om-lite includes a taxonomy of specialized observation classes, and sam-lite of specialized sampling feature classes.


schema.org is being suggested as a paradigm for the core, i.e. a flat list of classes and properties in a single namespace with few relationships.
Working on this assumption, then if there is a single core, then it should do little more than enumerate the key ½ dozen classes, and a comparable number of properties corresponding with a bland set of interrelationships, with no formal domain/range or restrictions – essentially just “tags”.
In the last day I’ve been working with Armin on a proposal in that direction [4].
This takes Jano’s proposal [1] and adds

-          SamplingFeature

-          separate classes for Procedures and Devices

-          Actuator.
Personally I’m not convinced that the latter two belong in the core – I think I would move those considerations up into the next layer, but they are there for the moment.
This would be the base of a stack something like this (would be better arranged in concentric circles, but I don’t have a tool to do that):

[cid:image001.jpg@01D1D3B0.F8C3EE70]

Note that Armin and I have been struggling to get WebProtege to behave, and are not convinced it is the long term solution ☹

Finally, a request to everyone – **please include links to the things you are discussing or complaining about** .
It may take a little more of your time when constructing your message, but it will save a lot more for everyone else.
And in particular, it helps everyone else come along with you if they can just click and see the actual artefact under discussion.

Simon

[1] https://www.w3.org/2015/spatial/wiki/SSN_core_modules

[2] http://def.seegrid.csiro.au/ontology/om/om-lite

http://def.seegrid.csiro.au/ontology/om/sam-lite

[3] http://www.semantic-web-journal.net/content/ontology-observations-and-sampling-features-alignments-existing-models-0

http://ceur-ws.org/Vol-1063/paper1.pdf

[4] http://webprotege.stanford.edu/#Edit:projectId=da9180fc-add3-4b6a-96d0-bf66c52744b7



From: Rob Atkinson [mailto:rob@metalinkage.com.au]
Sent: Thursday, 30 June 2016 9:35 PM
To: Kerry Taylor <kerry.taylor@anu.edu.au>; Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>; public-sdw-wg@w3.org
Subject: Re: ssn: lost something?

OK - throwing myself as a sacrifice into the teeth of the storm here ...

I've spent a bit of time looking at the SSN ontology and seeing where the "natural joints" appear to be and looked at the whiteboard sketch around proposed modularisation....

If I then think about the Use Case of a set of OGC SensorWeb services deployed, and using SSN to provide a metadata layer that would allow reasoning about these and how they relate to each other...

(at this point - if SSN is purely intended as a language for encoding results of sensing - not for describing sensing independent of the encoding of the results - then read no further and we'll go our separate ways without further pain...)

I get, and endorse the separation of  RealWorld (Stimulus Sensor Observation seems an ugly name - but the packaging of concerns seems OK, Device and Deployment....  )

more on the RealWorld module later...

where things go awry for me is the imports....

O&M is not going to import this - but an O&M profile that wants to define the sensor process in a specfic level of detail may import parts of SSN.
The containing rings are a problem though - you can only import a specific named, described, versioned artefact - not a vagure grouping - you'd need to name a package even if all it does is contain transitive imports. And the user will need it described to know how to use it this way.

And this leads me to the questions I expect will bring a rain of frogs upon my head..

I think we need to have a much clearer picture of how the modules would provide specific functional outcomes. I'm sure others have thought in more detail how to do this - and the suggestions below come from the perspective of not being able to see into that thinking well enough but wanting to support some fairly obvious use cases around deploying existing OGC standards with a much improved ability to share details about the sensing process.

IMHO there are several touch points and requirements w.r.t. the O&M space:
1) there is a pre-existing scope of O&M implemented in existing services, and if we want to talk about this body of information with a more powerful language (SSN) then we need a first-class mapping to O&M concepts
2) There is not yet AFAICT a canonical O&M ontology formalised in OWL - however there are candidates (?)  IMHO The ISO 19150 approach to encoding O&M appears unworkable however. The "modular" model - the vertical modules - RDFS, OWL-DL, SKOS etc views are necessary.
3) SSN has some extended semantics but does not at first glance appear to be fundamentally inconsistent with O&M
4) Users will hate us if there are multiple virtually indistinguishable approaches
5) The RealWorld maps properties of the Feature of Inerest to the sensing process... this seems to be where SamplingFeature comes in.

I would like to plead for an attempt to break the RealWorld module into several distinct modules with these characteristics:
1) O&M -lite - a pure RDFS vocabulary of the definitions used in O&M, as a canonical O&M ontology
2) O&M-sensor (imports O&M lite and any other SSN modules necessary) - defines sensor related extensions that allow an O&M instance to be attached to SSN details. (this may be quite trivial and only contain the links between observation and Sensing, Sensor etc - perhaps characterised as subProperties of om:observationProcess?
3) An alignment module if required mapping SSN1 terms to the new equivalents in appropriate namespaces, and defining the necessary imports)
3) SSN-ObservedFeature (imports O&M lite and a general spatial ontology defining a Feature) - that defines properties of a Feature, and relationships between a Feature and a SamplingFeature, and the real world phenomena being described

Device and platform modules would provide for device specific details of how the phenomenon is measured. Deployment would identify the samplingFeature and FoInterest.  SSN-ObservedFeature would provide the link between the FeatureOfInterest and how its properties are measured via a SamplingFeature.

Maybe we first need to explore if we can identify a canonical O&M vocabulary we can re-use - and if there are fundamental mismatches with SSN semantics? If this has been discussed and documented, just add these discussions as links in the modularity discussions I've been pointed to and I'll try to understand them. I'm assuming the lack of such links means this is just the elephant in the room - and step in to wrestle it like a fool.


Rob

u, 30 Jun 2016 at 11:22 Kerry Taylor <kerry.taylor@anu.edu.au<mailto:kerry.taylor@anu.edu.au>> wrote:
No – I was referring to the version of SSN as published with the FPWD, as I said: https://www.w3.org/ns/ssn/ . It also corresponds to the ontology documentation in the FPWD. Those things appear  to have been dropped accidently.

From: Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au> [mailto:Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>]
Sent: Wednesday, 29 June 2016 6:03 PM
To: Kerry Taylor <kerry.taylor@anu.edu.au<mailto:kerry.taylor@anu.edu.au>>; public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>
Subject: RE: ssn: lost something?

Are you looking at SANDA in WebProtege?
That is very incomplete yet.

I still see all the restrictions in the version of SSN here http://purl.oclc.org/NET/ssnx/ssn


Simon

From: Kerry Taylor [mailto:kerry.taylor@anu.edu.au]
Sent: Tuesday, 28 June 2016 6:16 PM
To: public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>
Subject: ssn: lost something?

Joel and I were looking at ssn today in the context of IoT  and we noticed that “ssn:Observation” has lost its restrictions for  properties “ssn:observationResultTime”, “ssn:qualityOfObservation” and “ssn:observationSamplingTime” somewhere in the translation to the FPWD form.
Can anyone explain? Have any others gone missing? Is a more thorough check warranted?

--Kerry