RE: State of SSN: comment on namespaces and urls

➢ The below does suggest to me that you want two separate IRIs and two separate ontology files, exactly the two votes we tried to resolve today where you objected.

I have to keep saying this, I am sorry. Again, the relationship of ssn to sosa needs to be well designed and modular. There are some ways this might go that means I can not accept 2  separate IRIS and 2 separate files. For example (and this is only an example) where we have ssn imports sosa and the name spaces are different and ssn:Sensor  rdfs:sublcass sosa:Sensor.  This does not simplify ssn for anyone and would be frankly an embarrassment despite being an option on the table.  

Better than that would be an option (which I also do not like) that looks like we currently have on our spec. Two completely independent ontologies that are inconsistent but at least are in both separate namespaces and separate files so you can use one or use the other and ne’er the twain shall meet. (perhaps they meet only in an explanation in the spec?)  In this case I would totally support separate namespaces and separate ontologies. It would be failure, but not completely  unacceptable.

➢ The example you give with PROV is the content negotiation that is implemented on the W3C servers for 303 redirects. I

I know that. What I was trying to point out is that a “namespace document” can reside at  a namespace uri.   This meets all the rules about resolvable uris for a term.  - right? The rules do not require that a single uniform ontology file resides at a single namespace  uri – right?  And in prov the normative url  (and I mean url) is not the namespace.  I believe (but cannot be certain) that this is quite ok in the W3C. 


> I don’t understand what you mean with same namespace prefix? The namespace prefix in SSN for SOSA can be anything, as long as it points to the IRI of the SOSA ontology and is different to the prefix for SSN. Technically they can’t be the same, otherwise it is not a valid RDF/XML or Turtle document.

And I don’t understand this. What is a “namespace prefix in SSN for SOSA”?   Are you confusing an ontology iri with a namespace prefix?  This has been teased out several times before, but  none of us are keeping up...

Perhaps I can repeat  what I said with expansion for clarity :

For our case this might mean:
-one  namespace  (say http://www.w3.org/ns/ssn/ )– which  resolves to a namespace document that explains  in text and links to urls for  both extended ssn ontology and simple sosa  ontology.
- Two  ontology files at  2 different urls (say http://www.w3.org/ssn-extended and  http://www.w3.org/ssn-sosa  or something entirely different)  that  correspond to two different ontology uris  (say   http://www.w3.org/ssn-extended   and http://www.w3.org/ssn-sosa  or whatever we chose on the previous parentheses) so that each uri resolves to an ontology (one simple, one complex). 


> Maxime’s proposal allowed for the resolving of ontology IRIs on the Web through HTTP header Content-Disposition to provide users with the latest version of the specific ontology file in the serialisation of choice, if I understood him correctly. It just allows us to serve TTL or RDF/XML files when we make the 303 as done in the case of PROV.

I don't think so . I don't claim expertise, I am just listening. This would be inconsistent with  my understanding of what Maxime said  to me at the Lisbon meeting. And  I did revist the presentation minutes  to check this (which I copied in to an earlier email on this topic to make this easy for others), but as I said I could not follow at the time and the minutes are not stunningly detailed. And my interpretation  expressed here is the same  as reported  by Josh in the past 24 hours or so on the list (as I understand it https://lists.w3.org/Archives/Public/public-sdw-wg/2017Jan/0193.html). And I suspect (only suspect ,I do not pretend to speak for him) it  also underlies Raphael's  constant questions and vote on this  matter on the list.

I *think* Maxime's presentation was more than that -- a proposal for modularity that enabled modules to be separable while sharing a common namespace.

Can I propose we invite Maxime back to a meeting?

-Kerry

------------- 






From: Armin Haller 
Sent: Wednesday, 1 February 2017 2:59 PM
To: Kerry Taylor <kerry.taylor@anu.edu.au>; Rob Atkinson <rob@metalinkage.com.au>; janowicz@ucsb.edu; Simon.Cox@csiro.au; phila@w3.org; public-sdw-wg@w3.org; Joshua Lieberman <jlieberman@tumblingwalls.com>
Cc: ssimmons@opengeospatial.org; fd@w3.org
Subject: Re: State of SSN: comment on namespaces and urls

The below does suggest to me that you want two separate IRIs and two separate ontology files, exactly the two votes we tried to resolve today where you objected.

I don’t understand what you mean with same namespace prefix? The namespace prefix in SSN for SOSA can be anything, as long as it points to the IRI of the SOSA ontology and is different to the prefix for SSN. Technically they can’t be the same, otherwise it is not a valid RDF/XML or Turtle document.

The example you give with PROV is the content negotiation that is implemented on the W3C servers for 303 redirects. If you request application/rdf+xml from https://www.w3.org/ns/prov# or https://www.w3.org/ns/prov you will get the RDF/XML representation of the ontology (you can try “wget --header='Accept: application/rdf+xml' https://www.w3.org/ns/prov#”) otherwise in your browser when you use the same URL you get an HTML document explaining the ontology, as you are requesting application/html.

Maxime’s proposal allowed for the resolving of ontology IRIs on the Web through HTTP header Content-Disposition to provide users with the latest version of the specific ontology file in the serialisation of choice, if I understood him correctly. It just allows us to serve TTL or RDF/XML files when we make the 303 as done in the case of PROV. It does not give us a way to use the same namespace for SOSA and SSN and then let the web server do the magic in figuring out which ontology file should be served. If we use the same namespace we will violate Linked Data principles, because the only thing we can then serve at the Ontology URL that corresponds to the namespace URI is a document explaining that there are two ontologies with two different semantics. We cannot serve the actual ontology, because we don’t know which of the two ontology files. I stand corrected if someone solved this with some named graph magic that is included in the HTTP header and is supported by Web servers.

From: Kerry Taylor <kerry.taylor@anu.edu.au>
Date: Wednesday, 1 February 2017 at 1:11 pm
To: Rob Atkinson <rob@metalinkage.com.au>, Armin Haller <armin.haller@anu.edu.au>, "janowicz@ucsb.edu" <janowicz@ucsb.edu>, "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, "phila@w3.org" <phila@w3.org>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>, Joshua Lieberman <jlieberman@tumblingwalls.com>
Cc: "ssimmons@opengeospatial.org" <ssimmons@opengeospatial.org>, "fd@w3.org" <fd@w3.org>
Subject: RE: State of SSN: comment on namespaces and urls

Hi Rob and all,
Not sure I follow this, from you,  but I think that Maxime’s proposal  last September(?) had  a design for modularity where terms in modules (that were separate ontology urls but I don’t know whether  they were also ontology uris)   in a shared a namespace , ie all had the same namespace prefix. As I mentioned, I got technically  stuck in that conf call and could not follow at the time. 
 
And I think I can see that Josh seems to have heard that the same way (separate recent email from josh – apologies to josh if I have misunderstood).
 
 
➢ to me, it feels a bit strange to have the namespace IRI not resolve to a complete list of entities defined in that namespace
 
Yes….
 
I believe the W3C often has no ontology sitting at a namespace uri, but instead a list of entities in the namespace and some documentation. Can Francois comment?
 
So could we have a common  namespace iri that points to such a document and use it to locate  (human readable) where those entities are used in ontologies.
Here is an example I just found:  namespace: https://www.w3.org/ns/prov#  or use this https://www.w3.org/ns/prov (which is not actually the namespace but I put here to show it is also possible). Note that for prov the ontology url is here http://www.w3.org/ns/prov-o and the ontology iri  is http://www.w3.org/ns/prov# (same as namespace on this case, but not necessary I think) while the terms are annotated by rdfs:isDefinedBy http://www.w3.org/ns/prov-o# (i.e indexes into ontology not namespace).  To complicate matters it seems that prov also has a  (slightly different from standard) version of ontology also retrievable from the namespace uri.
 
I am not sure whether Maxime’s proposal included  the namespace document  part – but isn’t this  useful?
 
For our case this might mean
-one  namespace  (ssn) – which  resolves to a namespace document that explans  in text and links to urls for  both sosa and complex ssn
- Two  ontology files at  2 different urls that  correspond to two different ontology uris so that each uri resolves to an ontology (one simple, one complex)
 
Using one namespace we have the interesting situation where the ontology you import determines your view of a namespace... How do we feel about that?  
 
I don’t think a namespace  determines an ontology – although an ontology does quite specifically reference a namespace for each term. In any case we are very deliberately looking for “views” here so a solution that supports  simultaneously the simple sosa view and the complex ssn view (just choose your ontology) seems to be a Good Thing.  Your “view” is then defined by the uri of the ontology you choose. Personally, however, I insist that the views are coherent. That is, to the extent that our “simple” view is constrained in what it can say, it is perfectly  consistent with the “complex ” view and vice versa.
 
Works for me – is there a technical objection that stupid tools will see a term and then load complex ssn from the namespace  when only simple sosa is  wanted?  That can be defeated by having No ontology (only an html doc) at the namespace url, I think. So such stupid tools get nothing. Not-so-stupid tools get the view they want by the ontology they actually name (e.g. by importing).
 
I really wish I had been there properly for Maxime’s presentation. 
 
-Kerry
 
 
 
From: Rob Atkinson [mailto:rob@metalinkage.com.au] 
Sent: Tuesday, 31 January 2017 2:15 PM
To: Armin Haller <armin.haller@anu.edu.au>; Kerry Taylor <kerry.taylor@anu.edu.au>; Rob Atkinson <rob@metalinkage.com.au>; janowicz@ucsb.edu; Simon.Cox@csiro.au; phila@w3.org; public-sdw-wg@w3.org
Cc: ssimmons@opengeospatial.org; fd@w3.org
Subject: Re: State of SSN
 
 
I was using "named graph" to be "ontology IRI" without assuming that the ontology IRI was a namespace (i.e. used as the root of entity IRIs)
 
I think it all boils down to whether terms defined in SSN (either additional terms or subclasses) are defined using the SSN ontology IRI or the SOSA namespace IRI. 
 
to me, it feels a bit strange to have the namespace IRI not resolve to a complete list of entities defined in that namespace - but there is nothing forcing this, so i'd +0 vote for additional SSN entities to be in a new SSN namespace, and then force sharing the SSN ontology and SSN namespace IRIs. This is what tools that try to import using the namespace would default to, but AFAICT there is nothing forcing us to do this, and we can use the same namespace.
 
Using one namespace we have the interesting situation where the ontology you import determines your view of a namespace... How do we feel about that?  
 
Rob
 
 
On Tue, 31 Jan 2017 at 13:10 Armin Haller <armin.haller@anu.edu.au> wrote:
Is there someone arguing for different namespaces willing to put the pro argument out there in public, please?
 
Assumption for the response below: Ontology Namespace = URI
 
Situation:
We have the core, SOSA with weak semantics, serialised in either TTL, RDF/XML etc.
We have SSN new, with stronger semantics, “narrowing” the meaning of classes/properties in the core using OWL, serialised in either TTL, RDF/XML etc.
We use Slash URIs
 
Option 1:
We have two URIs
http://www.w3.org/ns/sosa/ for the core, SOSA
http://www.w3.org/ns/ssn/ for SSN new
If you resolve http://www.w3.org/ns/sosa/ you get the serialisation of your choice based on the application type you are requesting of the SOSA ontology (303 redirect)
If you resolve http://www.w3.org/ns/ssn/ you get the serialisation of your choice based on the application type you are requesting of the SSN ontology (303 redirect)
 
Option 2:
We have one URI for the SSN new and SOSA
e.g., http://www.w3.org/ns/ssn/

If you resolve http://www.w3.org/ns/ssn/ you will get the serialisation of your choice based on the application type you are requesting of the combined SOSA and SSN new ontology, i.e. meaning you will always fall into the stronger semantics used by SSN new. For example, if you would resolve http://www.w3.org/ns/ssn/Sensor you would get the full axiomatization of the Sensor class defined by SSN. You can use named graphs, but I don’t know of any way in your HTTP request to address a named graph in an ontology file. There is a SPARQL protocol implementation proposal (https://www.w3.org/TR/2009/WD-sparql11-http-rdf-update-20091022/), but I do not know Web servers implementing it. Please anyone correct me if there is a way in Apache or other web servers the W3C can use to do that.
 
Since Option 2 has the caveat that a user would always get as response the SSN new ontology in its full semantic beauty, even if only weak semantics of SOSA were requested the group has opted for two Slash URI namespaces as in our WD.
 
From: Kerry Taylor <kerry.taylor@anu.edu.au>
Date: Tuesday, 31 January 2017 at 12:20 pm
To: Rob Atkinson <rob@metalinkage.com.au>, "janowicz@ucsb.edu" <janowicz@ucsb.edu>, 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
 
Rob,
>Only if the formal axioms for the SSN concept are reasonably identical to the informal ones for the SOSA concept should we reuse the SOSA concept directly."
 
And that is exactly what we should be doing. We can make it so. There is nothing preventing us from making it so!
 
>“hopefully (and my understanding of the process) SOSA is identical to SSN semantics except where some limitation or extended scope has been identified, in which case the original SSN concept should be a subclass of the SOSA term.  
 
I would go a step further ---  “except where some limitation or extended scope has been identified”. 
If such a  limitation or extended scope is identified  (and I don’t think  any such has been aired at all yet, with the possible exception of platform issue-88),  then this is solvable too without resorting to mindless subclassing. I hope my worked example for platform  demonstrates  that. Judicious changes to old ssn to adjust to scope requirements (especially when driven by our  use cases) is perfectly appropriate in this standards phase. Arbitrary changes to ssn *just because,*  are a bad idea, though. There is no reason at all to believe that SOSA as currently on github is the SOSA that we are forced to accept, either. Indeed our evaluation of our new SOSA badly needs an architectural/modularity framework in which to judge it. 
 
Only laziness prevents that happening well. How could we even consider, as I understand the alternative architecture relying on alignments has,
to publish something anywhere that requires  ssn:Sensor rdfs:subClassOf sosa:Sensor  ?
 
Your 1-5 summary is helpful.  I would add to that
6) Terms of the same intended meaning with different names
7) Poorer documentation – counterpart in case your (1) does not cover both cases which  both exist
 
>So, if all is good, SSN-2 just uses SOSA namespace and entities and is just a graph holding axioms that support a specific logic, and gives the user the power (and requirement) to perform additional reasoning.  As Jano says, SOSA users  may not comply with the SSN axioms, but probably ought to as they are probably formalisms of the wordy definitions in SOSA.  If we have no subclassing in SSN, or broadening of semantics, and only "extend" the expressivity - then SSN could be a semantic validator for SOSA instances perhaps?
 
+1. I like your “semantic validator” idea a lot but noting that (a) I am  personally not certain that the same namespace cannot or should not be used.  This seems to be an unsupported assertion (not entirely unsupported, but almost ). Is there someone arguing for different namespaces willing to put the pro argument out there in public, please? (b) SSN will also add new terms that are not even present in SOSA, but I suspect that is what you mean anyway.
 
>This still gives SOSA and SSN different functional roles, but common semantics - and that makes a lot of sense as a rationale to me. i think this is what Kerry is getting at - but as always we humans have imperfect communication :-)
 
Thank you for making the effort!
 
Kerry
 
 
 
 
From: Rob Atkinson [mailto:rob@metalinkage.com.au] 
Sent: Tuesday, 31 January 2017 8:17 AM
To: janowicz@ucsb.edu; Kerry Taylor <kerry.taylor@anu.edu.au>; Rob Atkinson <rob@metalinkage.com.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
 
As Josh puts it "wrt the specific relationship between similar concepts in SOSA and SSN, if the set of individuals for the SSN concept is smaller than that for the SOSA concept (the usual effect of restrictions) then the SSN concept should be a subclass of the SOSA concept. Only if the formal axioms for the SSN concept are reasonably identical to the informal ones for the SOSA concept should we reuse the SOSA concept directly."
 
hopefully (and my understanding of the process) SOSA is identical to SSN semantics except where some limitation or extended scope has been identified, in which case the original SSN concept should be a subclass of the SOSA term.  
 
Summary of what may be different (in entity definition, not including axioms) between SOSA and SSN (on a term by term basis):
1) Improved documentation, but no change in definition
2) Broaden definition from original SSN - but include original in scope
3) New term not in original SSN scope
4) Errata from SSN being addressed (if any)
5) terms from SSN that are deemed to be out of scope for SOSA (I havent seen a case for any such thing)
 
So, if all is good, SSN-2 just uses SOSA namespace and entities and is just a graph holding axioms that support a specific logic, and gives the user the power (and requirement) to perform additional reasoning.  As Jano says, SOSA users  may not comply with the SSN axioms, but probably ought to as they are probably formalisms of the wordy definitions in SOSA.  If we have no subclassing in SSN, or broadening of semantics, and only "extend" the expressivity - then SSN could be a semantic validator for SOSA instances perhaps?
 
This still gives SOSA and SSN different functional roles, but common semantics - and that makes a lot of sense as a rationale to me. i think this is what Kerry is getting at - but as always we humans have imperfect communication :-)
 
Rob
 
 
 
On Tue, 31 Jan 2017 at 03:29 Krzysztof Janowicz <janowicz@ucsb.edu> wrote:
➢  ) Where SSN needs to create specialisations it can subclass as required, in a new namespace - which can resolve to the SSN-2 graph 
 
No. And  this may be the nub. SSN should only ever extend sosa concepts , never subclass.  We should standardise the name and meaning of a core term (by its rdfs:comment) in the core and add deeper axiomatic semantics in extended ssn (acknowledgment to Raul for this).
 
Okay, Kerry, so please show us the OWL axiom by which an SSN concept 'extends' an SOSA concept without subclassing it? :-)



On 01/30/2017 06:35 AM, Kerry Taylor wrote:
Thankyou Rob,
 
I am really grateful that you summarised one possible architecture package. And as far as I can make out it accurately reflects one coherent option being proposed (although it missed perhaps the rdfs’comments part).
 
I would like to comment on these 1 by 1 wrt the architecture I have proposed over emails and have jst now documented on the wiki.
https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN#Compromise_Proposal_6_made_by_Kerry_January_2017

 
 
➢  1) Regardless of what we call it there will be a new namespace 
Not accepted by me and some others.  There might be a new namespace, but this is highly dependent on architecture as I see it.
➢  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)
Agreed (with caveat on “that namespace”)
 
➢  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)
Agreed (with important caveats about how that richer semantics is related  to the sosa entities ). Also, unless we have strong arguments to the contrary, ssn has existed and been widely used for 5+ years (legacy) and we should only change what we need to change – ie for which a good argument is made and agreed. There is no carte blanche for ssn. 
 
➢  ) Where SSN needs to create specialisations it can subclass as required, in a new namespace - which can resolve to the SSN-2 graph
 
No. And  this may be the nub. SSN should only ever extend sosa concepts , never subclass.  We should standardise the name and meaning of a core term (by its rdfs:comment) in the core and add deeper axiomatic semantics in extended ssn (acknowledgment to Raul for this).
 
. 5) informative "Alignments" help others use and understand - but dont affect SOSA or SSN semantics - alignments with DUL and iso-19150 flavour O&M 
 
The alignment with dul has been removed from ssn as you know, but it does affect semantics in that it is implicit in all ssn concepts and, if not, requires bigger changes to ssn than I am willing to make (remember legacy). So it is “otpional” you don’t have to use it but, just as for sosa terms, the descriptions of ssn terms (rdfs:comment) should be consistent with using the dul alignment.
 
As for o&M alignment (repeating myself) I believe we need an alignment with O&M the OGC standard (which, yes is uml, but  we can use the “terms” as defined in the standard – and  old ssn already did that for us anyway!)). I am wary of an iso-19150 flavour alignment because it might suggest that we think it should or even could be used, and I don’t think we do believe that, following the discussion at the last meeting. FWIW, I don’t believe that based on personal experience.
 
> 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.
 
Phil has advised us to be wary of being driven by the implementation demands. However, as the implementation requirements and goals to serve our legacy users align well , I believe we should be able to use implelementation evidence from the old terms. If we follow the architecture I propose then this *could* carry over to sosa terms as well, I think – but that is my untested theory and is only happenstance.  In any case, as you saty we do need the evidence for any new concepts.
-Kerry
 
From: Rob Atkinson [mailto:rob@metalinkage.com.au] 
Sent: Monday, 30 January 2017 11:59 AM
To: Kerry Taylor <kerry.taylor@anu.edu.au>; janowicz@ucsb.edu; 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
 
 
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 new 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> 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>
    Cc: Scott Simmons <ssimmons@opengeospatial.org>; Francois Daoust <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
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

Received on Wednesday, 1 February 2017 06:10:00 UTC