Re: Architecture of SOSA/SSN integration

Hi

thanks for taking the time to lay it out. I'm not sure that the case where
OWL axioms _exactly_ reflect the SOSA text definitions is fully expressed
here as an option?

What about the option that, (following the DC, DCAT, DCAT-AP pattern):

SOSA provides text definitions
SOSA-OWL (provides OWL axioms matching _exactly_ the definitions in SOSA)
SSN is an "application profile" that provides further constraints to
SOSA-OWL - such as cardinality, equivalent names more specific to sensors
that matches the existing SSN usage.

I dont that this is not quite the same as option 3 or 4, at least in
interpretation, in that semantics are always consistent, its only a
question of whether an instance conforms to SOSA or SOSA and SSN. AFAICT
SImon's investigation suggests this is possible and I beleive its
consistent with Kerry's

We could, IMHO, use content-negotiation to get SOSA-OWL from the SOSA
namspace IRI if the user asks for OWL - but use the lightweight SOSA
definitions if the client does not claim to understand OWL.

Rob


On Wed, 1 Feb 2017 at 11:12 Krzysztof Janowicz <janowicz@ucsb.edu> wrote:

> 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)
>
> ·         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
>
>