Architecture of SOSA/SSN integration

Hi,

Herewith I am trying to summarise what has been discussed in today’s meeting, what was discussed and proposed on the list and what we have already decided on earlier in the working group:


·         SOSA and SSN use Slash URIs/IRIs

·         SOSA and SSN use different IRIs and are serialised in separate ontology files (everyone expect Kerry agreed on that one, although there is her proposal on the wiki stating the same: https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN#Compromise_Proposal_6_made_by_Kerry_January_2017)

·         SOSA and SSN may use different ontology namespaces

·         SOSA uses simple semantics as decided upon earlier (i.e. owl classes, datatype and object properties, inverse properties, but no domain/range and no other owl restrictions)

·         SSN imports SOSA

·         SSN introduces stronger semantics, using several types of OWL restrictions. As far as I can tell, four options have been presented to add these additional semantics through the import of SOSA:

1.       SSN introduces new classes/properties in its ontology namespace and introduces where appropriate equivalence relations to the class/property in SOSA

2.       SSN introduces new classes/properties in its ontology namespace and introduces subclass relations and where appropriate equivalence relations to the class/property in SOSA

3.       SSN reuses the IRI for classes/properties defined in SOSA and introduces further axioms that “narrow” their meaning, but does not introduce subclass or equivalence relations relying on the user to choose through the ontology namespace the interpretation of the ontology.

4.       A separate core essentially introduces vocabulary terms with no semantics, only a description and a label (very abstract, similar to the annotations that I have added to the wiki https://www.w3.org/2015/spatial/wiki/Mapping_Table and we had no time to discuss), but its own IRI and “ontology” namespace. Both SOSA and SSN import this vocabulary and extend it with different semantics, solving the issue that SSN has two different IRIs for some classes/properties as would be the case in Option 1-2.

I had the impression that there was no strong objection against any of these options in the call today, but several issues have been raised.

·         In option 3 the issue that has been raised was that users who use a class/property in their tool of choice may not know which semantic interpretation should be used in the given context.

·         Earlier on the mailing list, an issues has arising that in Option 3 SSN would use the SOSA IRIs for several classes/properties whereas the old SSN only had one IRI for those classes/properties. That could potentially be solved with Option 4.

Please let me know if I missed an option.

Cheers,
Armin