W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2006

Re: Final text for Basic Graph Patterns

From: Bijan Parsia <bparsia@isr.umd.edu>
Date: Fri, 20 Jan 2006 01:17:43 -0500
Message-Id: <146bdb5e2f13ea85ed996a60f3bdb01d@isr.umd.edu>
Cc: Dan Connolly <connolly@w3.org>, Pat Hayes <phayes@ihmc.us>, RDF Data Access Working Group <public-rdf-dawg@w3.org>
To: Enrico Franconi <franconi@inf.unibz.it>

On Jan 19, 2006, at 1:00 PM, Enrico Franconi wrote:

> On 19 Jan 2006, at 18:33, Pat Hayes wrote:
>> Of course. You miss my point. I was simply following the general 
>> pattern of how SPARQL queries are defined, using our most recent 
>> attempt at an 'entailment-based' general form of definition, and 
>> applying that to OWL-DL as described in the OWL spec, and seeing what 
>> we finish up with. ( {:a rdf:type :b} is legal OWL-DL, under 
>> appropriate constraints, and is an instance of the query under 
>> binding of a variable to a legal OWL-DL identifier, so... ) I meant 
>> only that if one takes a 'natural' extension of SPARQL to OWL, 
>> keeping the basic form of the definitions but replacing simple 
>> entailment by OWL-DL entailment, then examples like this turn up.
>
> What I am also saying that you have to transport the syntactic 
> constraints that OWL-DL expressions have, to similar syntactic 
> constraints to SPARQL queries when using OWL-DL entailment. Namely, in 
> queries bnodes and variables are not in property position of any 
> triple, nor in object position of rdf:type triples, and there is no 
> rdf, rdfs, owl vocabulary symbol in the query with the exception of 
> rdf:type in property position.
[snip]

For the record, I always presumed that for OWL  DL Entailment, you'd 
work with the abstract syntax, as that's how entailment is defined:
	http://www.w3.org/TR/owl-semantics/direct.html#3.4

So, if I were going to write the spec for SPARQL parameterized  with 
OWL DL entailment, I would first define the abstract syntax of the 
basic query in terms of the abstract syntax (which would only allow 
query variables in certain places), then a transformation to triples of 
that abstract syntax.

So I don't think it's that big of a stretch, actually. You *could* 
define a query syntax with variables in funky places, but it's not 
immediate. And it's not immediate from the SPARQL (it's not *far*, 
cause you can sorta see where some variables "would go" if you tried to 
apply the reverse transformation to triples to sparql GPs).

Cheers,
Bijan.
Received on Friday, 20 January 2006 06:17:52 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:25 GMT