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

Re: State of SSN

From: Rob Atkinson <rob@metalinkage.com.au>
Date: Thu, 26 Jan 2017 01:08:23 +0000
Message-ID: <CACfF9LwDWxbg6DSCj=9X3QXsiUXVmsS6ypAs-up6E-p2669VGg@mail.gmail.com>
To: Armin Haller <armin.haller@anu.edu.au>, "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, "phila@w3.org" <phila@w3.org>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
Cc: "ssimmons@opengeospatial.org" <ssimmons@opengeospatial.org>, "fd@w3.org" <fd@w3.org>
Hi
thanks for the intervention Armin.

Can we please clarify how the following concerns are addressed in these
options
1) sub-classing - if SSN has a restricted semantics for a term, then it
should be a subclass of a SOSA (option 2, but also applies to alignment
axioms) - the option 2 outlined talks about "extending".
2) namespace and imports (cf Kerry's email): is SSN uses explicit OWL
imported, and specifically if client that use it explicitly import the SSN
ontology, then the fact that the namespace resolves to core SOSA
definitions should not impact implementation? SSN can introduce axioms it
likes to its hearts content, provided it uses subclasses if semantics are
narrowed.
3) Another ontology that uses SOSA and SSN should not find the semantics of
SOSA compromised by SSN axioms, - SSN may require more sophisticated
entailment to be most useful (OWL) whereas SOSA should not require clients
to perform any runtime entailment (= lightweight implementation) - i.e. SSN
needs to be semantically consistent with SOSA but re-use its terms and
namespace, and thus be able to co-exist with other specialisations of SOSA
that follow the same rules.

IMHO SSN is not an informative alignment - its a (not then only) driving
client Use Case for SOSA as a simple lightweight set of definitions.

Rob

On Thu, 26 Jan 2017 at 10:36 Armin Haller <armin.haller@anu.edu.au> wrote:

> Hi Phil,
>
>
>
> Thanks for raising these points. I had a longer F2F conversation with
> Kerry yesterday to discuss her concerns around the SOSA/SSN alignment and
> the more general issue she raised with
> https://www.w3.org/2015/spatial/track/issues/139. I think I now
> understand her preference, which I will outline in this email. Before, I
> want to more clearly outline the options we have in terms of alignment
> between SOSA and *SSN new *as of Point 6 from Phil below, seeing SOSA as
> the core as already outlined in the first working draft.
>
>
>
> *Option 1: SSN new imports SOSA and equivalence/subclass/subproperty
> relations are defined in SSN*: In this option both ontologies use a
> separate namespace and *SSN ne*w introduces its own classes/properties
> (in its own namespace) even for concepts/properties that are common to both
> ontologies, while doing so asserting equivalence and subclass/subproperty
> relations for those classes that are common and where appropriate.
>
> *Option 2: SSN new imports SOSA and “extends” classes/properties from
> SOSA: *In this option both ontologies use a separate namespace, but *SSN
> new* extends SOSA, meaning *SSN new* uses the SOSA namespace for
> concepts/properties that are shared between SOSA and *SSN new* and
> “extends” (narrows) them with stronger OWL axiomatizations.
>
> *Option 3: SSN does not import SOSA and alignment between SOSA and SSN is
> defined in a separate file/namespace:* This approach is similar to how we
> align *SSN new* to DULCE, i.e. the alignment is in a separate file with
> its separate namespace.
>
>
>
> Although my personal preference from the beginning was on Option 2, my
> belief was that some group members are against this option, in particular,
> Kerry, and I was under the working assumption that at best we will achieve
> Option 3. In my discussion with Kerry yesterday she made it very clear that
> she prefers *direct usage of SOSA classes/properties in SSN new*. This
> includes the introduction of properties in *SSN new* that are defined in
> SOSA for simplicity (traversing a property path of SSN new) while adding
> axioms to ensure the equivalence of these simplified properties to a
> property path. This also means that rdfs:comments will be shared between
> SOSA and *SSN new*. Since neither of the rdfs:comments in our mapping
> table on the wiki (https://www.w3.org/2015/spatial/wiki/Mapping_Table)
> are yet particularly suited for this purpose, the proposal was:
>
> -          To create one very abstract description for each shared
> concept that *DOES NOT* refer to classes/properties (i.e. using capital
> letters or camel casing), but uses English natural language. This
> rdfs:comment can then be *supplemented by annotation properties* in the
> two respective namespaces of SOSA and SSN new. These annotation properties
> can add examples, refer to classes and properties in the respective
> namespace using capital letters and describe the stronger semantics as
> required by *SSN new*.
>
>
>
> *If there is no objection from the group, I have volunteered to start with
> such an abstract description for the rdfs:comments in the mapping table. *I
> cannot guarantee to finish by our meeting next week, but I will attempt to
> at least finish some of those.
>
>
>
> Beyond that, the agreement with Kerry was that we continue (in the phone
> calls) with addressing the issues that have been already identified (by
> her) in the issue tracker in the alignment between SOSA and *SSN new*.
>
>
>
> Kind regards,
>
> Armin
>
>
>
> On 25/1/17, 11:28 pm, "Simon.Cox@csiro.au" <Simon.Cox@csiro.au> wrote:
>
>
>
>     Thanks Phil -
>
>
>
>     Just want to comment on your item 2.
>
>
>
>     SOSA is not 'inspired by O&M' any more than it is by any of the other
> prior work. It was an attempt to define a core with lightweight semantics
> for an audience interested in describing observations, actuation or
> sampling. The hope was that it could also serve as a core for more
> semantically rich vocabularies, along the lines proposed by Jano (aka
> vertical and horizontal modularization). So the scope of SOSA is broad but
> it is axiomatically shallow - deliberately not much more than schema-org
> style. Certainly it picks up some ideas from O&M, in particular the notion
> of Samples, but it also picks up ideas from IoT (Actuators) and SSN
> (Platform, properties of Sensors). SOSA is definitely not something that
> has just come from the O&M camp.
>
>
>
>     Simon
>
>
>
>     -----Original Message-----
>
>     From: Phil Archer [mailto:phila@w3.org]
>
>     Sent: Wednesday, 25 January, 2017 20:41
>
>     To: SDW WG Public List <public-sdw-wg@w3.org>
>
>     Cc: Scott Simmons <ssimmons@opengeospatial.org>; Francois Daoust <
> fd@w3.org>
>
>     Subject: State of SSN
>
>
>
>     Dear all,
>
>
>
>     As team contact for the WG, my role is not necessarily to get involved
> in every aspect of each of our deliverables. As is abundantly clear from
> our discussions over the last couple of years, the WG members are the
> domain experts, not me. But, all is not well in the state of SSN and so I
> feel that I need to take a more active position. My mail on Monday [1] is
> part of that.
>
>
>
>     My understanding of the current situation is likely to be less than
> 100% accurate - I know that - but what I see is:
>
>
>
>     1. There is a lot of prior work that predates the WG: SSN, O&M, Dolce.
>
>
>
>     2. There is SOSA, which is, I think I'm right in saying, largely
> inspired by the work to represent O&M in OWL and create a simple version
> for wider use.
>
>
>
>     3. There is a very understandable desire to see this work become a
> formal standard - that's what we're chartered to do. This entails gathering
> evidence of usage. But the problem is that the evidence that exists is from
> earlier work. What's being done now might be too new and we may not be able
> to gather that implementation evidence. That would be a pity but it's
> better than a bad design driven by process. SSN has a reputation for being
> too complicated so let's not hesitate to simplify it.
>
>
>
>     4. The published document states clearly that SOSA is the core and
> that SSN is an outer ring, with O&M and Dolce Ultra Lite alignments outside
> both.
>
>
>
>     5. There is a debate about whether the alignments, especially with
> O&M, should be normative. In favour: O&M is a formal standard and it feels
> right to me that it should be but I'm open to persuasion either way.
>
>
>
>     6. There is a debate about whether the SOSA-SSN relationship should be
> couched as sub classes/properties or whether one should be an extension of
> the other. That's a legitimate technical argument. Over to you to sort it -
> but as a design principle, please don't have the same property/class names
> in the two namespaces with different semantics (ssn:Platform and
> sosa:Platform, for example). My instinct is to prefer direct usage over sub
> classes but that's a generalist's view.
>
>
>
>     7. There is work going on concerning the SOSA-SSN alignment that is
> being shared piecemeal, issue by issue. That is not right. Put it on the
> wiki or GH, argue about it, edit it in front of everyone. The idea of
> "we'll share it when it's finished" is not the way we should work.
>
>
>
>     8. There is a lot of unhappiness in the SSN group at the moment, which
> is unfortunate and needs to be fixed before everyone walks away.
>
>
>
>     9. If the group so wishes, we can easily arrange a one off long telco.
>
>
>
>     Phil.
>
>
>
>
>
>     [1]
> https://lists.w3.org/Archives/Public/public-sdw-wg/2017Jan/0096.html
>
>
>
>     --
>
>
>
>
>
>     Phil Archer
>
>     Data Strategist, W3C
>
>     http://www.w3.org/
>
>
>
>     http://philarcher.org
>
>     +44 (0)7887 767755 <+44%207887%20767755>
>
>     @philarcher1
>
>
>
>
>
Received on Thursday, 26 January 2017 01:09:12 UTC

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