Re: Objections to current SPARQL specification

On Nov 3, 2007 12:11 AM, Eric Prud'hommeaux <eric@w3.org> wrote:
> On Fri, Nov 02, 2007 at 01:01:22PM +1000, Andrew Newman wrote:
> > I'd say, "Such a language would not only produce sets of variables but
> > also allow the production of RDF graphs".
> >
> > I also fully agree with the extraction of terms from an RDF graph in
> > Requirement 3.2.  The stage at which the extraction from an RDF graph
> > should take place at projection not at the graph matching stage.
> >
> > I'd also suggest that the implementation of SPARQL in JRDF
> > (http://jrdf.sf.net/) is a conceivable alternative form of the
> > language that does meet these goals.
>
> I see how extracting nodes is doable from an API (such as JRDF), but I
> don't see how you propose to return nodes with a query language
> (i.e. a return from a single call to an interpreter) that meets your
> criteria of only using graphs in the algebra. You would need some way
> to isolate the graph pattern of interest and extract, for instance,
> some people's names and mboxs.
>

To ensure that you can return graphs, the idea is to retain the
context of the nodes from the original graph.  So it has a little more
structure - it just retains triples - it doesn't have knowledge of
relationships/schemas.

Here's a small example with email addresses and names.

SELECT ?mbox ?name
{
  ?x foaf:mbox ?mbox .
  OPTIONAL { ?x foaf:name ?name } .
}

a1 foaf:mbox a1@a1.com
a2 foaf:mbox a2@a1.com
a2 foaf:name "Fred"
a2 foaf:nick "Freddy"

Currently, you'd have a list of bindings like { ?x = a1, ?mbox =
a1@a1.com}, { ?x = a2,  ?mobx = a2@a1.com } and as so on.

All I'm really suggesting is adding types to the bindings and a few
extra bindings/columns - sufficient information to retain a graph
structure.  So it would be: { subject:?x = a1, predicate:p1 =
foaf:mbox, object:?mbox = a1@a1.com}, { subject:?x = a2, predicate:p1
= foaf:mbox, object:?mbox = a2@a1.com} and for the OPTIONAL match
{subject:?x = a2, predicate:p2 = foaf:name, object:?name = "Fred"}.

The result of the optional is:
{subject: ?x = a1, predicate:p1 = foaf:mbox, object:?mbox = a1@a1.com},
{ subject:?x = a2, predicate:p1 = foaf:mbox, object:?mbox = a2@a1.com,
predicate:p2 = foaf:name, object:?name = "Fred"}

Which in triple form is:
a1 foaf:mbox a1@a1.com
a2 foaf:mbox a2@a1.com
a2 foaf:name "Fred"

There is a small increase in overhead but it's quite minial.  If you
use relations, the extra complexity is in a shared set of attributes.

Received on Saturday, 3 November 2007 19:54:02 UTC