W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > July 2012

Re: Question about duplicate triples

From: David Booth <david@dbooth.org>
Date: Tue, 31 Jul 2012 10:36:34 -0400
To: public-rdf-dawg-comments@w3.org
Message-ID: <1343745394.2725.72040.camel@dbooth-laptop>
On Mon, 2012-07-30 at 18:18 -0400, David Booth wrote:
> Suppose I LOAD a single file of NTriples into a named graph foo:, and
> that file contains some duplicate triples such as:
> 
>   _:bnode <http://example/ppp> <http://example/vvv> .
>   _:bnode <http://example/ppp> <http://example/vvv> .
>   _:bnode <http://example/ppp> <http://example/vvv> .
> 
> According to the RDF Semantics, an RDF graph is a *set* of triples.
> Hence, AFAIK the above file represents an RDF graph containing *one*
> triple, and the graph is lean.
> 
> If I then query that named graph as follows, how many solutions should I
> get?
> 
>   SELECT * WHERE { GRAPH foo: { ?s ?p ?v } }
> 
> Is the SPARQL server permitted to return more than one solution (i.e.,
> duplicates) in this case?
> 
> I am aware of the DISTINCT keyword, but I always understood it as being
> intended for situations where the query could generate multiple
> candidate solutions, which is not the situation in this case.  It seems
> a little weird if a SPARQL server might return multiple solutions in
> this case, but would it still be conforming to the SPARQL spec if it
> did? 

To further elaborate, if I issue this query in the above situation

  SELECT (COUNT(*) AS ?count) WHERE { GRAPH foo: { ?s ?p ?v } }

would any number greater than zero be a conforming result for ?count ?

Or in a more general sense, if DISTINCT is not used, are the only
semantically distinguishable values for COUNT: (a) zero; and (b) at
least one?



-- 
David Booth, Ph.D.
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.
Received on Tuesday, 31 July 2012 14:37:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 31 July 2012 14:37:03 GMT