RE: SOSA/SSN integration architecture

I think there is another option, using the ‘hijacking’ pattern, where SSN adds axioms to SOSA classes, rather than sub-classing or equivalent-classing. I have added this (mention only, no code snippets) as Option 3b.

Of course that approach begs the question of what graph (set of axioms) you get for each class, since the IRI is the same. This might be solved using owl:imports (or rdfs:isDefinedBy) in the data instance where the richer axiomatization is intended. That makes the data provider responsible to state explicitly which set of axioms they intend … though of course is not standard practice.

I also suggest that in order to fully see the implications of the different options, we need some example data instances alongside the schema/ontology snippets.

But clearly there are pros and cons with each solution, else we would have resolved this already. So which compromise can we live with?

Simon


From: Armin Haller [mailto:armin.haller@anu.edu.au]
Sent: Thursday, 23 February, 2017 17:16
To: public-sdw-wg@w3.org
Subject: SOSA/SSN integration architecture

Dear all,

In today’s plenary meeting it seemed as if we cannot separate the mechanics of the namespace issue<https://www.w3.org/2015/spatial/wiki/NamespaceIssue> from the different options of integrating the SOSA core with SSN.

I have now tried to summarise these integration options on a separate wiki page: https://www.w3.org/2015/spatial/wiki/Integration_Issue


I have come up with *four* options that have been proposed in one way or the other over the last couple of months. I tried to keep the explanation of the four options as abstract as possible. Please, especially the SSN subgroup members, do not add technical details on how each option would be achieved through redirects on the server etc. I have also deliberately chosen the word “Implications” rather than “Advantages” and “Disadvantages”, because what is an Advantage for someone may be a Disadvantage for someone else.

The ontology experts in the group, please do have a look at these options and correct any potential mistakes. Also, if you can think of a radically different option, please do add it to the Wiki. If it is only a small departure from an existing option, maybe add it to the implications section rather than creating a new option instead. For example, not all relations in Option 3 necessarily must be subclass/subproperty relations, but can also be equivalent class/property. But subclass is the axiomatically weaker one.

I hope that this helps us to arrive at a resolution in our next SDW meeting.

Kind regards,
Armin