Re: Blank Nodes and SPARQL

Eric Prud'hommeaux wrote:
> To figure this out, I'd like to see a use case where you extend SPARQL
> to use session-persistent bNodes. Then I'd like to see if a client
> that doesn't know of this extension will get different answers than it
> expects.

How about this use case:

Ron, a horrible kitchen danger, is looking up recipes for buttermilk
cornbread.  Ron needs to retreive the order to add the ingredients
(represented as a list) so he doesn't add the baking soda straight into
the buttermilk.

Now for the split.

Assume bnodes are no longer being used as sugar for variables.  Suppose
they explicitly match nothing when used over the normal sparql protocol.
Or it could be unspecified.  At any rate, it means that straight sparql
protocol clients would not use bnodes.

Assume we have session support where labeled bnodes in the query can
match bnodes in the store.  Either that, or we're using a local store
with the same bnode matching ability (this might match up with
http://www.w3.org/TR/rdf-dawg-uc/#r3.5  ).

In this case, Ron requests a session from the server.
He queries the server for the recipe data, including the head of the
list, using a hand written query [1] with some values plugged in

If Ron doesn't get back the whole list of instructions, he takes his
generic list query template [2] and fills in the last part of the list
he received.  Rinse and repeat until all the instructions are downloaded.


Option 2) Either we don't have session support in our client, or bnodes
are still sugar for variables.

Ron queries the server for the basic recipe data.
Ron notes that there is a bnode response for :steps, and uses the
previous query as a context for the list query, binding what things he
can to make the query smaller [3].

Now repeat, using the previous query as the context for the next one
[4].  Before, binding parts of the query significantly reduced the size.
 Now we're starting to build up baggage.


Ok, we got a handle on this.  So move it to the general case.  We've got
complicated, hetrogenous bnode structures used for OWL complex classes,
Rule languages, and funny looking FOAF files.  Are we starting to feel
the pain yet?

So to implement this in an automated way on the client side, we have to
either:
a) Preclude hand written queries.  Generate queries using an api,
keeping track of the contexts which generate bnode responses.
b) Include query parsing and analysis on the client side, so that
queries can be rewritten to include the contexts without stomping on
anything.
c) <Insert your idea here>



This seems like quite a burden to implement on each client.



[0] Basic data:
PREFIX : <http://example.com/food#>.
PREFIX dc: <http://purl.org/dc/elements/1.1/>.

:CornBread a :Recipe;
  dc:description "A simple corn bread recipe";
  :steps ( :AddMix, :Shake, :Bake, :FingerCheckForDoneness, :VisitER,
           :ReturnHome, :EatStaleHalfCookedCornBread ).

[1]
PREFIX food <http://example.com/food#>
PREFIX dc <http://purl.org/dc/elements/1.1/>
SELECT ?recipe ?description ?step
WHERE {
  ?recipe a food:Recipe;
     dc:description ?description;
     food:steps ?steps.
}


[2]
PREFIX rdf <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
SELECT ?item1 ?item2 ?item3 ?item4 ?tail
WHERE {
  %HEAD rdf:first ?item1;
        rdf:next ?list2 .
  OPTIONAL {
    ?list2 rdf:first ?item2;
           rdf:next ?list3 .
    OPTIONAL {
      ?list3 rdf:first ?item3;
             rdf:next ?list4 .
      OPTIONAL {
          ?list4 rdf:first ?item4;
                 rdf:next ?tail
      }
    }
  }
}


[3]
PREFIX food <http://example.com/food#>
PREFIX dc <http://purl.org/dc/elements/1.1/>
SELECT ?item1 ?item2 ?item3 ?item4 ?tail
WHERE {
  :CornBread food:steps ?steps.
  ?steps rdf:first ?item1;
         rdf:next ?list2 .
  OPTIONAL {
    ?list2 rdf:first ?item2;
           rdf:next ?list3 .
    OPTIONAL {
      ?list3 rdf:first ?item3;
             rdf:next ?list4 .
      OPTIONAL {
          ?list4 rdf:first ?item4;
                 rdf:next ?tail
      }
    }
  }

}

[3]
PREFIX food <http://example.com/food#>
PREFIX dc <http://purl.org/dc/elements/1.1/>
SELECT ?item1 ?item2 ?item3 ?item4 ?tail
WHERE {
  :CornBread food:steps ?steps.
  ?steps rdf:next ?steps2.
  ?steps2 rdf:next ?steps3.
  ?steps3 rdf:next ?steps4.
  ?steps4 rdf:next ?head.

  ?head rdf:first ?item1;
         rdf:next ?list2 .
  OPTIONAL {
    ?list2 rdf:first ?item2;
           rdf:next ?list3 .
    OPTIONAL {
      ?list3 rdf:first ?item3;
             rdf:next ?list4 .
      OPTIONAL {
          ?list4 rdf:first ?item4;
                 rdf:next ?tail
      }
    }
  }

}