RE: Query, rules and RDF datatyping

At 11:00 08/10/03 -0400, Geoff Chappell wrote:

>So do I understand correctly that it's not currently possible to return
>bindings from constraints in a RDQL query? And that's what you need to
>support your datatyping rules? I'd always wondered why the two pieces
>were separate - triple bindings and additional constraints - i.e. why
>isn't it just:
>
>  WHERE
>     :vehicle :standingCapacity ?x .
>     :vehicle :seatedCapacity ?y .
>     ?x + ?y = ?z .

Well, as I understand it, RDQL isn't so much a fixed specification as a 
point of reference for folks working in this space.  But as I understand 
it, this kind of additional query binding is not catered for by RDQL.

>We treat them that way in RDFQL - e.g.
>
>WHERE {[standingCapacity] [vehicle] ?x}
>         AND  {[seatedCapacity] [vehicle] ?y}
>         AND ?z=add(?x, ?y)

That's also very similar to the way that CWM works.  It would seem to work 
nicely for rule forward chaining, but I'm not yet sure if it is so helpful 
for backward chaining.

The other desideratum drives me is to separate the datatype-based 
inferences from the actual graph query, because I see them being 
implemented in very different ways.

(I started by thinking that I might be able to define datatype inferences 
as a set of "magic" rules, rules being one of my implementation switching 
points, but I couldn't see how to cleanly incorporate my example in such a 
framework.)

[...]
> > This begs questions about how new variable bindings may be generated,
> > particularly since I want to be able to use this with both forward and
> > backward rule chaining, but I have some ideas that I think I can see
>how
> > to
> > prototype.
>
>This gets you into the finite domain constraint world, doesn't it - i.e.
>you need some way of enumerating the possible (finite) values for a
>particular variable (and hopefully some means of propagating constraints
>to avoid combinatorial hell and make it practical with non-toy domains.)

Yes, very much so.  I hope to be able to make some pragmatic implementation 
constraints that will keep the problem tractable.  But I'm also hoping that 
the framework allows for future experimentation in this area based on 
lessons learned from other languages.

#g


------------
Graham Klyne
GK@NineByNine.org

Received on Wednesday, 8 October 2003 12:14:40 UTC