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

Re: State of SSN

From: Krzysztof Janowicz <janowicz@ucsb.edu>
Date: Sun, 29 Jan 2017 18:55:03 -0800
To: Simon.Cox@csiro.au, kerry.taylor@anu.edu.au, armin.haller@anu.edu.au, phila@w3.org, public-sdw-wg@w3.org
Cc: ssimmons@opengeospatial.org, fd@w3.org
Message-ID: <d099d48b-2e62-48b6-e5a6-66c8e78c4afa@ucsb.edu>
> 1.from last week’s email my impression was that a consensus was 
> emerging that ssn would import sosa and then either add axioms to the 
> sosa classes, or sub-class them. That isn’t alignment, its just 
> ontology engineering. 

Yes, and just as a reminder, this has been part of our draft, wikipages, 
figures, and discussions for like 8-9 months now.


On 01/29/2017 06:14 PM, Simon.Cox@csiro.au wrote:
>
> Ø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!
>
> Thanks Kerry –
>
> I agree – ‘alignment’ of ssn and sosa is missing the point. I was 
> under the impression that, if sosa is the core, then ssn would build 
> on it by adding formal axioms to sosa (which is axiomatically very 
> weak, by design).
>
> Now there are a couple of ways to do this.
>
> 1.from last week’s email my impression was that a consensus was 
> emerging that ssn would import sosa and then either add axioms to the 
> sosa classes, or sub-class them. That isn’t alignment, its just 
> ontology engineering.
>
> 2.OTOH – if classes that have been defined in SOSA have exact 
> equivalents in SSN, and these are not replaced by the SOSA classes, 
> then we are in alignment territory. As you say, that is really 
> unnecessary.
>
> I pushed some thoughts along the lines of option 1. into the GitHub 
> this morning and requested a review.
>
> See https://github.com/w3c/sdw/pull/517 
> <https://github.com/w3c/sdw/pull/517>
>
> The specific places where a ssn class could be replaced by sosa 
> classes have merely been annotated with skos:editorialNote so far.
>
> However, in a few places where sub-classing appeared to be required, I 
> did add those axioms.
>
> Simon
>
> *From:*Kerry Taylor [mailto:kerry.taylor@anu.edu.au]
> *Sent:* Monday, 30 January, 2017 10:53
> *To:* janowicz@ucsb.edu; Armin Haller <armin.haller@anu.edu.au>; Cox, 
> Simon (L&W, Clayton) <Simon.Cox@csiro.au>; phila@w3.org; 
> public-sdw-wg@w3.org
> *Cc:* ssimmons@opengeospatial.org; fd@w3.org
> *Subject:* RE: State of SSN
>
> _>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 
> <mailto:armin.haller@anu.edu.au>>; Simon.Cox@csiro.au 
> <mailto:Simon.Cox@csiro.au>; phila@w3.org <mailto:phila@w3.org>; 
> public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org>
> *Cc:* ssimmons@opengeospatial.org 
> <mailto:ssimmons@opengeospatial.org>; fd@w3.org <mailto: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)
>     <https://www.w3.org/2015/spatial/wiki/Mapping_Table%29> 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"
>     <mailto:Simon.Cox@csiro.au> <Simon.Cox@csiro.au>
>     <mailto: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>
>     <mailto:public-sdw-wg@w3.org>
>
>         Cc: Scott Simmons <ssimmons@opengeospatial.org>
>     <mailto:ssimmons@opengeospatial.org>; Francois Daoust <fd@w3.org>
>     <mailto: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
>
>         @philarcher1
>
> -- 
> Krzysztof Janowicz
> Geography Department, University of California, Santa Barbara
> 4830 Ellison Hall, Santa Barbara, CA 93106-4060
> Email:jano@geog.ucsb.edu <mailto:jano@geog.ucsb.edu>
> Webpage:http://geog.ucsb.edu/~jano/ <http://geog.ucsb.edu/%7Ejano/>
> 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
Received on Monday, 30 January 2017 02:55:47 UTC

This archive was generated by hypermail 2.3.1 : Monday, 30 January 2017 02:55:48 UTC