Re: SOSA/SSN integration architecture

From: Rob Atkinson <rob@metalinkage.com.au>
Subject: Re: SOSA/SSN integration architecture

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.


Ø  For the Platform class, SSN is assumed to add further (the same) axioms in all of these options. The System class is not defined in SOSA and is newly introduced in SSN (or in the core namespace as of Option 4). I will try to make that clearer with comments in the listings.

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)


Ø  Ok, do you think “common” would be a better term for “unified”? Raphaël made a similar comment yesterday that the option was a bit confusing. I already renamed “extension” to “module”.

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.


Ø  Your proposal is a possible technical implementation of Option 1. What your solution adds is the possibility that you have actually one storage location (Slash Directory) for the ontology on the server, but you distinguish by the MIME type what ontology file you want to get. There is a caveat with your solution, though. We agreed that SOSA and SSN are using Turtle, and Turtle has only one file extension, while the MIME type for OWL is application/owl+xml (i.e. tools will expect an XML serialisation, not Turtle). We could say that SOSA uses Turtle and .ttl as an extension and SSN RDF/XML and .owl as an extension. Not ideal, but doable. However, all other concerns of this solution would require either the mechanisms of Option 1 (reuse of terms) or Option 2 (introduction of new terms stating their equivalence).

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<mailto: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<mailto: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<mailto:raphael.troncy@eurecom.fr> & raphael.troncy@gmail.com<mailto:raphael.troncy@gmail.com>
Tel: +33 (0)4 - 9300 8242<tel:04%2093%2000%2082%2042>
Fax: +33 (0)4 - 9000 8200<tel:04%2090%2000%2082%2000>
Web: http://www.eurecom.fr/~troncy/