compared with
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (123)

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

h1. Introduction

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

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|| || Title || Weaved into ||
|Turtle | Turtle | (x) (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 | Axioms | builtin_RdfsRules.pie, at the beginning of section Axioms (after the opening brace) |
|Rule | Rule | builtin_RdfsRules.pie, at end of file (before the closing brace) |
|Rules | 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:

h2. Rule Validation

In addition to weaving FR-implementation.pie, the script performs rule validation: for each rule, checks that variables are used in a "linear" fashion, eg

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:
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. FR Dependency Graph also generates a dependency graph showing which CRM props and sub-FRs are used in the implementation of each FR.
- This lets you see which CRM properties are "bundled" into which FRs. Similar info about the old implementation is at [FR Implementation-old#FR Summary (Short Variant)|FR Implementation-old#FR Summary (Short Variant)] or [FR Implementation-old#FR Summary (Long Variant)|FR Implementation-old#FR Summary (Long Variant)]
- It was an indispensable debugging aid while creating th FRs.

h2. Prefixes

This would add prefixes to FR.ttl (but we don't use such file):

h3. TransitiveProperty

owl:TransitiveProperty is a well-known OWL type stating that a property is transitive. ECRM declares the appropriate CRM properties as transitive, but for some reason it doesn't declare P9,P46 transitive (other "part of" properties, eg P106,P148 are transitive). I posted a bug to CRM SIG and fix it here:

h3. transitiveOver

ptop:transitiveOver is a useful generalization defined by the [Proton Ontology|]. The semantics is defined with the following axiom:
{noformat}(p,transitiveOver,q) (x,p,y) (y,q,z) => (x,p,z){noformat}

h2. Inverse Properties

Most CRM properties have an inverse, eg P110i_was_augmented_by is inverse of P110_augmented (Symmetric properties are their own inverse). ECRM declares all inverse properties as owl:inverseOf. Inverse reasoning is useful since it frees you from dependencies on how exactly the data is asserted:

h2. Symmetric Properties

ECRM declares all CRM symmetric properties as owl:SymmetricProperty. ECRM always declares them as owl:inverseOf itself, so we don't need to treat them separately. Eg:

h2. No Reflexive Closure

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*. Eg
- x from z := x P74 y AND y P89\* z

But it's bad style to use reflexive closure in the implementation since it generates 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:
- x from z := x P74 z OR (x P74 y AND y P89\+ z)

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:
- 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 -- P128_carries \-> E73_Information_Object
the property P128 implies that the source and target have the indicated types
- We check types (FC70_Thing) as early as possible to eliminate useless inferences

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

The concept of "NOT subclass" is not expressible with OWLIM rules:
- OWLIM rules can check \!= class, but not subclasses
- <owl:complementOf> and <owl:disjointWith> are used only for consistency checking (to infer a contradiction), not to define classes

h3. FC70_Thing and FR_dataset for RS

In RS we compute a dataset, which is important to select the right RForm; and to display a Dataset facet in the RS search. We now have 3 datasets (RKD, BM, YCBA):
- RKD data includes sub-objects (eg related/n is a related work, part/n is a frame that is part of a painting) that we can't display, so we introduced an extension sub-class rso:E22_Museum_Object. Because Rembrandt paintings come from different places, RKD data has varying keepers/owners: Mauritshuis, Rijksmuseum, Metropolitan, NGA.

The BM has two sameAs URIs
- []
- []

So to avoid duplicate results, we define the dataset as a literal.
x <rdf:type> <crm:E22_Man-Made_Object>; x <crm:P50_has_current_keeper> <> => x <rso:FR_dataset> "BM"
x <rdf:type> <crm:E22_Man-Made_Object>; x <crm:P52_has_current_owner> <> => x <rso:FR_dataset> "BM"
x <rdf:type> <crm:E22_Man-Made_Object>; x <crm:P50_has_current_keeper> <> <> => x <rso:FR_dataset> "YCBA"
x <rdf:type> <crm:E22_Man-Made_Object>; x <crm:P52_has_current_owner> <> <> => x <rso:FR_dataset> "YCBA"
x <rso:FR_dataset> y => x <rdf:type> <rso:FC70_Thing>
(!) The last URI may change: [Yale Mapping Problems#Getty URIs]
(!) *Jana: Vlado, URI was changed from to in latest Yale exports. I have updated it here as well. Please remove this comment after regenerating the FRs implementation*

h1. Fundamental Relations

h2. Sub-FRs

Here we define some auxiliary (sub) FRs that are used below.
We are careful to root all of them on FC70_Thing in order not to generate useless triples

- FRT_46_106_148 := (P46_is_composed_of | P106_is_composed_of | P148_has_component)+
- FRT_46_106_148 := (P46_is_composed_of \| P106_is_composed_of \| P148_has_component)\+
x <rdf:type> <rso:FC70_Thing>; x <crm:P46_is_composed_of> y => x <rso:FRT_46_106_148> y

- FRT_46_106_148_128 := FRT_46_106_148 \| P128_carries\+
x <rso:FRT_46_106_148> y => x <rso:FRT_46_106_148_128> y

- FRT_46_106_148_128_130 := FRT_46_106_148_128 | (P130_shows_features_of | P130i_features_are_also_found_on)+
- FRT_46_106_148_128_130 := FRT_46_106_148_128 \| (P130_shows_features_of \| P130i_features_are_also_found_on)\+
x <rso:FRT_46_106_148_128> y => x <rso:FRT_46_106_148_128_130> y

- FRT107i_member_of := P107i_is_current_or_former_member_of\+
x <crm:P107i_is_current_or_former_member_of> y => x <rso:FRT107i_member_of> y

- FRT9i_10 := (P9i_forms_part_of \| P10_falls_within)\+
x <crm:P9i_forms_part_of> y => x <rso:FRT9i_10> y

- FRX24i_30i := (FC70_Thing) (P24i_changed_ownership_through | \| P30i_custody_transferred_through)
x <rdf:type> <rso:FC70_Thing>; x <crm:P24i_changed_ownership_through> y => x <rso:FRX24i_30i> y

- FRX24i_25i_30i := (FC70_Thing) (FRX24i_30i | \| P25i_moved_by) / P9_consists_of\*
x <rso:FRX24i_30i> y => x <rso:FRX24i_25i_30i> y
h2. Thing-Place

h3. Thing about Place\- FR67_about_place

Thing depicts or refers to a place or feature located in place, or is similar in features or composed of or carries an information object that depicts or refers to a place
#- If a thing is about Rano Raraku, it is *not* about Easter Island, Polynesia, and Oceania

- FRX67_about := (FC70_Thing) FRT_46_106_148_128_130\* (P62_depicts | \| P67_refers_to)
This is the top branch but without a check for E53. It will be used in all "About" FRs

- FRX67_about_feature_on_place := (FC70_Thing) FRT_46_106_148_128_130\* / (P62_depicts | \| P67_refers_to) (E26_Physical_Feature) / P53
This is the bottom branch

- FR67_about_place := FRX67_about (E53_Place) | \| FRX67_about_feature_on_place
x <rso:FRX67_about> y; y <rdf:type> <crm:E53_Place> => x <rso:FR67_about_place> y

h3. Thing referred to at Place\- WONTDO

h3. Thing created in Place\- FR92i_created_in

Thing (or part/inscription thereof) was created or modified/repaired at/in place (or a broader containing place)


The beginning is very similar to [#Thing created by Actor\- FR92i_created_by|#Thing created by Actor- FR92i_created_by], so we reuse from there
- FR92i_created_in := FRX92i_created / P7_took_place_at / P89_falls_within\*
x <rso:FRX92i_created> y; y <crm:P7_took_place_at> z => x <rso:FR92i_created_in> z

h3. Thing used at Place\- WONTDO

No such in BM data

h3. Thing located in Place\- FR55_located_in

Thing has current or permanent location in Place (or a broader containing place)
- No need to loop over parts, since they are never at a different place

- FR55_located_in := (FC70_Thing) (P55_has_current_location | \| P54_has_current_permanent_location) / P89_falls_within\*
x <rdf:type> <rso:FC70_Thing>; x <crm:P55_has_current_location> z => x <rso:FR55_located_in> z

h3. Thing found at Place\- FR12_found_at

Thing was found (discovered, excavated) at Place
- We don't loop at the beginning since object parts don't have a different findspot from the main object

- FR12_found_at := (E70_Thing) P12i (EX_Discovery) / P7 / P89\*
x <rdf:type> <rso:FC70_Thing>; x <crm:P12i_was_present_at> y; y <rdf:type> <bmo:EX_Discovery>; y <crm:P7_took_place_at> z => x <rso:FR12_found_at> z

h3. Thing from Place\- FR7_from_place

Thing has former, current or permanent location at place, or was created/found at place, or moved to/from place, or changed ownership/custody at place (or a broader containing place)


- FR7_from_place := FR92i_created_in | \| FR12_found_at | \|
(FC70_Thing) (P53_has_former_or_current_location | P54_has_current_permanent_location | FRX7_from_place) / P89_falls_within*
(FC70_Thing) (P53_has_former_or_current_location \| P54_has_current_permanent_location \| FRX7_from_place) / P89_falls_within\*
x <rso:FR92i_created_in> y => x <rso:FR7_from_place> y

h2. Thing-Thing\- WONTDO

We don't have any info about top-level Thing-Thing relations in Rembrandt nor BM data.
h2. Thing-Actor

h3. Thing has owner-keeper Actor\- FR52_current_owner_keeper

Thing has current owner or keeper Actor
- The original definition of FR14_by is a mix (mess) of "created, measured, modified, acquired or used for activity performed by actor", but we decided to restrict it

h3. Thing has former owner or keeper Actor\- FR51_former_or_current_owner_keeper

Thing has former or current owner or keeper Actor, or ownership/custody was transferred from/to actor in Acquisition/Transfer of Custody event
Note: this subsumes [#Thing has owner-keeper Actor\- FR52_current_owner_keeper|#Thing has owner-keeper Actor- FR52_current_owner_keeper]

Implementation: FRX24i_30i goes to E8,E10. We don't need to check any type

h3. Thing created by Actor\- FR92i_created_by

Thing (or part/inscription thereof) was created or modified/repaired by Actor (or group it is member of)

- FRX92i_created := (FC70_Thing) FRT_46_106_148_128* / (P31i_was_modified_by | P94i_was_created_by) / P9*
- FRX92i_created := (FC70_Thing) FRT_46_106_148_128\* / (P31i_was_modified_by \| P94i_was_created_by) / P9\*
x <rdf:type> <rso:FC70_Thing>; x <crm:P31i_was_modified_by> y => x <rso:FRX92i_created> y

- FR92i_created_by := FRX92i_created / P14_carried_out_by / P107i_is_current_or_former_member_of\*
x <rso:FRX92i_created> y; y <crm:P14_carried_out_by> z => x <rso:FR92i_created_by> z

h3. Thing influenced-motivated by Actor\- FR15_influenced_by

Thing's production was influenced/motivated by Actor (or group it is member of).
- Examples of [Influenced|BM Association Mapping#Influenced By] include Manner/Style of, After, Close to, Connected with.
- Examples of [Motivated|BM Association Mapping#Production Motivated By] include Eponym/Governor/Issuer/Ruler/Magistrate who authorised/patronised/ordered the production; Made for.

We usere the same beginning as [#Thing created by Actor\- FR92i_created_by|#Thing created by Actor- FR92i_created_by]:


h3. Thing found by Actor\- FR12_found_by

Thing was found (discovered, excavated) by Actor

h3. Thing has met Actor\- FR12_has_met

Thing (or part thereof) has met Actor in the same event, or Actor was involved in its acquisition or custody

- FR12X := (FC70_Thing) FRT_46_106_148\* / P12i_was_present_at / P9_consists_of\*
y <rdf:type> <rso:FC70_Thing>; y <crm:P12i_was_present_at> z => y <rso:FR12X> z
x <rso:FR12X> y; y <crm:P9_consists_of> z => x <rso:FR12X> z
- FR12_has_met := FR12X / P12_occurred_in_the_presence_of (E39_Actor) | \|
x <rso:FR12X> z; z <crm:P12_occurred_in_the_presence_of> t; t <rdf:type> <crm:E39_Actor> => x <rso:FR12_has_met> t

h3. Thing is referred to by Actor\- WONTDO

A related example in RKD data is: <Gertruidenberg> (Place) P67i_is_referred_to_by <Bathing Susana> which is created by <Rembrandt>,
which would map to <Gertruidenberg> "is referred to by" <Rembrandt>, except that Place is not a Thing.

h3. Thing refers to or is about Actor\- FR67_about_actor

The original definition (FORTH TR-429 p45) loops over the actor hierarchy (P107_has_current_or_former_member), which we think is wrong:
if a thing is about the United Nations, is it also about every nation that's member of the UN?
h2. Thing-Event

h3. Thing refers to or is about Event\- FR67_about_period

Thing depicts or refers to event/period, or carries information object that is about event, or bears similarity with a thing that is about event


h3. Thing is referred to at Event\- WONTDO

h3. Thing has met Event\- FR12_was_present_at

Thing was present at Event (eg exhibition) or is from Period

- FR12_was_present_at := (FC70_Thing) FRT_46_106_148_128* / P12i / (P9i|P10)*
- FR12_was_present_at := (FC70_Thing) FRT_46_106_148_128\* / P12i / (P9i\|P10)\*
x <rdf:type> <rso:FC70_Thing>; x <crm:P12i_was_present_at> y => x <rso:FR12_was_present_at> y

h4. Representing Acquisition

An acquisition can be modeled as an event having all these classes:
- E8_Acquisition: thing changes ownership

h4. BUG

The loop P46i_forms_part_of causes a serious problem if E79_Part_Addition is used. Assume Thing1 and Thing2 are part of the BM_collection, THEN:

h4. How to Fix

Cannot be fixed easily using negation: "P46i_forms_part_of <thing> where <thing> is not E78_Collection":
- Class negation causes much higher inferencing complexity in OWL
h2. Thing-Concept

h3. Thing is made of Material\- FR45_is_made_of

Thing (or part thereof) consists of material

- Original definition Includes P33_used_specific_technique/P68_foresees_use_of, but I think that is far-fetched: P33 should refer to an explicitly defined procedure, and if P68 then it stands to reason the material was actually P126_employed\!
- I use the same beginning as [#Thing created by Actor\- FR92i_created_by|#Thing created by Actor- FR92i_created_by] to also catch repairs (P31i_was_modified_by).
(P94i_was_created_by is superfluous here, but doesn't hurt)

- FR45_is_made_of := (FC70_Thing) FRT_46_106_148_128\* / P45_consists_of | \|
FRX92i_created / P126_employed
FRX92i_created / P126_employed
x <rdf:type> <rso:FC70_Thing>; x <crm:P45_consists_of> y => x <rso:FR45_is_made_of> y

h3. Thing used technique\- FR32_used_technique

The production/modification of Thing (or part thereof) used general technique
- This is an extension defined by me
- Similarly to [#Thing is made of Material\- FR45_is_made_of|#Thing is made of Material- FR45_is_made_of], it uses the same beginning as [#Thing created by Actor\- FR92i_created_by|#Thing created by Actor- FR92i_created_by].
P94i_was_created_by may be useful here: an immaterial feature on the object (eg Inscription) may be made using a specific technique,
- (I think P32_used_general_technique is more useful than P33_used_specific_technique, see [#Thing is made of Material\- FR45_is_made_of|#Thing is made of Material- FR45_is_made_of] above)


h3. Thing is/has Type\- FR2_has_type

Thing has Type (or has shape, is of kind, is about subject, etc)

- FRX2_has_type := (FC70_Thing) / FRT_46_106_148_128\* / (P2_has_type | \| P67_refers_to (E55_Type))
x <rdf:type> <rso:FC70_Thing>; x <crm:P2_has_type> y => x <rso:FRX2_has_type> y

- FR2_has_type := FRX2_has_type / P127_has_broader_term\*
x <rso:FRX2_has_type> y => x <rso:FR2_has_type> y
but our search UI currently has a restriction that the many-to-many relation "FRs-thesauri" should split both FRs and thesauri into equivalence classes.

h3. Thing identified by Identifier\- FR1_identified_by

Thing (or part thereof) has Identifier (exact-match string).
Extension defined by me:

- FR1_identified_by := (FC70_Thing) FRT_46_106_148\* / P1_is_identified_by / (P3_has_note | \| rdfs:label)
x <rdf:type> <rso:FC70_Thing>; x <crm:P1_is_identified_by> y; y <crm:P3_has_note> z => x <rso:FR1_identified_by> z

- FRX_label := P3 | \| rdfs:label
Using such intermediate relation is very stupid, since it will double the number of label triples & literals in the repo

h2. Thing-Image

In order to make access to images for display easier, and [FR Enhancements#Search by Image] faster, we implement two FRs according to the definitions in [Search Result Fields#Display Fields]