View Source

{excerpt}Some Rembrandt data rework, related to harmonization and improvements{excerpt}

h1. 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]

h1. Changes
I'll be specifying them in more detail

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

h2. {{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

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

h2. 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".
This includes:
- Main object: rkd-object vs rkd-shape.
- File: rkd-objectstatus vs rkd-area_captured (FRONT/BACK) vs rkd-area_captured (OVERALL/DETAIL)
- Image: rst-iconclass vs rkd-keywords: [RS-627@jira] "Cannot determine thesaurus for image type (autocomplete issue)"

h2. 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
{code}rso:P12i_was_present_at_exhibition rdfs:subPropertyOf crm:P12i_was_present_at{code}

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