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/
>
>