OWLIM Rules vs OWL RL

{excerpt}Use OWLIM Rules or OWL RL for FRs [CRM Search]?{excerpt}
{toc}

h1. Considerations on OWL RL

- what dialect will we have to use?
Mariana: OWL RL (optimized), i.e. builtin_owl2-rl.pie
- what constructs do we need?
owl:PropertyChainAxiom, owl:TransitiveProperty, owl:ReflexiveProperty; disjunction and conjunction
- should we use TTL or Manchester syntax?
OWLIM includes no parser for the OWL Functional syntax
-- Use the buttons in [OWL Primer|http://www.w3.org/TR/owl-primer/#OWL_Syntaxes] to switch between syntaxes, and use as syntax examples
-- Unlike the examples in OWL Primer, Mariana was able to use a simple TTL syntax (no blank nodes and no collections)
{code}rso:PS97_from_actor owl:propertyChainAxiom (crm:P46_is_composed_of crm:P108i_was_produced_by crm:P14_carried_out_by).{code}
-- Manchester (.omn) is cleaner than .TTL for more complicated stuff, but does Sesame have a reader for it?
- singleton propertyChainAxiom
Vlado: I think that instead of singleton propertyChainAxiom:
{code}rso:PS97_from_actor owl:propertyChainAxiom (crm:P52_has_current_owner).{code}
for efficiency we should use a super-property:
{code}crm:P52_has_current_owner rdfs:subPropertyOf rso:PX97_from_actor.{code}
- how to express disjunction?
owl:unionOf is for classes not properties, but you get disjunction simply by writing several clauses.
E.g. PX97_from_actor is defined through 3 disjunctive clauses (owner, keeper, composed-produced-carried):
{code}
crm:P52_has_current_owner rdfs:subPropertyOf rso:PX97_from_actor.
crm:P50F_has_current_keeper rdfs:subPropertyOf rso:PX97_from_actor.
rso:PX97_from_actor owl:propertyChainAxiom (crm:P46_is_composed_of crm:P108i_was_produced_by crm:P14_carried_out_by).

"For performance reasons, the rules should not be expressed in OWL 2 RL which is in turn interpreted through the OWLIM OWL2RL ruleset, but they should be expressed directly in the OWLIM rule language. See [OWLIM-280@JIRA] for performance considerations about OWL2 RL."
- Vlado: [OWLIM-280@jira] is closed, but I can't figure out from the comments whether property chains should be used or not.
-- Damyan 24 Nov 2011: we rewrote the rule implemenation. They now use special contexts instead of nodes, so the performance should be ok
-- Vlado: Great\! OWL is cleaner than custom rules. Our db is small, if we get performance problems we'll rewrite the FRs
- Mariana: OWL2-RL provides support for: owl:PropertyChainAxiom, owl:TransitiveProperty, owl:ReflexiveProperty. The rule prp-spo2 (and it's related rules, specifically prp-spo2_2 and prp-spo2_3) can lead to a performance hit due to OWL's RDF serialisation of property chains using RDF Lists. These standard OWL2-RL rules (from builtin_owl2-rl.pie) can be taken out (in groups) and added to a simpler ruleset like OWL-Horst, but this specific performance penalty is implicit in generically treating the OWL representation.

{code}?obj rso:PS97_from_actor ?actor ::=
?obj a rso:E22_Museum_Object.
?obj rso:PX97_from_actor ?actor.
?obj rso:PS2_has_type ?type ::=
?obj rso:P46_has_main_part ?part.
?part crm:P2_has_type ?type.
?type crm:P2_has_type rst-object:.
{code}
Notice that for both, we have conditions hanging "on the side" of a property chain.
- owl:intersectionOf is for classes, not properties.
- The OWL primer says: "The expression language for classes is very rich and sophisticated, whereas the expression language for properties is much less so."
- [This answer|http://answers.semanticweb.com/questions/11602/property-intersection-impossible-in-owl-2-full] suggests it's impossible to define a property by conjunction in OWL 2, even Full
-- references [DL Complexity Navigator|http://www.cs.man.ac.uk/~ezolin/dl/] (very nice!)
-- [this paper|http://www.cs.ox.ac.uk/files/1857/paper.pdf]: "shows that adding role conjunctions to DLs causes a jump in the computational complexity of the standard reasoning tasks.. due to a subtle interaction between *inverse roles, role hierarchies, and role transitivity* with role conjunctions"
-- (x) This is a major disadvantage of OWL compared to OWLIM Rules or SPIN

h3. Work-arounds
- Vlado: for RS3.1 we hacked the data a bit, but in later iterations when we get to implement more complex FRs, we may go back to doing it with OWLIM Rules
-- Mariana: maybe the model design is to be reconsidered.
-- Vlado: That's what we did for RS3.1 (hacked the data). But we shouldn't expect to be able to always hack the data. When we get to implement *complex* FRs, we'll need conjunctivity
- Mariana: This can be specified with domain and range of the property.
It is another thing, that the entire concept hierarchy above the class of the domain and the class of the range get inferred for the property when the domain and range get explicitly specified.
-- Vlado: domain and range DO NOT constrain anything. They only infer new types for nodes. Eg if you say:
{code}rso:PS97_from_actor rdfs:domain rso:E22_Museum_Object.{code}
trying to exclude eg Collections from the extent of this property, you'll only infer that Collections are E22_Museum_Object, which is manifestly false

h1. Cons of OWLIM Rules

- non-standard, and BM doesn't like if we use non-standard techniques in the repository
Better to use standard OWL axioms, with the appropriate parts of the standard OWL2-RL ruleset.
-- Mariana: Even in the presence of custom rules (triggered by the specific FR-related predicates) the ontology should probably preserve the working (if slow) OWL2-RL axioms but drop the generic rules from the ruleset.
Vlado: Why? I don't understand this
- harder to deploy: need to mix with the builtin PIE file, play with config files
- require repo reloading when changed