Re: SOSA/SSN integration architecture

have looked through arguments for votes, and its great to have people's
rationale's laid out.  Hopefully people are happy to examine these and
reconsider votes (I know I am happy to do this when I've misinterpreted).

so I'd like to dive into the option 5 comments:

Maxime: -1. This is the current de facto implementation and I could live
with it. The big problem of this solution is that in the same REC, terms
sometimes have namespace sosa:, sometimes namespace ssn:. Again, that might
confuse the end user.

*  "-1" is inconsistent with "I could live with it".
* I dont see that the same term ever has two different namespaces - this is
one of the distinguishing factors of this option - it explicitly avoids
that. Its more like option 1, but with a new namespace only for new terms
so no infrastructure tricks required.

Armin: 0. Since terms are just reused in SSN even if the semantics are
refined, it is impossible to access the stronger semantics of a term
directly through its URI. As this is not Linked Data compliant, I see
Option 2 as superior to this one.

* "Linked Data compliant" is a strong statement - and Linked Data makes no
statements at all about its relationship with OWL.
* Option 2 doesnt address the full semantics issue, except by forcing
instances to use ssn (wrtitten as module:) - so it only does it at the
expense of SOSA and SSN instances being different, and it purs burden on
client to negotiate equivalence relationships. Its a far higher burden on
users who dont expect to have to load and negotiate OWL to understand the
data. Option 2 is no more "Linked Data Compliant" because Linked Data is
also silent on how to handle non-unique naming at run time. In fact Option
2 is not Linked Data in that it demands using OWL to get definitions
transitively via equivalences rather than simple links.
* one option would be for sosa to owl:import sosa+owl.ttl  - so non OWL
environments will just ignore this, and OWL ones will access full semantics


I will add another option for this "clean case..." - the more we look at
this problem the more the mixing of concerns (axiomitisation vs extension)
in SSN over-complicates the implementation.

rob

On Mon, 27 Feb 2017 at 23:10 Armin Haller <armin.haller@anu.edu.au> wrote:

> 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> 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> 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>
> *Date: *Sunday, 26 February 2017 at 10:44 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
>
>
>
> 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> 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>
> *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/
>
>