- 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