Re: Architecture of SOSA/SSN integration

Thanks a lot Armin for providing this detailed summary!

Personally, I would be concerned about 3 and 4. 3 for formal reasons as 
described during the meeting (e.g., it will not be clear what the 
assertion sosa:Platform(platform1) actually refers to) and 4 because we 
are making things unnecessarily complicated and this will effect the end 
users particularly Web developers, citizen science use cases, 'naive' 
users, etc. of SOSA. 4 will also not really fix the issue of potentially 
incompatible semantics between SOSA and SSN and we will be asked about 
their alignment.

> ·SOSA and SSN may use different ontology namespaces

I think this would be really important as well especially as it will 
avoid confusion among many of our more 'naive' users and it will make 
immediately clear which classes are used.


> everyone expect Kerry agreed on that one, although there is her 
> proposal on the wiki stating the same

I think this is important to highlight, namely that we all votes +1 on 
both proposals and Kerry voted "[13:58] <kerry> I voted -1 every time". 
This makes me question the term 'compromise' in Kerry's proposal and it 
leaves me deeply worried.

Thanks again.
I am looking forward to jointly resolving these issues and moving forward.
Jano


On 01/31/2017 03:39 PM, Armin Haller wrote:
>
> 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) 
> <https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN#Compromise_Proposal_6_made_by_Kerry_January_2017%29>
>
> ·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
>


-- 
Krzysztof Janowicz

Geography Department, University of California, Santa Barbara
4830 Ellison Hall, Santa Barbara, CA 93106-4060

Email: jano@geog.ucsb.edu
Webpage: http://geog.ucsb.edu/~jano/
Semantic Web Journal: http://www.semantic-web-journal.net