We do inference during insert into the pimo. The rules used for inference are defined in a Jena rules file, you can read the rules. Based on these rules, additional triples are created during insert. Also when you delete triples, the same rules are used to entail the other triples that have to be deleted. To limit the complexity, we limit inference to the TBox. So we infer the subclass and sub-property relations and also inverse triples. We do not infer instance relations and individual triples. When querying the pimo-service, you can rely on all subclass and subproperty and inverse relations. The missing Abox-related relations can be easily added, see below.

see also:

When you want to add many triples yourself using the inference, use the following methods. If you insert to PimoStorage directly, no inference will be done (for performance reasons).

Additional triples inserted by the service

As we inference all subclass and sub-property relations, we lose the original super-class of a class and it is non-trivial to find it. So we decided to add additional helping triples that we find these assertions:

If you add triples to the PimoStorage, you should also add these helper triples as some gui components depend on it.

Querying with regards to Abox inference

To get all classes of all instances, use this SeRQL query:

select x, y from {x} rdf:type {t} rdfs:subClassOf {y}

To get all instances of Pimo:Person, use this:

select x from {x} rdf:type {t} rdfs:subClassOf {pimo:Person}
pimo = <>

To get all direct subclassed of Pimo:Thing, use this:

select x from {x} pimoapi:directSubClassOf {pimo:Thing}
pimo = <>, 
pimoapi = <>

Tips on inferencing by Michael Sintek

this here taken from an e-mail from michael sintek, our local demiurge of inference:

I had a look at the Sesame RDFS implementation, which is quite nice: they use a set of rules (implemented in Java!) for a forward rule engine (probably using some Rete algorithm).

The rules (for Sesame2) are here:

If you don't want the complete inferences, simply remove some of them, e.g. the rules for adding types:

rule rdfs9_1: xxx rdfs:subClassOf yyy && (nt) aaa rdf:type xxx

--> (t1) aaa rdf:type yyy (t2)

rule rdfs9_2: aaa rdf:type xxx && (nt) xxx rdfs:subClassOf yyy

--> (t1) aaa rdf:type yyy (t2)

I could imagine that creating a subclass of RDFSRules and removing these rules will do the magic already, but I have never looked at the code. Anyway, should be trivial ...

At least you could start with this implementation -- doing the entailment stuff from scratch is really nasty (you need something like a semi-naive bottom-up evaluation, otherwise you will derive the same new triples over and over again).

Comment by Florian Mittag

We tried to do just this, but it turned out to be anything else than trivial. The inference engine of sesame described above is only applicable on MemoryStore, but we need it for a NativeStore. Converting the code to do this would mean to implement an inferencer on the native sail, which is quite complicated due to many dependencies on the inner working of the MemoryStore.

Gunnar hacked an improvement of the Jena inferencer, that will do what we want with little transactions (ie only one). Additionaly we will try to create all necessary triples on creation or deletion of classes and things, so an inference engine hopefully won't be needed. Still, it is good to have a backup ;-)

Last modified 11 years ago Last modified on 09/20/06 23:29:05