W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > September 2005

Re: subgraph/entailment

From: Enrico Franconi <franconi@inf.unibz.it>
Date: Mon, 19 Sep 2005 20:55:04 +0200
Message-Id: <641b8800a511601633a7f592f5597af8@inf.unibz.it>
To: Pat Hayes <phayes@ihmc.us>, Peter F. Patel-Schneider <pfps@research.bell-labs.com>, Ian Horrocks <horrocks@cs.man.ac.uk>, Bijan Parsia <bparsia@isr.umd.edu>, Dan Connolly <connolly@w3.org>, public-rdf-dawg-comments@w3.org

> From: Pat Hayes <phayes@ihmc.us>
>
> If one wishes to offer a query-answering service that does check 
> entailments, then the appropriate thing to do within the SPARQL 
> framework is to declare that one is matching queries against a 
> 'virtual graph' which is some kind of logical closure of the graph, 
> rather than the graph itself. But these are different graphs, note.

Sure, we clearly understand that.

> SPARQL does not require queries to be evaluated only against graphs 
> which are closed under some notion of entailment: it is 
> entailment-neutral (except, as noted above, regarding simple 
> entailment, which follows in effect as a structural consequence of the 
> very act of matching itself.) This is not an error or an omission, I 
> would emphasize, but a design decision.

Fine, we want just give a nice semantics to it, which characterises the 
current design decisions, but that also scales up to have general 
entailment based query answering. Our proposal accommodates the current 
"syntactic-driven" behaviour of SPARQL *and* an entailment based one. 
Whatever has been done so far is fine for us, we are just giving a 
general entailment based semantics to it, which makes SPARQL much more 
useful and semantically meaningful.
I'll send to the list our proposal later today.

--e.
Received on Monday, 19 September 2005 19:00:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:14:49 GMT