- From: Enrico Franconi <franconi@inf.unibz.it>
- Date: Tue, 8 Aug 2006 20:09:41 +0200
- To: public-rdf-dawg-comments@w3.org
On 8 Aug 2006, at 17:42, Jorge Pérez wrote:
> Hi,
Hi,
> Only to state clearly my point (up to now I have only presented it
> off-lists to Enrico), I'm not saying that the definitions are
> wrong, they
> are just definitions. I'm only saying that in the way the
> definition of
> "BGP E-matching" is currently stated, there are claims in the spec
> that
> are false and confusing. For example, the last paragraph in section
> 5.2 in
> rq24 has the intention of an "implementation hint", but it does not
> follow
> the formal definition. Another focus of problems (and I presented
> the same
> example to Enrico) is in section 10.3 of rq24 when talking about
> constructing graphs (by CONSTRUCT). The specification says (not
> explicitly
> but at least is what I understand) that one can use the query ?s ?
> p ?o to
> obtain a (sintactic) "copy" of a graph in the case of simple
> entailment,
> but in my example this query (with graph template ?s ?p ?o)
> produces the
> graph { (a, p, a), (X, p, Y), (X, p, X), (Y, p, Y) } following the
> current
> definitions.
>
> I think then that the definitions in section 5.1 must be changed to
> avoid
> these problems, or the claim in section 5.2 must be revised to
> strictly
> reflect what an implementation has to do to find solutions in the
> case of
> simple entailment according to the formal definition.
The analysis is correct. I'd be strongly in favour of the latter,
i.e. to change the definitions in 5.1, since the claim in 5.2 relates
the theory with the current practice and efficient implementations
(based on subgraph matching), and the theory should just (elegantly)
capture that.
cheers
--e.
Received on Tuesday, 8 August 2006 18:10:00 UTC