On Wed, 2011-08-03 at 13:50 +0100, Igor Brussilowski wrote: 
> Hello,
> 
> I think I found out the difference between the two rules: the rule created by 
> builtin is a forward rule, and the other one - a backward rule.

Correct, as I explained earlier (maybe on a different list) the rule
layer is a common cause of such issues.

> But my goal is 
> to use the statically created backward rule because it shall also use the 
> EquivalentProperty rule, which is defined as backward. How can I solve the 
> problem?

It's tricky :)

The best answer is to write your own OWL rule set which just uses pure
forward (or backward, depending on your needs/tastes) rules so there is
no layering issue.  This could either be a pure rule set or a "compile
ontology to ruleset" algorithm like the OWL RL rulesets I pointed to
before.

The alternative, is to work with the existing Jena rule sets but add
your own additional sameAs inference steps.  Thus for any new rule where
you would expect to write:

  [ ... some pattern ... -> (?X owl:sameAs ?Y) ]

you would actually put:

  [ ... some pattern ... -> (?X owl:sameAs ?Y)
                               [(?X ?P ?V) <- (?Y ?P ?V)]
                               [(?V ?P ?X) <- (?V ?P ?Y)] ]

Dave

> ________________________________
> Von: Igor Brussilowski <[email protected]>
> An: [email protected]
> Gesendet: Mittwoch, den 3. August 2011, 14:27:59 Uhr
> Betreff: Rules creation: builtin vs. static computation
> 
> 
> Hello, 
>  
> I'm trying to construct a rule like owl:hasKey  by myself, which shall look 
> like 
> (?A owl:sameAs ?B) <- (?A :P ?v)(?B :P ?v).  I expect from this rule that the 
> instances A and B are declared sameAs and  merged together, so that 
> properties 
> of one instance are also applied to another instance.
> 
>  
> I compare two methods of rule creation - the  dynamic computation in a 
> builtin 
> and the static computation from ontology - and observe different results from 
> these two methods. Whilst the builtin rule works as expected, the  statically 
> computed rule does not merge the instances A and B but only declares  them 
> sameAs.I don't see any decisive difference between my  implementations of 
> these 
> two rules, but the results of their use are different. 
> 
>  
> I attached an  example project, which demonstrates this  test, and would 
> appreciate any advice.
>  
> Igor.



Reply via email to