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> 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]
> *Sent:* Wednesday, 29 June 2016 6:03 PM
> *To:* Kerry Taylor <kerry.taylor@anu.edu.au>; 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
> <kerry.taylor@anu.edu.au>]
> *Sent:* Tuesday, 28 June 2016 6:16 PM
> *To:* 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
>