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

Re: HTTPS and the Semantic Web

From: Nathan Rixham <nathan@webr3.org>
Date: Sat, 21 May 2016 16:50:45 +0100
Message-ID: <CANiy74ws+LKA4=P58xOkz+R9+19ovGiF-urbDqrigmsKyoVxeQ@mail.gmail.com>
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>
> 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

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