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

> On 21 May 2015, at 17:05, henry.story@bblfish.net wrote:
> 
> 
>> On 21 May 2015, at 15:54, Steve Harris <steve.harris@aistemos.com> wrote:
>> 
>>> On 21 May 2015, at 13:24, henry.story@bblfish.net wrote:
>>> 
>>> 
>>>> On 21 May 2015, at 13:02, Steve Harris <steve.harris@aistemos.com> wrote:
>>>> 
>>>>> On 21 May 2015, at 11:06, henry.story@bblfish.net wrote:
>>>>> 
>>>>> 
>>>>>> On 21 May 2015, at 10:08, Steve Harris <steve.harris@aistemos.com> wrote:
>>>>>> 
>>>>>> 
>>>>>>>> Alternatively, some SPARQL servers may use
>>>>>>>> stable internal identifiers that could serve this purpose (still
>>>>>>>> requiring normative normalization), but I suspect that there are some
>>>>>>>> implementations that don’t guarantee such stable identifiers).
>>>>>>> 
>>>>>>> Right, it would involve enhancing SPARQL servers.
>>>>>> 
>>>>>> Quite a few can do this already, and there’s a syntax sanctioned by RDF 1.1
>>>>>> 
>>>>>> http://www.w3.org/TR/rdf11-concepts/#section-skolemization
>>>>> 
>>>>> yes, except that skolemization using .well-konwn URLs is ugly, broken, and should
>>>>> never have made it into RDF1.1 spec. It breaks linked data clients that need to analyse the
>>>>> full uri for .wellknown urls before deciding wether to follow them. it would be better to have coined bnode URNs of some form. I made a suggestion along those lines at some point.
>>>>> 
>>>>> https://lists.w3.org/Archives/Public/semantic-web/2014Sep/0088.html
>>>> 
>>>> There’s nothing wrong with dereferencing a skolem URI. That’s what makes it better than a bNode label.
>>>> 
>>>> It’s perfectly legal to have something at the other end.
>>> 
>>> .well-known urls are meant to be used for well known urls that can be dereferenced, whereas the whole point of bnode urls is exactly not to dereference them.  It is quite obvious as there  is no specification about what to put there - ie no consensus was reached on the key part of what should have been reached.
>> 
>> I don’t know why you believe that bNode URLS can’t / shouldn’t be dereferenced. If they point back to a service, the service can return the CBD, or any domain specific representation that makes sense. That’s the whole point.
> 
> 
> 
> [[
> 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.

> If they can be dereferenced then why the restriction to .well-known URIs? Any other dereferenceable URI with a special header would have done as well. Why not have created
> an ontology then for skolem URIs such as 
> 
> <#bnode> a skolem:URI;
>   skolem:originalDocument </collection/document123> .

That wouldn’t work. You’d have to change the document structure in order to represent skolemised bNodes.

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

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

> I even proposed a bnode URN that would contain the original location of the document in which it appeared for people needing such a thing, without breaking linked data principles.

A URN would have been OK - but you’d have to wait the best port of a decade for the scheme to be minted.

> Creating HTTP Urls that represent blank nodes in a space that nobody usually has access to, requiring most Linked Data clients to potentially start looking at URL patterns to determing the meaning of those URLs!!!!
> 
> IT is the most anti linked data piece of stupidity I have ever seen! 

Then I believe you must have led quite a sheltered life ;-)

- Steve

Received on Friday, 22 May 2015 11:19:09 UTC