Re: HTTPS and the Semantic Web

Proposed x:alias symmetric, identical to owl:sameAs I think.

x:canonical definitely not symmetric.
aaa x:canonical bbb . true
bbb x:canonical bbb . true
bbb x:canonical aaa . false


On Sat, May 21, 2016 at 9:25 PM, Pat Hayes <phayes@ihmc.us> wrote:

>
> On May 21, 2016, at 7:40 AM, Nathan Rixham <nathan@webr3.org> wrote:
>
> Why not owl:sameas? Is it technically incorrect?
>
>
> Not for this usage. A owl:sameas B  is true when the thing denoted by A is
> also the thing denoted by B, ie when A and B both denote the same thing.
> The proposed x:alias is the a relation between two IRIs, not between the
> things the IRIs denote. The only way to do this in (correct) RDF is to use
> some kind of quotation, where one IRI can denote another.
>
> If this seems like a petifoggiing academic hair-split, consider that
> owl:sameas is symmetric, whereas the proposed x:canonical is definitely not
> symmetric. (I am not sure about x:alias.)
>
> Pat
>
> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
> ------------------------------------------------------------
> 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
>
>
>
>
>
>