[RIF] Action 63 on mapping Xcerpt/XChange to the condition language

Hi,

This is a response to my action 'Look at mapping between condition part 
of Xcerpt/XChange and proposed draft RIF condition language', which is 
recorded at http://www.w3.org/2005/rules/wg/track/actions/63 .

Together with Tim Furche, we looked at the proposed condition language 
and the body (query) of an Xcerpt rule, which corresponds to the 
condition part of an XChange rule, and tried to translate the Xcerpt 
queries/XChange condition part to the condition language and back. We 
drew the conclusion that these translations are possible and can be done 
in different ways depending on the granularity of the chosen mapping. We 
will provide the rules for translating Xcerpt queries/XChange condition 
part to the condition language (possibly also for the reverse 
translation), as soon as the condition language progresses from the 
status of proposal. Some comments and details on Xcerpt, XChange, and 
mapping parts of them to the condition language follow.

Regards,
Paula

Xcerpt, XChange and the proposed condition language
----------------------------------------------------------

Xcerpt [1] is a Web and Semantic Web query language that follows the 
logic programming paradigm. It is a deductive, rule-based language 
capable of querying tree- and graph-shaped data. An Xcerpt rule is 
similar to views in database systems, it constructs data based on the 
data items selected from possibly different Web documents. An Xcerpt 
rule separates the query and construction parts: The body of the rule 
queries the data and binds the variables used in the query to data 
items. The head of the rule  constructs data by using the variable 
bindings gathered by evaluating the query. Chaining Xcerpt rules is 
possible giving thus an elegant solution to complex querying problems.

XChange [2] is a reactive, rule-based language for realizing reactive 
behaviour on the Web. XChange is based on Event-Condition-Action (ECA) 
rules: The E-part is an event query specifying the events of interest 
and gathering variable bindings from received events. The C-part is an 
Xcerpt query, which checks if some conditions hold. The A-part specifies 
the action to be executed if the desired events have occurred and the 
conditions hold; actions here are updates to data and raising and 
sending events to XChange programs at other Web nodes.

For determining the suitability of the proposed condition language for 
interchanging parts of Xcerpt and XChange rules, we looked at the query 
part of Xcerpt, which is at same time the condition part of XChange 
rules. As stated above, we didn't had problems in translating this 
language part to the condition language and back. We noticed that the 
proposed condition language corresponds actually to so-called 
conjunctive queries. Conjunctive queries are used for formalizing the 
query core of XML and RDF query languages such as XQuery or SPARQL. Our 
group in REWERSE has already worked on mapping core Xcerpt queries to 
conjunctive queries, see [3] for more details. Not all language features 
are covered in this work, but the ones left out does not pose problems. 
A conjunctive query has a query body and a query head: The body is a 
conjunction of atoms, which are relations over variables (these range 
over the domain of data nodes of the queried tree or graph data). The 
head is used for giving the answer to the query in form of variable 
bindings. One can have unary, binary relations but also ternary 
relations can be considered. Example of such relations are for 
restricting the valuation of nodes (unary relations) or for comparing 
nodes based on some property (join relations). A proposal for the 
semantics of such relations is given in [3].

Perhaps this would be a next step, but we noticed that problems might 
arrise when using the condition language for translating between Xcerpt 
queries and e.g. XQuery queries if the semantics of the language 
constructs is not interchanged. Syntactically it wouldn't pose problems 
for translating between Xcerpt and XQuery queries, if some language 
construct is not supported you don't get the answer to your query. But 
there might also be the case that each of these languages support a 
cosntruct but with different semantics. If the semantics is not 
interchanged, the answers you'll get might be the wrong ones.

Forward-looking, we think that interesting issues to be resolved occur 
when extending the condition language to a rule language (by adding a 
language for the head of the rules)...we move from querying data and 
finding variable bindings to constructing data and using these variable 
bindings. Some languages use set of possible bindings for the variables 
and some use sequence of variable bindings in the construction. Also, 
some languages offer constructs where the order of the variable bindings 
is important (such as FOR in XQuery). One step further, chaining of 
rules is also an issue to be considered.

Comments on existing proposal:
1. It is not really clear why we need to differentiate between internal 
and external atoms in the condition language. Also, such external atoms 
might be of different kinds and it would be good to define them precisely.
2. I'm not sure if someone already tried to parse the given grammar of 
the condition language, but we might get into problems when trying to 
determine if a token is a value or something else. Don't we need to 
quote somehow the values?


[1] http://www.xcerpt.org
[2] http://reactiveweb.org/xchange/intro.html
[3] http://www.pms.ifi.lmu.de/publikationen/index.html#PMS-FB-2006-20