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:31:54 -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: <863722c7-0f0f-e31d-7571-0adbb839593f@ucsb.edu>
And this is exactly what makes me so worried :-)

On 02/28/2017 11:30 AM, Joshua Lieberman wrote:
> And yet we are trying to conjure up distinct scopes of execution. ;>)
>
>> On Feb 28, 2017, at 2:27 PM, 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> 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"
>>>>>>>             <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
>


-- 
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 22:02:43 UTC

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