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 22:23:25 -0800
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>
Message-ID: <fb452dd1-03b8-a997-8b4d-4015b9a097e9@ucsb.edu>
Yes, agreed. My point was that we can often be way more specific without 
running into problems in terms of different semantics between SOSA and SSN.

On 01/29/2017 10:05 PM, Armin Haller wrote:
>
> The Proposal was not to have something that represents  “everything 
> that goes” but a comment that is shared between SSN new and SOSA 
> without referencing classes/properties that may exist only in the one 
> or the other (because of simplification of property chains). Then each 
> ontology, SOSA and SSN new add a second annotation and/or examples 
> that illustrate the use of that concept/property in its context (i.e. 
> SSN new and SOSA).
>
> I had a quick go at an abstraction of the shared classes between SOSA 
> and SSN on the wiki (in the ‘Generic’ column), 
> https://www.w3.org/2015/spatial/wiki/Mapping_Table to illustrate what 
> I mean.
>
> *From: *Krzysztof Janowicz <janowicz@ucsb.edu>
> *Reply-To: *"janowicz@ucsb.edu" <janowicz@ucsb.edu>
> *Date: *Monday, 30 January 2017 at 12:44 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
>
> 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>
>     <mailto:janowicz@ucsb.edu>
>     *Reply-To: *"janowicz@ucsb.edu" <mailto:janowicz@ucsb.edu>
>     <janowicz@ucsb.edu> <mailto:janowicz@ucsb.edu>
>     *Date: *Thursday, 26 January 2017 at 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> <Simon.Cox@csiro.au>
>     <mailto:Simon.Cox@csiro.au>, "phila@w3.org" <mailto:phila@w3.org>
>     <phila@w3.org> <mailto:phila@w3.org>, "public-sdw-wg@w3.org"
>     <mailto:public-sdw-wg@w3.org> <public-sdw-wg@w3.org>
>     <mailto:public-sdw-wg@w3.org>
>     *Cc: *"ssimmons@opengeospatial.org"
>     <mailto:ssimmons@opengeospatial.org> <ssimmons@opengeospatial.org>
>     <mailto:ssimmons@opengeospatial.org>, "fd@w3.org"
>     <mailto:fd@w3.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 <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 06:24:17 UTC

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