Do not edit this page in Rich Text mode, edit only in Wiki mode

Introduction

TODO: copy more from my email to Martin

OWLIM Rules and Reasoning Dialect

RS3.1 FRs were implemented using reasoning dialect "OWL RL (optimized)", i.e. builtin_owl2-rl.pie.
We used constructs owl:PropertyChainAxiom, owl:TransitiveProperty, owl:ReflexiveProperty, and rdfs:subPropertyOf (which amounts to disjunction).
But as described in [OWLIM Rules vs OWL RL#Cons: Less Expressive], OWL RL is less expressive than OWLIM Rules, since one cannot define a property by conjunction.
We are pretty sure the full FR set will require conjunction, so we'll go with OWLIM Rules. See OWLIM Rules documentation.

We'll use the RDFS reasoning dialect as a basis, by weaving our rules into builtin_RdfsRules.pie. That file is part of the OWLIM distribution (in my case [c:\my\Onto\proj\OWLIM\software\owlim-se-4.2.3924\builtin_RdfsRules.pie]).

Weaving for Production

This page is used to generate OWLIM artefacts for production. We "weave" them from {code} blocks in the page, following Literate Programming. We weave several files based on code block titles:

• the weaver automatically generates rule identifiers in the form "Id: fr$n" where $n is a counter
• "Rule" includes one rule per code block in the OWLIM notation, eg:
• "Rules" includes one rule per line in a shorthand notation, eg:

  The shortcut notation is translated to the OWLIM notation. This shortcut form is very useful for shorter rules

Modularity and Naming

A very important aspect of our implementation is modularity: we define appropriate sub-FRs and use them when defining FRs.
We use the Erlangen CRM (ECRM) naming variant (underscores instead of dots), and the following naming conventions:

• crm: Enn_entity_name, crm: Pnn_property_name: CRM entities and properties
• rso:FRnn_name: property representing an FR
  • rso stands for "RS ontology"
  • nn is a number that we try to keep the same as a related CRM property number (eg FR7_thing_from_place is numbered after P7_took_place_at)
• rso:FRXnn_name: property representing a sub-FR
  • sometimes we use two numbers if the sub-FR refers to two CRM properties, eg
    FRX62_67_depicts_or_refers_to := P62_depicts or P67_refers_to
• rso:FRTnn_name: transitive closure of crm: Pnn_name
  • we denote this as FRTnn_name := Pnn_name+
• rso:FRSTnn_name: symmetric-transitive closure of crm: Pnn_name
  • we denote this as FRSTnn_name := (Pnn_name or Pnni_inverse_name)+
• rso:FCnn_name: Fundamental Concept or another class used in defining FRs

Prefixes

This adds prefixes to FR.ttl:

This adds prefixes to the rules file (it already has: rdf rdfs owl xsd):

Transitive and Inverse Properties

We use the RDFS dialect as a basis, which implements rdfs:subClassOf and rdfs:subPropertyOf reasoning.
In addition, ECRM declares Transitive and Inverse Properties, eg

ECRM also defines Symmetric properties, but always declares them as self-Inverse, so we don't need to treat them separately. Eg:

It's very useful to rely on general Transitive and Inverse reasoning, so we copy the relevant rules from builtin_owl2-rl.pie:

Reflexive Properties

FR definitions are full of reflexive-transitive sub-FRs. In FRThing.docx they are denoted (Pnnn)(0,n), and below we denote them as Pnn*
But I think it's bad style to use reflexive properties in the implementation since they generate lots of trivial facts (self-loops) in the semantic repository. Instead of reflexive closure, we use disjunction: the iterated property is applied 0 times in the first disjunct, and n times in the second, eg:

• person from place :=
  • person P74_has_current_or_former_residence place OR
  • person P74_has_current_or_former_residence subPlace AND subPlace FRT89_falls_within place

FR Notes

FR design in the following sections is based on FRThing.docx by M.Doerr and K.Tzompanaki, after clarifications and corrections by V.Alexiev.

• We don't implement FRs:
  • for which there is no data in neither Rembrandt nor BM collections
  • that are interesting for history/archaeology but not museum collections (eg Destroyed at)
• We omit composite FR such as "Was created/produced by person from" since they are treated separately
• In many cases we don't check types, since these are implied by the domain/range of a property. Eg in:
  • E24.Physical_Man-Made_Thing – P128F.carries -> E73.Information_Object
    the property P128 implies that the source and target have the indicated types

Fundamental Concepts

Thing

FC70_Thing in General

"Thing" is defined as the following (was called C1.Object):

• FC70_Thing := E70_Thing NOT E21_Person NOT E55_Type NOT E30_Right NOT E41_Appellation

Here we enumerate all subclasses of the undesirable classes, since neither OWL nor OWLIM can express "NOT subclass". <owl:disjointWith> is used to infer a contradiction, not to define a class.
If someone defines an application-specific subclass of an undesirable classes, it can "sneak through" this rule

FC70_Thing for RS

In RS we search only for top-level things (eg a Painting, but not a Frame that makes part of a painting). These have type E22_Museum_Object, so the rule is much simpler:

Fundamental Relations

Thing-Place

Thing "refers to or is about" Place

As defined in FRThing.docx:

Problems:

1. At beginning: does not allow paths
   including mixed properties (eg P130-P130i, P106-P148), or
   in which P46,P106,P148 precede P130,P130i
   • Resolved: we mix all these properties freely: any path of the indicated properties, in any order, of any length
2. At E73: does not allow P106_is_composed_of, P148_has_component which are legitimate for E73 (being a subclass of both E89_Propositional_Object and E90_Symbolic_Object)
   • Resolved: we add P128 into the mix.
     Did we mix it up too much? I think it's ok: not all allowed paths are correct, but all correct and relevant paths are allowed
3. At E26: does not allow P130,P130i,P46
   • Resolved by adding the mix at E26 too
4. At end: is it really appropriate to use part-transitivity for this FR? If a thing is about Knossos, is it also about every little village, house and room in Knossos?
   It was established this FR is not co-variant (not appropriate to loop using P89*), but is it appropriate to use P89i*
   • PENDING

Corrected definition:

• FRT130_46_106_148_shows_features_or_is_composed_of := (P130 or P130i or P46 or P106 or P148)+
  Rules

• FRX62_67_depicts_or_refers_to := P62_depicts or P67_refers_to
  Rules

• FRX67_refers_to_or_is_about := paths from FC70 to E53, with no loops at start & end nor type constraints
  Rules

• FRT67_refers_to_or_is_about := add loops at start & end
  (Note: ECRM defines P89i_contains as transitive)
  Rules

• FR67_refers_to_or_is_about := add type constraints at start & end
  Rules

Thing "is referred to at" Place

Thing "from" Place

Thing "used at" Place

Thing "created at" Place

Thing "found or acquired at" Place

Thing "is/was located at" Place

Thing-Thing

Thing-Actor

Thing-Event

Thing-Concept

Scratchpad

• FRT46_is_composed_of := P46_is_composed_of+
  For some reason ECRM doesn't declare P46 transitive though it does it for P106,P148 (posted bug to CRM SIG)
  Rules