W3C home > Mailing lists > Public > public-rdf-wg@w3.org > April 2011

Re: Skolemization and RDF Semantics

From: Steve Harris <steve.harris@garlik.com>
Date: Sun, 17 Apr 2011 12:09:05 +0100
Cc: Ivan Herman <ivan@w3.org>, Dan Brickley <danbri@danbri.org>, David Wood <dpw@talis.com>, "public-rdf-wg@w3.org" <public-rdf-wg@w3.org>
Message-Id: <3754873A-1DAF-486D-80DE-80582C7BB96A@garlik.com>
To: Pat Hayes <phayes@ihmc.us>
On 2011-04-17, at 08:06, Pat Hayes wrote:
>> I believe what Steve meant, by 'export', simply the SPARQL query return results. 
>> <a> <b> _:x .
>> query:
>> SELECT ?z WHERE { <a> <b> ?z }
>> if the store decides to skolemize on return the blank node _:x, it is good if the skolemization is such the the store can recognize its own, so it can make sense of a subsequent
>> I guess, at least, that is what he meant:-)
> Ah, OK. That makes sense, thanks. I think this would be covered by the 'who owns the URI' rule I suggested, BTW; In this case, the SPARQL engine owns the URIs, so it has the responsibility of making sense of them in the future. 
> FWIW, I would suggest that it would be bad design to send back skolemised results without first skolemising the actual data the results were derived from. But that is only a suggestion :-)

What actually happens is a little complex, typically the bNode is skolemised, but to a value space that's disjoint from both URIs and Literals, so it can be unambiguously identified as a bNode, but has been given an identifier.

I don't really know how that fits into the terminology.

It also potentially has a bearing on the SPARQL isBlank() function http://www.w3.org/TR/rdf-sparql-query/#func-isBlank as it's defined now, if the bNode has already been skolemised to a URI it should return false.

- Steve

Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD
Received on Sunday, 17 April 2011 11:09:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:58 UTC