Loosely Coupled

Back when I started working with Jena, my first "ontology task" was to iterate through a subset of objects in the model, perform some operations to slightly modify these objects, and then store the objects back into the model. Sounds simple right? In a traditional database application, this program would consist of a SELECT statement, followed by some business logic, and conclude with a SQL UPDATE . I've probably written code like this hundreds of times. It's simple and runs quickly. On paper, the ontology task seems even easier. Once opening a Jena ontology model , you can query for objects ( Resources ) in any number of ways (including a SQL-like SPARQL syntax). From there you simply create or modify properties on the resource. Since the ontology model is in memory, the changes happen real time (no need for an UPDATE ). And while you could persist the changes, there really isn't any need to. While this seems quite easy, I noticed severe performanc...

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 ...