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