View Source

{color:red}*Do not edit this page in Rich Text mode, edit only in Wiki mode*{color}

h1. Introduction
TODO: copy more from my email to Martin

h2. 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

h2. 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 | 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:
premise1 [Constraint ...]
premise2 [Cut]
- "Rules" includes one rule per line in a shorthand notation, eg:
premise1 [Constraint ...]; premise2 [Cut] => corollary1; corollary2
The shortcut notation is translated to the OWLIM notation. This shortcut form is very useful for shorter rules

h2. 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

h2. Prefixes
This adds prefixes to FR.ttl:
@prefix crm : <> .
@prefix owl : <> .
@prefix rdf : <> .
@prefix rdfs : <> .
@prefix rso : <> .

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

h2. 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:P106_is_composed_of rdf:type owl:ObjectProperty, owl:TransitiveProperty.
ecrm:P110i_was_augmented_by rdf:type owl:ObjectProperty ;
owl:inverseOf ecrm:P110_augmented ;
ECRM also defines Symmetric properties, but always declares them as self-Inverse, so we don't need to treat them separately. Eg:
ecrm:P122_borders_with rdf:type owl:ObjectProperty, owl:SymmetricProperty ;
owl:inverseOf ecrm:P122_borders_with.

It's very useful to rely on general Transitive and Inverse reasoning, so we copy the relevant rules from builtin_owl2-rl.pie:
p <rdf:type> <owl:TransitiveProperty>; x p y; y p z => x p z
p1 <owl:inverseOf> p2; x p1 y => y p2 x
p1 <owl:inverseOf> p2; x p2 y => y p1 x

h2. 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

h2. 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

h1. Fundamental Concepts

h2. Thing

h3. 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.
(x) If someone defines an application-specific subclass of an undesirable classes, it can "sneak through" this rule
{code:title=Rule-COMMENTED OUT}
x <rdf:type> t [Constraint t!=<rso:FC70_Thing>, t!=<crm:E21_Person>, t!=<crm:E55_Type>, t!=<crm:E56_Language>, t!=<crm:E57_Material>, t!=<crm:E58_Measurement_Unit>, t!=<crm:E30_Right>, t!=<crm:E41_Appellation>, t!=<crm:E35_Title>, t!=<crm:E42_Identifier>, t!=<crm:E44_Place_Appellation>, t!=<crm:E45_Address>, t!=<crm:E46_Section_Definition>, t!=<crm:E47_Spatial_Coordinates>, t!=<crm:E48_Place_Name>, t!=<crm:E49_Time_Appellation>, t!=<crm:E50_Date>, t!=<crm:E51_Contact_Point>, t!=<crm:E75_Conceptual_Object_Appellation>, t!=<crm:E82_Actor_Appellation>]
t <rdfs:subClassOf> <crm:E70_Thing>
x <rdf:type> <rso:FC70_Thing>

h3. 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:
<rso:FC70_Thing> <rdfs:subClassOf> <rso:E22_Museum_Object>
<rso:E22_Museum_Object> <rdfs:subClassOf> <rso:FC70_Thing>

h1. Fundamental Relations

h2. Thing-Place

h3. Thing "refers to or is about" Place
As defined in FRThing.docx:

(!) Problems:
# 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
# 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
# At E26: does not allow P130,P130i,P46
#- Resolved by adding the mix at E26 too
# 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:

- FRT_130_46_106_148 := (P130 or P130i or P46 or P106 or P148)+
x <crm:P130_shows_features_of> y => x <rso:FRT_130_46_106_148> y
x <crm:P130i_features_are_also_found_on> y => x <rso:FRT_130_46_106_148> y
x <crm:P46_is_composed_of> y => x <rso:FRT_130_46_106_148> y
x <crm:P106_is_composed_of> y => x <rso:FRT_130_46_106_148> y
x <crm:P148_has_component> y => x <rso:FRT_130_46_106_148> y
x <rso:FRT_130_46_106_148> y; y <rso:FRT_130_46_106_148> z => x <rso:FRT_130_46_106_148> z

- FRX_62_67 := P62_depicts or P67_refers_to
x <crm:P62_depicts> y => x <rso:FRX_62_67> y
x <crm:P67_refers_to> y => x <rso:FRX_62_67> y

- FRX67_refers_to_or_is_about := paths from FC70 to E53, with no loops at start & end nor type constraints
x <rso:FRX_62_67> y => x <rso:FRX67_refers_to_or_is_about> y
x <rso:FRX_62_67> y; y <crm:P53_has_former_or_current_location> z => x <rso:FRX67_refers_to_or_is_about> z
x <rso:FRX_62_67> y; y <rso:FRT_130_46_106_148> z; z <crm:P53_has_former_or_current_location> t => x <rso:FRX67_refers_to_or_is_about> t

- FRT67_refers_to_or_is_about := add loops at start & end
(Note: ECRM defines P89i_contains as transitive)
x <rso:FRX67_refers_to_or_is_about> y => x <rso:FRT67_refers_to_or_is_about> y
x <rso:FRT_130_46_106_148> y; y <rso:FRT67_refers_to_or_is_about> z => x <rso:FRT67_refers_to_or_is_about> z
x <rso:FRT67_refers_to_or_is_about> y; y <crm:P89i_contains> z => x <rso:FRT67_refers_to_or_is_about> z

- FR67_refers_to_or_is_about := add type constraints at start & end
x <rdf:type> <rso:FC70_Thing>; x <rso:FRT67_refers_to_or_is_about> y; y <rdf:type> <crm:E53_Place> => x <rso:FR67_refers_to_or_is_about> y

h3. Thing "is referred to at" Place
h3. Thing "from" Place
h3. Thing "used at" Place
h3. Thing "created at" Place
h3. Thing "found or acquired at" Place
h3. Thing "is/was located at" Place

h2. Thing-Thing
h2. Thing-Actor
h2. Thing-Event
h2. Thing-Concept

h1. 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)
x <crm:P46_is_composed_of> y => x <rso:FRT46_is_composed_of> y
x <rso:FRT46_is_composed_of> y; y <rso:FRT46_is_composed_of> z => x <rso:FRT46_is_composed_of> z