[Eulergui-user] generating SPARQL queries using rules

[Jean-Marc V. <jea...@gm...>]

Hi

Pasted from my blog ; comments welcome :
Rules are not only for business rules

In fact business rules are raw material for the building of business
applications just like ontologies and structural models. And, because we
build business applications using rules (applicative and infrastructure
rules), this means having rules manipulating rules.

We already have such rules manipulating rules to :

   - transform SWRL rules into N3 rules
   - check N3 rules for undeclared properties and classes
   - declare undeclared properties and classes in N3 rules

We need to have more rules manipulating rules to :

   1. transform N3 rules into Drools rules (currently implemented by ad-hoc
   Java code)
   2. generate SPARQL queries from N3 rule base and a *simplified N3 query* (an
   N3 expresion with triples including variables but no braces)

Point 1 will stay like this in the near future, as current implementation
is well tested and extensible.

The point 2 is necessary for automating access to Linked Open Data (see Roadmap
for EulerGUI 2.1<http://eulergui.svn.sourceforge.net/viewvc/eulergui/trunk/eulergui/html/documentation.html#L9989>
,
and Sketch of a roadmap / The Déductions
stuff<file:///Volumes/NO%20NAME/jmvanel.free.fr/computer-notes_2008.html#L141>
in
this blog).

We need to design and implement a backward engine for querying SPARQL
databases; it will generate a big SPARQL query by recursively accumulating
criterium terms, substituting bound variables, renaming variables if
necessary.

I used to think that for point 2, the capabilities of Euler or
CHR<http://en.wikipedia.org/wiki/Constraint_Handling_Rules> to
handle unbound variables can be leveraged. But I changed my mind. Since I
already have experience with dealing with SWRL, it ' s probably quite easy
to first convert the N3 to SWRL. Good thing with SWRL is, it's plain RDF,
and as a consequence there's no possible confusion between input rules and
transformation rules (this is actually a problem when processing N3 with
N3). It's also easier to match rule parts when the rule is expressed as
pure RDF graph (SWRL or other).

So the roadmap for this SPARQL generation feature could be :

   1. transform N3 rules into SWRL rules
   2. transform one SWRL rule into SPARQL (needs an RDF vocabulary for
   SPARQL queries)
   3. add recursivity by finding SWRL rules matching a simplified N3 query
   4. add recursivity by replacing matching triples in antecedent with
   their definition from a rule

As an exemple, think of a family relationship rule base (see rules examples
- Family relationships<http://eulergui.svn.sourceforge.net/svnroot/eulergui/trunk/eulergui/html/rules-examples.html#L492>
 ).

Starting from a *simplified N3 query* :

:John :hasUncle ?U

By 3, this rule is picked:

{ ?X hasParent ?P .
  ?P hasBrother ?B .
} => {
  ?X hasUncle ?Y }.

By 4, the rule for hasBrother is picked, and the antecedent is substituted
in preceding rule :

{ ?X hasParent ?P .
  ?B a Male.
  ?P hasSibling ?B .
} => {
  ?X hasUncle ?Y }.

For property hasParent, a background declaration states that the
corresponding triples are hosted in some SPARQL endpoint:

hasParent eg:inSPARQL_endpoint <http://mydatasource.org/> .

So, no need to recurse on property hasParent.

Similarly, for class Male, , a background declaration states that the
corresponding triples are hosted in some SPARQL endpoint:

Male eg:inSPARQL_endpoint <http://mydatasource.org/> .

Process goes on with expanding hasSibling .


-- 
Jean-Marc Vanel
Déductions SARL - Consulting, services, training,
Rule-based programming, Semantic Web
http://jmvanel.free.fr/ - EulerGUI, a turntable GUI for Semantic Web +
rules, XML, UML, eCore, Java bytecode
+33 (0)6 89 16 29 52
chat :  irc://irc.freenode.net#eulergui