Re: SOSA/SSN integration architecture

Version I edited has this a 3b/1b - so not sure what else changed since -
but in the context of 3a I had read this as ssn "hijacking" sosa meaning
adding restrictions that changed its meaning. If the meaning of "hijacking"
means just adding axioms already expressed in sosa text then I believe
these are the same....

AFAICT the updated 2b/3c version is now identical to Option 5, without the
confusing language.

and IMHO much better as a separate option than something bundled in as a
sub-option of something otherwise fundamentally different (e.g. the nub of
option 2 using subclasses to create proxies in a new namespace)
(the ssn:System superclass came from a different conversation and I believe
is the intent here and relevant to the discussion - i think defining a more
general class from a core module is a pattern we need to provide guidance
about the best practice.



On Sun, 26 Feb 2017, 4:36 PM Armin Haller <armin.haller@anu.edu.au> wrote:

I agree that hijacking conveys a negative meaning. Raphaël already
mentioned earlier that he does not want to convey that negative meaning, so
your renaming to “precises” is good.



We could make Option 2b/3c just Option 5. I will wait for Rob’s response,
but as it looks to Simon and me, these two options are the same.



*From: *Maxime Lefrançois <maxime.lefrancois@emse.fr>
*Date: *Saturday, 25 February 2017 at 12:30 am
*To: *Rob Atkinson <rob@metalinkage.com.au>, Armin Haller <
armin.haller@anu.edu.au>, Raphaël Troncy <raphael.troncy@eurecom.fr>, "
public-sdw-wg@w3.org" <public-sdw-wg@w3.org>


*Subject: *Re: SOSA/SSN integration architecture



Dear all,





I checked the options 2 to 4 and corrected some inconsistencies with
respect to the URIs of the ontologies. :

 - the URI of the SOSA ontology is once written http://www.w3.org/ns/sosa/,
and once written unify:localname. From this one can infer that ''unify''
equals "sosa", and ''localname'' equals the empty string.

 - the URI of the SSN ontology is also written unify:localname, so it has
 the  same URI as the SOSA ontology.





The object of the rdfs:isDefinedBy is often the ontology where the term is
defined, not the namespace.

I updated the snippets to reflect this. Please tell me if you think
otherwise.





I believe term "hijacking" is not well chosen here. It's conveys a negative
meaning, and does not reflect what is actually happening:

SSN "refines", or "precises" the semantics of some SOSA terms. I changed
hijacking to "precises".





In option 2b/3c, SOSA and SSN are  not in the same namespace, hence I
hardly see why it would  be considered  as a variant of option 2.



I just added some spaces in option 5 to correct the "code" sections.



Kind regards,

Maxime



Le ven. 24 févr. 2017 à 09:03, Rob Atkinson <rob@metalinkage.com.au> a
écrit :

And the mime type handling is a corner case that only applies to the case
of clients who want owl and gind resources that dont use explicit imports -
ir instead choose to rely on namespace only (if indeed such clients exist)



On Fri, 24 Feb 2017, 6:36 PM Rob Atkinson <rob@metalinkage.com.au> wrote:

No the difference is no neec to subclass sosa terms to ssn equivalents.

Perhaps this makes no difference after owl entailment but it makes a big
difference in that ssn instances are not sosa instances without extra
reasoning.

Rob



On Fri, 24 Feb 2017, 4:23 PM Armin Haller <armin.haller@anu.edu.au> wrote:

Now that you have described your option, I don’t see any difference to
Option 3b which itself is a slight variant of Option 2 (reusing of terms
ONLY rather than reintroducing terms within the new namespace).



You define terms in SOSA.

In SSN you import these terms and add axioms.

If the term has not been introduced in SOSA, you define it in the new
module-specific namespace (SSN).



If I interpret this correctly, it is exactly Option 3b with the addition of
the mechanism of handling MIME types.



*From: *Rob Atkinson <rob@metalinkage.com.au>
*Date: *Friday, 24 February 2017 at 1:58 pm
*To: *Rob Atkinson <rob@metalinkage.com.au>, Armin Haller <
armin.haller@anu.edu.au>, Maxime Lefrançois <maxime.lefrancois@emse.fr>,
Raphaël Troncy <raphael.troncy@eurecom.fr>, "public-sdw-wg@w3.org" <
public-sdw-wg@w3.org>


*Subject: *Re: SOSA/SSN integration architecture



Have added option 5 and some clarifications to issue scope (i.e. what does
extended mean)

Rob



On Fri, 24 Feb 2017 at 13:13 Rob Atkinson <rob@metalinkage.com.au> wrote:



IMHO My proposal is not an implementation of option 1,  because new terms
in SSN are added to a new namespace, and only axioms 100% compatible to
SOSA are allowed in SSN against SOSA defined terms.



Option 1 seems to be explicitly about the opposite strategy: new terms in
SSN in the SOSA namespace and heroics in the infrastructure to manage
finding these.



I'm convinced its different, and simpler than the existing options and will
add it - we can always remove it if people can prove one of the other cases
is equivalent,



Rob









On Fri, 24 Feb 2017 at 10:38 Armin Haller <armin.haller@anu.edu.au> wrote:

Thanks!



I have removed the **bold** in the implication of Option 1. I do want to
keep the implications neutral. Some people may care a lot about that
specific implication, some others not.



I also deleted the statement “always the case with slash-based URIs” with
the “One needs to dereference a term to figure out where this term is
defined”. Raphaël added the yesterday as an implication. The commonly
expected behaviour/expectation with Ontology Slash URIs on the Linked Data
Web is that the ontology sits at the directory level of that term. I think
it is a valid point to make in this option that the behaviour here and in
Option 2 would be different. Again, some people may care about that, some
others not.



*From: *Maxime Lefrançois <maxime.lefrancois@emse.fr>
*Date: *Friday, 24 February 2017 at 6:09 am
*To: *Raphaël Troncy <raphael.troncy@eurecom.fr>, Armin Haller <
armin.haller@anu.edu.au>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>


*Subject: *Re: SOSA/SSN integration architecture



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/