Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current  |   View Page History

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

There are currently no attachments on this page.

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#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:

Title Weaved into
Turtle (not yet implemented) FR.ttl, The old file RF.ttl will be deleted from svn
Prefices builtin_RdfsRules.pie, at the beginning of section Prefices (after the opening brace)
Axioms builtin_RdfsRules.pie, at the beginning of section Axioms (after the opening brace)
Rule builtin_RdfsRules.pie, at end of file (before the closing brace)
Rules same place, but these are shorthand rules (see below)
  • 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
    • if the sub-FR is a disjunction of several CRM properties, we mention all numbers
      FRX_62_67 := 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:

Turtle

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

Prefices

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:

Rules

ECRM Fixes

For some reason ECRM doesn't declare P9,P46 transitive, although it does it for P106,P148. Posted bug to CRM SIG and make P9, P9i, P46, P46i transitive:

Axioms

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)
    • that use the CRM Digital (CRMdig) extensions
  • 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

Rule-COMMENTED OUT

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:

Axioms

Fundamental Relations

Thing-Place

Thing "refers to or is about" Place

As defined in FRThing.docx:

Problems:

  1. At beginning: does not allow paths of mixed properties (eg P130-P130i, P106-P148),
    or with P46,P106,P148 preceding 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 contra-variant (appropriate to loop using P89i*)?
    • PENDING

Corrected definition:

Implementation

  • FRT_130_46_106_148_128 := (P130 or P130i or P46 or P106 or P148 or P128)+
    Rules
    Axioms
  • FRX_62_67 := P62_depicts or P67_refers_to
    Rules
  • FRX_62_67_E26 := FRX_62_67 and check type E26
    Rules
  • FRX67_refers_to_or_is_about := paths from FC70 to E53, with no loops nor type check at start & end
    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 check at start & end
    Rules

Thing "is referred to at" Place

Thing "from" Place

As defined in FRThing.docx (without C2.Finding which is undefined):

Problems:

  1. At beginning: does not allow paths of mixed properties (eg P46i,P106i)
    • Resolved by "mixing" as FRT_46i_106i_148i
  2. At E9: does not allow a loop P9i* (Move forms part of a bigger event)
    • Resolved by merging all Event nodes (E8, E9, second E63) and allowing P9i*
    • Note that P26,P27 are subproperties of P7, so we don't need to use them
    • (We could even merge both E63, but then we'd have a back-link and before traversing P14 must check that the event is the production/creation of a Thing: E12, E65, E81)

  • FRT_46i_106i_148i := (P46i or P106i or P148i)+
    Rules
    Axioms
  • FRX_53_54_current_location := P53 or P54
    Rules
  • FRT92i_9i := P92i then P9i*
    Rules
  • FRT107i_member_of := P107i+
    Rules
    Axioms
  • FRX_P92i_P14_P107i := FRT92i_9i then P14 then P107i*
    Rules
  • FRX_FC70_key_event := paths from FC70 to E8,E9,E63 (a "key event")
    Rules
  • FRT_FC70_key_event_P9i := FRX_FC70_key_event then P9i*
    Rules
  • FRX7_from_place := paths from FC70 to E53, with no loops nor type check at start & end
    Rules
  • FRT7_from_place := add loops at start & end
    Rules
  • FR7_from_place := add type check at start
    (No need to check at end since all relations are to E53_Place)
    Rules

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

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.