Saturday, August 13, 2011

Improving my TopSPIN forehand: Working with TBC and SPIN

In my new position as visiting research faculty at IUPUI, I am working on synthesizing sensor based systems based upon mission requirements from infrared sensors and allied processing algorithms for visualization and classification. For me, this marks a return to where I started off during my PhD years at the University of Memphis. Back then, I developed the very first version of the OntoSensor ontology for the Center for Advanced Sensors. Since then, OntoSensor has grown into a definitive resource for sensor descriptions. It gives me great satisfaction to learn this work has 72 citations. OK, quite a few of them are from the same group under Dr David Russomanno, who is now Dean at the Purdue School of Engineering and Technology at IUPUI. But still..

This project follows up on some good work by Joseph Qualls. In his PhD thesis work,he has used an ontological framework to describe mission tasks and objectives and combined it with the OntoSensor ontology and a simple ontology to describe algorithms to synthesize novel systems that bring together sensors and algorithms to satisfy a mission objective. Examples of these simple objectives are "identify human carrying a backpack" and "generate a silhouette profile of target at coordinates ." Algorithms implemented in Java are coupled to output data through SPARQL CONSTRUCT queries. The project has been implemented using TopBraid Composer (TBC), the licensed ontology development software being developed at TopQuadrant.

After all these years working with open source ontology development tools like Protege and Swoop , it is something new for me to work with a licensed product like TBC. TBC has been built upon the Eclipse platform and brings together a lot of the current state of the art Web 3.0 technologies such as OWLIM, Jena, and Pellet.

To this, TBC brings in its own in-house reasoner called SPIN or the SPARQL Inferencing Notation. SPIN modules and templates attempt to circumvent the reliance of full blown OWL 2 ontologies on restrictions, which cause well documented issues of tractability and scalability. SPIN is actually mapped to a fragment (or profile) of OWL 2 called the OWL 2 RL. SPIN allows for constraints and inferencing rules to be added to simple RDF classes in much the same way as OWL, while dispensing with complications such as cardinality restrictions. SPIN modules also allow for the invocation of Java functions from a SPARQL query using the LET and BIND constructs. Java functions can be wrapped in a SPIN module, allocated a URI that can be shared on the Web, saved, and subsequently invoked as part of a SPARQL CONSTRUCT or even a SELECT query. For more, consult Holger Knoblauch's blog . Whether SPIN rules and templates can be used outside the TBC environment is an open question.

To avoid this potential pitfall, I am also looking into encapsulating each sensor and algorithm as a Semantic Web service, that can be dynamically configured and invoked in the same fashion as in biological workflow engines such as Taverna. Talk about learning from past experiences!