Re: SOSA/SSN integration architecture

Agreed.

On Mon, 27 Feb 2017 at 09:16 <Simon.Cox@csiro.au> wrote:

> I used the term ‘hijacking’ because I believe in the past that has been
> used for every case of adding axioms to someone else’s class or property. (
>
>
>
> But the key idea was that creating a new class in the SSN namespace that
> is equivalent to a class in the SOSA namespace may not be necessary. (But
> may only be acceptable where the additional axioms only formalize
> definitions provided in text in SOSA, or maybe not.)
>
>
>
> I think this matches your intention with Option 5.
>
>
>
> *From:* Rob Atkinson [mailto:rob@metalinkage.com.au]
> *Sent:* Sunday, 26 February, 2017 22:48
> *To:* Armin Haller <armin.haller@anu.edu.au>; Maxime Lefrançois <
> maxime.lefrancois@emse.fr>; Rob Atkinson <rob@metalinkage.com.au>;
> Raphaël Troncy <raphael.troncy@eurecom.fr>; public-sdw-wg@w3.org
>
>
> *Subject:* 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/
>
>