Re: deterministic naming of blank nodes - .well-known side debate

> On 22 May 2015, at 12:52, Steve Harris <steve.harris@aistemos.com> wrote:
> 
>> 
>> [[
>> Systems may wish to mint Skolem IRIs in such a way that they can recognize the IRIs as having been introduced solely to replace blank nodes. This allows a system to map IRIs back to blank nodes if needed.
>> 
>> Systems that want Skolem IRIs to be recognizable outside of the system boundaries should use a well-known IRI [RFC5785] with the registered namegenid. This is an IRI that uses the HTTP or HTTPS scheme, or another scheme that has been specified to use well-known IRIs; and whose path component starts with /.well-known/genid/.
>> ]]
>> 
>> Here it says "solely to replace blank nodes". I don't create something to **SOLELEY** replace a blank node - WHICH CANNOT BE DEREFERENCED - and then put a URI which can be dereferenced !!!
> 
> I think you’re misreading the intent of the world “solely”. You keep saying they cannot be dereference, but they’re URIs, of course they can be dereferenced.

not all URIs can be dereferenced. UUID URNs for example cannot. It is easy to create a new scheme, if needed. Or using an existing one would have also done. Breaking HTTP URIs and web architecture to do what could have been done in other ways is not really an acceptable trade off.

>> [snip]
>> Clearly if HTTP URLs can represent blank nodes then such an ontology would have done as well.
>> 
>> Do most services really have dereferenceable URIs at .well-known? IS your interpretation backed by any facts? Or is it just wishful thiunking. I think it can only be wishful thinking given that no body would know what to put there. Why not instead have used special URNs that really are not dereferenceable, such as UUIDs that act somehow like global blank nodes, since there is no way of knowning who minted them, or what they may possibly mean other than by looking at the document in which they have been minted.
> 
> Most? No, of course not.

So if most cases don't work, and since HTTP connections are very expensive to make compared to the cost of the fastest operation on a CPU, then it becomes pragmatically a waste of time to dereference these URLs. Web sites that server these URLs therefore could appear as broken to any well built client. Either that or we now need to add case statments to all our code with regexpressions on the strings of http(s) URLs.  Neither of these is justified by the alleged advantage that this .well-known urls allegedly bring.  It is part of web architecture that one should not build semantics into URLS and yet here the position you defend has. 

> 
> You seem fixated on the idea of non-deferencencability, but part of the point of this idea is to make them dereferencable.

Except that as I pointed out if you want dereferenceability any other method could have done, of which the most prominent is just to use normal linked data principles. 

In conclusion:
Web sites that use .well-known minted URLs for skolem URIs as specified by RDF 1.1 will 
 1. Actually appear broken to most clients, which may decide to avoid them or count them as spam sites - since as you admit most sites probably just return 404s
 2. would force clients to start looking at URIs for semantic content, which is against web architecture principles
 3. This could be avoided using either
  -  UUID URNs  if you want to have a BNOde that is not dereferenceable
  - using normal http URLs that dereference to some text describing a family of URLs as some kind of skolemized bnodes, which would have allowed people other than web admins to produce skolem URIS
  - create a new bnode URN type
  4. Creating bnodes in .well-known space could easily lead to URIs being created that tie into a URN created in another document, which could lead to problems of accidentally identifying two distinct objects

Need I go on?

Or perhaps we can start a competition for who can find more things wrong with this proposal.

Henry


Social Web Architect
http://bblfish.net/

Received on Friday, 22 May 2015 12:10:09 UTC