Warning:
This wiki has been archived and is now read-only.

Remaining Options for SOSA-SSN Integration

From Spatial Data on the Web Working Group
Jump to: navigation, search

Back to Semantic_Sensor_Network_Ontology.

PLEASE NOTE THAT WE HAVE VOTED FOR OPTION 5 DURING CALL 2017-03-21
We still need to choose the exact prefixes and namespaces for SOSA and SSN, but they will be different.

See previous wiki page with the options 2, 3, 4, 6, 7 that have been ruled out during F2F 2017-03-20: Integration_Issue

There are now three options for the integration of SOSA and SSN.

Assumptions for all solutions:

  • SOSA ontology has its own IRI and ontology file
  • SSN ontology has its own IRI and ontology file
  • SSN ontology imports SOSA ontology
  • An ontology (possibly but not necessarily SSN) ontology adds additional axioms to classes/properties defined in SOSA ontology where necessary
  • SSN ontology defines additional terms (classes and properties) not defined in SOSA ontology
  • There are no duplicate terms: if there exists ns1:Platform, then there must not be ns2:Platform

For all Options an illustration is given on the Platform and System class. Why, because all decisions so far point to the case that the Platform class will be introduced in SOSA and have extended axiomitisation in SSN, whereas the System class will only be introduced in SSN. Please note that the Platform and System class would require additional axioms in either, SOSA and SSN, but for brevity only the essential class definitions are shown below.

Options are detailed below:

Possible options in a nutshell

unified namespace for SOSA and SSN different namespaces for SOSA and SSN
Two documents only Option 1:
  • ontology unify:Core declares unify:* terms
  • ontology unify:Full refines existing unify:* terms, and introduces new unify:* terms

Look up behaviour:

  • looking up unify:Platform, one retrieves SOSA.

Major pro:

  • every term has the same namespace, no confusion possible.

Major con:

  • does not conform to the standard expectation that one namespace = one ontology.
  • infrastructure needs rules per term, and this pattern cannot be replicated for further specialisation of terms (e.g. an ontology describing mobile sensors)
 Option 5, de facto implementation:
  • ontology sosa: declares sosa:* terms
  • ontology ssn: refines existing sosa:* terms, and declares new ssn:* terms.

Look up behaviour:

  • looking up sosa:Platform, one retrieves SOSA.
  • using Content negotiation (asking explicitly for application/owl+xml documents) is used to discover stronger axiomitisation from SOSA (NB Option 8 uses owl:imports and better modularity to avoid this)

Major pro:

  • conforms to the standard expectation that one namespace = one ontology.

Major con:

  • term are defined in different namespaces: sosa:ActuatableProperty, ssn:Property, sosa:Procedure, ssn:Sensing, ... this may bring confusion among the users

(note, this doesnt stop infrastructure helping finding the term if no namespace is supplied, and URIs just work as expected - con probably only applies to the Use Case of hand editing examples)

  • some OWL clients do not request application/owl+xml documents, OWLAPI and Protégé for instance will not be able to access the stronger sosa:owl-dl axiomatization.


Three documents n/a Option 8, simple owl:imports based implementation:
  • ontology sosa: declares sosa:* terms, imports sosa:owl-dl so OWL clients get axioms
  • ontology sosa:owl-dl: provides explicit axioms based on a transparently designated language (OWL-DL)
  • ontology ssn: declares new ssn:* terms.

Look up behaviour:

  • looking up sosa:Platform, RDF clients access SOSA whereas OWL clients automatically access the stronger sosa:owl-dl axiomatization, without needing to resort to content negotiation (this is this difference between option 5 and option 8)

Major pros:

  • futher axiomatization (of SOSA terms), and specialization (additional SSN terms) are separated in two files.
  • axioms are automatically discovered by clients who understand owl:imports

Major con:

  • term are defined in different namespaces: sosa:ActuatableProperty, ssn:Property, sosa:Procedure, ssn:Sensing, ... this may bring confusion among the users

(note, this doesnt stop infrastructure helping finding the term if no namespace is supplied, and URIs just work as expected - con probably only applies to the Use Case of hand editing examples)

Other concerns noted: "some clients may choose to follow owl:import but not be able to handle the owl axioms thus loaded" (Is this really a valid concern?)

Option 1: One unified namespace

The mechanics of how this option works are detailed in Option 2 in NamespaceIssue.

Let unify be equal to string "sosa" (variant A), or "ssn" (variant B). Then the namespace is: 

@Prefix unify: <http://www.w3.org/ns/unify/> .

SOSA: 

 @Prefix unify: <http://www.w3.org/ns/unify/> .

 unify:SOSALocalName rdf:type owl:Ontology ;

 unify:Platform rdf:type owl:Class ;
   rdfs:isDefinedBy unify:SOSALocalName .

SSN: 

 @Prefix unify: <http://www.w3.org/ns/unify/> .

 unify:SSNLocalName rdf:type owl:Ontology ;
   owl:imports unify:SOSALocalName ;

 unify:Platform
   # additional axioms on unify:Platform ...
   rdfs:isDefinedBy unify:SOSALocalName .

 unify:System rdf:type owl:Class ;
   rdfs:isDefinedBy unify:SSNLocalName .

Implications:

  1. @Prefix unify: <http://www.w3.org/ns/unify/> can either be <http://www.w3.org/ns/sosa/> or <http://www.w3.org/ns/ssn/>
  2. If you type unify:Platform in your browser you get to the axioms of the Platform class defined by SOSA.
  3. If you type unify:System in your browser you get to the axioms of the System class defined by SSN.
  4. with variant "sosa1", if you type http://www.w3.org/ns/unify/ in your browser you get to the SOSA ontology file. On the other hand, one need to know the ontology URI of SSN to access it.
  5. with variant "ssn1", if you type http://www.w3.org/ns/unify/ in your browser you get to the SSN ontology file. On the other hand, one need to know the ontology URI of SOSA to access it.
  6. all old SSN terms point to terms defined in the one unified namespace.
  7. all of the terms defined in the REC share the same namespace.
  8. You cannot directly access the stronger SSN axiomatization of the unify:Platform class, unless you know the ontology IRI of SSN.
  9. All SOSA instances are valid SSN instances (if used correctly).
  10. All SSN instances are valid SOSA instances (if used correctly).
  11. One needs to dereference a term to figure out where this term is defined OR to use the ontology URI of SOSA or SSN explicitly since there is just ONE unify namespace.

Votes

During F2F 2017-03-20, this option had votes: 3 x -1, 3 x 0, 3 x +1.

Original votes: Maxime: +1, and +1 for unify="sosa", SOSALocalName equal to the empty string, SSNLocalName equal something like "SSNOntology":

Armin: 0, if this Option +1 for unify="sosa". In this Option you cannot access the stronger semantics of an SSN term directly, a problem solved in Option 2 (if Option 2 also implements the same technical means for rewriting unified terms to SOSA/SSN as this Option).

KJ: -1 to 0 ; fine with unify="sosa".

Rob: -1, relies heavily on non-standard infrastructure mechanism that doesn't provide significant additional information. (Note - redirecting a / URI to a # URI against the relevant document is IMHO fine - but not being able to know from the namespace which ontology defines the term means that a client has to resolve every single URI in a document to know if it has downloaded the relevant ontology, rather than just knowing it has downloaded the relevant ontology for the namespace). Also the scalability of this option is unaddressed - is the pattern safe in a transitive environment - can someone extend SSN with further specialisations and use the same mechanism without modifying that infrastructure - it appears not.

Kerry: +1. There is nothing non-standard about the infrastructure... Can live with unify being either ssn or sosa. Terms resolve nicely and as everybody expects, with the only exception case being that terms defined in both ssn and sosa always resolve to the simpler definition (sosa) and to get to the more complex definition you need to go to the ssn ontology yourself.

Raúl: +1. unify could be either ssn or sosa. We should standardise a single ontology (with different representations for different users) and not two ontologies. 

@Prefix sosa: <http://www.w3.org/ns/sosa/> .

sosa: a owl:Ontology ; dc:title "The SOSA ontology" .
sosa:SSNOntology a owl:Ontology ; dc:title "The SSN ontology" .

Option 5: Two distinct (sibling) namespaces for SOSA and SSN, SSN precises the semantics of the terms from SOSA

PLEASE NOTE THAT WE HAVE VOTED FOR THIS OPTION DURING CALL 2017-03-21
We still need to choose the exact prefixes and namespaces for SOSA and SSN, but they will be different.

This Option removes the need to always create duplicate classes in SSN that are already defined in SOSA (as described in Option 2). As a result, it has implications in terms of direct accessibility of terms that are further refined in SSN, e.g. the stronger SSN axiomatization of the unify:Platform cannot be directly accessed. If the richer axiomatization is intended, the data provider can add the following triple to point to the SSN graph, within the data:

[] owl:imports ssn: . 

@Prefix sosa: <http://www.w3.org/ns/sosa/> .
@Prefix ssn: <http://www.w3.org/ns/ssn/> .

SOSA: 

 sosa: rdf:type owl:Ontology ;

 sosa:Platform rdf:type owl:Class ;
   rdfs:isDefinedBy sosa: .

SSN: 

 ssn: rdf:type owl:Ontology ;
   owl:imports sosa: ;

 sosa:Platform
   # additional axioms
   rdfs:isDefinedBy sosa: .

 ssn:System rdf:type owl:Class ;
   rdfs:isDefinedBy ssn: .

Implications:

  1. If you type sosa:Platform in your browser you get to the axioms of the Platform class defined by SOSA.
  2. If you type ssn:System in your browser you get to the axioms of the System class defined by SSN.
  3. if you type http://www.w3.org/ns/sosa/ in your browser you get to the SOSA ontology file.
  4. if you type http://www.w3.org/ns/ssn/ in your browser you get to the SSN ontology file.
  5. Terms are either defined in SOSA, or in SSN.
  6. Some of the terms have the sosa: namespace, some have the ssn: namespace.
  7. You cannot directly access the stronger SSN axiomatization of the sosa:Platform class, unless you know the ontology IRI of SSN.
  8. All SOSA instances are valid SSN instances (if used correctly).
  9. All SSN instances are valid SOSA instances (if used correctly).
  10. One can just "remove" the localname of a term to get the IRI of the ontology where it is defined.
  11. old SSN terms point to terms defined in one or the other namespace.


Votes

During F2F 2017-03-20, this option had votes: 0 x -1, 8 x 0, 1 x +1.

Original votes: Maxime: 0. This is the current de facto implementation and I could live with it. The big problem of this solution is that in the same REC, terms sometimes have namespace sosa:, sometimes namespace ssn:. Again, that might confuse the end user.

Armin: 0. Since terms are just reused in SSN even if the semantics are refined, it is impossible to access the stronger semantics of a term directly through its URI. As this is not Linked Data compliant, I see Option 2 as superior to this one.

KJ: 0 (see Armin's comment)

Rob: +1 ( note now changed to 0, in the light of information about OWL clients not using OWL mimetype reliably). simple - but option 8 is a repeatable pattern (and addresses Kerry's concern about this option).

Kerry: 0. I don't care a lot about failing to access the stronger semantics by term resolution. I just don't like the loss of a core in the design here. Btw I don't think the "A potential technical implementation..." works because there is no OWL mimetype -- only RDF-XML and tutrle which does not help. This is simple enough but it has the disadvantages of Option 1 but misses its advantage of a single namespace design for our unified ssn.

Raúl: -1. I think that we should standardise a single ontology and not two.

Option 8: Two distinct namespaces for SOSA and SSN, SSN for new terms only, SOSA packages as basic and OWL ontologies linked by import.

This option uses standard behaviours, makes function of each ontology clear and provides a template for further specialisation of SOSA (or SSN)

NB: at this stage, only a preference for fewer files (2 vs three) has been advanced as a counter argument - but this seems to lead to the complexity of implementation, rationale and expectation management issues plaguing us above). Other options above include three files, so this can be revisited as a more elegant option.

Examples of usage:

  1. imports SSN, and transitively sosa and sosa-owl
  2. instances are sosa compatible

[] owl:imports ssn: .

  1. imports sosa, and transitively sosa-owl

[] owl:imports sosa: .


  1. doesnt use OWL import, clients may choose to import sosa and ssn using namespaces. OWL clients can then choose to transitively import using owl:imports
@Prefix sosa: <http://www.w3.org/ns/sosa/> .
@Prefix ssn: <http://www.w3.org/ns/ssn/> .

SOSA: 

 sosa: rdf:type owl:Ontology ;
   # non -OWL clients will just ignore this, but its still a useful documentation link
   owl:imports sosa:OWL-DL ;

 sosa:Platform rdf:type owl:Class ;
   rdfs:isDefinedBy sosa: .

SOSA OWL DL axioms 

 sosa:owl-dl rdf:type owl:Ontology ;
 rdfs:comment "This ontology provide OWL-DL axiomitisation of the terms defined in sosa:. It is automatically loaded by OWL-aware clients, and ignored otherwise. No new terms or semantics are introduced. It is separated from sosa: in order to make it clear to sosa: users that OWL reasoning is not required to use the sosa: ontology.

 sosa:Platform rdfs:subclassOf [ some OWL axioms based on SOSA semantics... ] .


SSN: 

 ssn: rdf:type owl:Ontology ;
   owl:imports sosa: ; # and transitively sosa:owl-dl

 ssn:System rdf:type owl:Class ;
   rdfs:isDefinedBy ssn: .

Implications:

  1. If you type sosa:Platform in your browser you get to the axioms of the Platform class defined by SOSA.
  2. If you type ssn:System in your browser you get to the axioms of the System class defined by SSN.
  3. if you type http://www.w3.org/ns/sosa/ in your browser you get to the SOSA ontology file.
  4. if you type http://www.w3.org/ns/ssn/ in your browser you get to the SSN ontology file.
  5. Terms are either defined in SOSA, or in SSN.
  6. Some of the terms have the sosa: namespace, some have the ssn: namespace.
  7. OWL clients automatically access the stronger sosa:owl-dl axiomatization of the sosa:Platform class.
  8. All SOSA instances are valid SSN instances (if used correctly).
  9. All SSN instances are valid SOSA instances (if used correctly).
  10. One can just "remove" the localname of a term to get the IRI of the ontology where it is defined.
  11. old SSN terms point to terms defined in one or the other namespace.

Votes

During F2F 2017-03-20, this option had votes: 2 x -1, 4 x 0, 3 x +1.

Original votes: Rob: +1. IMHO this does everything required with only the most basic common behaviour requirements, and the packaging rationale is simple to explain and a template for further extension. All other options require us to explain the multiple roles of SSN ontology, and some form of infrastructure heroics to find the OWL.

Armin: 0. I would prefer this Option if SOSA:OWL-DL imports SOSA and SSN SOSA:OWL-DL. That would void Point 7, but avoids users that don't really understand OWL, but want a simple ontology, but still using an ontology editors, getting all the complex OWL axioms when they just want to see a simple SOSA ontology.

-- Rob's response - users who dont understand OWL dont follow the owl:imports automatically surely, and annotations can make it clear they dont have to.

Kerry: -1. I agree with Armin's comment but I am giving -1 because I really don't think this separation is realistically possible. While it sounds conceptually elegant, it will not work in our current situation. For example, in the Platform case (https://www.w3.org/2015/spatial/wiki/Platform), we have "sosa:hosts" refined by the axiom sosa:Platform rdfs:subClassOf [ owl:onProperty sosa:attachedSystem ; owl:allValuesFrom ssn:System] which is both typing constraints and uses non-core terms at the same time. Accepting such a separation would, perhaps, imply splitting this statement below into multiple modules? Not nice.

-- Rob's response - i think this is a case where SSN wants restricted semantics, not direct axiomitisation of SOSA (which knows nothing about SSN). So either put it as extra axioms in SSN, and accept SSN constrains SOSA further, or create a subClass in SSN with specific restricted semantics and a new name. either way, it doesnt belong in SOSA-OWL and hence i think the reason and vote needs revisiting.

Raúl: -1. Adds complexity for sosa users: need to know about OWL imports, OWL DL... They can ignore it, but at the end of the day they won't because they want to know the effect of that in their software.

-- Rob's response - SOSA users do _not_ need to know about owl:imports. Only OWL clients who want OWL axioms would use the owl:imports to find the axioms, avoiding the fundamental flaw with Option 1 that axioms cannot be discovered.

Retrieved from "https://www.w3.org/2015/spatial/wiki/index.php?title=Remaining_Options_for_SOSA-SSN_Integration&oldid=3702"