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

Introduction

TODO:

  • copy more from my email to Martin
  • consider checking types as early as possible to eliminate useless inferences
  • Define FRs and sub-FRs usign SPARQL Property Paths

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 Properties

ECRM declares appropriate CRM properties as owl:TransitiveProperty.
For some reason it doesn't declare P9,P46 transitive, though it does it for other "part of" properties, eg P106,P148. I posted a bug to CRM SIG and fix it here:

Axioms

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
  • P148_has_component, P148i_is_component_of

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.

We use the RDFS reasoning dialect as a basis, which implements rdfs:subClassOf and rdfs:subPropertyOf reasoning.
But it's very useful in FR definitions to rely on general Transitive and Inverse reasoning, which frees you from dependencies on how exactly data is asserted.
So we copy the relevant rules from builtin_owl2-rl.pie:

Rules

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:

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

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 I think 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)

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

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
    TODO: says who? Prove this

I tried enumerating negative classes:

Rule-WRONG

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

SPARQL

FC70_Thing for RS

In RS we search only for Man-Made Objects (MMO) so the rule is much simpler:

Axioms

TODO: in BM data, MMO are only top-level (eg Print, Painting).
But in Rembrandt data there are sub-object MMO (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 a special sub-type rso:E22_Museum_Object.

Fundamental Relations

Thing-Place

Thing "refers to or is about" Place: FR67_refers_to_or_is_about

As defined in FRThing.docx:

Corrected definition:

Fixed 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*)
    • PENDING: but is it contra-variant (appropriate to loop using P89i*)?

Implementation

  • FRT_46_106_148 := (P46 or P106 or P148)+
    Rules
    Axioms
  • FRT_46_106_148_128_130 := (FRT_46_106_148 or P128 or P130 or P130i)+
    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: WONTDO

Thing "from" Place: FR7_from_place

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

Corrected definition:

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

Implementation:

  • FRT_46i_106i_148i := (P46i or P106i or P148i)+
    Rules
    Axioms
  • FRX_53_54_current_location := P53 or P54
    Rules
  • FRT92i_9i := P92i / 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: WONTDO

No such in BM data

Thing "created at" Place: WONTDO

This is very similar to "from", which in addition has a part "created by person born at".
But RKD Person thesaurus doesn't have birth details, and I don't know whether BM Person exported to SKOS has such details.

Thing "found or acquired at" Place: WONTDO

C2.Finding is not defined

Thing "is/was located in" Place: FR53_is_was_located_in

This is a very simple subset of FR7_from_place (Thing "from" Place)

Implementation:

  • FRT53_is_was_located_in := FRT_46i_106i_148i* then P53 then P89*
    Rules
  • FR53_is_was_located_in := add type check at start
    (No need to check at end since the relation is to E53_Place)
    Rules

Thing-Thing

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

Thing "has met" Thing: WONTDO

Thing "refers to or is about" Thing: WONTDO

Thing "is referred to by" Thing: WONTDO

Thing "from" Thing: WONTDO

Thing "is part of" Thing: WONTDO

Thing "was made from" Thing: WONTDO

Thing "has part" Thing: WONTDO

Thing "is similar or same with" Thing: WONTDO

Thing-Actor

Thing "has met" Actor: FR12_has_met

As defined in FRThing.docx:

Corrected definition:

Fixed Problems:

  1. At beginning: why consider part composition only of E18_Physical_Thing (P46i) but not of Symbolic/Propositional Objects (P106i,P148i)?
    Note: P12 is applicable to any E77_Persistent_Item
    • Resolved by adding P106i,P148i: do you agree

Further discussion:

  • We consider carefully the directions of the "part" relations. Here's an example where we have 3 levels of nested Things, Events and Actors and the relation is made at level2:
    • Jewel1 is part of Necklace2 is part of Treasure3
    • AuctionLot1 is part of Auction2 is part of AuctionSeries3
    • Dealer1 is part of JewelSellers2 is part of Corp3
    • Necklace2 was sold at Auction2 by JewelSellers2
  • I think we can infer these relations:
    • (Jewel1,Necklace2) was sold at (Auction2,AuctionSeries3) by (JewelSellers2,Corp3)
  • However, FRThing.docx dismisses the "Actor member of Group" inference because "it is not so probable that the Group has also been in the same event as the Actors".
  • Ok, agreed

Implementation:
We reuse [#Thing "has met" Event: FR12\_was\_present\_at] as the initial sub-FR from FC70 to E5.

  • FR12_has_met := FR12_was_present_at / P12 / E39
    Rules

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.

Thing "refers to or is about" Actor: TODO

Thing "by" Actor: FR14_by

Thing was created, modified, measured, found, acquired by actor; or was used for an activity performed by actor

As defined in FRThing.docx:

Corrected definition:

Fixed Problems:

  1. At beginning: allow paths of mixed properties
  2. At E8: allow a hierarchy of Acquisition events (not that it'll happen often)
  3. Note: we don't need to check the types E7, E8 since the properties P24i, P14, P22 ensure them.

Implementation:

  • FRX_92_16_39_31_24i := P92i_was_brought_into_existence_by | P16i_was_used_for | P39i_was_measured_by | P31i_was_modified_by | P24i_changed_ownership_through
    Rules
  • FRX_14_22 := P14_carried_out_by | P22_transferred_title_to
    Rules
  • FRX_46_106_148_92_16_39_31_24i := FRT_46_106_148* / FRX_92_16_39_31_24i
    Rules
  • FRX14_by := FRX_46_106_148_92_16_39_31_24i / P9i*
    Rules
  • FR14_by := FRX14_by / FRX_14_22 / P107i*
    Rules

Thing-Event

Thing "refers to or is about" Event: FR67_about_event

Thing depicts or refers to Event, or carries information object that is about Event, or bears similarity with a thing that is about Event.

  • The beginning is the same as [#Thing "refers to or is about" Place: FR67\_refers\_to\_or\_is\_about] so we reuse properties FRT_46_106_148_128_130 and FRX_62_67. TODO: optimize this reuse, by carefully thinking where to put the type check
  • The ending is way simpler.
  • TODO: harmonize FR names (this says "_event" but "about Place" doesn't say "_place")

As defined in FRThing.docx:

Corrected definition:

Fixed Problems:

  1. At beginning: does not allow paths of mixed properties
  2. At E73: does not allow P106,P148. Resolved by adding P128 into the mix

Implementation:
We reuse a lot of properties from above, so we don't need to define any auxiliary sub-FRs here

  • FR67_about_event := FC70 / FRT_46_106_148_128_130* / FRX_62_67
    Rules

Thing "is referred to at" Event: WONTDO

Thing "has met" Event: FR12_was_present_at

Thing was present (has metm, is from) Event.
(FRThing.docx refers to this variously as "has met" or "from", but we use FR12_has_met for Actor, so for this we use FR12_was_present_at which is derived from the key CRM property name)

As defined in FRThing.docx:

Implementation:

  • FR12_was_present_at := FC70 / FRT_46i_106i_148i* / P12i / P9i*
    Rules

Thing-Concept

Thing "is made of" Material: FR45_is_made_of

Thing (or its part) consists of Material.

As defined in FRThing.docx:
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!

Corrected definition:

Implementation

  • FRX45_is_made_of := P45 | (FRT92i_9i / P126)
    Rules
  • FR45_is_made_of := (FC70) / FRT_46_106_148* / FRX45_is_made_of
    Rules

Thing "is/has" Type: FR2_has_type

Thing has Type (or has shape, is of kind, uses material, etc)
(FRThing.docx calls this "has type" but I think "is/has" matches the general usage "is Weapon", "has shape Vertical Rectangle", etc)

This is an extension of [#Thing "is made of" Material: FR45\_is\_made\_of]:

Corrected definition:

Implementation:

  • FR2_has_type := ((FC70) / FRT_46_106_148* / P2_has_type) | FR45_is_made_of
    Rules

Thing "used technique": FR32_used_technique

The production of Thing (or its part) used general Technique.

Extension defined by me:

(I think P32_used_general_technique is more useful than P33_used_specific_technique, see [#Thing "is made of" Material: FR45\_is\_made\_of] above)

Implementation:

  • FR32_used_technique := (FC70) / FRT_46_106_148* / FRT92i_9i / P32
    Rules

Thing "identified by" Identifier: FR1_identified_by

Thing (or its part) has Identifier (exact-match string).

Extension defined by me:

Implementation:

  • FR1_identified_by := (FC70) / FRT_46_106_148* / P1 / P3
    Rules

    TODO: it may be better to stop at P1 so the identifier type can also be examined

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