W3C home > Mailing lists > Public > public-sdw-wg@w3.org > February 2017

Re: SOSA/SSN integration architecture

From: Krzysztof Janowicz <janowicz@ucsb.edu>
Date: Tue, 28 Feb 2017 11:27:27 -0800
To: Joshua Lieberman <jlieberman@tumblingwalls.com>
Cc: 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" <public-sdw-wg@w3.org>
Message-ID: <dc15e49c-8742-d0e7-c35c-0f7a60b6f1d9@ucsb.edu>
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>
>>>>> *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 
>>>>> writtenhttp://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
>>>>>             <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> 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
>>>>>                         <tel:04%2093%2000%2082%2042>
>>>>>                         Fax:+33 (0)4 - 9000 8200
>>>>>                         <tel:04%2090%2000%2082%2000>
>>>>>                         Web:http://www.eurecom.fr/~troncy/
>>>>>
>>>>
>>>>
>>>> -- 
>>>> 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
>>>
>>
>>
>> -- 
>> 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
>


-- 
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
Received on Tuesday, 28 February 2017 19:34:15 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:30 UTC