Re: deterministic naming of blank nodes

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

- Steve

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