Re: SOSA/SSN integration architecture

Kerry,

This requires infrastructure to implement:

"

   1. If you type unify:Platform in your browser you get to the axioms of
   the Platform class defined by SOSA.
   2. If you type unify:System in your browser you get to the axioms of the
   System class defined by SSN."


If you try to further refine it (add new terms - e.g. a class of sensors -
to the same unify: namespace) you will need to negotiate to change that
implementation...

Rob

On Wed, 8 Mar 2017 at 00:02 Kerry Taylor <kerry.taylor@anu.edu.au> wrote:

> Rob,
>
> Noting on the wiki here:
> https://www.w3.org/2015/spatial/wiki/Integration_Issue
>
> You said of option 1 that  it “relies on non-standard infrastructure
> mechanism that doesn't provide significant additional information. Also the
> scalability of this option is unaddressed - is the pattern safe in a
> transitive environment - can someone extend SSN with further
> specialisations and use the same mechanism without modifying that
> infrastructure - it appears not.”
>
>
>
> I see no non-standard infrastructure nor any scalability issue --- the
> answer to your “further specialisations” doubts seems a clear yes to me. No
> problem at all. What is the problem you see that I am missing please?
>
> -Kerry
>
>
>
> *From:* Rob Atkinson [mailto:rob@metalinkage.com.au]
> *Sent:* Thursday, 2 March 2017 10:55 AM
> *To:* Armin Haller <armin.haller@anu.edu.au>; janowicz@ucsb.edu; Rob
> Atkinson <rob@metalinkage.com.au>; Joshua Lieberman <
> jlieberman@tumblingwalls.com>
> *Cc:* Maxime Lefrançois <maxime.lefrancois@emse.fr>; Raphaël Troncy <
> raphael.troncy@eurecom.fr>; public-sdw-wg@w3.org
>
>
> *Subject:* Re: SOSA/SSN integration architecture
>
>
>
>
>
> It has always been my impression we have been mixing these concerns -
> axioms vs specialisations - rdfs:subClassOf does use the same approach, but
> because a class is always a subClassOf itself it works - but doesnt
> adequately document what the intent actually is.
>
>
>
> This is a reason why i think option 8 is superior - it makes it absolutely
> clear exactly what is happening in each module, and this is very much worth
> the minimal overhead of an extra file, that is invisible - only OWL users
> care about it and they transitively import it with no extra effort.
>
>
>
>
>
>
>
> On Thu, 2 Mar 2017 at 09:45 Armin Haller <armin.haller@anu.edu.au> wrote:
>
>
>
>
>
> *From: *Krzysztof Janowicz <janowicz@ucsb.edu>
> *Reply-To: *"janowicz@ucsb.edu" <janowicz@ucsb.edu>
> *Date: *Wednesday, 1 March 2017 at 6:59 am
> *To: *Rob Atkinson <rob@metalinkage.com.au>, Joshua Lieberman <
> jlieberman@tumblingwalls.com>
> *Cc: *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
>
>
>
> On 02/28/2017 11:55 AM, Rob Atkinson wrote:
>
>
>
> I dont think Simon meant any form of change - i.e. are talking about
> adding axioms to support the text definition, in a particular formalism.
>  (i also originally misunderstood the intention to be referring to SSN
> making narrower scoped subclasses.)
>
>
>
> therefore -1 for anything that suggests change: hijack, override, overload
> all fail that criterion.
>
>
>
>
>
>
> But many of the proposals do just that, right?
>
> Ø  No, the assumption is for all options that they are only adding
> axioms, not “overriding”, in support of the text definition (or at the very
> least, not violating any text definition) in SOSA. For example, SSN may add
> minimum cardinalities which, however, should be reflected in the textual
> definition of SOSA.
>
>
>
> "Precises" is a bit weird, but not so misleading - it feels like "creating
> a precis" - i.e. a summary, which is not quite right - unless you consider
> it  a precis of the text definitions expressed in OWL...
>
>
>
> axiomatise, adds axioms to, formalises  ... ?
>
>
>
>
>
>
>
> On Wed, 1 Mar 2017 at 06:27 Krzysztof Janowicz <janowicz@ucsb.edu> wrote:
>
> Yes, but note that the idea of /encapsulation/ does not exist in RDF, OWL,
> and so forth.
>
>
>
> On 02/28/2017 11:25 AM, Joshua Lieberman wrote:
>
> My mistake. The term I intended was “Overriding” which is a local
> re-implementation of an existing method + signature. Generally the intent
> is to provide similar behavior but in a different execution context.
>
>
>
> Josh
>
>
>
> On Feb 28, 2017, at 2:19 PM, Krzysztof Janowicz <janowicz@ucsb.edu> wrote:
>
>
>
> On 02/28/2017 11:06 AM, Joshua Lieberman wrote:
>
> “Overloading” ?
>
>
> I am a bit more concerned about SOSA, SSN, SSN-OLD, SSN+DUL, and so forth
> all creating different results when performing reasoning (or even just
> simple SPARQL queries). IMHO, we need to be as clear as possible about what
> to expect when using these classes and enable users to clearly distinguish
> between them. If I see a triple and I have no way of immediately knowing
> what it implies, that would be very concerning to me (but maybe not to
> others, or maybe I am simply missing something). This is also true for
> overloading in programming languages, the method's signature tells you what
> has changed.
>
> Best,
> Jano
>
>
>
>
> On Feb 28, 2017, at 1:58 PM, Krzysztof Janowicz <janowicz@ucsb.edu> wrote:
>
>
>
> On 02/25/2017 09:36 PM, Armin Haller 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.
>
>
> Yes, but this depends a bit on what more we add, especially if this would
> include existential quantifications.
>
> Jano
>
>
>
>
> 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>
> <maxime.lefrancois@emse.fr>
> *Date:* Saturday, 25 February 2017 at 12:30 am
> *To:* Rob Atkinson <rob@metalinkage.com.au> <rob@metalinkage.com.au>,
> Armin Haller <armin.haller@anu.edu.au> <armin.haller@anu.edu.au>, Raphaël
> Troncy <raphael.troncy@eurecom.fr> <raphael.troncy@eurecom.fr>,
> "public-sdw-wg@w3.org" <public-sdw-wg@w3.org> <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
>
>
>
>
>
> --
>
> Krzysztof Janowicz
>
>
>
> Geography Department, University of California, Santa Barbara
>
> 4830 Ellison Hall, Santa Barbara, CA 93106-4060
>
>
>
> Email: jano@geog.ucsb.edu
>
> Webpage: http://geog.ucsb.edu/~jano/
>
> Semantic Web Journal: http://www.semantic-web-journal.net
>
>