Re: HTTPS and the Semantic Web

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
[2]   https://dbpedia.org/resource/Category:Semantics

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).

[3]   http://dbpedia.org/resource/Category:Semantics
[4]   http://dbpedia.org/resource/Category%3ASemantics

---
Cheers,
Wouter.

On Sat, May 21, 2016 at 5:50 PM, Nathan Rixham <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 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>