A constructive and productive path forward for SSN/SOSA

Dear all,

I believe that there are a few important issues we need to clarify.

Let me begin with a very brief history of SOSA; I will need it for my 
argumentation later on. I proposed a vertical and horizontal 
modularization of the SSN with a small and lightweight core at it's 
center. You can find the proposal here 
https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN. I then 
proposed a first axiomatization. Namely here: 
https://www.w3.org/2015/spatial/wiki/SSN_core_modules. It merely 
consists of 6 classes and 6 properties. Armin (and Simon) took this 
approach and implemented the first SANDA version. Simon moved this to 
SOSA (https://www.w3.org/2015/spatial/wiki/SOSA_Ontology) and provided 
evidence that the modularization proposed above is indeed feasible and 
that other common sensor/observation work can be aligned. Since then we 
have moved SOSA forward on Github documenting and discussing each and 
every step. These ideas and files have been around for weeks, they don't 
just popped out of the blue.

The different sosa-om, sosa-sam, and so forth files that you can find on 
Github are (outdated) outlines to demonstrate the modularization. This 
was (and is) a very important step towards making progress. In *no* way 
it implies that those files are part of SOSA-core nor that they will be 
part of the SSN without all of us agreeing on them. The very same is 
true for concepts such as Activity, Sensing, Platform, and so forth that 
are now in the SOSA-core file. The very idea of using *Git* is to enable 
us to work in individual branches and to test our ideas and the results 
of our discussions *frequently*. Just like for sosa-om and other files 
and graphs (https://www.w3.org/2015/spatial/wiki/SOSA_Ontology), we 
implement and upload them because they are the *results* of our 
discussions (on the mailinglist) and thoughts. Without somebody doing 
the work of actually *formalizing* what we discussed, we would not be in 
the position to take any decisions! I am surprised and disappointed to 
see Simon being attacked for doing this and can only believe that this 
is due to some sort of misunderstanding. If we discuss issues and 
everybody ends up being too afraid to implement this into actual code, 
we will get absolutely nowhere.

Please be respectful of other people's work and constructive in your 
criticisms. I fully understand that we are in the middle of the summer 
and reading all those mails and code and reacting to them is difficult. 
However, the consequence cannot be to suddenly jump onto something you 
disagree with without following the discussion and without asking for 
clarification first. If you have different opinions and ideas, please 
bring them forward and please introduce your own branch on Github that 
allows everybody to review your proposal. Other people's branches are 
*invitations* for discussions, not an approach to get something 
standardized without your consent. This will require following the 
changes on Github (yes, it will) as this is the tool we agreed to use. 
Please lets also not jump on every unpolished aspect of an ontology that 
is in it's early development purely for the sake of calling things /broken/.

The sole reason for having SOSA in gh-pages is to ensure that there is 
something like a master branch that people can easily follow without 
having to visit the multiple branches that have been created so far. 
Again, this does in no way imply that some decision was taken and that 
things are set in stone.

The very idea of an *unchanged* or merely slightly changed SSN seems 
like something out of a feverish dream to me. This is the first joint 
working group of the W3C and the OGC. How can we approach OGC later on 
and tell them that the synthesis of all the work done on this and 
related topics from both sides is simply going to be the current (W3C) 
SSN? If this is the case, why invite OGC at all? More importantly, there 
are issues with the SSN and issues with O&M and other approaches. This 
is our chance to fix them!

I would propose that we continue our work on SOSA-core and explore in a 
constructive and productive setting what should be part of the core and 
what not. Classes and relations that will not remain part of core are 
not lost, they can be used in other modules.  Let us be free to play 
around with ideas and to implement them and upload them as often as 
possible so that we have *informed* discussions/decisions. If people 
always end up having to defend themselves for actually doing some work, 
they will stop contributing. Testing ideas is not implying that they 
will end up in the final version.

I do realize that there are many unsolved problems and many important 
questions we have to clarify, but let us make sure that they do not stop 
us from taking small steps one at a time. Lets make sure we finish a 
first SOSA-core draft within the next few weeks and then dive into all 
the potential issues that may arise some way down the road.

Finally, lets measure our success by whether we will see billions of 
observations posted on the Web using SSN/SOSA 5 years from now, not 
based on who had which idea (first).


Cheers,
Krzysztof

Received on Wednesday, 27 July 2016 04:39:48 UTC