FR Implementation

Version 1 by Vladimir Alexiev
on Mar 20, 2012 15:59.

compared with

Version 2 by Vladimir Alexiev
on Mar 20, 2012 16:09.

Changes from 2 to 3 >>

Key

This line was removed.

This word was removed. This word was added.

This line was added.

Changes (26)

View Page History

...

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|http://owlim.ontotext.com/display/OWLIMv43/OWLIM-SE+Reasoner#OWLIM-SEReasoner-RuleFormatandSemantics].

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]).

c:\my\Onto\proj\OWLIM\software\owlim-se-4.2.3924\builtin_RdfsRules.pie

h2. Weaving for Production

...

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

-- if the sub-FR is a disjunction of several CRM properties, we mention all numbers

FRX62_67_depicts_or_refers_to 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:
{code:title=Turtle}
@prefix crm : <http://erlangen-crm.org/current/> .
@prefix owl : <http://www.w3.org/2002/07/owl#> .
@prefix rdf : <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs : <http://www.w3.org/2000/01/rdf-schema#> .
@prefix rso : <http://www.researchspace.org/ontology/> .
{code}

This adds prefixes to the rules file (it already has: rdf rdfs owl xsd):
{code:title=Prefices}
crm : http://erlangen-crm.org/current/
rso : http://www.researchspace.org/ontology/
{code}

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

It's very useful to rely on general Transitive and Inverse reasoning, so we copy the relevant rules from builtin_owl2-rl.pie:
{code:title=Rules}
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
{code}

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:

...

(!) Problems:

# At beginning: does not allow paths of mixed properties (eg P130-P130i, P106-P148),

including mixed properties (eg P130-P130i, P106-P148), or
in which P46,P106,P148 precede P130,P130i

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)

...

# 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|http://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)] (not appropriate to loop using P89*), but is it appropriate to use P89i*

#- (?) PENDING

Corrected definition:
!FR67_refers_to_or_is_about-fixed.png!

- FRT130_46_106_148_shows_features_or_is_composed_of FRT_130_46_106_148 := (P130 or P130i or P46 or P106 or P148)+

{code:title=Rules}

x <crm:P130_shows_features_of> y => x <rso:FRT130_46_106_148_shows_features_or_is_composed_of> <rso:FRT_130_46_106_148> y

x <crm:P130i_features_are_also_found_on> y => x <rso:FRT130_46_106_148_shows_features_or_is_composed_of> <rso:FRT_130_46_106_148> y

x <crm:P46_is_composed_of> y => x <rso:FRT130_46_106_148_shows_features_or_is_composed_of> <rso:FRT_130_46_106_148> y

x <crm:P106_is_composed_of> y => x <rso:FRT130_46_106_148_shows_features_or_is_composed_of> <rso:FRT_130_46_106_148> y

x <crm:P148_has_component> y => x <rso:FRT130_46_106_148_shows_features_or_is_composed_of> <rso:FRT_130_46_106_148> y

x <rso:FRT130_46_106_148_shows_features_or_is_composed_of> y; y <rso:FRT130_46_106_148_shows_features_or_is_composed_of> z => x <rso:FRT130_46_106_148_shows_features_or_is_composed_of> z

x <rso:FRT_130_46_106_148> y; y <rso:FRT_130_46_106_148> z => x <rso:FRT_130_46_106_148> z

{code}

- FRX62_67_depicts_or_refers_to FRX_62_67 := P62_depicts or P67_refers_to

{code:title=Rules}

x <crm:P62_depicts> y => x <rso:FRX62_67_depicts_or_refers_to> <rso:FRX_62_67> y

x <crm:P67_refers_to> y => x <rso:FRX62_67_depicts_or_refers_to> <rso:FRX_62_67> y

{code}

- FRX67_refers_to_or_is_about := paths from FC70 to E53, with no loops at start & end nor type constraints
{code:title=Rules}

x <rso:FRX62_67_depicts_or_refers_to> <rso:FRX_62_67> y => x <rso:FRX67_refers_to_or_is_about> y

x <rso:FRX62_67_depicts_or_refers_to> <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:FRX62_67_depicts_or_refers_to> <rso:FRX_62_67> y; y <rso:FRT130_46_106_148_shows_features_or_is_composed_of> <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

{code}

...

{code:title=Rules}
x <rso:FRX67_refers_to_or_is_about> y => x <rso:FRT67_refers_to_or_is_about> y

x <rso:FRT130_46_106_148_shows_features_or_is_composed_of> <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
{code}

...