This is one of the possible Use Cases.
1. Abstract
The rule interchange format, which will be standardized, web-friendly, and interchangeable, is a useful tool for describing concepts and relations that are difficult to generally describe in OWL.
2. Status
Proposed by MinsuJang
3. Links to Related Use Cases
4. Relationship to OWL/RDF Compatibility
- It's required to reference resource IDs defined in RDF or OWL.
5. Examples of Rule Platforms Supporting this Use Case
- SWRL and WRL are two representative examples of efforts to support the features described in this use case. KAON2 is announced that it supports SWRL reasoning.
- Rule-based OWL reasoners such as Bossam, Euler etc can easily import RDF/OWL documents as a series of plain 2-ary ground predicates and perform reasoning with the rules that refer to them. These platforms, however, are not known to support sound neither complete inference.
6. Benefits of Interchange
- Benefit 1: Rules that extend OWL-based ontologies are exchanged among parties that use different rule engines, which enhances the expressivity of web semantics.
7. Requirements on the RIF
- Requirement 1: Guidance on how OWL/RDF triples are associated to the patterns in rules. (OWL/RDF compatibility issue?)
8. Breakdown
8.1. Actors and Their Goals
Domain Knowledge Author writes formal term definitions and shares them.
Semantic Search Engine collects and performs reasoning on the knowledge shared on the web.
8.2. Main Sequence
Domain Knowledge Author builds formal descriptions, in OWL and RIF, of the terms in the domain of interest.
Domain Knowledge Author publishes the descriptions on the web to share them among knowledge authors.
Domain Knowledge Authors refer to the terms defined in the formal descriptions written by other authors to write their own descriptions or to derive new knowledge by performing reasoning.
Semantic Search Engine collects formal descriptions on the web and performs reasoning on the descriptions to search for specific knowledge. For such engine to exist, the formal descriptions should be specified in a standard, compatible syntax and semantics.
9. Narratives
9.1. Building and Sharing a Family Ontology
Joe, a web ontology designer, tries to build and share a family ontology. But he finds that it's not easy to come up with a general description of the hasUncle property. He tries to do it anyway as follows. He defines the Uncle class using suitable property restrictions:
ObjectProperty(hasSibling Symmetric) ObjectProperty(isUncleOf inverseOf(hasUncle)) Class(Man partial Human) Class(Parent complete Human restriction(hasChild someValuesFrom(Human))) Class(Uncle complete Man restriction(hasSibling someValuesFrom(Parent))) Individual(Sam type(Human)) Individual(John type(Man)) Individual(Bob type(Human) value(hasChild Sam) value(hasSibling John))
Joe is pleased to discover that the above axioms entail that John actually belongs to the Uncle class, because John is a Man, and has a sibling Bob who is (implicitly) a Parent (Bob is a Human and has a child, Sam, who is also a Human).
Joe soon discovers, however, that the axioms do not entail that "John isUncleOf Sam". Even adding the axiom
(Class(Uncle partial restriction(isUncleOf someValueFrom(Human)))
doesn't help: the axioms now entail that John is the uncle of some Human, but not necessarily of Sam. Finally, Joe realises that it is impossible to describe the desired relationship between the hasSibling, hasChild and hasUncle properties in OWL - he will instead need to explicitly specify each and every instance of the hasUncle property.
Joe would obviously prefer to describe the hasUncle property in a general way so that instances of the property can be derived from Parent-Child and Sibling relationships. This is not difficult to do using rules. Joe arrives at the following extended web ontology definition that is associated with a rule.
ObjectProperty(hasSibling Symmetric) ObjectProperty(isUncleOf inverseOf(hasUncle)) Class(Man partial Human) Class(Parent complete Human restriction(hasChild someValuesFrom(Human))) Class(Uncle complete Man restriction(hasSibling someValuesFrom(Parent))) (Class(Uncle partial restriction(isUncleOf someValueFrom(Human))) Individual(Sam type(Human)) Individual(John type(Man)) Individual(Bob type(Human) value(hasChild Sam) value(hasSibling John)) Uncle001: hasUncle(?x,?y) :- hasChild(?z,?x) ^ hasSibling(?z,?y) ^ Man(?y) ^ Person(?z) ^ Person(?x)
Now, anybody who uses Joe's family ontology doesn't have to enumerate hasUncle property instances as they are now entailed by the added rule.
The rule, Uncle001, may be written in a separate document along with a sentence that specifies the pointer to the family ontology the rule is associated with. The rule and the ontology are publicly published as OWL ontologies are. The rule should be authored in a standard interchangeable format so that many different rule engines can process it.
10. Commentary
This may be seen as it is not appropriate as a RIF use-case. But, I bet once RIF is defined, many will use it as if it were an RL.