- From: Enrico Franconi <franconi@inf.unibz.it>
- Date: Mon, 30 Jan 2006 12:45:33 +0100
- To: andy.seaborne@hp.com
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
- Message-Id: <9794547A-F95D-4B19-AA70-6F278BEA3C41@inf.unibz.it>
On 30 Jan 2006, at 12:28, Seaborne, Andy wrote: > > 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. That's correct, since the query wouldn't be well formed for simple entailment. > 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. In the case of SPARQL intended as subgraph matching, allowing bnodes in predicate position seems natural, and of course it would work easily. However, when we formalise subgraph matching with standard simple entailment (as we are doing now), we loose the ability to express queries with bnodes in predicate position, since standard simple entailment is not defined for them. My personal suggestion would be to forbid them. Remember, that this is no loss of expressivity at all, since you could use a variable in predicate position (instead of a bnode) to get the same result: @prefix : <http://example/> . :x :p 1 . { ?x ?y 1 } => { ?x :q 2 } . you get :x :q 2 . in the resulting graph. cheers --e.
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Monday, 30 January 2006 11:45:43 UTC