RE: Scope

Hi Andy,

> I'm not up to speed on RuleML but it does seem like a starting point to
> consider.   Would someone like to comment here?  How would it describe
> getting back a set of results?

An XML-RDF standard for inference *results* is not part of the current RuleML 0.8
proposal. But like in Bruce Spencer's recent j-DREW or Richerd Fikes' DAML+OIL query
proposal, inference results could be represented as instantiated query atoms in 0.8.

For example, assuming there is an own(Mary,book) fact encoded in a RuleML rule base,
the query

<atom> <_opr> <rel> own </rel> </_opr> <ind> Mary </ind> <var> What </var> </atom>

could return the instantiated atom

<atom> <_opr> <rel> own </rel> </_opr> <ind> Mary </ind> <ind> book </ind> </atom>

Such an ATOM, then, could be regarded as a RuleML fact <fact> <_head> ATOM </_head> </fact>.
If there are several (finitely many) inference results, i.e. several instantiated ATOMs or
FACTs, we would obtain an entire "result rule base" <rulebase> FACT1 ... FACTm </rulebase>.

A disadvantage of this "instantiated query atom" method is some redundancy for the results
of queries with repeated variable occurrences (especially, when we allow Prolog structures,
i.e. RuleML's cterms, not just Datalog constants).

Alternatively, we could use an XML-RDF representation for (result) environments of bindings.

Using this, the example query could, e.g., yield some XML element like

<environment> <bind> <var> What </var> <ind> book </ind> </bind> </environment>

Environments might also be useful for "extra-logical" purposes in an extended rule language,
e.g. for defining its own (meta-)interpreter. However, explicit environment elements in rule
bodies would, among other things, entail variable scoping problems.

In spite of its above-mentioned disadvantage, I currently prefer the "instantiated query atom"
method, since it works without introducing any new language construct.

Cheers, Harold

Received on Tuesday, 20 November 2001 17:33:46 UTC