W3C home > Mailing lists > Public > semantic-web@w3.org > May 2016

Re: HTTPS and the Semantic Web

From: Henry Story <henry.story@bblfish.net>
Date: Sun, 22 May 2016 08:23:19 +0200
Cc: nathan <nathan@webr3.org>, Simon Spero <sesuncedu@gmail.com>, Halpin Harry <hhalpin@ibiblio.org>, Carvalho Melvin <melvincarvalho@gmail.com>, Patrick Hayes <phayes@ihmc.us>, Archer Phil <phila@w3.org>, Semantic Web IG <semantic-web@w3.org>
Message-Id: <B4502311-401B-4148-BBAA-D7A55B25F5D6@bblfish.net>
To: Wouter Beek <w.g.j.beek@vu.nl>

> On 21 May 2016, at 18:51, Wouter Beek <w.g.j.beek@vu.nl> wrote:
> 
> Hi,
> 
> From the comments so far it seems that most are in favor of a data publisher adding explicit relations between [1] and [2], whether they be `owl:sameAs' or some variant.
> 
> [1]   http://dbpedia.org/resource/Category:Semantics <http://dbpedia.org/resource/Category:Semantics>
> [2]   https://dbpedia.org/resource/Category:Semantics <https://dbpedia.org/resource/Category:Semantics>

Yes.
The correct variant being that one speak about the URLs and not the resources, since it is not the resources that have changed, but
the URLs that are considered deprecated.

Btw. This would allow one to use work such as POWDER https://www.w3.org/2001/sw/wiki/POWDER <https://www.w3.org/2001/sw/wiki/POWDER> to rename decaratively in one resource all URLs 
on a web site just using regular expressions.

> I want to point out that a similar issue has already been around for as long as the SW exists: IRIs that differ only in terms of escaping are different SW names even though they denote the same Web location.  In practice I do not always see a data publisher make explicit (`owl:sameAs') assertions between [3] and [4] (although some do, I've seen them in LOD Laundromat).

I think that equivalence is covered by the URI and IRI spec. URIs have to be compared for equivalence after denormalisation, including relative URI
resolution. ie. <https://www.w3.org/2001/sw/wiki/POWDER <https://www.w3.org/2001/sw/wiki/POWDER>> is the same as <https://www.w3.org/2002/../2001/sw/wiki/POWDER <https://www.w3.org/2001/sw/wiki/POWDER>>.

The equivalence between http and https URLS is not part of the URI spec though, and would probably be wrong in many cases. Even though that
looks like a very attractive solution, reaching consensus there seems to be fraught with difficulty.

Henry


> 
> [3]   http://dbpedia.org/resource/Category:Semantics <http://dbpedia.org/resource/Category:Semantics>
> [4]   http://dbpedia.org/resource/Category%3ASemantics <http://dbpedia.org/resource/Category%3ASemantics>
> 
> ---
> Cheers,
> Wouter.
> 
> On Sat, May 21, 2016 at 5:50 PM, Nathan Rixham <nathan@webr3.org <mailto:nathan@webr3.org>> wrote:
> > 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 <https://example.com/Alice#me> rather than http://example.com/Alice#me <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# <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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:phayes@ihmc.us>> wrote:
> 
> On May 20, 2016, at 5:02 PM, Nathan Rixham <nathan@webr3.org <mailto: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# <https://www.w3.org/1999/02/22-rdf-syntax-ns#>
>> 
>>    rdf: x:canonical <http://www.w3.org/1999/02/22-rdf-syntax-ns# <http://www.w3.org/1999/02/22-rdf-syntax-ns#>> .
>> 
>> Result:
>> <http://www.w3.org/1999/02/22-rdf-syntax-ns# <http://www.w3.org/1999/02/22-rdf-syntax-ns#>> a owl:Ontology .
>> <https://www.w3.org/1999/02/22-rdf-syntax-ns# <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# <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 <http://w3.org/> for dcat and the results are https://www.google.com/search?q=site:w3.org%20dcat <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 <mailto:melvincarvalho@gmail.com>> wrote:
>> 
>> 
>> On 20 May 2016 at 20:08, Phil Archer <phila@w3.org <mailto: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 <http://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/ <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://www.w3.org/2013/data/>
>> 
>> http://philarcher.org <http://philarcher.org/>
>> +44 (0)7887 767755 <tel:%2B44%20%280%297887%20767755>
>> @philarcher1
>> 
>> 
>> 
> 
> ------------------------------------------------------------
> IHMC                                     (850)434 8903 <tel:%28850%29434%208903> home
> 40 South Alcaniz St.            (850)202 4416 <tel:%28850%29202%204416>   office
> Pensacola                            (850)202 4440 <tel:%28850%29202%204440>   fax
> FL 32502                              (850)291 0667 <tel:%28850%29291%200667>   mobile (preferred)
> phayes@ihmc.us <mailto:phayes@ihmc.us>       http://www.ihmc.us/users/phayes <http://www.ihmc.us/users/phayes>
> 
> 
> 
> 
> 
> 
> 
> 
Received on Sunday, 22 May 2016 06:23:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 25 May 2016 10:59:47 UTC