- 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