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

Re: State of SSN

From: Krzysztof Janowicz <janowicz@ucsb.edu>
Date: Mon, 30 Jan 2017 08:25:04 -0800
To: Armin Haller <armin.haller@anu.edu.au>, Kerry Taylor <kerry.taylor@anu.edu.au>, Rob Atkinson <rob@metalinkage.com.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: <88e81524-c0b2-06f9-d920-e20ee92bbf74@ucsb.edu>
> As discussed and agreed there will be different namespaces for SOSA 
> and SSN 

"there will be" --> "we already have" :-)

The namespace for SSN terms is http://www.w3.org/ns/ssn/
The namespace for SOSA terms is http://www.w3.org/ns/sosa/

See http://w3c.github.io/sdw/ssn and meeting notes from the general SDW 
meeting were we set this namespaces up.

On 01/30/2017 04:10 AM, Armin Haller wrote:
>
> Kerry, I don’t understand your objections here. The proposal you are 
> making on the Wiki almost completely overlaps to what Rob was saying 
> in his email. The only difference is Point 8 in your Wiki proposal. As 
> discussed and agreed there will be different namespaces for SOSA and 
> SSN for all the reasons we discussed F2F last week (i.e. Linked Data 
> principles and tool support) and that have been stated on the mailing 
> list. However, as we discussed last week, SSN can share the SOSA URIs 
> for common classes/properties. If desired, we can also make 
> equivalence relations if a new URI is wanted. However, I understood 
> that your preference was to just reuse the SOSA URI.
>
> The only other difference I can see between your Wiki compromise and 
> Rob’s email below is Rob’s proposal to add subclasss relations, if 
> appropriate. Again, I know that your preference is not to use 
> subclasses and a consensus must be found here (many other people in 
> the working group think that we should use subclass relations), but 
> your point 7 in the Wiki (i.e. Every core ssn instance (ie data) 
> SHOULD be a valid extended SSN instance), which I think is the reason 
> you don’t like sub-classing, will largely not be achievable, unless a 
> user of the SOSA core is acutely aware of the axiomatization in SSN. A 
> naïve user will in many cases produce instances that are not valid SSN 
> instances, and we cannot enforce the opposite, as the semantics of 
> SOSA are deliberately weak.
>
> However, as mentioned, your compromise in the wiki is otherwise 
> completely aligned with Rob’s understanding of the proposed Option 2 
> that I posted to the list after our discussion.
>
> The SubSystem axiom that was changed (and Rob mentioned) was the one 
> with the partOf relation that we left you to decide upon 
> (https://www.w3.org/2015/spatial/track/issues/85)
>
> *From: *Kerry Taylor <kerry.taylor@anu.edu.au>
> *Date: *Monday, 30 January 2017 at 6:07 pm
> *To: *"janowicz@ucsb.edu" <janowicz@ucsb.edu>, Rob Atkinson 
> <rob@metalinkage.com.au>, 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
>
> 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
>     <mailto: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
>         <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) 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://www.w3.org/>
>
>             http://philarcher.org
>
>             +44 (0)7887 767755 <tel:+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 <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 16:25:47 UTC

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