Jena Lessons - The Reasoner
Earlier this year I started to work with ontology, specifically utilizing Jena to process and manipulate an ontology model. I thought it would be good to share some of what I'm learning as I gain experience programming in this environment.
I thought I'd start with a quick discussion of the Reasoner. First, let me give my 10-cent understanding of ontology and where the Reasoner fits in to all of this.
For me, it's easiest to think of an ontology as an object store. There are classes, and the classes can be related to each other in a number of ways. In an object oriented sense, these relationships can be associations, aggregations, or through inheritance.
Both the class definitions and the instances of these classes are stored in the ontology. Like a regular Java class, an ontology class definition might include a supertype and some distinguishing properties. When an instance of the class is created, the instance gets a unique name (a URI), at least 1 statement to identify it's class, and any number of properties belonging to the unique instance. This "hard data" belonging to the class instance is often referred to as "facts".
Additional knowledge can be "inferred" from the model by combining the instance information (facts) with the data contained in the class relationship. For example, assume we have the following hierarchy
The model only really "knows" that Yogi is a Bear, but the Reasoner can "infer" with some certainty that Yogi is also a Mammal and an Animal based on the class relationship. Note that there is no "hard data" in the model asserting these facts.
It's the Reasoner that creates this inference information. The example above was intentionally trivial. It's not hard to imagine how a more sophisticated model can result in more complex inferences and a much deeper understanding of the data and the relationships contained within.
Powerful stuff.
I thought I'd start with a quick discussion of the Reasoner. First, let me give my 10-cent understanding of ontology and where the Reasoner fits in to all of this.
For me, it's easiest to think of an ontology as an object store. There are classes, and the classes can be related to each other in a number of ways. In an object oriented sense, these relationships can be associations, aggregations, or through inheritance.
Both the class definitions and the instances of these classes are stored in the ontology. Like a regular Java class, an ontology class definition might include a supertype and some distinguishing properties. When an instance of the class is created, the instance gets a unique name (a URI), at least 1 statement to identify it's class, and any number of properties belonging to the unique instance. This "hard data" belonging to the class instance is often referred to as "facts".
Additional knowledge can be "inferred" from the model by combining the instance information (facts) with the data contained in the class relationship. For example, assume we have the following hierarchy
- Animal (class)
- Mammal (class)
- Bear (class)
- Yogi (instance)
The model only really "knows" that Yogi is a Bear, but the Reasoner can "infer" with some certainty that Yogi is also a Mammal and an Animal based on the class relationship. Note that there is no "hard data" in the model asserting these facts.
It's the Reasoner that creates this inference information. The example above was intentionally trivial. It's not hard to imagine how a more sophisticated model can result in more complex inferences and a much deeper understanding of the data and the relationships contained within.
Powerful stuff.
Comments