Skip to end of metadata
Go to start of metadata

FR Implementation in RS3.1
Since the specification CRM Search#FRs of Thing by M.Doerr was not ready for RS3.1, we defined and implemented a few FRs ourselves.
For RS3.3 we follow that specification and collaborate with M.Doerr on FR Implementation-old.

FR Names

FR names follow the form "rso:PSn_name", where:

  • "rso" stands for "ResearchSpace Ontology"
  • "PS" stands for "Property for Search"
  • "n" is the number of the most salient CRM property used in the FR
FR property
Thing from Actor rso:PS97_from_actor
Thing From Place rso:PS7_from_place
Has Type rso:PS2_has_type
Thing has Material rso:PS45_consists_of
Thing Uses Technique rso:PS32_uses_technique

Serial-Parallel Networks

RS3.1 FRs are limited to serial-parallel networks and are implemented in pure OWL using two constructs:

  • owl:propertyChainAxiom, which implements a series, eg:

    rso:Pn holds whenever there is a chain of nodes connected by crm:Px, crm:Pn, crm:Pz

  • disjunction, which implements parallel paths, eg

    rso:Pn holds whenever path1, or path2, or property crm:Pn holds

Implicit Filter

Serial-parallel networks lack conjunctive properties, so one cannot put additional conjunctive conditions on a node.
Typically, type checking cannot be expressed, eg this:

RS3.1 searches for (top-level) museum objects only. So EntityAPI.Search adds an implicit condition at the top level of every search (FR and FTS):

FR Implementation

FR Diagrams

The FR diagrams below are done in Visio.
A detailed description is in FRs-v2-withComments.pdf, including explanations of the changes compared to a previous version

Thing from Actor

  • the creator of a Museum object part
  • the current owner of the Museum object
  • the current keeper of the Museum object

Notes:

  • We don't consider the creator of an entire Museum object since such situation does not exist in the data
  • Actors come from the thesauri for Artists (represented as E21_Person), Institutions (E39_Actor) and Collections (E78_Collection and E39_Actor)
  • The creators of both the main part (painting, eg rkd-artist:Rembrandt) and other parts (frame, eg rkd-artist:Willem_de_Vries) are represented (in thesauri-extracted.ttl)

Thing From Place

  • part of museum object produced at a certain place
  • location of the current keeper
  • location where the museum object is currently kept (coincides with the above)

Notes:

  • The location is taken from the Places thesaurus
  • P89_falls_within is transitive, which obtains the complete hierarchy of locations
  • P46_is_composed_of is transitive, which supports nested parts (we don't have such in the data, only 1 level of nesting)
  • We don't consider productuon place of the overall objects, since we don't have such in the current data
  • Former locations, auctions, exhibitions are excluded
  • Artist's birth-place is excluded since we don't have such data in Persons thesaurus
  • crm:P54_has_current_permanent_location is not included
    • for Susanna it's Rijksmuseum Amsterdam (the owner), but it was loaned to Mauritshuis TheHague and was never actually in Amsterdam)
    • Mariana: "thing from place" should be interpreted as its actual current location., e.g. where it is kept at present.

Collection as Place

We could include Collections at the lowest level. Mauritshuis is a Place Name (though I don't know its street address, and don't care). This will let us search by collection too, and for free! With Exhibit faceting it could look like this:

  10 Netherlands
     5 Amsterdam
       3 Rijkmuseum
     5 The Hague
       5 Mauritshuis
  3 France
    3 Paris
      3 Napoleon Museum
  • Note: Why the 3 paintings in Rijkmuseum increase to 5 paintings in Amsterdam? Well, maybe 2 of the paintings that are currently in The Hague were made in Amsterdam
  • Mariana: Introducing another FR: "Thing from Collection" would be more precise

Thing has Type

Notes:

  • This shows rso:P46_has_main_part (part/1) which is the main part of the museum object (P2_has_type rkd-object:painting).
    But it has other types as well (eg "rkd-shape:rectangle--vertical"), so we had to check the meta-thesaurus:
  • We added the same type to the root object (this is not shown above). It has no other types, so the FR is simplified

Thing has Material

Notes:

  • Material and Technique are split into two FRs, since they are in different places in the data: Material and Medium-Technique
  • Both Material and Technique are described as referring to a particular part of the museum object, not to the entire museum object.
  • Material is linked directly to the part (P45_consists_of), and alternatively through a part Production event (P126_employed)

Thing uses Technique

Technique is described via a part Production event (P32_used_general_technique)

Thing from Time (RS 3.?)

This is postponed for RS3.3, because it has complications: date vs gMonthYear vs gYear; P82 vs P82a & P82b; main part vs all parts?
This is a draft:

Type vs Material vs Technique

Dominic: the original FC/FR description talks about Concept being a E55_Type. This refers to a range of different terms commonly found in organisational thesauri. You have picked out material and technique, and therefore excluded other types?

Vlado: Although the FR spec talks about all types collectively, I think they should be implemented separately:

  • Keeping different types in different search fields (thus different FRs) has practical benefits:
    • Easier for the user to select thesaurus values; harder to select from a mega-thesaurus
    • Can make conjunctive query "things that are made of Oak and used technique Oil Painting" even with a limited query grammar
  • Different Types are spread in different paths, e.g.
    • obj.type (painting) is at the root
    • material is at object/part/N/consists_of (directly on the parts)
    • technique is at object/part/N/production/used_general_technique (through part Production)
    • shape (rectangle) is at object/part/1 (being the Main part)
  • We'll add more type FRs (e.g. Shape) in future iterations

In RKD, Material is split into Support vs Frame (RKD uses different thesauri for Support vs Frame), so we are already doing some combination of thesauri in RS3.1
The question is how much combining do we want? Do you prefer to have all type searches collapsed in one search field?

SPARQL query

If you're looking for all FRs (user entered all criteria), the query looks like this:

If only some criteria are entered, delete the others.

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