Integration Issue

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

Back to Semantic_Sensor_Network_Ontology.

PLEASE NOTE OPTIONS 2, 3, 4, 6, 7 HAVE BEEN RULED OUT DURING F2F 2017-03-20

See now Remaining_Options_for_SOSA-SSN_Integration.

Based on discussions on the mailing list and in our phone conferences it appears as if we have multiple possible options for the integration of SOSA and SSN.

Assumptions for all solutions:

  • SOSA has its own IRI and ontology file
  • SSN has its own IRI and ontology file
  • SSN imports SOSA
  • SSN adds additional axioms to classes/properties defined in SOSA where necessary
  • SSN defines additional terms (classes and properties) not defined in SOSA

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. Note that in the case of Platform having different semantics in SSN and SOSA a different issue arises - whether sosa:Platform and ssn:Platform should be allowed to co-exist, or use a naming convention to highlight different intent: sosa:Platform, ssn:MySpecializedPlatform. (please - if necessary raise a separate issue and options for this case instead of mixing into this discussion!!)

Options are detailed below. This does not mean that other options cannot be considered:

Contents

Possible options in a nutshell

High level description of several options:

unified namespace for SOSA and SSN unified namespace for SOSA and SSN

second namespace to declare some terms

different namespaces for SOSA and SSN different namespaces for SOSA and SSN

third namespace to declare some terms

There are no duplicate terms Option 1:
  • ontology unify:Core declares unify:* terms
  • ontology unify:Full refines existing unify:* terms, and introduces new unify:* terms
Option not detailed:
  • ontology unify:Core declares module:* terms
  • ontology unify:Full refines existing module:* terms, and declares new module:* terms
Option 5, de facto implementation:
  • ontology sosa: declares sosa:* terms
  • ontology ssn: refines existing sosa:* terms, and declares new ssn:* terms.

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.
Option 7:
  • ontology unify: declares unify:* terms
  • ontology sosa: precises the semantics of unify:* terms
  • ontology ssn: precises the semantics of unify:* terms
There exists duplicate terms n/a Option 2:
  • ontology unify:Core declares unify:* terms
  • ontology unify:Full declares one term module:* for each unify:* term declared in unify:Core, and asserts they are equivalent. It also declares new unify:* terms when they are not declared in unify:Core
Option 6:
  • ontology sosa: declares sosa:* terms
  • ontology ssn: declares one term ssn:* for each sosa:* terms, adds axioms to ssn:* terms, and asserts they are equivalent to sosa:* terms.
Option not detailed:
  • ontology unify: declares unify:* terms
  • ontology sosa: declares some terms sosa:*, adds axioms to sosa:* terms, and asserts they are equivalent to unify:* terms
  • ontology ssn: declares one term ssn:* for each unify:* term, adds axioms to ssn:* terms, and asserts they are equivalent to unify:* terms
Option not detailed:
  • ontology unify:Core declares unify:* terms
  • ontology unify:Full declares one term module:* for each unify:* term declared in unify:Core, and asserts they are sub terms. It also declares new unify:* terms when they are not declared in unify:Core
Option 3:
  • ontology sosa: declares sosa:* terms
  • ontology ssn: declares one term ssn:* for each sosa:* terms, adds axioms to ssn:* terms, and asserts they are sub terms of sosa:* terms.
Option 4:
  • ontology unify: declares unify:* terms,
  • ontology sosa: precises the semantics of the unify:* terms
  • ontology ssn: declares one term ssn:* for each unify:* term, adds axioms to ssn:* terms, and asserts they are equivalent to unify:* terms

High level PROPOSAL proposals:

  1. PROPOSAL: terms will not be duplicated, i.e., if a term ns1:Xxx exists, then there will not exist another term ns2:Xxx.
  2. PROPOSAL: terms will be duplicated, i.e., if a term ns1:Xxx exists, then there will exist another term ns2:Xxx.
  3. PROPOSAL: SSN precises the semantics of each of the terms that SOSA declared.
  4. PROPOSAL: SSN defines a duplicate terms for each of the terms that SOSA declared, and align it with some equivalence relation.
  5. PROPOSAL: SSN defines a duplicate terms for each of the terms that SOSA declared, and align it with some subClass/subProperty relation.
  6. PROPOSAL: the namespace of the terms that SOSA declares, and the namespace of the SOSA ontology, are the same.
  7. PROPOSAL: the namespace of the terms that SSN declares, and the namespace of the SSN ontology, are the same.
  8. PROPOSAL: all of the terms must have the same namespace.
  9. PROPOSAL: some terms may have different namespaces.
  10. PROPOSAL: there will be a separate namespace other than the one(s) for SOSA and SSN.
  11. PROPOSAL: there will not be separate namespace other than the one(s) for SOSA and SSN.
  12. PROPOSAL: the namespace of the terms that SOSA declares, and the namespace of the terms that SSN declares, are the same.

KJ: Just for the record, I think the usage of the term duplicate here is not precise.

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

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 on non-standard infrastructure mechanism that doesn't provide significant additional information. 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. On transitivity (see Rob above), of course you can. You can add infinitely many ontologies this way, and each may add new terms (as ssn does here) and stronger axioms (as ssn does here). The relationship of nextnewontology to ssn would mimic the relationship of ssn to sosa here, and in all cases the same one namespace would apply throughout. Note that implication 8 here equally well holds true for the bog-standard 2-namespace option 5.

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 2: One unified namespace, and a separate namespace ONLY for terms whose semantics need to be precised in SSN. Use of equivalence axioms between these duplicate terms and the terms from SOSA.

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 .

Namespace module: there is no file accessible at that namespace.

Let module be equal to some non empty string. Then the module namespace is:

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

SSN:

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

 # this ontology does not add triples with subject unify:Platform.

 module:Platform owl:equivalentClass unify:Platform ;
   # additional axioms narrowing the semantics of the Platform class
   rdfs:isDefinedBy unify:SSNLocalName .

 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. If you type module:Platform in your browser you get to the axioms of the Platform class defined by SSN.
  5. 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.
  6. 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.
  7. All terms are redefined in SSN and introduced with their own IRI, either using the module namespace if extended from SOSA or the unify namespace if introduced new in SSN.
  8. You can directly access the stronger SSN axiomatization of the module:Platform class by its IRI module:Platform.
  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.
  12. All old SSN terms point to terms defined in the unified namespace.


Votes

Maxime: -1. would rather have a separate namespace for the SSN ontology and the terms it declares. (option 6 below)

Armin: +1. I prefer this Option over Option 1. It uses a common namespace, but the user is able to get the stronger semantics of SSN. When using SOSA or SSN the user would also know exactly which semantic interpretation they get.

KJ: +1 (equivalentClass --> subclass?)

Rob: -1. I really cant see why you would need equivalence classes for the same object, yet still maintain a new namespace, and then define new terms in the old namespace. and it has the same infrastructure challenges as 1. Seems like the worst of all worlds, not the best, and the rationale for this pattern would be very hard to explain I think.

Kerry: -1 I don't think the added complexity justifies the advantage over option 1 (ie implication 8 above, but even then you have to know which of the 2 IRIS for Platform you should resolve to get whichever axiomitisation you want, as opposed to defaulting to the simplest axiomitisation as offered by Option 1). Unlike option 1 it has separate namespaces for sosa and ssn (ie 2 namespaces anyway) with equivalentclass axioms linking them for some terms.

Raúl: -1. We are adding unnecessary complexity by declaring different URIs for the same classes and using the equivalence axioms.

Option 3: Two distinct (sibling) namespaces for SOSA and SSN. SSN duplicates the terms from SOSA and precises their semantics. Use of subclass/subproperty axioms between these duplicate terms and the terms from SOSA.

@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: .

 ssn:Platform rdfs:subClassOf sosa:Platform ;
   rdfs:isDefinedBy ssn: .

 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. All of SOSA terms are duplicated in the SSN ontology with the ssn: namespace.
  6. Some of the terms have only the ssn: namespace.
  7. You can directly access the stronger SSN axiomatization of the ssn:Platform class by its IRI ssn:Platform.
  8. Some, but not all SOSA instances are valid SSN instances.
  9. Some, but not all SSN instances are valid SOSA instances.
  10. Old SSN terms either point to terms defined in the SOSA or SSN namespace.
  11. One can just "remove" the localname of a term to get the IRI of the ontology where it is defined.

Votes

Maxime: -1. subClass/subProperty prevents old SSN data to be valid SOSA data.

Armin: -1. This is kind of a fall-back solution. Old SSN data can still be made valid SOSA data with aligning it to the SOSA terms, but any of the other Options demonstrates a stronger alignment.

Rob: 0. This solution works without infrastructure gymnastics, and is I think a pattern that can be used transitively. The subClassing just seems unneccesary and means implementations will rely on RDFS reasoning and resolving the ontology URIs to determine equivalence of sosa: and ssn: based instances. A lot of work for no added information in the system.

Kerry: A very strong -1 . We have ssn:Platform and sosa: Platform as different concepts occuring in the same ontology (ssn). This is really horrible for usability. Not only does this prevent sosa data from being anything at all in new ssn (all sosa instance data needs to be explicitly, by hand, rewritten to work with ssn), but it makes a mockery of sosa as the core of ssn and indeed of the concept of modules. It does nothing more than any other arbitrary alignment of incompatible ontologies. I think implication 8 (Some, but not all SOSA instances are valid SSN instances) is false -- as no SOSA instances would be SSN instances.

Raúl: -1. ssn:Platform and sosa:Platform should be the same concept.

Option 4: Three namespaces, one ontology per namespace. One core ontology introduces the list of terms that all have the core namespace. SOSA imports this core ontology and refines the semantics of these terms. SSN imports the SOSA ontology, duplicate terms, and define the semantics of the duplicate terms.

Let unify be equal to some non-empty string. Then the three namespaces are:

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

Vocabulary Terms:

This file is the vocabulary term list ontology file. It introduces all classes and properties that are used in SOSA and SSN. It is imported by both SOSA and SSN ontologies.

UNIFY:

 unify: rdf:type owl:Ontology .

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

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

SOSA:

SOSA imports the core ontology and refines the semantics of its terms.

 sosa: rdf:type owl:Ontology ;
   owl:imports unify: .

 unify:Platform 
   # additional axioms

SSN:

SSN imports the SOSA ontology, duplicate terms, and define the semantics of the duplicate terms.

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

 ssn:Platform owl:equivalentClass unify:Platform ;
   # additional axioms
   rdfs:isDefinedBy ssn: .

 ssn:System owl:equivalentClass unify:System ;
   # additional axioms
   rdfs:isDefinedBy ssn: .

Implications:

  1. If you type unify:Platform in your browser you get to the vocabulary term list ontology file.
  2. If you type unify:System in your browser you get to the vocabulary term list ontology file.
  3. If you type ssn:Platform in your browser you get to the axioms of the Platform class defined by SSN.
  4. If you type ssn:System in your browser you get to the axioms of the System class defined by SSN.
  5. if you type http://www.w3.org/ns/sosa/ in your browser you get to the SOSA ontology file.
  6. if you type http://www.w3.org/ns/ssn/ in your browser you get to the SSN ontology file.
  7. You cannot directly access the weaker SOSA axiomatization of the unify:Platform class, unless you go directly to the ontology IRI of SOSA.
  8. No term has the sosa: namespace.
  9. All of the unify terms are duplicated in the SSN ontology with the ssn: namespace.
  10. You can directly access the stronger SSN axiomatization of the ssn:Platform class by its IRI ssn:Platform.
  11. Some, but not necessarily all SOSA instances are valid SSN instances. Depends on how rigorously SOSA is aligned with SSN.
  12. Some, but not necessarily all SSN instances are valid SOSA instances. Depends on how rigorously SOSA is aligned with SSN.
  13. All old SSN terms point to terms defined in the unified namespace.
  14. SSN could also only extend terms from the unified namespace without the equivalence relation. See option 7 below.

Votes

Maxime: -1. Strongly against three namespaces. Unless unify="sosa", which makes this option collide with Option 6 below.

Armin: 0. This solution has no real disadvantages. It does introduce three namespaces, though, which makes Option 2 superior to me.

Rob: 0. Three ontologies, _two_ namespace with distinct functions is the most scalable pattern - its only the small size of SSN that makes collapsing desirable. The option is worded unfortunately - the way we have been talking about it is that SOSA is the core, then we could have SOSA+OWL with precise axioms, SSN with extensions. IMHO there is no "new" thing called unify - thats just plain old SOSA as discussed - the issue is whether the two separate functions of SSN are best conflated into one package or two.

Kerry: It has the disadvantage that core terms introduced in sosa are resolved to no axioms at all -- just the namespace "unify" thing. I have to agree with Maxime that having unify=="sosa" would be better. But then it collapses to option 2, is it not? The idea of the base common neutral namespace here seems to have some merit, but then I think I would redesign the rest of the pattern... I can't see the value of three namespaces when we only need one!

Raúl: -1. We are adding unnecessary complexity by declaring different URIs for the same classes and using the equivalence axioms. The idea of declaring separately the vocabulary terms with documentation is good, but that is the idea for having a core module. There is no need for a "core of a core" module.

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

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: .

A potential technical implementation could be to serve the SSN ontology if you ask for mimetype OWL at the SOSA URI.

@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

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. simple - but option 8 is a repeatable pattern (and addresses Kerry's concern about this option). I disagree with Maxime's analysis though - in this solution terms _always_ have a single namespace and conventional resolution behaviour.

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 6: Two distinct (sibling) namespaces for SOSA and SSN. SSN duplicates the terms from SOSA and precises their semantics. Use of equivalence axioms between these duplicate terms and the terms from SOSA.

@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: .

 ssn:Platform owl:equivalentClass sosa:Platform ;
   rdfs:isDefinedBy ssn: .

 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. All of SOSA terms are duplicated in the SSN ontology with the ssn: namespace.
  6. Some of the terms have only the ssn: namespace.
  7. You can directly access the stronger SSN axiomatization of the ssn:Platform class by its IRI ssn:Platform.
  8. All SOSA instances are valid SSN instances.
  9. Some, but not all SSN instances are valid SOSA instances.
  10. Old SSN terms either point to terms defined in the SOSA or SSN namespace.
  11. One can just "remove" the localname of a term to get the IRI of the ontology where it is defined.

Votes

Maxime: 0. With this option the end user can use any ssn:Term, and his graph will still be valid SOSA. that's ok. On the other hand, terms are artificially duplicated, this goes against the "reuse existing vocabularies" principles.

Armin: 0. Very similar to Option 2, but since Option 2 uses a common namespace while still allowing for direct access of terms through their URIs I prefer Option 2. Duplicating some terms and introducing equivalence relations is a common practice in ontology engineering, though.

Rob: 0. Better than option 2 in terms of infrastructure, but unnecessary duplications and complication of navigating equivalences throw to the user.

KJ: 0 to +1 (would be fine with me, especially as compared to some other options)

Kerry: -1 Much dislike the two namespaces. Much dislike the unnecessary duplications muddying ssn. Propose we put those unnecessary equivalence axioms in sosa instead if we do this (and then my vote would change to 0). Much Prefer option 5 if we must insist on more than one namespace.

Raúl: -1. We are adding unnecessary complexity by declaring different URIs for the same classes and using the equivalence axioms. I think that we should standardise a single ontology and not two.

Option 7: Three namespaces, one ontology per namespace. One core ontology introduces the list of terms that all have the core namespace. SOSA imports this core ontology and refines the semantics of these terms. SSN imports the SOSA ontology and the core ontology, and refines the semantics of these terms

Let unify be equal to some non-empty string. Then the three namespaces are:

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

Vocabulary Terms:

This file is the vocabulary term list ontology file. It introduces all classes and properties that are used in SOSA and SSN. It is imported by both SOSA and SSN ontologies.

UNIFY:

 unify: rdf:type owl:Ontology .

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

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

SOSA:

SOSA imports the core ontology and refines the semantics of its terms.

 sosa: rdf:type owl:Ontology ;
   owl:imports unify: .

 unify:Platform 
   # additional axioms

SSN:

SSN imports the SOSA ontology, duplicate terms, and define the semantics of the duplicate terms.

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

 unify:Platform 
   # additional axioms

 unify:System 
   # additional axioms

Implications:

  1. If you type unify:Platform in your browser you get to the vocabulary term list ontology file.
  2. If you type unify:System in your browser you get to the vocabulary term list ontology file.
  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. You cannot directly access the SOSA axiomatization of the unify:Platform class, unless you go directly to the ontology IRI of SOSA.
  6. You cannot directly access the SSN axiomatization of the unify:Platform class, unless you go directly to the ontology IRI of SSN.
  7. No term has the sosa: namespace, no term has the ssn: namespace
  8. No term is duplicated.
  9. All SOSA instances are valid SSN instances.
  10. Some, but not necessarily all SSN instances are valid SOSA instances.
  11. All old SSN terms point to terms defined in the unified namespace.

Votes

Maxime: 0. SOSA is merely a selection of a set of terms from unify:. What would be the additional axioms ? relations "isDefinedBy" would be meaningless in SOSA and SSN.

Armin: -1. Option 4 is the more elegant derivative of this Option.

Rob: -1. Unnecessary unless there was a requirement for SSN to change meaning of terms in SOSA, and to have SOSA and SSN semantics that are incompatible. I havent seen any argument for this.

Kerry: 0. I don't think we need 3 namespaces, but at least this option avoid several nasties from some others.I think implication 10 is wrong -- we can and should ensure by design that all ssn instances ( for the instances of the subset of terms that do appear in sosa) are valid sosa instances.

Raúl: -1. The idea of declaring separately the vocabulary terms with documentation is good, but that is the idea for having a core module. There is no need for a "core of a core" module.


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

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.


Some issue I hope we can sort out

Let us assume there are two ontologies A and B at different URLs (but possible using the same namespace).

Now ontology A defines:

C \sqsubseteq D


Next, ontology B adds more axioms to C (from ontology/URL A), e.g.,:

C \sqsubseteq E.

So, here is the issue. Under ontology A, {C \sqsubseteq D , C(x)} entails {D(x)} but under ontology B {C \sqsubseteq D , C(x)} entails {D(x), E(x)}. If you would like to have an example C is Sensor, D is object, and E is PhysicalObject. These are not actual SSN/SOSA axioms, they are examples. If I get an assertion of the form a common namespace ssn:C(x) back from a visualization interface, a federated SPARQL query, a paper, etc, what does it imply? D(x), or aditionally E(x)?

Kerry: Clearly here we are assuming a "black box" service and we don't know what ontology is being used. In this case you need to to ask your black box (i.e. vis interface, SPARQL server, paper etc). This is no different to the case of not knowing whether C(y) or even G(x) holds.

Rob: i believe options 5 and 8 avoid this by forcing only axioms consistent with SOSA defs on sosa:X objects. you get different entailment using OWL or RDFS, but never inconsistent entailment.