xsd:anyURI - was: HTTPS and the Semantic Web

> On 21 May 2016, at 08:01, Henry Story <henry.story@bblfish.net> wrote:
> 
>> 
>> On 21 May 2016, at 06:04, 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.) 
> 
> yes.
> 
>> 
>> 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.
> 
> Not a good idea.
> -1 from me.
> 
>> 
>> 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. 
> 
> The good news is that there is an official iri quoting convention. https://www.w3.org/TR/xmlschema-2/#anyURI <https://www.w3.org/TR/xmlschema-2/#anyURI>
> 
> [Definition:]   <> anyURI represents a Uniform Resource Identifier Reference (URI). An anyURI value can be absolute or relative, and may have an optional fragment identifier (i.e., it may be a URI Reference). This type should be used to specify the intention that the value fulfills the role of a URI as defined by [RFC 2396] <https://www.w3.org/TR/xmlschema-2/#RFC2396>, as amended by [RFC 2732] <https://www.w3.org/TR/xmlschema-2/#RFC2732>.
> 
> So in serialisations that allow literals as subjects such as N3 one can write
> 
> "http://dbpedia.org/resource/Eiffel_Tower <http://dbpedia.org/resource/Eiffel_Tower>"^^xsd:anyURI :deprecatedAndReplacedBy "https://dbpedia.org/resource/Eiffel_Tower <https://dbpedia.org/resource/Eiffel_Tower>"^^xsd:anyURI .
> 
> Perhaps if this gets to be really widely used one could even invent a URI quotation mechansim that would make it easier to 
> write in papers and in e-mail forums such as this.
> 
> >http://dbpedia.org/resource/Eiffel_Tower <http://dbpedia.org/resource/Eiffel_Tower>< :deprecatedAndReplacedBy >https://dbpedia.org/resource/Eiffel_Tower <https://dbpedia.org/resource/Eiffel_Tower>< .
> 
> (N3 is quite flexible in allowing new notations, so I would expect something from there first)
> 
> For notations that don't allow literals in subject position one has to blank nodes and owl:sameAs statements as explained in the rdf semantics
> spec.

Perhaps this last sentence was a bit too terse for some readers. Here is an example of a rewriting for 
the first example but without  a literal as subject that is logically equivalent.

[] owl:sameAs "http://dbpedia.org/resource/Eiffel_Tower <http://dbpedia.org/resource/Eiffel_Tower>"^^xsd:anyURI;
   :deprecatedAndReplacedBy "https://dbpedia.org/resource/Eiffel_Tower <https://dbpedia.org/resource/Eiffel_Tower>"^^xsd:anyURI .
   
So really all that is needed is a widely accepted vocaluary for :deprecatedAndReplacedBy.

One step further
----------------------

We should see this large movement as an opportunity to fix a lot of other problems that have come
up in Linked Data. For example it could allow us to move away from 303 redirects to hash urls that are much 
more efficient, and finally put that old discussion to rest. This transformation could be done the same way:

>http://dbpedia.org/resource/Eiffel_Tower< :deprecatedAndReplacedBy >https://dbpedia.org/resource/Eiffel_Tower#< .

So my analysis for the deeper cause of the hash url problem is that it is a purely syntactic problem. 
The following answer to the problem will both make it clear what the problem was, and why the fix will 
remove the problem.

All that would be needed would be for serilisations such as N3 to allow more flexible
namespacing, so that one can address all dbpedia urls with one namespace, making the life of people
writing the URLs easy whilst also being good for the web. So by introducing an @pattern that could be
used like this:

@pattern dbpedia: ( >https://dbpedia.org/resource/ <https://dbpedia.org/resource/>< %1 >#< %2 )

where we have something that is similar to @prefix but a bit more sphisticated, as it allows one to match
patterns of urls. So then one could write

dbpedia:Eiffel_Tower a dbpedia:HistoricMonument .

Which would describe the following triples: 

<https://dbpedia.org/resource/Eiffel_Tower#> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>  <https://dbpedia.org/resource/HistoricMonument#> .

Notice the trailing "#"s, that the person writing the code does not have to bother with.

With vocabularies with more than one hash definition per document one could have something like:

@pattern foaf: ( >http <https://dbpedia.org/resource/>s://xmlns.com/foaf/< %1 >#< %2 )

[] a foaf:Person;
   foaf:account [ foaf:account:serviceHomePage <https://twitter.com/>;
                         foaf:account:name "bblfish" ] .

Notice the double colons in the name space!
This would be equivalent to the following NTriples:

_:b1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://xmlns.com/foaf/Person#> .
_:b1 <https://xmlns.com/foaf/account#> _:accnt .
_:accnt <https://xmlns.com/foaf/account#serviceHomePage> <https://twitter.com/> .
_:accnt <https://xmlns.com/foaf/account#name> "bblfish".



>> 
>> 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 home
>> 40 South Alcaniz St.            (850)202 4416   office
>> Pensacola                            (850)202 4440   fax
>> FL 32502                              (850)291 0667   mobile (preferred)
>> phayes@ihmc.us <mailto:phayes@ihmc.us>       http://www.ihmc.us/users/phayes <http://www.ihmc.us/users/phayes>