Re: Architecture of SOSA/SSN integration (let's have a better idea of what's at risk or not).

Hi,

I have looked at the minutes http://www.w3.org/2017/01/31-sdwssn-minutes

and I am not convinced that any progress has been made this morning on
what's blocking progress.
I want to express my support to Kerry's objections (you can see below which
particular points are important for me on the whole SOSA + SSN + old SSN +
DUL debate) and to her argument that it was hard to understand which
questions were asked (possibly because of audio problems on her side but
probably also because the sequence in which the questions were asked.

This imbroglio is also apparent in your summary below with things such as:
- a MAY sentence which does not appear as a choice between two options (may
and may not)
- options 1 to 4 answering a sub-part of the debate (and placed after
bullet points which, if I interpret the structure of the message well) are
deemed to be agreed
- no references on past resolutions or to closed issues which should have
marked times when the group has indeed reach a consensus (required to build
up the trail of evidence for later evaluation of the quality of our work
and also show that all views have been taken into account)
- and finally "Kerry disagrees" and "but Kerry seems to agrees in the same
sentence" (it's more complicated and from what I see this morning it was a
clear Kerry disagrees).

To be constructive, my impression is that the current deadlock (yes, I
think we are in a deadlock) is because the group doesn't have a clear
picture of the diversity of positions on what to do / where to go with the
different parts of the proposed specification as it currently stands.

My proposal is to check this diversity by asking all interested group
members to choose between three positions:
- I want to include a feature in the specification:
- I think this feature is a "at risk" feature (no one has convinced me that
we should include it nor to drop it yet)
- I want to drop this feature.

We can apply these recipes this at two levels:
- modules: my approach would be to identify at least  these sub-categories
 - what we call the core,
  with the part(s) which is/are unchanged from SSN
  with the part(s) which is/are modified or new
   corresponding to SSN
   corresponding to SOSA (definitions which are different
from what was already in SSN)
 - what we call the old SSN or SSN extensions
  with the part(s) which has/have passed the implementation test
  with the part(s) which has/have not passed the implementation
test
   because they were faulty (not convenient) but for which
there is an expressed need (evidenced by users inventing alternative
solutions)
   because there were no interest in them
 - what we call the alignments to DUL (with two flavours: an OWL (DL)
one and a visual and/or tabular one)
  with the part(s) which is/are unchanged from SSN
  with the part(s) which is/are modified or new
 - what we call the alignments to O&M - same two flavours


- vocabulary elements: we can also work at the level of individual classes,
properties (and axioms e.g. property chains) to flag:
 - which ones we intend to keep
 - which ones we intend to modify
 - which ones we intend to drop
(this is where Raul's work on finding out about the SSNXG implementations
will be useful).


To give you an idea, here is my view on which sub-modules are at risk or
not:
- core (unchanged from SSN): pass (my assumption is that there are
implementations for these)
- core (parts modified or new): at risk (because we have not demonstrated
the added value - not reached group consensus + no implementations)
 - SSN: at risk (need to see examples / implementations)
  - what we do for ssn:Platform is there:
 - SOSA:  at risk (need to see examples / implementations plus have an
explanation of where it's coming from and how it "covers" the requirements
of users having these needs
  - new pattern for Actuation / Actuator; at risk: in its current
state, it is a simple transposition of what we've done for sensing with no
detailed argumentation + example proving that this is useful on its own.
Also, there are some classic examples of "active sensors" e.g. radars we
should have tested the pattern against.
- old-SSN unchanged with implementations: pass (but probably worth to seek
implementations too to prove that current SSN users intend to move to the
new SSN).
- old-SSN faulty but needed: currently at risk, work required to reach
consensus and provide implementations
 - most important one is to fix how we attach data to observations
 - this list should be completed ...
- old-SSN uninteresting: drop
 - for example, I have not noticed any implementation of ssn:Condition
(my impression is that sensor performances data sheet would look more like
data cube on the model of DQV).
 - I also have some doubts on the usufulness of the classes in the
MeasurementProperty sub-module (I'd rather leave the space open for a
VIM-based solution)
- alignment to DUL:
 OWL alignment: at risk (current blocking factor for me is that I get
something unsatisfiable when I put everything together)
 Visual alignment: at risk (the main reason to keep it is to mark the
deviations between the old SSN and the new SSN)
- alignment to old SSN:
 OWL alignment: keep (and use it as proxy for alignemnt to DUL - this
may requires to republish a fixed version of the old SSN)
 Visual alignment: keep
- alignment to O&M
 OWL alignment: at risk
 Visual alignment: at risk (the two options provided by Simon are not
sufficient as guidance for implementers as they currently stands)


Once we have a consensus defining what we want to do and what we hope to
do, then we would be in a better place to have the discussion on
architectural issues and decouple it from issues which are specific to each
module (and also to issues at a finer grain to each vocabulary element) and
also find the best way to publish the vocabularies AND their documentation.

It would then be a lot easier for the group to discuss the pros and cons of
the proposed solution(s) for each feature (or sub-parts of a feature) vs.
what we lose / gain by dropping the controversial feature or sub-part
entirely and for proponents of features at risks to pitch why we should
include them  (and also for them to better understand where there is a gap
which needs to be filled with arguments, examples, ... ).

HTH.
Laurent Lefort
Assistant Director
Emerging Data and Methods  |  Methodology Transformation Branch  |
Methodology Division  | Australian Bureau of Statistics
(P) +61 2 6252 5652 (M) +61 409 129 739
(E) laurent.lefort@abs.gov.au (W) www.abs.gov.au

PS: <rant>
Can we also stop having arguments on how a very rigid application of OWL DL
(a la DUL) may or may not be compatible with a very loose application of
OWL DL (a la schema.org). My view here is that the group need to settle on
a single approach amd aim for maximum consistency with what has been done
in other W3C WG, in particular RDF Data Cube and Prov.

Our charter says: The WG will work with the members of the former Semantic
Sensor Network Incubator Group to develop its ontology into a formal
Recommendation, noting the work to split the ontology into smaller sections
to offer simplified access.

Can someone explain to me how we are going to keep it simple for our users
by publishing OWL classes (in current sosa) using meta:rangeIncludes and
meta:domainIncludes (annotations?) and a 2nd ontology which is based on
OWL-DL. For me, the obvious middle ground we should move towards is to
simplify SSN a bit (e.g. no property chain axioms) and to keep the core at
the level of other published vocabularies (so with owl:someValues from
restrictions or domain/ranges with union of classes when required plus as
many figures as required to explain the ontology to users).




From: Armin Haller <armin.haller@anu.edu.au>
To: SDW WG Public List <public-sdw-wg@w3.org>,
Date: 01/02/2017 10:41 AM
Subject: Architecture of SOSA/SSN integration



Hi,

Herewith I am trying to summarise what has been discussed in today’s
meeting, what was discussed and proposed on the list and what we have
already decided on earlier in the working group:

      ·         SOSA and SSN use Slash URIs/IRIs
      ·         SOSA and SSN use different IRIs and are serialised in
      separate ontology files (everyone expect Kerry agreed on that one,
      although there is her proposal on the wiki stating the same:
      https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN#Compromise_Proposal_6_made_by_Kerry_January_2017)
      ·         SOSA and SSN may use different ontology namespaces
      ·         SOSA uses simple semantics as decided upon earlier (i.e.
      owl classes, datatype and object properties, inverse properties, but
      no domain/range and no other owl restrictions)
      ·         SSN imports SOSA
      ·         SSN introduces stronger semantics, using several types of
      OWL restrictions. As far as I can tell, four options have been
      presented to add these additional semantics through the import of
      SOSA:
            1.       SSN introduces new classes/properties in its ontology
            namespace and introduces where appropriate equivalence
            relations to the class/property in SOSA
            2.       SSN introduces new classes/properties in its ontology
            namespace and introduces subclass relations and where
            appropriate equivalence relations to the class/property in SOSA
            3.       SSN reuses the IRI for classes/properties defined in
            SOSA and introduces further axioms that “narrow” their meaning,
            but does not introduce subclass or equivalence relations
            relying on the user to choose through the ontology namespace
            the interpretation of the ontology.
            4.       A separate core essentially introduces vocabulary
            terms with no semantics, only a description and a label (very
            abstract, similar to the annotations that I have added to the
            wiki https://www.w3.org/2015/spatial/wiki/Mapping_Table and we
            had no time to discuss), but its own IRI and “ontology”
            namespace. Both SOSA and SSN import this vocabulary and extend
            it with different semantics, solving the issue that SSN has two
            different IRIs for some classes/properties as would be the case
            in Option 1-2.

I had the impression that there was no strong objection against any of
these options in the call today, but several issues have been raised.
      ·         In option 3 the issue that has been raised was that users
      who use a class/property in their tool of choice may not know which
      semantic interpretation should be used in the given context.
      ·         Earlier on the mailing list, an issues has arising that in
      Option 3 SSN would use the SOSA IRIs for several classes/properties
      whereas the old SSN only had one IRI for those classes/properties.
      That could potentially be solved with Option 4.

Please let me know if I missed an option.

Cheers,
Armin