Re: State of SSN and josh's thoughts re modules and namespaces

Hi Kerry,

Just trying to get us all on the same page with what is required, what is possible, what is good practice, and what is just a habit or software default in using rdf/owl. I’ve added responses and clarifications inline below, which I hope are consistent with what I said and wrote in yesterday’s telecon.

> On Jan 31, 2017, at 11:07 PM, Kerry Taylor <kerry.taylor@anu.edu.au> wrote:
> 
> Thank you Josh for a careful analysis and a healthy respect for what a modular design should do.
>  
> If I missed someone-else’s follow up comment to this, I apologise – but I cannot find one- so am not ignoring it intentionally.
>  
> >A best practice consensus here on modularization is finally beginning to take shape. In my mind, that’s almost as important a result as the SSN vocabulary itself, since it can have application to many other modular ontologies. It still seems to be hazy on “namespace”, though, so that needs to cleared up. Namespace, as I understand it, has no functional role in an ontology or vocabulary. It’s a “hack” on the path of identifier URI's and a convenience in the specification of those URL’s. Not fundamental to the uniqueness of URI’s.
>  
> Not sure …. I think I agree, but I am not sure I understand.
> For any term the namespace  part of the term uniquely identifies the term  (because it is a part of the  the uri for the term.)  But I think I agree with you in that a “namespace” is only  important  for its role in a term uri. But it is nevertheless a fundamental part of a uri (I mean a term uri, not an ontology uri here.) AFAIK, there is no such thing as a namespace for an ontology uri  because an ontology is not a term.
>  
> However, apparently some tools  expect to find an ontology at a namespace uri and load it up whenever they encounter a term from that namespace. 
> I am not going to back this  claim up – I have not had this experience- but unfortunately it may be something we cannot ignore in practice.

Three observations here:
There really is nothing essential about a namespace. It’s a shortcut for shortening IRI’s / URI’s / URL’s. They can be useful in making sure that terms are given distinct IRI’s. They are often used to suggest that terms should be grouped together, but there is nothing inherent in RDF / OWL processing that makes use of them except as shortcuts.
Tools such as Protege default in their automatic IRI assignment to using a namespace path as the IRI for an ontology, then adding on the term for, e.g., a class to that path to form term IRI’s. This is not required. As I showed in my examples, Protege is quite happy with whatever unique IRI’s you choose manually and they do not need to follow the automated pattern. Particularly you can choose to give the ontology or ontologies a distinct IRI by adding a term to a defined namespace.
It makes sense to expect to retrieve an ontology document by resolving the IRI of that ontology. It makes little sense to expect a namespace to function the same way, since a namespace is not an IRI for anything in particular unless explicitly assigned as such.
>  
>  
> >Now there is a need for different URI’s for different concepts, specifically ontologies. So if there are distinct SOSA and SSN(-2) ontologies, for example, they need to have distinct URI’s. If a concept itself, such as a class, is different in any way within the SOSA and SSN ontologies respectively, then there should be two distinct URI’s. Our practice also indicates that those differences can be defined informally by annotations, but also formally (in SSN(-2) only) by axioms on the SSN concept. 
>  
> Agreed.  But as long as the term is perfectly consistent  I can’t see any rule why a term cannot occur in 2 ontologies – where it is defined simply in one and extended in another – actually  it happens all the time. Most often I see it , it is rather disapproved of (because it takes some-one else’s term and “changes” it by adding axioms, which is kind-of rude  but in our case we have complete control and there is nothing rude about it at all.) As long as we are perfectly coherent and consistent!
>  
>  
> >My understanding is that “membership” itself in an ontology is indicated not by presence or absence in a particular file, or the use of a particular namespace, but by rdfs:isDefinedBy statements that connect a class concept for example and an ontology concept such as SOSA.
>  
> I am not ignoring this, but I don’t feel sufficiently educated to respond on all of that point. I think whteher or not a term is a “member” of an ontology entirely depends on whether a term occurs in an ontology. And given that an ontology iri uniquely identifies an ontology --- I  suppose the  sentence may be false.
> However, this may be only an OWL view of an ontology – as rdfs “ontologies” don’t have ontology iris… Then there is the view that the whole web is one ontology (think of the owl:sameas debate, where potentially one statement somewhere binds every connected term everywhere) in  one big graph but I certainly do not  advocate view.

If we are to have modules and not one global ontology, then we must have a way of indicating module membership, e.g. "whether a term occurs in an ontology". For OWL, that means indicating what should be evaluated as part of a particular ontology and what not. This can be formal or informal, robust or brittle. Formally, anything with an assigned IRI can be assigned to an ontology with rdfs:definedBy, and one ontology can import another ontology with those same rdfs:definedBy statements. However, restrictions and other axioms do not have assigned IRI's, so neither method works to clearly indicate ontology membership.

Informally, we can imply that any statements in the same file with an ontology declaration should “belong” to that ontology. There is, however, no meaning for a file in RDF/OWL, so if files are refactored or re-organized, the implication is changed. We can also make the assumption that any statements involving IRI’s in a namespace should be considered part of an ontology in that namespace. This can be independent of file organization, but fundamentally ambiguous whenever we have a statement such as a restriction that combines IRI’s from two namespaces (e.g. ssn and sos !).

NOTE: this is a possible argument for separate SOS and SSN concepts (with subclass or equivalentClass relationships as needed). Then formal axioms can be stated that only involve SSN IRI’s and therefore unambiguously “belong" to the SSN ontology. 

>  
> >There seem to be various practices concerning the use of namespaces to act as “hints” for membership and other connections between ontology elements. One approach is to have separate namespaces (remember, only the prefixes for URI’s) for separate collections / ontologies / modules. This certainly emphasizes the separation between such collections, but may obscure the affinities such as “these modules are part of an integrated domain expression”. One could further hack namespace paths to be similar (e.g. differing only in the last term ), but this has no effect on the actual namespace mechanism and requires reading more meaning  into the path than may be advisable.
>  
> >@prefix sosa: <http://www.w3.org/ns/sosa/ <http://www.w3.org/ns/sosa/>> .
> @prefix ssn2: <http://www.w3.org/ns/ssn2/ <http://www.w3.org/ns/ssn2/>> .
> sosa:Ontology  rdf:type owl:Ontology ;
> ssn2:Ontology  rdf:type owl:Ontology ;
>  
> Agreed.
>  
> >The practice that seems to be advocated by Maxime is to have one namespace in which to gather the terms for a set of modular ontologies. Each concept and each ontology module still has unique URI’s, but these are formed using the same prefix indicating the namespace and suggesting informally that the modules belong to some sort of distinct whole. 
>  
> >@prefix sosa-ssn2: <http://www.w3.org/ns/sosa-ssn2/ <http://www.w3.org/ns/sosa-ssn2/>> .
> sosa-ssn2:SosaOntology  rdf:type owl:Ontology ;
> sosa-ssn2:SsnOntology  rdf:type owl:Ontology ;
>  
> I love this. I think you are saying one namespace but multiple ontologies (as indicated by multiple ontology iris, and also multiple files)?
>  
> >It is still possible, I think, to add some informal membership information to the names, but again this is an informal hack on the URI pattern to suggest membership, e.g.
>  
> >@prefix sos-ssn2: <http://www.w3.org/ns/sosa-ssn/ <http://www.w3.org/ns/sosa-ssn/>> .
> sosa-ssn2:sosa/Ontology  rdf:type owl:Ontology ;
> sosa-ssn2:ssn/Ontology  rdf:type owl:Ontology ;
>  
>  
> Sorry, not sure I get this part. And I wonder whether you are assuming that the ontology uri resolves to the ontology file(it should)? But  what happens when you visit the namespace url? I think (see related email  https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0002.html <https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0002.html>)  that you should get a namespace document, but what ontology would you retrieve? I propose none – what do you think?
>  
> >I don’t have a problem with including informal semantics in our namespace practice, but we need to pick a practice, be consistent in applying it, and provide a clear narrative describing what we mean by it.
>  
> >Thoughts? I want to apply this practice as well to both the spatial ontology and hydro ontology that I’m trying get out the door, so settling the issue would have many positive effects.
>  
> >—Josh
>  
> >PS - 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. This will still be a risk of trouble in case that someone does not follow the informal restrictions correctly and someone else then applies the formal ones to the result. In a sense, we would be relying on the informal and formal vocabulary usages not to overlap.
>  
>  
> My take on this is that the more complex ssn axioms indeed do restrict the interpretation wrt the simple core/sosa axioms in a formal sense, but this does not imply that “the SSN concept should be a subclass of the SOSA concept.”.

Yes, it does. The class concept in RDF/OWL is set-theoretic, meaning classes are defined as collections of individuals. If a subset of individuals belong to an SSN class relative to a SOSA class, then that is precisely a subclass relationship.

> Indeed “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” .

Simon and others are asserting that this is generally the case, so it would be appropriate to reuse the sosa concepts. See, however, NOTE: above.

>  
> --warning – strong opinions  and considerable frustration expressed here—
>  
> Without accepting that there are  distinct  “sosa” concepts and “ssn” concepts  and that these are somehow different we can and should strive to ensure that *every* concept is at least  “reasonably identical” as you suggest.  They are all ssn concepts (think “modules” of ssn). Some are introduced in the  simple core
> ( we are informally calling these sosa concepts) . Others are not introduced in the simple core. (we are informally calling these ssn concepts – I would prefer to call them “extended” concepts.)  This cannot be done as sosa and ssn are right now – but it should always have been done in the sosa design (I tried to say it at the beginning  but I was actively discouraged by both caustic responses  and a failure to bring the developing design to the group so I felt it necessary to wait until somehow the architecture emerged) but  it is not too late to do it properly now. I am saying (yet again) that BOTH ssn and sosa need to change to make this work. I do not accept that sosa as it is now has any kind of precedence in this  marriage – In fact ssn has had much more history and use and impact  and oversight (reiterating other people’s comments here). We have not even been allowed within this group yet to comment specifically on sosa terms (see all the  unaddressed issues in the tracker) . However, I totally understand that resolving this modularity architecture comes first so that sosa can be reviewed in exactly that context.

The terms “extended” and “extension” suffer from multiple ambiguous and contradictory definitions. It would better to avoid them. There was reasonable agreement that changes to the incubator SSN were needed - hence the formation of the group - in terms of complexity and of consistency with other widely used specifications, namely O&M and SensorML. Rather than repeating “what’s in a name”, it would be most useful to figure out how to address complexity and consistency by devising and agreeing on good engineering practice that works around some of the identified weaknesses in RDF and OWL. I feel we are making good progress in both that practice and in re-factoring incubator SSN into SOSA + SSN if we can just avoid getting into more discussion loops and instead provide useful feedback to the actual proposals being made

>  
> The worst thing we can do is just bung them together –as it looks right now (both on github and in our formal spec).  It would be better to publish old ssn and give up entirely on modularity (which I have consistently said is our most important task…).
>  
> --end warning – strong opinions  and considerable frustration expressed here--
>  
> > This will still be a risk of trouble in case that someone does not follow the informal restrictions correctly and someone else then applies the formal ones to the result. In a sense, we would be relying on the informal and formal vocabulary usages not to overlap.
>  
> Yes,  this trouble can happen - but I think we can manage this well – ensuring that anyone following the “informal” restrictions properly  (according to the rdfs:comment) is also compliant with the formal one . I think I showed this in the Platform example – at least I meant to.  I had to change both current ssn and currnet sosa to do this.https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN#Example <https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN#Example>  So we do not need to rely on non-“overlap”.  Quite the opposite – they can and should align neatly by design. Every informal statement should be supported by formal axioms (although a core user need not know that).  We only ask  our users for proper
> use according to documentation. Which of course will not always happen – but we cannot be blamed for that!

No blame needs to go around, it’s just something that the documentation needs to emphasize, along with the implications we make for equivalence of formal and informal axioms, significance of document contents, and significance of defined namespaces. The significance of RDF / OWL rules is baked into their specifications. The rest of the practice we are establishing here we have to (narratively) be clear about.

>  
> And to avoid confusion  (and repeating myself) – in that example I have used 2 different namespaces.  This does not imply I think 2 different namespaces are necessary nor even good. (however many times somebody tells me that it does) On the contrary – I like very much what Josh is saying here about namespaces.
> So that example works even better if you apply s/sosa:/ssn:/g

My impression from the telecon is that most think your proposal is a very clear one to build on. The most equivocal question we seem to need to deal with is the one vs two namespaces, because there are many pros and cons, as well as not clear decision criteria since they only have informal significance. It will be easier to decide once we agree that it just isn’t that important.

>  
> -Kerry
>  
>  
>  
> From: Joshua Lieberman [mailto:jlieberman@tumblingwalls.com <mailto:jlieberman@tumblingwalls.com>] 
> Sent: Tuesday, 31 January 2017 2:47 AM
> To: Kerry Taylor <kerry.taylor@anu.edu.au <mailto:kerry.taylor@anu.edu.au>>
> Cc: Rob Atkinson <rob@metalinkage.com.au <mailto:rob@metalinkage.com.au>>; janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>; 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>; ssimmons@opengeospatial.org <mailto:ssimmons@opengeospatial.org>; fd@w3.org <mailto:fd@w3.org>
> Subject: Re: State of SSN
>  
> A best practice consensus here on modularization is finally beginning to take shape. In my mind, that’s almost as important a result as the SSN vocabulary itself, since it can have application to many other modular ontologies. It still seems to be hazy on “namespace”, though, so that needs to cleared up. Namespace, as I understand it, has no functional role in an ontology or vocabulary. It’s a “hack” on the path of identifier URI's and a convenience in the specification of those URL’s. Not fundamental to the uniqueness of URI’s.
>  
> Now there is a need for different URI’s for different concepts, specifically ontologies. So if there are distinct SOSA and SSN(-2) ontologies, for example, they need to have distinct URI’s. If a concept itself, such as a class, is different in any way within the SOSA and SSN ontologies respectively, then there should be two distinct URI’s. Our practice also indicates that those differences can be defined informally by annotations, but also formally (in SSN(-2) only) by axioms on the SSN concept. 
>  
> My understanding is that “membership” itself in an ontology is indicated not by presence or absence in a particular file, or the use of a particular namespace, but by rdfs:isDefinedBy statements that connect a class concept for example and an ontology concept such as SOSA.
>  
> There seem to be various practices concerning the use of namespaces to act as “hints” for membership and other connections between ontology elements. One approach is to have separate namespaces (remember, only the prefixes for URI’s) for separate collections / ontologies / modules. This certainly emphasizes the separation between such collections, but may obscure the affinities such as “these modules are part of an integrated domain expression”. One could further hack namespace paths to be similar (e.g. differing only in the last term ), but this has no effect on the actual namespace mechanism and requires reading more meaning  into the path than may be advisable.
>  
> @prefix sosa: <http://www.w3.org/ns/sosa/ <http://www.w3.org/ns/sosa/>> .
> @prefix ssn2: <http://www.w3.org/ns/ssn2/ <http://www.w3.org/ns/ssn2/>> .
> sosa:Ontology  rdf:type owl:Ontology ;
> ssn2:Ontology  rdf:type owl:Ontology ;
>  
>  
> The practice that seems to be advocated by Maxime is to have one namespace in which to gather the terms for a set of modular ontologies. Each concept and each ontology module still has unique URI’s, but these are formed using the same prefix indicating the namespace and suggesting informally that the modules belong to some sort of distinct whole. 
>  
> @prefix sosa-ssn2: <http://www.w3.org/ns/sosa-ssn2/ <http://www.w3.org/ns/sosa-ssn2/>> .
> sosa-ssn2:SosaOntology  rdf:type owl:Ontology ;
> sosa-ssn2:SsnOntology  rdf:type owl:Ontology ;
>  
>  
> It is still possible, I think, to add some informal membership information to the names, but again this is an informal hack on the URI pattern to suggest membership, e.g.
>  
> @prefix sos-ssn2: <http://www.w3.org/ns/sosa-ssn/ <http://www.w3.org/ns/sosa-ssn/>> .
> sosa-ssn2:sosa/Ontology  rdf:type owl:Ontology ;
> sosa-ssn2:ssn/Ontology  rdf:type owl:Ontology ;
>  
> I don’t have a problem with including informal semantics in our namespace practice, but we need to pick a practice, be consistent in applying it, and provide a clear narrative describing what we mean by it.
>  
> Thoughts? I want to apply this practice as well to both the spatial ontology and hydro ontology that I’m trying get out the door, so settling the issue would have many positive effects.
>  
> —Josh
>  
> PS - 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. This will still be a risk of trouble in case that someone does not follow the informal restrictions correctly and someone else then applies the formal ones to the result. In a sense, we would be relying on the informal and formal vocabulary usages not to overlap.
>  
>  
> On Jan 30, 2017, at 9:35 AM, Kerry Taylor <kerry.taylor@anu.edu.au <mailto:kerry.taylor@anu.edu.au>> 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 <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 <mailto:rob@metalinkage.com.au>] 
> Sent: Monday, 30 January 2017 11:59 AM
> To: Kerry Taylor <kerry.taylor@anu.edu.au <mailto:kerry.taylor@anu.edu.au>>; janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>; 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
>  
>  
> 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 <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 withhttps://www.w3.org/2015/spatial/track/issues/139 <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 newextends 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 <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 <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 <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/~jano/>
> Semantic Web Journal: http://www.semantic-web-journal.net <http://www.semantic-web-journal.net/>