Re: Objections to current SPARQL specification

On Fri, Nov 02, 2007 at 01:01:22PM +1000, Andrew Newman wrote:
> This is close but not quite right.
> 
> 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.

> > [[
> > In objection 8, Andrew Newman objects to the early direction of
> > SPARQL, preferring an RDF query language based on manipulations of
> > graphs. Such a language would not produce sets of variables, but
> > instead produce only RDF graphs.
> >
> > The first document published by the Working Group was the RDF Data
> > Access Use Cases and Requirements [UCR]. Requirement 3.2, Variable
> > Binding Results [VBR] requires the extraction of terms from the RDF
> > graph into a set of solution tuples. No yet-concieved form of a
> > language meeting the commentor's design goals meets this requirement.
> >
> > [UCR] http://www.w3.org/TR/2005/WD-rdf-dawg-uc-20050325/
> > [VBR] http://www.w3.org/TR/2005/WD-rdf-dawg-uc-20050325/#r3.2
> > ]]
> >
> > > The basis of my objection is founded on SPARQL being an RDF query
> > > language and that it should use an RDF data model throughout.  This is
> > > one property that represents what is considered good design for query
> > > languages (for RDF query languages see [1] but it has been covered
> > > elsewhere in criticism of other query languages such as SQL).
> > >
> > > One feature that SPARQL lacks is closure.  Having closure on all
> > > operations means that intermediate results and answers are always tied
> > > to an RDF graph.  It means that in each step of the query evaluation
> > > you are dealing with valid subsets of RDF graphs.  The current
> > > specification, however, reverts to an SQL/multiset/bindings to
> > > variables that is not compatible with the RDF model.
> > >
> > > To summarize, my objections include [2][3][4][5]:
> > > * Lack of closure.
> > > * Inconsistencies between SPARQL triples and the currently defined RDF
> > > standard (requiring special handling of say CONSTRUCT when there are
> > > literals as subjects).  If SPARQL was defined in terms of RDF, if RDF
> > > changed then SPARQL would naturally change.  The current way the
> > > specification was created seems to allow a difference between the
> > > language and the data it's querying.
> > > * The use of multiset semantics instead of semantics consistent with
> > > RDF (set based semantics).
> > > * The multiple uses of unbound - you cannot distinguish between a
> > > result from an OPTIONAL operation or from a variable that is not used
> > > in the query.  This prevents it from being understood, without
> > > retaining the original query, what unbound means.
> > > * Existence of DISTINCT and REDUCED (set based semantics don't have duplicates).
> > > * Existence of CONSTRUCT (should just be a projection of all columns).
> > > * Existence of ASK (should just be a projection of no columns giving
> > > DEE or DUM, T/F).
> > > * Lack of nadic operators (JOIN, UNION and possibly OPTIONAL).
> > > * Lack of SUMMARIZE (set based aggregate function).
> > >
> > > [1] J. Bailey et al, "Web and Semantic Web Query Languages: A Survey,"
> > > LNCS 3564, 2005, Norbert Eisinger, Jan Maluszynski (editor(s)),
> > > [2] http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2006Nov/0006.html
> > > [3] http://jrdf.sourceforge.net/thesis/2006/RelationalBasedSPARQL.html
> > > [4] http://www.xml.com/lpt/a/1695
> > > [5] http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2004Nov/0001.html
> >
> >
> > office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
> > mobile: +1.617.599.3509
> >
> > (eric@w3.org)
> > Feel free to forward this message to any list for any purpose other than
> > email address distribution.
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.6 (GNU/Linux)
> >
> > iQEVAwUBRyqGI5ZX2p1ccTnpAQJAmwgAuF95zU8V4D/0DlJw3zo0kE3jNqUuVdWP
> > 4biucrMPO+sIDJOuPyWc0OgVCUeKXTakGWdECtRh7L3yk0UyVNHYmREQ1HD8gPox
> > Uykru0tsNB6004ydtqYgk6Tmkuy6hOH/EpdAt23Vi2bo+/lTzsnyJY4O/vOZY/GQ
> > oqoA8OHz+vQnfuT3Va8fqhFJBbYeMpgV5/HV8RBTi2wi9AoP+buwsLvpd3jyXhXR
> > K6JbXEJBk2h+SSSVCg1WDwxA8W3zx5qrxAUOVPqUOQt6kIBb43mSvdwWxsJz2VS4
> > vCreDw8asH28DjuvYa648PQhmbBo+hec/oOTOmdoV0+Rh2p7hanXSg==
> > =P7Vn
> > -----END PGP SIGNATURE-----
> >
> >

-- 
-eric

home-office: +1.617.395.1213 (usually 900-2300 CET)
cell:        +81.90.6533.3882

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.