Re: SOSA/SSN integration architecture

Hi,

In case of Option 2 as in Option 1 I don’t have a strong preference in terms of values for “unify” or “module”. Logically SOSA may be more appropriate for “unify”, but I think some group members, because of the existing brand SSN prefer SSN for “unify”, which I wouldn’t mind either.

Option 2 introduces equivalence relations and allows therefore access to the more precise definitions of a term through their URI. In Option 6, which otherwise is very similar, you can’t. For me the trade-off of introducing a couple of equivalence relations is worth the ability to access terms directly. I have removed the word “elegant” and detailed why I prefer Option 2 over 6.

Cheers,
Armin

From: Maxime Lefrançois <maxime.lefrancois@emse.fr>
Date: Monday, 27 February 2017 at 10:39 pm
To: Armin Haller <armin.haller@anu.edu.au>, Rob Atkinson <rob@metalinkage.com.au>, Raphaël Troncy <raphael.troncy@eurecom.fr>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
Subject: Re: SOSA/SSN integration architecture

Hi Armin, all,

Armin, just in case we vote for option2, could you state your preferences in terms of values for ''unify'', ''SOSALocalName'', ''SOSALocalName'', ''module''?

why is it that using namespaces "unify:" and "module:" in option 2 makes it more elegant than using namespaces "sosa:" and "ssn:" in option 6  to you?
(if you substitute ''unify:'' by ''sosa:'' and ''module:'' by ''ssn:'', you get very close to option 6)

Kind regards,
Maxime

Le lun. 27 févr. 2017 à 11:53, Maxime Lefrançois <maxime.lefrancois@emse.fr<mailto:maxime.lefrancois@emse.fr>> a écrit :
Dear all,

I added a list of high level PROPOSAL proposals, these may help us proceed by dichotomy among the options.

The table cells contain a high level description of the options, not the implications.
What is it that confuses you? the lines headers? the columns headers? the terms "declare" and "refines"? something else?

Two of the new options in the table are now detailed as option 6 and option 7.

There is a "vote" section under each of these options for us to express our preferences.
Would love option 1 -  Strongly opposed to options 2, 3, 4 - Could live with options 5, 6, 7

Some of Rob's ideas in former Option are gathered in https://www.w3.org/2015/spatial/wiki/Make_SSN_reachable_from_SOSA_using_seeAlso_and_comment


Kind regards,
Maxime

Le lun. 27 févr. 2017 à 07:23, Armin Haller <armin.haller@anu.edu.au<mailto:armin.haller@anu.edu.au>> a écrit :
Thanks Maxime. I have to say the table confuses me a bit, though. Not sure if it helps others, who don’t necessarily intimately understand the options. Others?

I have merged Simon’s and Rob’s options and denoted it as Option 5.

I think the page is fairly stable now and we have discussed potential derivations of each Option. I would ask everyone now to have their opinions heard in terms of preference. Maybe also mention what Option you can definitely not live with and what options are acceptable to you as a compromise.



From: Maxime Lefrançois <maxime.lefrancois@emse.fr<mailto:maxime.lefrancois@emse.fr>>
Date: Sunday, 26 February 2017 at 10:44 pm
To: Armin Haller <armin.haller@anu.edu.au<mailto:armin.haller@anu.edu.au>>, Rob Atkinson <rob@metalinkage.com.au<mailto:rob@metalinkage.com.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 added a section https://www.w3.org/2015/spatial/wiki/index.php?title=Integration_Issue&action=submit#Possible_options_in_a_nutshell with a table that summarizes several options, including some that are not detailed in the wiki page.


About Option 5:

To me it's also equivalent to option 2b/3c, but it provides interesting features that can be propagated to all of the other options. Some precisions:

The introductory sentence is misleading:
 - It mentions that it's "same as option 1, except...". Yet, two namespaces are defined in option 5, whereas only one is defined in option 1. I would not say option 5 is the "same as option 1" because of this.
 - It says "new terms are introduced into a module-specific namespace". It appears in the snippets that this "modules-specific namespace" is the ssn: namespace. I would rephrase this sentence as "New terms are introduced in the ssn: namespace"
 - It says "any semantic changes to definitions require new terms". It is also assumed in all of the other options that SSN brings no semantic change to SOSA terms, but instead precises their semantics. In those cases where an "equivalence" relation is used between a SOSA term and its duplicate SSN term, then SSN terms indirectly precise the semantics of the duplicated SOSA terms.
 - About "Behaviours are consistent with W3C architecture, and will work best with compliant tools, but are recoverable (i.e. supported by documentation hints) if tools make loose assumptions.", see my comments below.

snippet sosa.ttl:
 - it mentions "sosa:Ontology", which is not defined (is it a typo and you wanted to use ssn:Ontology ?)
 - the rdfs:comment s provides relevant information and could be used in the other options. I suggest we add this triple along with "rdfs:seeAlso ssn:Ontology" in sosa.ttl snippets of other options.

snippet ssn.ttl:
 - the rdfs:comment s provides relevant information and could be used in the other options. I suggest we add this triple in ssn.ttl snippets of other options.
 - it mentions "unify:Platform" which is not defined in this option (is it a typo and you wanted to use sosa:Platform ?)
 - rdfs:subClassOf ssn:System ; should either be in all options, or nowhere. I suggest we delete.

snippets FlibberSensors.ttl and FlobberSensors.ttl
 - I like the definition of Flibber and Flobber in the urban dic :-) are they commonly used like Foo and Bar ?
 - these snippets are relevant to any of the other options as well. I suggest either we add them there, or remove altogether .

"And the final mechanism: if you ask for sosa: or sosa:Definitions using mimetype for OWL, then you get redirected to ssn:Ontology". I suggest we do not implement this mechanism.
 - as you "303 redirect" to the URL of the SSN ontology, I agree that this mechanism conforms to the Web architecture principles. i.e., your are not "200 OK serving" two different RDF Graphs at the same URL.
 - This mechanism may be documented in the spec, but existing Sem Web will ignore it. In fact, most Sem Web tools accept preferably application/rdf+xml. This is the case for OWLAPI [1], and is therefore the case in Protégé. What's worse, any tool that accepts preferably application/owl+xml will never be able to load SOSA from its IRI. Yet, SOSA is a perfectly valid OWL DL Ontology, although it has very few axioms.

Kind regards,
Maxime

[1] - see class DocumentSource.java and its variable REQUESTTYPES, https://github.com/owlcs/owlapi/search?q=openConnection


Le dim. 26 févr. 2017 à 06:36, Armin Haller <armin.haller@anu.edu.au<mailto:armin.haller@anu.edu.au>> a écrit :
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<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 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<mailto:raphael.troncy@eurecom.fr> & raphael.troncy@gmail.com<mailto:raphael.troncy@gmail.com>
Tel: +33 (0)4 - 9300 8242<tel:04%2093%2000%2082%2042>
Fax: +33 (0)4 - 9000 8200<tel:04%2090%2000%2082%2000>
Web: http://www.eurecom.fr/~troncy/