FR Implementation

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

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|http://en.wikipedia.org/wiki/Literate_Programming]. We weave several files based on code block titles:
||Title ||Weaved into||
|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 | 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:
{code}
premise1 [Constraint ...]
premise2 [Cut]
-------------------
corollary1
corollary2
{code}
- "Rules" includes one rule per line in a shorthand notation, eg:
{code}
premise1 [Constraint ...]; premise2 [Cut] => corollary1; corollary2
{code}
The shortcut notation is translated to the OWLIM notation. This shortcut form is very useful for shorter rules

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
{code:title=Example}
x <rdf:type> <rso:FC70_Thing>; x <crm:prop1> y; y <rso:subFR> z => x <rso:FR> z
{code}
Variables on the LHS should form a chain, with possible type-check branches.
The RHS should use the first and last var in the same order

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

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

<crm:P9i_forms_part_of> <rdf:type> <owl:TransitiveProperty>
<crm:P46_is_composed_of> <rdf:type> <owl:TransitiveProperty>
<crm:P46i_forms_part_of> <rdf:type> <owl:TransitiveProperty>
{code}

The full list of transitive properties is:
- P9_consists_of, P9i_forms_part_of (ADDED)
- P10_falls_within, P10i_contains
- P46_is_composed_of, P46i_forms_part_of (ADDED)
- P86_falls_within, P86i_contains
- P88_consists_of, P88i_forms_part_of
- P89_falls_within, P89i_contains
- P106_is_composed_of, P106i_forms_part_of
- P114_is_equal_in_time_to
- P115_finishes, P115i_is_finished_by
- P116_starts, P116i_is_started_by
- P117_occurs_during, P117i_includes
- P120_occurs_before, P120i_occurs_after
- P127_has_broader_term, P127i_has_narrower_term

{code}

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:
{code}
crm:P122_borders_with rdf:type owl:SymmetricProperty.
crm:P122_borders_with owl:inverseOf crm:P122_borders_with.
{code}

The full list of symmetric properties is:
- P69_is_associated_with
- P114_is_equal_in_time_to
- P121_overlaps_with
- P122_borders_with
- P132_overlaps_with
- P133_is_separated_from

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:
-- 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 -- 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
- We define FRs and sub-FRs using [SPARQL Property Paths|http://www.w3.org/TR/sparql11-property-paths/#path-language]

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

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

I tried enumerating negative classes:
{code:title=Rule-WRONG}
x <rdf:type> t [Constraint t!=<crm:E21_Person>, t!=<crm:E55_Type>, t!=<crm:E30_Right>, t!=<crm:E41_Appellation>]
t <rdfs:subClassOf> <crm:E70_Thing>
--------------------
x <rdf:type> <rso:FC70_Thing>
{code}
But that doesn't work (even if I enumerate all negative subclasses), since an E21_Person (negative) is also an E19_Physical_Object (positive), and we want E19.
Enumerating positive classes doesn't work either, for the same reason.

So FC70 would need to be implemented in SPARQL, eg
{code:sql|title=SPARQL}
?x rdf:type crm:E70_Thing.
NOT (?x rdf:type crm:E21_Person, etc)

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)+
{code:title=Rules}
x <rdf:type> <rso:FC70_Thing>; x <crm:P46_is_composed_of> y => x <rso:FRT_46_106_148> y
x <rdf:type> <rso:FC70_Thing>; x <crm:P106_is_composed_of> y => x <rso:FRT_46_106_148> y
x <rdf:type> <rso:FC70_Thing>; x <crm:P148_has_component> y => x <rso:FRT_46_106_148> y
x <rso:FRT_46_106_148> y; y <crm:P46_is_composed_of> z => x <rso:FRT_46_106_148> z
x <rso:FRT_46_106_148> y; y <crm:P106_is_composed_of> z => x <rso:FRT_46_106_148> z
x <rso:FRT_46_106_148> y; y <crm:P148_has_component> z => x <rso:FRT_46_106_148> z
{code}

- FRT_46_106_148_128 := FRT_46_106_148 | P128_carries+

{code}

- 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_130> y; y <crm:P130_shows_features_of> z => x <rso:FRT_46_106_148_128_130> z
x <rso:FRT_46_106_148_128_130> y; y <crm:P130i_features_are_also_found_on> z => x <rso:FRT_46_106_148_128_130> z
{code}

- FRT107i_member_of := P107i_is_current_or_former_member_of+
{code:title=Rules}
x <crm:P107i_is_current_or_former_member_of> y => x <rso:FRT107i_member_of> y
x <crm:P107i_is_current_or_former_member_of> y; y <rso:FRT107i_member_of> z => x <rso:FRT107i_member_of> z

- FRX24i_30i := (FC70_Thing) (P24i_changed_ownership_through | P30i_custody_transferred_through)
{code:title=Rules}
x <rdf:type> <rso:FC70_Thing>; x <crm:P24i_changed_ownership_through> y => x <rso:FRX24i_30i> y
x <rdf:type> <rso:FC70_Thing>; x <crm:P30i_custody_transferred_through> y => x <rso:FRX24i_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
{section}{column}
As defined in FRThing.docx:
!FR67_about_place.png!
{column}{column}
Corrected definition:
!FR67_about_place-fixed.png!
{column}{section}

Fixes:
# 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_Information_Object: 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 end: do not loop over the place hierarchy: About is neither [covariant nor contravariant|http://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)]
{jira:RS-1490}
#- If a thing is about Knossos, it is *not* about every little village, house and room in Knossos
#- 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
{code:title=Rules}
x <rdf:type> <rso:FC70_Thing>; x <crm:P62_depicts> z => x <rso:FRX67_about> z
x <rdf:type> <rso:FC70_Thing>; x <crm:P67_refers_to> z => x <rso:FRX67_about> z
x <rso:FRT_46_106_148_128_130> y; y <crm:P62_depicts> z => x <rso:FRX67_about> z
x <rso:FRT_46_106_148_128_130> y; y <crm:P67_refers_to> z => x <rso:FRX67_about> z
{code}

- 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
{code:title=Rules}
x <rdf:type> <rso:FC70_Thing>; x <crm:P62_depicts> z; z <rdf:type> <crm:E26_Physical_Feature>; z <crm:P53_has_former_or_current_location> t => x <rso:FRX67_about_feature_on_place> t
x <rdf:type> <rso:FC70_Thing>; x <crm:P67_refers_to> z; z <rdf:type> <crm:E26_Physical_Feature>; z <crm:P53_has_former_or_current_location> t => x <rso:FRX67_about_feature_on_place> t
x <rso:FRT_46_106_148_128_130> y; y <crm:P62_depicts> z; z <rdf:type> <crm:E26_Physical_Feature>; z <crm:P53_has_former_or_current_location> t => x <rso:FRX67_about_feature_on_place> t
x <rso:FRT_46_106_148_128_130> y; y <crm:P67_refers_to> z; z <rdf:type> <crm:E26_Physical_Feature>; z <crm:P53_has_former_or_current_location> t => x <rso:FRX67_about_feature_on_place> t
{code}

- FR67_about_place := FRX67_about (E53_Place) | FRX67_about_feature_on_place
{code:title=Rules}
x <rso:FRX67_about> y; y <rdf:type> <crm:E53_Place> => x <rso:FR67_about_place> y
x <rso:FRX67_about_feature_on_place> y => x <rso:FR67_about_place> y
{code}

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)

{section}{column}
As defined in FORTH TR-429 p25:
!FR92i_created_in.png!
{column}{column}
Corrected definition:
!FR92i_created_in-fixed.png!
{column}{section}

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

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.png!

- FR55_located_in := (FC70_Thing) (P55_has_current_location | P54_has_current_permanent_location) / P89_falls_within*
{code:title=Rules}
x <rdf:type> <rso:FC70_Thing>; x <crm:P55_has_current_location> z => x <rso:FR55_located_in> z
x <rdf:type> <rso:FC70_Thing>; x <crm:P54_has_current_permanent_location> z => x <rso:FR55_located_in> z
x <rdf:type> <rso:FC70_Thing>; x <crm:P55_has_current_location> y; y <crm:P89_falls_within> z => x <rso:FR55_located_in> z
x <rdf:type> <rso:FC70_Thing>; x <crm:P54_has_current_permanent_location> y; y <crm:P89_falls_within> z => x <rso:FR55_located_in> z
{code}

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
- The original definition also had "or acquired", but we don't need that

!FR12_found_at.png!

- FR12_found_at := (E70_Thing) P12i (EX_Discovery) / P7 / P89*
{code:title=Rules}
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
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; z <crm:P89_falls_within> t => x <rso:FR12_found_at> t
{code}

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)

{section}{column}
As defined in FRThing.docx:
!FR7_from_place.png!
{column}{column}
Corrected definition:
!FR7_from_place-fixed.png!
{column}{section}

Corrections:
# The original had "was created by someone born at place, or part of a group having residence at place". Although BM Person thesaurus provides birth place details, Dominic doesn't want this branch

Implementation:

- FRX7_from_place := FRX24i_25i_30i / P7_took_place_at
{code:title=Rules}
x <rso:FRX24i_25i_30i> y; y <crm:P7_took_place_at> z => x <rso:FRX7_from_place> z
{code}

- 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*
{code:title=Rules}
x <rso:FR92i_created_in> y => x <rso:FR7_from_place> y
x <rso:FR12_found_at> y => x <rso:FR7_from_place> y
x <rdf:type> <rso:FC70_Thing>; x <crm:P53_has_former_or_current_location> z => x <rso:FR7_from_place> z
x <rdf:type> <rso:FC70_Thing>; x <crm:P54_has_current_permanent_location> z => x <rso:FR7_from_place> z
x <rdf:type> <rso:FC70_Thing>; x <rso:FRX7_from_place> z => x <rso:FR7_from_place> z
x <rdf:type> <rso:FC70_Thing>; x <crm:P53_has_former_or_current_location> y; y <crm:P89_falls_within> z => x <rso:FR7_from_place> z
x <rdf:type> <rso:FC70_Thing>; x <crm:P54_has_current_permanent_location> y; y <crm:P89_falls_within> z => x <rso:FR7_from_place> z
x <rdf:type> <rso:FC70_Thing>; x <rso:FRX7_from_place> y; y <crm:P89_falls_within> z => x <rso:FR7_from_place> z
{code}

h2. Thing-Thing- WONTDO

We don't have any info about top-level Thing-Thing relations in Rembrandt nor BM data.
- In Rembrandt there is part composition info, but we don't display other than top-level objects
- In one case "<painting> P130i_features_are_also_found_on <sketch>", but these relate to sub-objects, eg
{code}<obj/2926> crm:P130i_features_are_also_found_on <obj/2926/related/1>{code}

So we won't do:
- Thing has met Thing
- Thing refers to or is about Thing
- Thing is referred to by Thing
- Thing from Thing
- Thing is part of Thing
- Thing was made from Thing
- Thing has part Thing
- Thing is similar or same with Thing

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

Implementation:
{code:title=Rules}
x <crm:P50_has_current_keeper> y => x <rso:FR52_current_owner_keeper> y
x <crm:P52_has_current_owner> y => x <rso:FR52_current_owner_keeper> y
{code}

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
!FR51_former_or_current_owner_keeper.png!
Note: this subsumes [#Thing has owner-keeper Actor- FR52_current_owner_keeper]

Implementation: FRX24i_30i goes to E8,E10. We don't need to check any type
{code:title=Rules}
x <crm:P49_has_former_or_current_keeper> y => x <rso:FR51_former_or_current_owner_keeper> y
x <crm:P51_has_former_or_current_owner> y => x <rso:FR51_former_or_current_owner_keeper> y
x <rso:FRX24i_30i> y; y <crm:P22_transferred_title_to> z => x <rso:FR51_former_or_current_owner_keeper> z
x <rso:FRX24i_30i> y; y <crm:P23_transferred_title_from> z => x <rso:FR51_former_or_current_owner_keeper> z
x <rso:FRX24i_30i> y; y <crm:P28_custody_surrendered_by> z => x <rso:FR51_former_or_current_owner_keeper> z
x <rso:FRX24i_30i> y; y <crm:P29_custody_received_by> z => x <rso:FR51_former_or_current_owner_keeper> z
{code}

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)

{section}
{column}
As defined by FORTH TR-429, p49:
!FR92i_created_by.png!
{column}
{column}
Corrected definition:
!FR92i_created_by-fixed.png!
{column}
{section}

Corrections:

x <rso:FRX92i_created> y; y <crm:P14_carried_out_by> z => x <rso:FR92i_created_by> z
x <rso:FRX92i_created> y; y <crm:P14_carried_out_by> z; z <rso:FRT107i_member_of> t => x <rso:FR92i_created_by> t
{code}

h3. Thing found by Actor- FR12_found_by
Thing was found (discovered, excavated) by Actor
{code:title=Rules}
x <crm:P12i_was_present_at> y; y <rdf:type> <bmo:EX_Discovery>; y <crm:P14_carried_out_by> z => x <rso:FR12_found_by> z
{code}

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
{section}{column}
As defined in FRThing.docx:
!FR12_has_met.png!
{column}{column}
Corrected definition:
!FR12_has_met-fixed.png!
{column}{section}

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?

!FR67_about_actor-fixed.png!

- FR67_about_actor := FRX67_about (E39_Actor)
{code:title=Rules}
x <rso:FRX67_about> y; y <rdf:type> <crm:E39_Actor> => x <rso:FR67_about_actor> y
{code}

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

{section}{column}
As defined in FORTH TR-429 p55:
!FR67_about_period.png!
{column}{column}
Corrected definition:
!FR67_about_period-fixed.png!
{column}{section}

(i) We reuse a lot of properties from above, so we don't need to define any auxiliary sub-FRs here
- FR67_about_period := FR67_about (E4_Period)
{code:title=Rules}
x <rso:FRX67_about> y; y <rdf:type> <crm:E4_Period> => x <rso:FR67_about_period> y
{code}

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

- E10_Transfer_of_Custody: thing changes custody
- E80_Part_Removal: thing is removed from old collection
- E79_Part_Addition: thing is added to BM collection

The following entities are present at an acquisition:
- the thing itself: (E8, E10), E80, E79
- the seller: E8, E10
- the seller's collection: E80
- the buyer: E8, E10

Thing2(E22_Man-Made_Object) -- P46i_forms_part_of -> BM_Collection (E78_Collection). # given
Thing1_Acquisition(E79_Part_Addition) -- P110_augmented -> BM_Collection. # given
BM_Collection -- P12i_was_present_at -> Thing1_Acquisition. # P110i is sub-property of P12
Thing2 -- FR12_was_present_at -> Thing1_Acquisition. # by the FR definition
{noformat}

This causes *all* BM objects to be present at all Acquisition events *of each other*, which is wrong:
- If Thing2 was added to BM after Thing1, it's causally impossible for Thing2 to be present at the acquisition of Thing1
- If Thing2 was added to BM before Thing1, you *could* say that while sitting in BM, it quietly observed the addition of Thing1, but that is silly and not useful.

- I'm sure there are other twisted cases, eg "each part of a building observed all modifications that added other parts to that building"

We had some discussions about following P46i:
- for some FRs it's appropriate to follow the other direction P46 ("contra-variant" not "co-variant" FRs)
- for some FRs it's appropriate to follow neither P46i, nor P46 (eg for Thing *about* Entity)

For this FR, we loop over P46_is_composed_of in order to account for:
- part made by: P46_is_composed_of/P108i_was_produced_by/P14_carried_out_by
- inscription made by: P128_carries/P94_has_created/P14_carried_out_by

h2. Thing-Concept

h3. Thing is made of Material- FR45_is_made_of
Thing (or part thereof) consists of material
!FR45_is_made_of-fixed.png!

!FR2_has_type-fixed.png!
- FRThing.docx calls this "has type" but I think "is/has/about" matches the general usage "is Weapon", "has shape Vertical Rectangle", etc

Fixes:
- added P67 (E55_Type), since some types are attached using P67_refers_to (or P129_is_about),
eg these RKD extension properties: rso:P129_has_iconclass, rso:P129_has_keyword
- added P128_carries (E73_Information_Object) to move from physical to conceptual, eg
{code}<obj/2926> crm:P65_shows_visual_item [crm:P129_is_about rst-iconclass:_71P412]{code}
- added "P127_has_broader_term" to search by type hierarchy

x <rdf:type> <rso:FC70_Thing>; x <crm:P67_refers_to> y; y <rdf:type> <crm:E55_Type> => x <rso:FRX2_has_type> y
x <rso:FRT_46_106_148_128> y; y <crm:P2_has_type> z => x <rso:FRX2_has_type> z
x <rso:FRT_46_106_148_128> y; y <crm:P67_refers_to> z; z <rdf:type> <crm:E55_Type> => x <rso:FRX2_has_type> z
{code}

- FR2_has_type := FRX2_has_type / P127_has_broader_term*
{code:title=Rules}
x <rso:FRX2_has_type> y => x <rso:FR2_has_type> y
x <rso:FRX2_has_type> y; y <crm:P127_has_broader_term> z => x <rso:FR2_has_type> z
{code}

Notes:
- Martin also adds here FR45_is_made_of. This would be easy to add with this clause:
{code}
x <rso:FR45_is_made_of> y => x <rso:FR2_has_type> y
{code}

Extension defined by me:
!FR1_identified_by.png!

- FR1_identified_by := (FC70_Thing) FRT_46_106_148* / P1_is_identified_by / (P3_has_note | rdfs:label)
{code:title=Rules}
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
x <rso:FRT_46_106_148> y; y <crm:P1_is_identified_by> z; z <crm:P3_has_note> t => x <rso:FR1_identified_by> t
x <rdf:type> <rso:FC70_Thing>; x <crm:P1_is_identified_by> y; y <rdfs:label> z => x <rso:FR1_identified_by> z
x <rso:FRT_46_106_148> y; y <crm:P1_is_identified_by> z; z <rdfs:label> t => x <rso:FR1_identified_by> t
{code}

Notes:
- TODO: it may be better to stop at P1 so the identifier type can also be examined
- we add rdfs:label since that's what BM uses for identifier values (not P3_has_note)
{jira:RS-1408}