Re: xsd:anyURI - was: HTTPS and the Semantic Web

(Of course I would say this :-) …)

One way to handle a lot of this is to use a sameAs service as in our sameAs.org and related services.
This can be done either by a standard service where all the appropriate pairs are asserted, or by a programmatic service with the same API, which gives the https (or whatever) for every http.
I could modify sameAs.org etc. to actually do this, roughly doubling the number of URIs - but somehow I don’t think that would be useful at the moment.
Of course I might well bring up a separate service doing this.

However, in addition I was prompted to write this posting because these services also handle deprecation, in two possible ways:
a) the service response can be configured to give a preferred or canonical URI first, or you can ask the service for the canon;
b) URIs can be asserted to be properly deprecated - that means they can be used as a look-up key, but will never appear in a result set.

Best
> On 21 May 2016, at 20:54, Henry Story <henry.story@bblfish.net> wrote:
> 
> 
>> On 21 May 2016, at 21:07, Michael Brunnbauer <brunni@netestate.de> wrote:
>> 
>> 
>> Hello Henry,
>> 
>> I am glad you agree with me that there is no need for widely deployed URIs to
>> change. I have no problem with redirects of widely deployed HTTP URIs to
>> HTTPS as long as it is made clear that using the HTTPS namespace is not OK.
> 
> yes, no need to rock the whole boat at the same time.
> 
>> 
>> We are talking about privacy and security issues of Semantic Web applications 
>> with regard to the use of TLS. For me, this is clearly Science Fiction, so we
>> have some time to fix it. In the meantime, paranoid applications can use
>> HSTS and preloaded HSTS lists as a temporary workaround.
> 
> This is actually not science fiction, and has many very important use cases
> for building distributed social networks, including b2b applications where
> confidentiality is important. The Snowden revelations should have made that
> clear by now. The pieces have been in place to use it for a while now, and
> the semantic web community has lost many valuable opportunities for failing
> to take this more seriously. Some pointers to the uses of it are here:
> 
> https://www.w3.org/2005/Incubator/webid/spec/
> 
> Luckily since those applications are not wide spread, there is not that
> much problem moving over to use https urls to identity people, organisations
> and agents generally (see the WebID spec).
> 
>> 
>> In the long run, this should be fixed on a lower layer and there is already 
>> work underway to enable publishing "TLS required" preferences via DNSSEC:
>> https://tools.ietf.org/html/draft-hallambaker-esrv-01
> 
> There are many different problems that come together here. Some can be fixed
> with Redirects plus DNSEC, others by just deprecating vocabularies. 
> 
> It seems to me that vocabulary deprecation ontology would be very useful 
> in any case, even if only to make a case about the stability of urls.
> 
>> 
>> So I actually see no case for a namespace change even for less known
>> vocabularies. Anyway, there is already owl:sameAs and a property to express a 
>> preferred namespace. Naturally, the latter is meant for human consumers.
>> What whould be the automated consequences of ex:canonical/ex:preferreduri? 
>> Would app developers care about it?
> 
> yes they would. If there were a way to automate the movement to better vocabularies,
> old software could last much longer without breaking.
> 
> We have to live in a world that changes, even if it helps to think atemporally when
> building our functional programs.
> 
>> 
>> Regards,
>> 
>> Michael Brunnbauer
>> 
>> On Sat, May 21, 2016 at 06:13:20PM +0200, Henry Story wrote:
>>> 
>>>> On 21 May 2016, at 17:40, Michael Brunnbauer <brunni@netestate.de> wrote:
>>>> 
>>>> 
>>>> Hello Henry,
>>>> 
>>>> On Sat, May 21, 2016 at 04:18:47PM +0200, Henry Story wrote:
>>>>> 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.
>>>> 
>>>> Ha! Let the games begin! :-)
>>>> 
>>>> Seriously, I cannot believe we are having this discussion. The day that that "a"
>>>> in Turtle/SPARQL represents https://www.w3.org/1999/02/22-rdf-syntax-ns#type
>>>> instead of http://www.w3.org/1999/02/22-rdf-syntax-ns#type will be the day
>>>> when RDF breaks. Leave it as it is.
>>> 
>>> clearly some RDF URLS are so widely documented and deployed that these meanings 
>>> have to a certain extend escaped from the definition placed at their location. 
>>> As a result they won't gain much in security by having https urls. This would
>>> be the case for many major w3c rdf and owl URLS. So I don't think there is really
>>> a need to move those URLs over.
>>> 
>>>> All those URI changing fixes to get rid of technical debt will mean a lot of 
>>>> pain for a lot of people - unless you can come up with a scheme where those 
>>>> fixes are handled transparently by the software. I am not talking of reasoners
>>>> here.
>>> 
>>> You mean like using redirects? That would allow ontologies to be moved to secure 
>>> namespaces without I think changing the old URLs.
>>> 
>>> I think there are ways of doing these redirects securely. I have not looked at that 
>>> carefully. Anyone?
>>> 
>>>> A large fraction of the users don't use them because they are a PITA.
>>>> RDF should stay accessible for people who are not top of the range and use 
>>>> hard-coded URIs in their code.
>>> 
>>> yes, there will be quite a long time to live for old well known http URLs. On the
>>> other hand for people building less well known vocabs who want to move to more
>>> secure vocabs you'll need some "reasoning type solution" like the one we're starting 
>>> to propose. In any case that will be needed for changing ontologies, and overcomeing
>>> mistakes, etc... So there is good reason to formalise vocabulary transitions, so that
>>> these can be automated.
>>> 
>>>> Maybe we can come up with a completely new RDF where "Cool URIs don't change"
>>>> is enforced technically? ;-)
>>> 
>>> Things change. "Cool URIs' don't change" is of motto so that people think before they
>>> change URIs, because of the cost involved which we are just discussin.
>>> It's not a statement about the impossibility to make mistakes.
>>> 
>>> Henry
>>> 
>>>> 
>>>> Regards,
>>>> 
>>>> Michael Brunnbauer
>>>> 
>>>> -- 
>>>> ++  Michael Brunnbauer
>>>> ++  netEstate GmbH
>>>> ++  Geisenhausener Straße 11a
>>>> ++  81379 München
>>>> ++  Tel +49 89 32 19 77 80
>>>> ++  Fax +49 89 32 19 77 89 
>>>> ++  E-Mail brunni@netestate.de
>>>> ++  http://www.netestate.de/
>>>> ++
>>>> ++  Sitz: München, HRB Nr.142452 (Handelsregister B München)
>>>> ++  USt-IdNr. DE221033342
>>>> ++  Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
>>>> ++  Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
>>> 
>> 
>> -- 
>> ++  Michael Brunnbauer
>> ++  netEstate GmbH
>> ++  Geisenhausener Straße 11a
>> ++  81379 München
>> ++  Tel +49 89 32 19 77 80
>> ++  Fax +49 89 32 19 77 89 
>> ++  E-Mail brunni@netestate.de
>> ++  http://www.netestate.de/
>> ++
>> ++  Sitz: München, HRB Nr.142452 (Handelsregister B München)
>> ++  USt-IdNr. DE221033342
>> ++  Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
>> ++  Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
> 
> 

--
Hugh
023 8061 5652

Received on Saturday, 21 May 2016 21:45:00 UTC