Since version 5.3 OntoBroker supports updatable materialization. This means that when you add facts or rules after materialization, the materialized rules are re-evaluated together with the changed facts and rules. Technically this works by separating the base facts from the derived facts.

An example: If you have

Tom:Cat.

RULE r1: ?X:"Predator" :- ?X:"Cat".

and you want to materialize rule "r1" then the materialized fact

Tom:Predator.

will not be stored in the table "instanceOf", but instead it will be stored in the table "MAT_instanceOf".

This way OntoBroker can differentiate between base facts and materialized facts. Hence it is possible to revert and update the materialization. If you want the materialization to be updatable then you have to materialize via

OntoBroker32.exe -m:update someRulesToBeMaterialized.obl

or via

start-ontobroker.sh -m:update someRulesToBeMaterialized.obl

on Unix-based systems.

If you don't want to update the materialization you materialize the rules this way:

OntoBroker32.exe -m:noupdate someRulesToBeMaterialized.obl

or

OntoBroker32.exe -m someRulesToBeMaterialized.obl

In this case the materialized facts will be stored in the same tables as the base facts. So it is no longer possible to differentiate between the two types of facts.

Materialization strategies

OntoBroker supports different materialization strategies. The "DRed" strategy works incrementally, the "RFS" strategy will update the knowledge base from scratch. Which strategy will deliver better performance depends on your rules and the change rate.

DRed (Delete and Rederive)

This materialization strategy works incrementally. It creates a maintenance program which aims to re-evaluate only the rules which are affected by the changes. Note that there are cases where this approach does not very well. A typical example is when you have many connected rules and simple changes lead to a re-evaluation of most rules. We also experienced problems when the number of rules is too large.

NOTE: This materialization strategy will delay changes to the ontology until the materialization is triggered again. This means if you add a fact then queries and requests for this fact will only return the expected result after the materialization was executed again.

The DRed algorithm is a well-known materiallization algorithm (original paper: "Maintaining Views Incrementally" by Gupta, Mumick, Subrahamanian). We use a pure declarative version of the algorithm. Basically we rewrite rules like

p(?X,?Z) :- q(?X,?Y) AND r(?Y,?Z).

to the maintenance rules

p_plus(?X,?Z) :- q_insert(?X,?Y) AND r(?Y,?Z).

p_plus(?X,?Z) :- q(?X,?Y) AND r_insert(?Y,?Z).

Then we execute queries on the "p_plus" predicates and add the results to the "p" table of the EDB.

RFS (Rebuild From Scratch)

This strategy works very simple: If a change occurs all materialized facts are thrown away. Then all rules are materialized again. This simple strategy works especially well if

If you decided you want updatable materialization you have to find out which update strategy matches your needs. Currently we support two update strategies: triggered updates and immediate updates.

NOTE: Currently bulk change operations are not supported.

Update strategies

Immediately

This update strategy will execute the materialization as soon immediately after a fact or rule was added or removed.

Triggered

This update strategy will execute the materialization only when the "mat_executeMaterialization" command was executed. A typical scenario is to update the materialization at some time where no one accesses the server (e.g. once a night).