- From: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
- Date: Fri, 25 Feb 2011 16:21:39 +0100
- To: public-rdf-wg <public-rdf-wg@w3.org>
Some more thoughts on Sandro's g-* terminology, and trying to cut the
gordian blank node (sorry, I couln't resist to make that pun!...).
For the moment, as I read it, the idea seems to be that a g-box contains
a g-snap, which can be expressed by a g-text, grapĥically:
g-box --> g-snap --> g-text
However, the g-snap is an abstract thing, which has no counterpart in
the physical or digital world, while g-boxes and g-texts do. Another way
to look at it is that the value (or state) of g-box is a g-text -- it
may not be in a serialization format, but it *is* essentially a sequence
of bytes representing a g-snap. So the links would rather look like
g-box --> g-text --> g-snap
The impact is that parsing or serializing become mere *translations*
from one g-text to another g-text representing an equivalent g-snap.
Note that I write "equivalent", not "the same", because all those
processing will *not be required* to preserve blank nodes identity.
They *may* preserve it in some cases, but as they are not required to,
it would be a mistake to rely on them doing so. It implies that, in
general, blank nodes should be assumed to be scoped to a given g-text.
This is a change from what has been written until now, where blank nodes
are scoped to g-boxes. But it better reflects my frustrating experience
with querying a g-box containing blank nodes, related below.
Consider a g-box, which is not changing, to which you ask several
queries in a row. For example:
# QUERY1: retrieve all persons with a mailbox
SELECT ?p, ?b WHERE { ?s a foaf:Person ; foaf:mbox ?b . }
Now for some of the persons that I retrieved, I would like to get more
information, by asking
# QUERY2: retrieve additional information for a person
SELECT * WHERE { % foaf:name ?n }
# where '%' above will be replace by one of the nodes retrieved
# in QUERY1
For all URI nodes I retrieved, the generic query above works fine. But
for all the blank nodes, it is useless. Worse, it will return all the
foaf:names of *any* the resources in the store (because a blank node
matches anything).
This is frustrating when you consider blank nodes to be scoped to the
store, because you may assume that, as the store has not changed, the
blank nodes are still valid for subsequent queries.
There are two ways to explain this apparent paradox:
1/ (considering blank nodes are scoped to g-boxes)
When retrieving the SPARQL results, you are parsing them and storing
them locally in your own g-box, hence changing the blank nodes into
local ones. That is why you can no longer use them when querying the
distant store.
2/ (considering blank nodes are scoped to g-texts)
The blank nodes conveyed in the SPARQL results are local to the
serialization of the result, hence distinct from the internal
representation of the store.
Both explanations work, so both points of view (g-box scope vs. g-text
scope) stand to the paradox. However, I think the 2nd one is more natural.
pa
Received on Friday, 25 February 2011 15:22:08 UTC