Re: Blank nodes and predicates

>>At the moment, rq23 allows blank nodes in the predicate position 
>>both in the definition of a triple pattern and in the grammar.  I 
>>changed the definition recently to make the syntax and the 
>>definitions consistent.  There are approved syntax tests with bnodes 
>>in the predicate position but, being syntax tests, the tests do not 
>>given any clue as to what is supposed to happen.
>>
>>The text in 2.5.2 that describes how to do simple entailment 
>>matching would cover the case of blank nodes in the predicate 
>>position.  Pat said in the telecon (26 jan 06) that a blank node in 
>>the predicate position would never match under entailment.
>>
>>Looking for experience, I tried cwm.  cwm allows blank nodes in the 
>>predicate position in rule matching.
>>
>>I tried --
>>
>>@prefix : <http://example/> .
>>:x :p 1 .
>>{ ?x _:p 1  } => { ?x :q 2 } .
>>
>>and got :x :q 2 . in the resulting graph.
>>
>>I have added this as a test case in tests/data/BasicGraphPatterns
>>http://www.w3.org/2001/sw/DataAccess/tests/data/BasicGraphPatterns/
>>
>>We need to be consistent: if they can match then we can allow them 
>>in both syntax and definition of a triple pattern.  If they don't, 
>>then I see it as confusing to allow them in the syntax or definition 
>>of triple pattern.
>
>I agree.
>
>There is an issue that I didn't think of earlier, I confess. 
>Consider this trivial example:
>
>Dataset
>:a :p :b .
>
>Query
>SELECT ?x WHERE { :a _:bb ?x .}
>
>Should this succeed with x/:b ? Or should it fail? Right now it 
>fails, because the query pattern has no legal RDF instances. But if 
>we were to treat query bnodes as blank query variables, then it would 
>succeed, since then the answer mapping (x/:a, _:bb/:p) would make the 
>illegal pattern into legal RDF.
>
>Now, even though we havn't treated bnodes as blank variables, this is 
>a very string intuition, as comments have already pointed out. And 
>moreover it is a sound intuition all the way up through RDFS and 
>maybe even further. So, allowing bnodes in property position in query 
>patterns seems to require us to take a rather firm stance against a 
>strong and useful intuition. Which might not be good.
>
>So, I suggest that we either eliminate property-bnodes from the 
>syntax, or else (my preference) we treat query bnodes as being just 
>like blank variables, so that this query would succeed, conforming to 
>cwm usage. This makes semantic sense for RDF and RDFS. It would be 

I fully agree to treat query bnodes as bvars and have
test evidence from 3 independent reasoners that they do so

1/ cwm gives
    {
        <http://example.org/eg#b>     :bound "x" .
 
        }     a :Result .

2/ ARQ gives
[]    rdf:type      rs:ResultSet ;
      rs:resultVariable  "x" ;
      rs:solution   [ rs:binding    [ rs:value      :b ;
                                      rs:variable   "x"
                                    ]
                    ] .

3/ euler gives
(:b) .

>ruled out as ill-formed for OWL-DL in its current strictly 
>"first-order" incarnation, but an OWL version will need to impose 
>many syntactic constraints on query patterns anyway, so this will 
>just be one more to add to the list.


-- 
Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/