image006.jpg

 

 

 

 

 

Text Box: Main Features: Employ semantic concepts in rules and make rules themselves semantic concepts. Write natural language rules – rules are stored in an OWL ontology and rule expressions are written as natural English. Import OWL/RDF semantics and instance data. Define queries in SQL and SPARQL. Queries can be used both as input to the rule engine and as part of a rule expression. Capture forensic data – provide users the rule engine’s reasoning for a decision with the engine’s forensics data. Integrate using the JSR-94 standard. Transform data from XML and relational DBMS into semantic data using the rules4J Knowledge Factory. Use the same rules with heterogeneous data. Manage semantics and rules using the combined rules4J editor. Build your own rule and semantic editor using the Rulelite API. sales@rules4j.com

M

odern analysis applications require semantic data and semantic rules. The shift towards semantic solutions comes from the need for applications to be more readily adaptable to new situations and problems. Systems built with hard-coded rules operating over engineered structures of Floats, Integers, and Strings are fading into obsolescence.

 

Tellilink’s semantic rule engine, rules4J, is the first commercially available product to fully leverage open-standard semantics (OWL, RDF, SPARQL, etc) and natural language business rules in a Java rule engine. The product includes a data transformation API to marshal data (OWL/RDF, XML, relational DBMS) into a semantic form, a natural language parsing engine, the Java based rule engine itself, and a client application to author, test, and manage rules and semantics (ontologies).

 

It is easily deployed into a Service Oriented Architecture, web applications, or stand-alone desktop applications—anywhere Java is used.

 

Traditional rule engines use engineered data structures (i.e., from a programming language or a database) directly in the logic of the rules. These data structures are tied directly to specific system behavior and a specific business problem. There is no real layer of abstraction above raw system code.

 

Such systems can exist only as a single, engineered whole. Each part, from the rules to the data to the system’s capability, resists change and adaptation to new problems. In such systems, programmers need subject matter expertise, and real subject matter experts participate only indirectly in defining how the system works.

 

Ultimately, this drives systems to be “hard-wired” for specific, moment-in-time problems with well-known and predefined sources of data.

 

rules4J, with its emphasis on semantics, is designed to solve this problem. Semantics provide a layer of abstraction between the logic of the system and the data it uses. Data can exist in multiple and varied forms and can change without breaking the logic—the rules—of the system. Engineers can focus on building features and capability. Subject matter experts can focus on defining the rules and semantics.

 

rules4J enables rules to be written that use concepts (Types and their Properties) from an ontology. So one might write a rule as:

 

If this is an IllegalTransport

Then send an alert.

 

IllegalTransport is a semantic concept. It is created by a subject matter expert. Sending an alert is a capability of the system written by an engineer. Rules4J uses such rules and concepts to classify data and control the system.

 

The separation of rules, data, and capability means that a system of very general capability can be tailored for very specific use, with subject matter experts defining the specifics. To think of it in human terms: a person’s response to “danger” might always be the same—fight or flee—we are very general systems in a sense. But the concept of what danger is changes constantly depending on the situation. What distinguishes us as a species (and what keeps us alive) is that concepts like danger are not hard-wired into us. This is also what distinguishes systems built on semantics.

 

 

Reducing system complexity is one of the chief goals for rules4J, and it seeks to do this not only by simplifying and better organizing the rules in a system, but also by simplifying the creation of semantics.

 

Rules are simplified by placing them in rulesets that are managed as concepts. In the example shown at left, all of the rulesets (HazMatDriver, Medical, IllegalTransport, Waste, etc) are semantic concepts. This means that they can be organized as a hierarchy and that child concepts inherit the rules of parent concepts. These concepts can be formed from concrete types such as Truck, or Waste as well as from business processes such as TruckInspection or CargoScanning. The behavior of the system can be changed not only by changing the way a rule is written, but by changing the way these concepts relate to one another.

 

Complexity has also traditionally been a problem in projects that use semantics (and particularly OWL). And most of the complexity comes from the need to express the logic of the system in the structure of the semantics. This usually takes the form of anonymous classes and local restrictions, and what you end up with when you take this design approach are semantics that apply only to a very narrowly defined problem and whose meaning can be very subtle and hard to understand. In fact, the behavior of a system that runs from these semantics can be hard to predict.

 

Rules4J solves this problem by taking the logic out of the semantic model altogether. Since rules drive classification, there is no need for the model to be designed for problem-specific classification. It can be more general and more reusable; and it can be maintained by a greater number of people with a greater variety of skills.

 

This opens up new possibilities for who modifies and maintains a system and the ease with which the system can be changed. With rules written in English and semantics maintained in simple, concrete models, many of the things that had to be done by an IT staff can now be done by system users.