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

Some Rembrandt data rework, related to harmonization and improvements

Way of working:

  • Vlado makes changes to susana.ttl and diff
  • Matthew makes changes to Migration
  • Jana makes changes to RForm templates
  • Mitac makes changes to EntityAPI (hopefully not many will be needed)

A lot of these are changes marked WILL in Rembrandt Mapping Review. Some was investigated in RS-323@jira


Remove part/1

BM data doesn't have parts. For harmonization and simplification:

  • get rid of part/1, and put all its properties directly on the object.
    I've been assured this won't constitute lying about its production, creator, material
  • treat part/2 (the frame) as an accessory (less important) part.
    Keep its URI as is, no need to change.
  • has_number_of_parts: output 1 if there is frame; no property if there is no frame (Matthew please take note)
  • get rid of rso:P46_has_main_part,
    • Keep rso:P46_has_other_part: needed by properties.txt.
    • We could compute this (as rso:P46_has_proper_part) from the standard property, then maybe use it to resolve the [FR BUG]:
spec diff mig rforms

Update properties.txt

RS-92 uses a file of "business meaningful properties" to collect a complete Museum Object. Based on BM mapping and Rembrandt Changes, update this list

spec diff mig rforms

rdfs:label vs crm:P3_has_note

Following Martin's recommendation, BM will use rdfs:label for the main label of every node, and crm:P3_has_note only for auxiliary notes. This is useful, since we may decide to skip their P3_has_note that duplicate structured data in a label, eg "Width :: 23.0"

However, this is not yet adopted by the CRM SIG, and it's unclear whether we're getting rid of P3_has_note altogether. So unless Jana says otherwise, we'll keep P3_has_note for Rembrandt

spec diff mig rforms

Searchability and Display Fields

We cannot display search results including sub-objects (eg a Document or Related drawing that lacks most fields). That's why they should not be searchable, which we've accomplished by introducing E22_Museum_Object and marking only top-level objects with that class.

  • Rethink where we find the Display fields, so we can display both Rembrandt and BM objects
  • BM data doesn't include E22_Museum_Object
    • If possible we should formulate a different criterion for searchability, but I don't think CRM has such notion of "top-level or independent object"
    • If not, we should add such class to BM data
spec diff mig rforms

Disentangle P2_has_type by introducing sub-properties

When two thesauri are mapped to P2_has_type, selecting New value in data annotation doesn't work since it cannot determine which thesaurus to use. Therefore sub-properties should be introduced. P2_has_type can be used as-is only if the node has a single "type".
We replace P2_has_type with the following:

  • Object:
    • rso:P2_has_object_type (rkd-object)
    • rso:P2_has_object_shape (rkd-shape)
  • Image: (RS-627@jira "Cannot determine thesaurus for image type")
    • crm:P129_is_about (rst-iconclass)
      TODO Vlado: add clause "P129_is_about E55_Type" to FR2_has_type, else we can't search by Iconclass
    • rso:P2_has_keyword (rkd-keywords)
  • Frame: rso:P2_has_object_type (rkd-object)
  • File:
    • rso:P2_has_object_status (rkd-objectstatus)
    • rso:P2_has_area_captured (rkd-area_captured: FRONT/BACK and OVERALL/DETAIL).
      Note: Jana, we cannot split rso:P2_has_area_captured to two separate fields for <file.spec.overall_detail> vs <file.spec.front_back>,
      since if you look in thesauri-all.ttl, rkd-area_captured has many tangled values, eg "whole (front)". So we leave 2 instances of this property, and leave it to the user to put two "compatible" values in them.
spec diff mig rforms

Unchangeable P2_has_type

Jana, please note that the following P2_has_type properties are unchangeable (fixed).
They don't come from a thesaurus, i.e. don't have skos:inScheme, so a new value cannot be proposed.

Business-specific sub-properties

Maria RS-273@jira: we planned initially that data in a record will be grouped into sections: Basics, Parts, Exhibitions, Auctions, Collections, etc.
But RForms cannot create different sections (lists) based on P2_has_type of a node: it can distinguish only based on relation.
Therefore make some business-specific sub-properties, eg

spec diff mig rforms

Thesaurus changes

Verify that Rembrandt and BM thesauri satisfy BMX Issues#Thesaurus Requirements, and make appropriate changes:

  • rkd-places: replace P89_falls_within with P88i_forms_part_of, else FR won't work (this is a bug)
spec diff mig rforms
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.