We are interested in enabling DAML+OIL-marked documents to be used in applications which require higher reasoning capabilities.
We have experimented with DAML+OIL in assignment 1, in there we developed ontologies and documents that establish facts, and we realize that there is a need for higher reasoning capabilities. For example, if you have an ontology for shopping and documents with facts about customers, you might want to establish "rules" to handle discount to customers depending on their history. You can do this in a straight forward maner using a general reasoner, but these general reasoners are not capable of dealing with (and taking advantage of) rich mark up languages like DAML+OIL.
Some of the issues in this topic are "how to enable inter-operability between heterogeneous rule systems and between heterogeneous intelligent applications that make use of such rule systems. Rules are widely deployed today to represent and automate e-business policies and workflows, for example. Practical advances in such inter-operability would offer the promise to greatly facilitate program-to-program knowledge sharing and integration...". [taken from http://userpages.umbc.edu/~mgandh1/publication/SweetJess.htm]
In this project we review some of the tools with capabilities to map rich markup languages (e.g., DAML) into a form suitable for knowledge-based processing and related tools like translators of general rules into semantic rules, and some of the languages used for such intercommunication between tools.
RuleML is a language based on XML, designed to allow the publishing of business rules. This language can be used to markup both facts and rules, making possible indeed the representation of knowledge bases in web documents. However, in the tools researched for this report, RuleML is used only as an interchange language, whereby the knowledge base is translated to the particular language of the reasoner being used (Jess, Prolog, etc) before any reasoning is done.
Sweetjess is a translator tool for rule languages, specifically it enables bidirectional translation between Jess and RuleML/DAMLRuleML . It is in the form of an API or Java Library. This library contains functions useful in the implementation of Java applications that deal with RuleML.
Sweetjess can take an input (DAML)RuleML document, translate it into the Jess language, assert it into the Jess reasoner, and translate the output (inferred facts) back into (DAML)RuleML.
Sweetjess incorporates situated logic, which means it allows queries or actions to be carried out through the execution of procedural attachments, for example Java programs.
We marked up some documents from the Nature Dataset using RuleML, and wrote some rules to make inferences of the sort “if two documents have the same author, they are related”, or “document a is more recent than document b if the publication date of a if later than the publication date of b”. Notice that the later rule requires the comparison between two dates; to achieve this we took advantage of the situated logic capabilities of Sweetjess.
Example of one rule written in Jess:
(defrule rule3
(publication_date ?doc1 ?date1)
(publication_date ?doc2 ?date2)
(year ?date1 ?y1)
(month ?date1 ?m1)
(day ?date1 ?d1)
(year ?date2 ?y2)
(month ?date2 ?m2)
(day ?date2 ?d2)
(test
(greaterThan mGreaterThan Greater (create$ ?y1 ?y2)))
=>
(assert (more_recent_than ?doc1 ?doc2)))
Example of the same rule written in RuleML:
<imp>
<_rlab>
<ind>rule3</ind>
</_rlab>
<_body>
<and>
<atom>
<_opr>
<rel>publication_date</rel>
</_opr>
<var>doc1</var>
<var>date1</var>
</atom>
<atom>
<_opr>
<rel>publication_date</rel>
</_opr>
<var>doc2</var>
<var>date2</var>
</atom>
<atom>
<_opr>
<rel>year</rel>
</_opr>
<var>date1</var>
<var>y1</var>
</atom>
<atom>
<_opr>
<rel>month</rel>
</_opr>
<var>date1</var>
<var>m1</var>
</atom>
<atom>
<_opr>
<rel>day</rel>
</_opr>
<var>date1</var>
<var>d1</var>
</atom>
<atom>
<_opr>
<rel>year</rel>
</_opr>
<var>date2</var>
<var>y2</var>
</atom>
<atom>
<_opr>
<rel>month</rel>
</_opr>
<var>date2</var>
<var>m2</var>
</atom>
<atom>
<_opr>
<rel>day</rel>
</_opr>
<var>date2</var>
<var>d2</var>
</atom>
<atom>
<_opr>
<rel>greaterThan</rel>
</_opr>
<var>y1</var>
<var>y2</var>
</atom>
</and>
</_body>
<_head>
<atom>
<_opr>
<rel>more_recent_than</rel>
</_opr>
<var>doc1</var>
<var>doc2</var>
</atom>
</_head>
</imp>
Below is an example RuleML document containing a set of rules and the marked version of a few documents from the Nature Dataset
Here is the result in RuleML after the document being processed by Sweetjess.
Example, this jess file was translated into this RuleML file, when the correct translation was this one (they are different in the body of rule3, rule4, and rule5 where the sensors are called, and also the function of the sensors are not traslated).
DAMLRuleML is a syntax for writing RuleML documents in DAML+OIL, which makes them somehow more portable.
In a similar fashion to Sweetjess, TRIPLE is a system that allows the assertion of facts without any semantic specified before-hand. The semantic must be specified through rules in the document. The triple reasoner is supossed to supports rules with full FOL bodies, but the syntax is native (no support for RuleML nor DAML+OIL nor XML).
The example below is similar to the example presented for Sweetjess, this time written down in the TRIPLE language:
In this case the rule is:
Two articles are related if:
// nature := "http://www.mindswap.org/2002/nature#
// collection of nature documents
@nature:documents {
nature:doc1[
dc:author->pb[name->"Philip Ball"];
dc:title->"DNA Computers help travelling salesman";
dc:subject->Tecnology;
dc:subject->Genetics].
nature:doc2[
dc:author->pb[name->"Philip Ball"];
dc:title->"Curtains for LCD rubdown";
dc:subject->Tecnology].
nature:doc3[
dc:author->pb[name->"Philip Ball"];
dc:title->"Not a tangled web";
dc:subject->Physics].
nature:doc4[
a->na:NSUArticle ;
dc:title->"Taste triumph" ;
dc:author->sa[name->"Sara Abdulla"];
dc:creator->"Sara Abdulla" ;
dc:date->"2000:01:25" ;
na:nsuCategory->"brain" ;
dc:subject->RDFs;
na:nsuType->"news" ;
na:lead->"For the first time..." ;
na:body->"<p>As every take-away .... "].
}
// domain ontology
@NatureOntology {
Genetics[subClassOf -> Physics].
// ...
}
FORALL DCModel,Ontology @related(DCModel,Ontology) {
FORALL doc1,doc2, title1 related(doc1,doc2) <- doc1[dc:title->title1]@DCModel AND doc2[dc:title->title1]@DCModel.
FORALL doc1,doc2, subject1 related(doc1,doc2) <- doc1[dc:subject->subject1]@DCModel AND doc2[dc:subject->subject1]@DCModel.
FORALL doc1, doc2, subject1 related(doc1, doc2) <- // trivial heuristics
EXISTS subject2 (
subject2[subClassOf->subject1]@Ontology AND
doc1[dc:subject->subject1]@DCModel AND doc2[dc:subject->subject2]@DCModel).
}
FORALL Doc1,Doc2,Title1,Title2 <- related(Doc1,Doc2)@related(nature:documents,NatureOntology) AND Doc1[dc:title->Title1] AND Doc2[dc:title->Title2].
Output from TRIPLE:
Output From TRIPLE Engine *** Doc1 = nature:doc1, Doc2 = nature:doc2, Title1 = 'DNA Computers help travelling salesman', Title2 = 'Curtains for LCD rubdown' Doc1 = nature:doc1, Doc2 = nature:doc1, Title1 = 'DNA Computers help travelling salesman', Title2 = 'DNA Computers help travelling salesman' Doc1 = nature:doc2, Doc2 = nature:doc1, Title1 = 'Curtains for LCD rubdown', Title2 = 'DNA Computers help travelling salesman' Doc1 = nature:doc2, Doc2 = nature:doc2, Title1 = 'Curtains for LCD rubdown', Title2 = 'Curtains for LCD rubdown' Doc1 = nature:doc3, Doc2 = nature:doc1, Title1 = 'Not a tangled web', Title2 = 'DNA Computers help travelling salesman' Doc1 = nature:doc3, Doc2 = nature:doc3, Title1 = 'Not a tangled web', Title2 = 'Not a tangled web' Doc1 = nature:doc4, Doc2 = nature:doc4, Title1 = 'Taste triumph', Title2 = 'Taste triumph' --------------------------------------------------------------------------------
Notice, that this example go beyond the example of Sweetjess. In this case we are to infer that to articles are related if they have the same subject, OR if one subject is subClass of another. However, that the property subClass is not transitive because TRIPLE is not using the semantics of a daml+oil ontology but it has to be defined by user through rules.
Example: In this example, we assert that Test5 is a class with the restriction of having Turkey as a value for the property meep. We also assert that Joe is an instance of Test5 This is the Input File, after using DAMLJessKB we get Output File.
Note that this triples are asserted by Jess:
http://plan.mcs.drexel.edu/projects/legorobots/ontology/test.daml#meep
http://plan.mcs.drexel.edu/projects/legorobots/ontology/test.daml#Joe
http://plan.mcs.drexel.edu/projects/legorobots/ontology/test.daml#Turkey
This is, the reasoner is able to find that Joe should have Turkey as a value for meep. While other systems would report this as an inconsistency in the ontology, DAMLJessKB chooses to assert it.
We welcome your suggestions.