RE: Questions regarding test case: agg-groupconcat-01 (GROUP_CONCAT 1)

Hello Lee, and everyone else taking the time to answer my question.

Thanks for your responses.

Yes, this answers my questions. However, I've tried to understand why this was not clear to me when reading this.

In the 1.1 documentation, the phrase is:
"Blank nodes in graph patterns act as variables, not as references to specific blank nodes in the data being queried."

While in the 1.0 documentation, the corresponding phrase is:
"Blank nodes in graph patterns act as non-distinguished variables, not as references to specific blank nodes in the data being queried."

For some reason, I must have confused this definition of "acts as non-distinguished variable" (what's a non-distinghuided variable?), perhaps focusing instead on "not as references to specific blank nodes" and confusing this with all other descriptions of how blank node matching should not be done per label. And since my 1.0 implementation passed the tests I didn't think more about it. (However, now I cannot find the 1.0 tests anywhere... Do you have a link?)

However, there's a follow-up question to this: Acts as a variable is a little vague. How does this relate to SELECT * ? In your mail, you make a third definition:
"Blank nodes in SPARQL query patterns act as unnamed variables, and can match any RDF term in the target RDF dataset."

This is a much better description (that even I understand :)), especially the second part. It also clearly implies that these "variables" should not be available in SELECT * responses. I hope you change the description in the specification to include this info.

Anyway, thanks for all the responses.
Sincerely,
Peter Waher


From: Lee Feigenbaum [mailto:lee@thefigtrees.net]
Sent: den 19 juni 2012 19:09
To: Peter Waher
Cc: public-rdf-dawg-comments@w3.org
Subject: Re: Questions regarding test case: agg-groupconcat-01 (GROUP_CONCAT 1)

Hi Peter,

Blank nodes in SPARQL query patterns act as unnamed variables, and can match any RDF term in the target RDF dataset. (This behavior is unchanged from SPARQL 1.0.)

The relevant parts of the specification are:

http://www.w3.org/TR/sparql11-query/#QSynBlankNodes

"""
Blank nodes<http://www.w3.org/TR/rdf-concepts/#section-blank-nodes> in graph patterns act as variables, not as references to specific blank nodes in the data being queried.
"""

http://www.w3.org/TR/sparql11-query/#BGPsparql

"""
A basic graph pattern is matched against the active graph for that part of the query. Basic graph patterns can be instantiated by replacing both variables and blank nodes by terms, giving two notions of instance. Blank nodes are replaced using an RDF instance mapping<http://www.w3.org/TR/rdf-mt#definst>,  σ, from blank nodes to RDF terms; variables are replaced by a solution mapping from query variables to RDF terms.
"""

We'd appreciate it if you could let us know if this addresses your question.

many thanks,
Lee
On behalf of the SPARQL Working Group
On 6/19/2012 11:55 AM, Peter Waher wrote:
Hello

I have some questions regarding the use of [] is queries in the test cases. To me, the following test case (aggregates/agg-groupconcat-01, GROUP_CONCAT 1) is not correctly defined. Have I misunderstood something, or is this a known error, or does the short form [] match anything, and not only blank nodes?

Manifest: (Notice it has been approved)

:agg-groupconcat-01 rdf:type mf:QueryEvaluationTest ;
    mf:name    "GROUP_CONCAT 1" ;
            mf:feature sparql:group_concat ;
    dawgt:approval dawgt:Approved;
    dawgt:approvedBy <http://www.w3.org/2009/sparql/meeting/2010-09-07#resolution_2><http://www.w3.org/2009/sparql/meeting/2010-09-07#resolution_2> ;
    mf:action
         [ qt:query  <agg-groupconcat-1.rq> ;
           qt:data   <agg-groupconcat-1.ttl> ] ;
    mf:result  <agg-groupconcat-1.srx>


Data:

@prefix : <http://www.example.org/><http://www.example.org/> .

:s :p1 "1", "22" .
:s :p2 "aaa", "bb", "c" .

Query:

PREFIX : <http://www.example.org/><http://www.example.org/>
ASK {
            {SELECT (GROUP_CONCAT(?o) AS ?g) WHERE {
                         [] :p1 ?o
            }}
            FILTER(?g = "1 22" || ?g = "22 1")
}


To my eyes (and in our implementation) this returns false. But the test case states it should evaluate to true:

<?xml version="1.0"?>
<sparql xmlns="http://www.w3.org/2005/sparql-results#<http://www.w3.org/2005/sparql-results>">
  <head/>
  <boolean>true</boolean>
</sparql>


To me, this pattern in the query shouldn't match any pattern at all in the data (:s is not a blank node, but an iri):

[] :p1 ?o

However, if I change this pattern in the query to

?x :p1 ?o

then the query evaluates to true in my implementation.

According to the specification, [] should match a blank node (not just anything):
http://www.w3.org/TR/sparql11-query/#QSynBlankNodes

So, which is correct?


·         Should [] in  a query be able to match any type of term?

o   Is this described in the specification, or does the specification need to be updated?

o   How does this relate to compatibility with SPARQL 1.0 queries?

·         Should the query in the test case be updated?

·         Have I misunderstood something else?

Thanks in advance,
Peter Waher