W3C home > Mailing lists > Public > public-sdw-wg@w3.org > January 2017

Some concerns (was Re: Agenda SSN meeting this week)

From: Phil Archer <phila@w3.org>
Date: Mon, 23 Jan 2017 12:13:57 +0000
To: Armin Haller <armin.haller@anu.edu.au>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
Message-ID: <ed4b8883-72bd-6307-eafe-f3f2638285d8@w3.org>
Reading through last week's minutes, I see the issues around 
implementation of old SSN etc. keep coming up. So let me express some 
concerns in the hope that we can make rapid progress in the right direction.

As a guiding principle, process should not affect design. That is, just 
because we want SSN to become a Rec/OGC standard, that desire should not 
affect how the document is arranged, what is normative, what is 
informative etc. I am, of course, aware of the original work and of the 
deadline that we are all facing, so it is natural to want to use old 
implementation experience as evidence to support the new work - but 
that's back to front.

So let's look at the document as it is currently published. I see this 
in section 4.1:

"The Sensor, Observation, Sample, and Actuator (SOSA) ontology is one of 
the modules provided by the Semantic Sensor Network ontology. It acts as 
the core building block of SSN around which all other classes and 
relationships evolve. "

The namespace for SOSA is defined as http://www.w3.org/ns/sosa/

The conclusion is, I think, obvious: we will need multiple 
implementations of SOSA *at that namespace*. That's a new namespace, you 
can make any change you like there (there have been additions and new 
experiences since SSN was first done and they should be reflected).

Then we get to SSN, so far this appears in the doc just as the 
auto-generated classes and property definitions. There's no other info, 
but it has the new namespace of http://www.w3.org/ns/ssn/. If this is 
going to be normative, then, again the Director will expect to see 
multiple implementations of this at that namespace.

The sections on alignment are useful background. They help people who 
have used the old system to see the relationships with the new - that's 
good, and I'd expect to see those sections as informative. They would 
supplement the evidence of implementation of SOSA and SSN and mean that 
we sail through process, but I do not think they should be replied upon 
as evidence of implementation per se.

Now, it may be that we don't and won't have the evidence needed to get 
SOSA and SSN through the process. That would be disappointing for 
everyone but I believe it is preferable to have a well-designed and well 
documented Note than a Rec/standard that not what we actually think is 

Some salve for this...

An internal debate has been going on at W3C for *years* about how we 
should best support the development and maintenance of vocabularies. I 
understand similar debates take place at OGC. There's a tension between 
the rock solid dependency of a standard cf. the agility/real world 
practicality of a Note. One thing we're looking at - that we can do 
within our current processes - is to include the word 'Reference' in our 
Note subtitles, i.e.

Semantic Sensor Network
Working Group Reference Note {date}

There's still some debate about this but essentially it would mean "It's 
not a formal standard but you can refer to this with confidence."

My preference at this stage is, of course, that SSN becomes a formal 
standard, that is, it reflects the settled consensus of the relevant 
community. Let's see if we can make that. If not, let's not force it 

If you want to talk about this on the call this week, Armin, that's up 
to you of course, but I hope it's not too contentious and we won't need 
to spend time talking about process when really we want to get on with 
the proper work.



On 23/01/2017 03:10, Armin Haller wrote:
> Agenda for SSN-focused meeting 24 January 2017 21:00 UTC<http://www.timeanddate.com/worldclock/fixedtime.html?iso=20170124T21&ah=1&msg=SSN%20Call>
>   1.  Commit Workflow for Editor’s draft
>   2.  O&M alignment “normative” or “non-normative”
>   3.  Proposal to align sosa:Platform and ssn:Platform from Krzysztof, taking into account virtual sensors (https://www.w3.org/TR/sdw-ucr/#VirtualObservations) as of ISSUE 88 (carried from https://www.w3.org/2016/12/06-sdwssn-minutes#item05) and ACTION-251
>      *   Proposed new rdfs:comment as in SOSA and in the mapping table (https://www.w3.org/2015/spatial/wiki/Mapping_Table) for ssn and sosa:Platform
>      *   “A device, (computational) system, or agent (including humans). A platform carries at least one Sensor, Actuator, or Sampling Device to produce observations, actuations, or samples, by following a Procedure. In case of virtual sensors, a platform can be a computing system which hosts software implementations, e.g., simulations”
>   4.  ISSUE-140 https://www.w3.org/2015/spatial/track/issues/140: sosa:hasvalue is different to ssn:hasValue and similar ISSUE-138, sosa:hasResult https://www.w3.org/2015/spatial/track/issues/138
>   5.  SOSA classes/properties to be super classes of SSN, i.e. SSN new imports SOSA https://www.w3.org/2015/spatial/track/issues/37?
> Further details and dial in instructions: https://www.w3.org/2015/spatial/wiki/Meetings:SSN-Telecon20170124
> Re 1: There was a preference for the following workflow going forward. I have clarified it a bit where necessary.
> 1.       All commits to the Editor's Draft + the ontologies the Editor’s draft depends upon regardless if you are editor or not need to be committed to your own branch
> 2.       Pull requests need to be issued assigning all editors but yourself, but multiple commits can be made in each PULL request. Each commit should be atomic enough to make it easy for the approver to recognise the diff.
> 3.       The Pull request needs to be approved by ONE editor other than the one who made the change.
> 4.       This means that once you have committed your changes and a PULL request, until your PULL request is accepted, you need to again create a new Branch from the main branch in your local repository. Preferably, though, the PULL request should be accepted quickly and prior to you needing to make a new branch.
> Kind regards,
> Armin


Phil Archer
Data Strategist, W3C

+44 (0)7887 767755
Received on Monday, 23 January 2017 12:13:53 UTC

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