- From: Nathan Rixham <nathan@webr3.org>
- Date: Sat, 21 May 2016 16:50:45 +0100
- To: Simon Spero <sesuncedu@gmail.com>
- Cc: Harry Halpin <hhalpin@ibiblio.org>, Melvin Carvalho <melvincarvalho@gmail.com>, Pat Hayes <phayes@ihmc.us>, Phil Archer <phila@w3.org>, Semantic Web IG <semantic-web@w3.org>
- Message-ID: <CANiy74ws+LKA4=P58xOkz+R9+19ovGiF-urbDqrigmsKyoVxeQ@mail.gmail.com>
> On the other hand, there is no specific reason not to continue using http: IRIs as names It seems perfectly rational for somebody to want to say refer to #me as https://example.com/Alice#me rather than http://example.com/Alice#me please ( con:preferredURI ). Likewise for any name. More so if for technical or financial reasons they cannot eternally support their old name in a linked-data friendly way. Let's say HostGator or GoDaddy migrate all shared hosting accounts to https supporting 301s only for 6 months only. > owl:sameAs x:canonical rdfs:subPropertyOf owl:sameAs . x:canonical rdfs:subPropertyOf ??? . What to use for ???, where ??? is like http://www.w3.org/2000/10/swap/pim/contact#preferredURI but for any name. Ultimately I guess we're just looking for a property that when encountered informs a developer or system to perform a graph update and replace aaa with bbb. On Sat, May 21, 2016 at 4:16 PM, Simon Spero <sesuncedu@gmail.com> wrote: > sameAs is correct, though under under the OWL Direct Semantics, it may > not give all the desirable entailments if the IRI denotes a Class or > *Property. Using equivalentClass / equivalentProperty axioms gives desired > result. > > On the other hand, there is no specific reason not to continue using > http: IRIs as names, and using a different protocol if those names are > converted to locators. > > Simon > > > > On Sat, May 21, 2016, 10:40 AM Nathan Rixham <nathan@webr3.org> wrote: > >> Why not owl:sameas? Is it technically incorrect? >> >> If it's the correct property to use and widely understood + supported, >> saying it's been used incorrectly previously doesn't hold much weight as an >> argument against using it correctly to solve a web scale real world problem >> simply. >> On 21 May 2016 2:28 pm, "Simon Spero" <sesuncedu@gmail.com> wrote: >> >>> There is no necessary between an IRI used in any position in an RDF >>> triple, and any #$InformationBearingObject that may be returned as a result >>> of interpreting the lexical form of such an IRI as a set of procedural >>> directives. >>> >>> There is thus no reason why Stigmergic Web applications cannot >>> interpret these lexical forms such that they perform different actions, >>> with no required changes anywhere else. >>> >>> Meet the new sameAs, same as the old sameAs. >>> >>> Simon >>> On May 21, 2016 12:53 AM, "Harry Halpin" <hhalpin@ibiblio.org> wrote: >>> >>>> Given that the Semantic Web use of HTTP URIs basically means that any >>>> use of 'follow your nose' is easily subverted by anyone with access to the >>>> raw HTTP stream, we should just update the Semantic Web specs and reasoners >>>> so that TLS is enforced by default and HTTP = HTTP(S). >>>> >>>> While it is true that some normal web-pages *can* serve different >>>> content at TLS than non-TLS, it's currently considered pathological. >>>> >>>> If the Semantic Web doesn't gracefully deal with the upgrade from HTTP >>>> to TLS, it will date itself quite quickly and will not be usable for any >>>> real-world usage (notice almost all major sites now are moving to TLS) >>>> outside of enterprise use within a firewall or usages where there's no >>>> 'follow your nose' effort. In the latter case, I'm not sure if using HTTP >>>> URIs makes sense to begin with. >>>> >>>> Note that the upgrade should be relatively cost-free, see the "Let's >>>> Encrypt" effort for free TLS certs. >>>> >>>> On Fri, May 20, 2016 at 6:04 PM, Pat Hayes <phayes@ihmc.us> wrote: >>>> >>>>> >>>>> On May 20, 2016, at 5:02 PM, Nathan Rixham <nathan@webr3.org> wrote: >>>>> >>>>> .... >>>>> An x:alias predicate which asserts that one name (IRI) is an alias of >>>>> another name (IRI) would be very useful. <a#b> x:alias <c#d> . >>>>> >>>>> An x:canonical predicate which asserts <a#b> x:alias <c#d> . and that >>>>> <a#b> is the preferred IRI more useful still. >>>>> >>>>> >>>>> Just an observation - it may be that practical needs override >>>>> formality - but this is not legal according to the RDF semantics. The truth >>>>> of a triple aaa R bbb depends only on what the IRIs in the triple, in >>>>> particular aaa and bbb, *denote*, not on their syntactic form. So x:alias >>>>> would have the same semantics as owl:sameAs (and we all know what happened >>>>> to *that* when it got out into the wide world.) >>>>> >>>>> We could sneak around this by declaring (contrary to the normative >>>>> semantics, but still...) that x:alias is a new kind of property, one that >>>>> quotes its arguments and is therefore referentially opaque. There would >>>>> have been a time when I would have opposed this idea with some vigor, but >>>>> age has mellowed me. And the internal semantic coherence of the Web can >>>>> hardly get worse than it is already, so what the hell. Just be ready for >>>>> the truly awful muddle that will arise when x:alias bumps into owl:sameAs >>>>> and reasoners try to figure out what the consequences might be. >>>>> >>>>> A better solution would be to invent, and have everyone adopt[**], a >>>>> IRI-quoting-IRI convention, something like x:theIRI# , with the semantics >>>>> that x:theIRI#someOtherIRI always denotes someOtherIRI. (Maybe this would >>>>> need some clever character-escaping? I leave that to others to work out.) >>>>> Then x:theIRI#a#b x:alias x:theIRI#c#d would mean what you want to express, >>>>> above. >>>>> >>>>> Pat Hayes >>>>> >>>>> [**] There's the rub, of course. >>>>> >>>>> >>>>> Using syntax shortcuts you could add the following triple to the >>>>> turtle document at https://www.w3.org/1999/02/22-rdf-syntax-ns# >>>>> >>>>> rdf: x:canonical <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . >>>>> >>>>> Result: >>>>> <http://www.w3.org/1999/02/22-rdf-syntax-ns#> a owl:Ontology . >>>>> <https://www.w3.org/1999/02/22-rdf-syntax-ns#> a owl:Ontology . >>>>> >>>>> >>>>> Point 2: >>>>> >>>>> Using a 307 redirect for the semantic is nice, but practically click >>>>> http://www.w3.org/ns/dcat# and you are redirected, refresh and you >>>>> find the client does use the redirected url for subsequent requests. >>>>> >>>>> As a general person or developer search w3.org for dcat and the >>>>> results are https://www.google.com/search?q=site:w3.org%20dcat - the >>>>> url listed is the https url. >>>>> >>>>> Usage of the https IRIs will enter the web of data ever increasingly, >>>>> whether people say the http one should be used or not. >>>>> >>>>> Point 3: >>>>> >>>>> Practically taking a simple real world step like migrating to a CDN >>>>> will often give http/2+tls thus https IRIs automatically. >>>>> >>>>> Test case: >>>>> >>>>> Alice has a wordpress/drupal site that publishes RDF automatically. >>>>> She doesn't know about the RDF. >>>>> Alice clicks the "free CDN" button in her hosting account. >>>>> Alice now has https and http IRIs in RDF on both http:// and https:// >>>>> protocols. >>>>> >>>>> Personally I cannot think of anything easier than as best practise >>>>> adding a single triple to rdf documents when migrating protocols. Anything >>>>> within the black box will fail and be implemented incorrectly. >>>>> >>>>> On Sat, May 21, 2016 at 12:42 AM, Melvin Carvalho < >>>>> melvincarvalho@gmail.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> On 20 May 2016 at 20:08, Phil Archer <phila@w3.org> wrote: >>>>>> >>>>>>> Not a moan about spam, or a CfP, but an actual discussion point, yay! >>>>>>> >>>>>>> I've just blogged about our use of HTTPS across www.w3.org which >>>>>>> raises some questions for this community. Please see >>>>>>> >>>>>>> https://www.w3.org/blog/2016/05/https-and-the-semantic-weblinked-data/ >>>>>> >>>>>> >>>>>> On the one hand more security is a nice to have, but on the other, >>>>>> Cool URIs dont change. It's really hard to estimate the cost, and >>>>>> unintended consequences of changing URIs. But my feeling is that we >>>>>> systematically underestimate it. >>>>>> >>>>>> IMHO, It's kind of a shame that http wasnt made secure, and that a >>>>>> new scheme https was invented. >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> Comments welcome. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> >>>>>>> Phil Archer >>>>>>> W3C Data Activity Lead >>>>>>> http://www.w3.org/2013/data/ >>>>>>> >>>>>>> http://philarcher.org >>>>>>> +44 (0)7887 767755 >>>>>>> @philarcher1 >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> ------------------------------------------------------------ >>>>> IHMC (850)434 8903 home >>>>> 40 South Alcaniz St. (850)202 4416 office >>>>> Pensacola (850)202 4440 fax >>>>> FL 32502 (850)291 0667 mobile >>>>> (preferred) >>>>> phayes@ihmc.us http://www.ihmc.us/users/phayes >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>
Received on Saturday, 21 May 2016 15:51:15 UTC