Re: SOSA/SSN integration architecture

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<mailto: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<mailto: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<mailto: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><mailto:maxime.lefrancois@emse.fr>
Date: Saturday, 25 February 2017 at 12:30 am
To: Rob Atkinson <rob@metalinkage.com.au><mailto:rob@metalinkage.com.au>, Armin Haller <armin.haller@anu.edu.au><mailto:armin.haller@anu.edu.au>, Raphaël Troncy <raphael.troncy@eurecom.fr><mailto:raphael.troncy@eurecom.fr>, "public-sdw-wg@w3.org"<mailto:public-sdw-wg@w3.org> <public-sdw-wg@w3.org><mailto: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<mailto: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<mailto: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<mailto: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<mailto:rob@metalinkage.com.au>>
Date: Friday, 24 February 2017 at 1:58 pm
To: Rob Atkinson <rob@metalinkage.com.au<mailto:rob@metalinkage.com.au>>, Armin Haller <armin.haller@anu.edu.au<mailto:armin.haller@anu.edu.au>>, Maxime Lefrançois <maxime.lefrancois@emse.fr<mailto:maxime.lefrancois@emse.fr>>, Raphaël Troncy <raphael.troncy@eurecom.fr<mailto:raphael.troncy@eurecom.fr>>, "public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>" <public-sdw-wg@w3.org<mailto: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<mailto: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<mailto: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<mailto:maxime.lefrancois@emse.fr>>
Date: Friday, 24 February 2017 at 6:09 am
To: Raphaël Troncy <raphael.troncy@eurecom.fr<mailto:raphael.troncy@eurecom.fr>>, Armin Haller <armin.haller@anu.edu.au<mailto:armin.haller@anu.edu.au>>, "public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>" <public-sdw-wg@w3.org<mailto: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<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




--

Krzysztof Janowicz



Geography Department, University of California, Santa Barbara

4830 Ellison Hall, Santa Barbara, CA 93106-4060



Email: jano@geog.ucsb.edu<mailto:jano@geog.ucsb.edu>

Webpage: http://geog.ucsb.edu/~jano/


Semantic Web Journal: http://www.semantic-web-journal.net