Re: State of SSN

Kerry,
i'm not sure I can comprehend the objection regarding there being new
namespace(s)  in the light of with what you wrote on the 2nd Jan:

"Note that http://w3c.github.io/sdw/ssn/ has been unchanged since 21
December, but there are two further changes decided in the meeting of
2016/12/20 that are yet to be pulled but are intended to be included, that
is,

   - Change backward compatibility ontology name ssn-bc to ssn-ssnxg and
   move to a w3c dated namespace
   - Add a "namespace" paragraph in SOSA section, declaring
   http://www.w3.org/ns/sosa/"


Maybe I have misunderstood one or the other, but perhaps I wont be the only
one in that boat.  Can you elucidate a counter proposal using concrete
examples?

its possible to do everything in a single namespace, and use named graphs
to partition the - but we seem to hit counter-intuitive behaviours of
tools. Arguably a SSN ontology doesnt need a namespace - its defining
behaviours on entities in the SOSA namespace.  What seems to be the issue
for you is whether SOSA reflects SSN requirements - and there seems to be a
conflict between compatibility with the original SSN and the broader domain
requirements?


Rob

On Mon, 30 Jan 2017 at 18:07 Kerry Taylor <kerry.taylor@anu.edu.au> wrote:

Actually there have been  several  emails on the list that disagree with
this  statement (as presented in earlier times) And a presentation at an
SSN meeting  on this topic too.

Ø  1) Regardless of what we call it there will be a new namespace



Those opinions have been  ignored and deserve listening to.



The “legacy SSN" case” is not an issue provided  the core is designed
appropriately.  If there eis an “issue” it purely arises from the current
core being designed independently of the ssn of which it is the core.
Fixing this requires adjustment to both legacy ssn and the current version
of the core.





Personally – I am unconvinced that multiple namespace have any purpose.
Therefore , if there is no purpose, one namespace should be used.



> ) Where SSN needs to create specialisations it can subclass as required,
in a new namespace - which can resolve to the SSN-2 graph



I am in violent disagreement with this statement., as I have said many
times previously. Sorry to bore the list.





Ø  We also changed a few other axioms, e.g., on SubSystems.



I missed that entirely. When? Where?



--Kerry







*From:* Krzysztof Janowicz [mailto:janowicz@ucsb.edu]
*Sent:* Monday, 30 January 2017 5:29 PM
*To:* Rob Atkinson <rob@metalinkage.com.au>; Kerry Taylor <
kerry.taylor@anu.edu.au>; Armin Haller <armin.haller@anu.edu.au>;
Simon.Cox@csiro.au; phila@w3.org; public-sdw-wg@w3.org


*Cc:* ssimmons@opengeospatial.org; fd@w3.org
*Subject:* Re: State of SSN



Hi Rob,


1) Regardless of what we call it there will be a new namespace

2) SOSA contains the broad, inclusive, definitions for things we care about
- i.e. it will be what lives behind that namespace URL and require no
specific reasoning on the client side ("lightweight" to use)

3) SSN-2 can import and reference these SOSA entities and add additonal
axioms (in a flavour of OWL with a specific expressivity which we should
document the intent). (richer semantics but more demanding to use)

4) Where SSN needs to create specialisations it can subclass as required,
in a new namespace - which can resolve to the SSN-2 graph

5) informative "Alignments" help others use and understand - but dont
affect SOSA or SSN semantics - alignments with DUL and iso-19150 flavour
O&M


Yes, great summary, this is very much what I believe we wanted to do since
a long time. I think/hope we are all in violent agreement here :-).


All this is pretty straightforward IMHO until we hit the "legacy SSN" case


Oh yes...


My naive understanding is if we publish an alignment using strong axioms
(equivalence or subclass?) then we are able to use original SSN deployments
as evidence of implementation ... of the subset of semantics  - but we'd
still need IMHO to demonstrate the broader sense and any new concepts. So
its not trivial and we'd need a plan anyway - maybe its easier just to get
someone to upgrade their legacy SSN to the new SOSA scope and namespace and
show the broader definitions are usable directly.


I think we need new implementation evidence anyway due to the new
namespace.  We cannot have equivalence classes between most old SSN and new
SSN classes as the new classes lack DUL and so forth. We also changed a few
other axioms, e.g., on SubSystems. I agree that this is the part that will
need further strategizing and there will be no perfect solution.

Cheers,
Jano

On 01/29/2017 04:59 PM, Rob Atkinson wrote:



I think Kerry is correct to say we need to get on the same page with the
"architecture" - and until we do that its hard to actually understand
everybody's positions. Perhaps we focus on what that architecture means for
users and the process?



Here's my understanding of that architecture:



1) Regardless of what we call it there will be a new namespace

2) SOSA contains the broad, inclusive, definitions for things we care about
- i.e. it will be what lives behind that namespace URL and require no
specific reasoning on the client side ("lightweight" to use)

3) SSN-2 can import and reference these SOSA entities and add additonal
axioms (in a flavour of OWL with a specific expressivity which we should
document the intent). (richer semantics but more demanding to use)

4) Where SSN needs to create specialisations it can subclass as required,
in a new namespace - which can resolve to the SSN-2 graph

5) informative "Alignments" help others use and understand - but dont
affect SOSA or SSN semantics - alignments with DUL and iso-19150 flavour
O&M



All this is pretty straightforward IMHO until we hit the "legacy SSN" case



My naive understanding is if we publish an alignment using strong axioms
(equivalence or subclass?) then we are able to use original SSN deployments
as evidence of implementation ... of the subset of semantics  - but we'd
still need IMHO to demonstrate the broader sense and any new concepts. So
its not trivial and we'd need a plan anyway - maybe its easier just to get
someone to upgrade their legacy SSN to the new SOSA scope and namespace and
show the broader definitions are usable directly.



Rob







On Mon, 30 Jan 2017 at 10:53 Kerry Taylor <kerry.taylor@anu.edu.au> wrote:

*>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.



This is close, but not an accurate representation of my position. Please
see the multiply-posted comments under the topic of  issue-88 , including
but by no means limited to :
https://lists.w3.org/Archives/Public/public-sdw-wg/2017Jan/0099.html



I will endeavour to write it up again on the wiki --- with a worked example
if I can for the next  ssn meeting, although I  cannot promise to complete
in time.



I would like to add that I don’t see how these things can be solved term by
term  or comment-by-comment as is currently proposed by the Chair.  The
architecture of modularisation has been questioned for a **very** long time
 (and there are multiple unresolved issues on the tracker on this topic
e.g. issue-37, issue-115, issue-120, issue-139) yet has failed to be fully
articulated ---- so it seems we all  have, unsurprisingly, different
interpretations of the intention. The fact that sosa , as the “core” module
of ssn, was developed quite independently of ssn and with apparent
disregard of these modularisation/architecture questions is rather
unfortunate --- but nothing that can not  be fixed.





And, for the record, I do not accept that that any alignment between ssn or
sosa is either useful or necessary.  It is frankly absurd that an ontology
needs to be  ”aligned” with it’s own core! The alignment  proposed in the
past week is also highly faulty – I need to put this opinion on  the record
 only because I am  wary of  being told  again that “we all agreed” with
something that has  simply been posted to github  by surprise.  However,
because I believe it is neither useful nor necessary I will not go into
details of the faults here.



--Kerry





*From:* Krzysztof Janowicz [mailto:janowicz@ucsb.edu]
*Sent:* Thursday, 26 January 2017 2:09 PM
*To:* Armin Haller <armin.haller@anu.edu.au>; Simon.Cox@csiro.au;
phila@w3.org; public-sdw-wg@w3.org
*Cc:* ssimmons@opengeospatial.org; fd@w3.org


*Subject:* Re: State of SSN



Hi All,



Thanks Armin for the nice summary!

Please note however that option 3 would contradict our own figures and
draft as pointed out by Phil and this figure (and text) has been around for
a year now.

Options 1 and 2 are what we need and as SSN imports SOSA anyway, 2 may be
easier solution.

Wrt to the comments, I agree with the idea in general (and proposed it
myself before) but think we need to be very, very careful here. *Abstract*
comments are almost never a good idea and may actually hurt SOSA *and* SSN.
Again, just to be clear about this, ideally we would have the same comment
but this comment has to be on a level that is directly understandable and
usable, i.e., not too abstract.

Frankly speaking, I am not so happy with having them reworked all at a time
by a single person and then presented. Why don't we use the next 2-3
telco's to do this together class by class  as a group so that we do not
have to re-discuss them afterwards over and over again to find a
compromise. We are really running late by now :-)

Cheers and thanks again!
Jano

P.s. Let us also please switch back to a mode where everybody participates
regularly and does not merely jump in a few times per year to revisit
decisions taken months ago, and let us also all work in a constructive and
supportive atmosphere. We have a great and impactful product and we are all
interested in getting it in the best possible shape.



On 01/25/2017 03:36 PM, Armin Haller 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>
<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 <phila@w3.org>]

    Sent: Wednesday, 25 January, 2017 20:41

    To: SDW WG Public List <public-sdw-wg@w3.org> <public-sdw-wg@w3.org>

    Cc: Scott Simmons <ssimmons@opengeospatial.org>
<ssimmons@opengeospatial.org>; Francois Daoust <fd@w3.org> <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









-- 

Krzysztof Janowicz



Geography Department, University of California, Santa Barbara

4830 Ellison Hall, Santa Barbara, CA 93106-4060



Email: jano@geog.ucsb.edu

Webpage: http://geog.ucsb.edu/~jano/

Semantic Web Journal: http://www.semantic-web-journal.net





-- 

Krzysztof Janowicz



Geography Department, University of California, Santa Barbara

4830 Ellison Hall, Santa Barbara, CA 93106-4060



Email: jano@geog.ucsb.edu

Webpage: http://geog.ucsb.edu/~jano/

Semantic Web Journal: http://www.semantic-web-journal.net