Re: Skolemization and RDF Semantics

On Sun, Apr 17, 2011 at 1:53 PM, Steve Harris <steve.harris@garlik.com>wrote:

> On 2011-04-17, at 14:44, Pat Hayes wrote:
>
> >
> > On Apr 17, 2011, at 6:09 AM, Steve Harris wrote:
> >
> >> 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
> >>>>
> >>>> INSERT { <WHATEVERCAMEBACKFOR?z> <p> <q> . }
> >>>>
> >>>> 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.
> >
> > Um..how then is the resulting RDF legal? That is, if you substitute this
> into the variables in the query pattern, the result will not be RDF. Doesn't
> that directly violate the SPARQL specs?
>
> They can be mapped back into bNodes at export/results time, so it's OK.
>

FWIW, some (many? most?) triple store implementations provide what might be
called a weak form of skolemization at the API level, in that the bNode
object ('object' in the programming language sense of the word) often
encodes the internal identifier.  When the object is passed back to the
store in a subsequent query or update, the store can recognize the object as
a bNode that originated from a local graph and dereference the identifier to
find the internal node.

Using bNode identifiers this way is probably an abuse of how they were
originally intended, but it's also extremely useful for following your nose
within the context of a single graph without having to formulate a monstrous
SPARQL query to find the bNode you're looking for and pull in all of its
properties in one fell swoop.  As a consumer of RDF data, if the same
feature were exposed via SPARQL then I don't really care how it happens,
I'll jump for joy.  As a WG member, I do recognize that it's our task to
work out the "how it happens" part :-)

-Alex



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