Re: State of SSN

Hey Armin,


> Let’s try to get this over the line!

Yes! :-)

> I disagree that abstract comments would hurt SSN or SOSA as they are 
> an additional rdfs:comment that is shared between the two. Additional 
> documentation can never hurt. For example, an abstract rdfs:comment 
> for the platform class could be:
>
> “A platform is an entity that carries other entities, in particular 
> sensors, actuators or other platforms.”

I may have phrased this in an unfortunate way. What I meant is that we 
need to make sure the comments provide enough detail to be 
understandable and clear even without a lot of supporting axioms. I.e., 
something that carries something seems way to broad to me as this makes 
my dog a platform while he is carrying his bone. I always thought that 
the rather short descriptions we used in SSN were a problem. On top of 
that SOSA provides a very, very lightweight axiomatization so if we are 
not clear and restrictive enough, we will end up in an interoperability 
nightmare for users of SOSA/SSN.

Here is one potential proposal, simply to highlight what I mean:

> “A platform is an entity that carries other entities, in particular 
> sensors, actuators or other platforms.”

Instead, what about the following compromise:

"A platform is an entity that carries other entities. Platforms can be 
mobile (e.g., satellites) or stationary (e.g., buoys). The carried 
entities are typically sensors, actuators, sampling devices, or other 
platforms. Platforms themselves are usually physical objects, including 
devices and animated agents.  In case of virtual sensors, a platform can 
be a computing system which hosts software implementations or a 
simulated, i.e., virtual, entities themselves. Platforms have a local 
coordinate reference frame which can be put in relation to an external 
reference frame, e.g., to specify the location of a particular sensor on 
the platform as well as on the surface of the Earth."

Again, this is just an example (and we can remove the examples). My 
point here is that we should be specific wrt what we mean instead of 
opting for an 'everything goes'.  Clearly, the second will be easier to 
achieve but will risk ending up as an empty compromise by moving the 
problems of interpretation and interoperability away from us to the end 
users.

Btw, the definition above is a mix of (old) SSN, SOSA, and SensorML.

Cheers,
Jano



On 01/26/2017 06:15 PM, Armin Haller wrote:
>
> Hi Jano,
>
> Yes, Option 3 would contradict our own figure. I was just afraid that 
> this will be the only thing we can achieve. However, as mentioned, 
> Kerry was in favour of Option 2 too. Let’s try to get this over the line!
>
> I disagree that abstract comments would hurt SSN or SOSA as they are 
> an additional rdfs:comment that is shared between the two. Additional 
> documentation can never hurt. For example, an abstract rdfs:comment 
> for the platform class could be:
>
> “A platform is an entity that carries other entities, in particular 
> sensors, actuators or other platforms.”
>
> Noting we do not have a decision on Sampling Devices in the core yet 
> (https://www.w3.org/2015/spatial/track/issues/92). There should still 
> be more specific comments for either of the two using additional 
> annotation properties (that also reference the classes/properties to 
> use in its context), similar to what Simon has already done in SOSA 
> with splitting out the examples.
>
> I have offered to do that in a first go since we are trying to align 
> the comments already since Mid of November last year when the table 
> was first presented in the teleconference, with no progress so far. It 
> is not that I am a stickler for writing rdfs:comments, but by trying 
> to find a common denominator between the two current rdfs:comments 
> that can then be extended I am hoping to progress faster on resolving 
> several of the issues on the tracker. And I am doing that exactly to 
> speed up the process. I proposed to do it on the wiki, so everyone can 
> do it. If you or others jump in and help, please do so!
>
> Cheers,
>
> Armin
>
> *From: *Krzysztof Janowicz <janowicz@ucsb.edu>
> *Reply-To: *"janowicz@ucsb.edu" <janowicz@ucsb.edu>
> *Date: *Thursday, 26 January 2017 at 2:09 pm
> *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>
> *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