W3C home > Mailing lists > Public > public-sdw-wg@w3.org > February 2017

Re: SOSA/SSN integration architecture

From: Rob Atkinson <rob@metalinkage.com.au>
Date: Thu, 23 Feb 2017 21:26:49 +0000
Message-ID: <CACfF9Lybo_qFh2HNFk6+1NLvOTd0-Tdp5Kj7jn7jV1UriUPZBQ@mail.gmail.com>
To: Maxime Lefrançois <maxime.lefrancois@emse.fr>, Raphaël Troncy <raphael.troncy@eurecom.fr>, Armin Haller <armin.haller@anu.edu.au>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
I still think this is inaccessible to the wider group because its never
clear if the examples are adding axioms, defining new terms, or changing
the meaning (intent) of original SOSA.

These three cases need to be treated separately,

I cant easily see what the options mean against all three potential cases -
the only possible match I see i
"One unified namespace and a separate module namespace ONLY for terms that
are further axiomatized in SSN. Use of equivalent class and equivalent
property relations in SSN to SOSA terms."

except that the two clauses:
a) "One unified namespace and a separate module namespace ONLY for terms
that are further axiomatized in SSN"
b) "Use of equivalent class and equivalent property relations in SSN to
SOSA terms."

 are IMHO both inconsistent and an unnecessary mixing of quite distinct
concerns

(inconsistent in that a unified namespace means there are not new SSN terms
minted anyway, so no need for equivalences, and distinct, because the
equivalence mechanisms need to be discussed only when we have distinct
things to equivocate (pun intended :-) ) over)

I also think option 2 is unnecessarily bound up in mechanisms for
redirection.

I believe we need a simpler version of Option 2 for which standard
ontology/namespace/files mappings are used, with the only
standard-but-perhaps-poorly-understood behaviour is that if you ask for a
term in SOSA namespace and ask for OWL (using MIME type) you set SSN -
which acts as an alternative representation of the same resources (SOSA
defs).

the only two sanity checks i see in this are:
1) when you get OWL you may also get a few SSN terms you need to ignore -
but AFAICT these dont change semantics or add anything that will affect
reasoning over SOSA terms.
2) SSN imports SOSA, and SSN users import  SSN - the only issue here is
that OWL MIME types are probably not used consistently in the wild and
tools are likely to be loose and may not correctly set the MIME type - the
possible solution is for SSN to import a specific SOSA-OWL IRI which
redirects to the same resource.

Even though i have suggested this many times AFAICT at no stage has an
argument been put forward that its incorrect, unworkable or inconsistent
with practices - it seems to have been ignored in the process of arguing
over other aspects, such as use of equivalence axioms.

If people concur this is not currently an available option I will add as
Option 5a and 5b (with the axioms and extensions in SSN in a single file or
two files)

Rob


On Fri, 24 Feb 2017 at 06:09 Maxime Lefrançois <maxime.lefrancois@emse.fr>
wrote:

> Dear all,
>
> I updated option 1, and highlighted its multiple variants,
>
> I would like to highlight variant sosa1, for which looking up the unified
> namespace leads to the SOSA ontology.
>
> Kind regards,
> Maxime
>
>
> Le jeu. 23 févr. 2017 à 12:12, Raphaël Troncy <raphael.troncy@eurecom.fr>
> a écrit :
>
> > ➢ Done, changed it on the Wiki. I think that makes it clearer.
>
> Thanks.
>
> > ➢ You can use the ontology URI to figure out which terms are in the core
> (SOSA). It is the same behaviour as in Option 1. In Option 1 you also
> either need to dereference each term to figure out where it is defined or
> to use the ontology URI of SOSA or SSN explicitly. If you think this is an
> important caveat, you can spell that out in the implication for both
> options.
>
> I agree, this is true for both options 1 and 2. Done, I have added for
> each: "* 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."
>
> Note: Option 3b is still Option 3b and not a variant of Option 1
> although it could be.
>
>    Raphaël
>
> --
> Raphaël Troncy
> EURECOM, Campus SophiaTech
> Data Science Department
> 450 route des Chappes, 06410 Biot, France.
> e-mail: raphael.troncy@eurecom.fr & raphael.troncy@gmail.com
> Tel: +33 (0)4 - 9300 8242 <04%2093%2000%2082%2042>
> Fax: +33 (0)4 - 9000 8200 <04%2090%2000%2082%2000>
> Web: http://www.eurecom.fr/~troncy/
>
>
Received on Thursday, 23 February 2017 21:34:20 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:30 UTC