Re: SOSA/SSN namespaces - ontology

I do think I have interpreted your solution correctly. But let me give you an example, and you can outline where axioms should go. I detail both options below.

In SOSA we have currently:

sosa:Platform rdf:type owl:Class ;
  rdfs:comment "A Platform is an entity that hosts other entities, particularly Sensors, Actuators and other Platforms."@en ;
  rdfs:label "Platform"@en ;
...

In SSN we have:
sosa:Platform
  rdfs:subClassOf [ a owl:Restriction ; owl:onProperty sosa:hosts ; owl:allValuesFrom ssn:System ] .
  rdfs:subClassOf [ a owl:Restriction ; owl:onProperty ssn:inDeployment ; owl:allValuesFrom ssn:Deployment ] ;
…

ssn:system is only defined in the SSN ontology, so is ssn:inDeployment and ssn:Deployment.

So if these axioms are only defined in ssn.ttl in Option 8, I cannot see any discernible difference of Option 8 to Option 5, just that there is an OWL version of SOSA Platform and an RDFS version of SOSA Platform through sosa.ttl and sosa-owl-dl.ttl (which are almost identical since the only OWL term we use is inverseOf) and a more expressive SOSA Platform in ssn.ttl. If all axioms of Platform are indeed living in sosa-owl-dl.ttl, which makes the option significantly different to Option 5, you will have tools import ssn.ttl as well. The concern I raised.


From: Rob Atkinson <rob@metalinkage.com.au>
Date: Thursday, 9 March 2017 at 11:16 am
To: Armin Haller <armin.haller@anu.edu.au>, Rob Atkinson <rob@metalinkage.com.au>, SDW WG Public List <public-sdw-wg@w3.org>
Subject: Re: SOSA/SSN namespaces - ontology


As per my comment to Kerry - referring to SSN in SOSA axioms would violate the rules for option 8 - these are SSN axioms and should only be in SSN. Only axioms relating to SOSA should be in sosa-owl. (and if no such axioms exist, then this is not a problem - option 8 just collapses to option 5, but as a general pattern for modularity, 8 is re-usable in transitive specialisations, and i dont think that holds true for most other options.)

so I dont think the issues you mention, or Kerry's voting rationale, actually arise for option 8.

given you have both interpreted option 8 in almost its pure antithesis, is there something we can do to make its wording clearer?






On Thu, 9 Mar 2017 at 10:27 Armin Haller <armin.haller@anu.edu.au<mailto:armin.haller@anu.edu.au>> wrote:
I agree, Option 8 is technically no more difficult to implement than any other option. As you mentioned, probably easier than Option 1 and Option 2.

However, personally I am concerned about the fact that there is an OWL import in SOSA, meaning if you use Protégé or some other editor, you will not only get all the additional axioms for a term, but these additional axioms may refer to terms that are defined only in SSN full and as such, the tool will even import SSN. This is probably something Kerry is concerned with and why she is thinking of a method to separate parts of the axioms out that refer terms that are not defined within SOSA. Which I think is actually impossible in this solution. The fact that at the end, in most tools you will end up with all axioms of SSN when you import SOSA is the reason that I, personally, prefer Option 1 and Option 2 (and even Option 4 and Option 5) over Option 8.

From: Rob Atkinson <rob@metalinkage.com.au<mailto:rob@metalinkage.com.au>>
Date: Thursday, 9 March 2017 at 8:15 am
To: SDW WG Public List <public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>>
Subject: SOSA/SSN namespaces - ontology
Resent-From: <public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>>
Resent-Date: Thursday, 9 March 2017 at 8:16 am

In SDW plenary Kerry expressed view that Option 8 looked elegant but we wont have time to implement.

I personally dont see any qualitative difference - or if anything Options 5 and 8 are probably easiest to implement in time available.

So I have offered to implement - as i think its simpy a matter of splitting SSN into tow files:
sosa-owl.ttl - anything that just adds sosa axioms without mentioning SSN
ssn.ttl - everything else

this will IMHO only take a few minutes if SOSA + SSN in two namespaces is available.

Looking at the ontology files however I don't see any artefact where SSN adds such axioms,

Please point me to such a thing if it exists...

If not, then I would propose:

Option 8 allows us to stabilise sosa and ssn - and add the axioms to sosa-owl.ttl in a separate process. (i think every other option would require us to version at least SSN files as this work is done, but option 8 would allow us to split out the task of axiomitisation)

If it does exist, and someone points me to an artefact we all agree is the current modelm then I think I can whip up the option 8 implementation quickly :-)

Rob