compared with
Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (11)

View Page History

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

h2. Remove part/1
- 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|#Update 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|FR Implemenatation|#BUG]:
{code}
x rso:P46_has_proper_part y := x crm:P46_is_composed_of y AND NOT (x rdf:type crm:E78_Collection)
{code}

{status:colour=Green|title=spec}{status:colour=Green|title=diff}{status:colour=Red|title=mig}{status:colour=Red|title=rforms}

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

{status:colour=Red|title=spec}{status:colour=Red|title=diff}{status:colour=Red|title=mig}{status:colour=Red|title=rforms}

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

{status:colour=Red|title=spec}{status:colour=Red|title=diff}{status:colour=Red|title=mig}{status:colour=Red|title=rforms}

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.
-- If not, we should add such class to BM data

{status:colour=Red|title=spec}{status:colour=Red|title=diff}{status:colour=Red|title=mig}{status:colour=Red|title=rforms}

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

{status:colour=Green|title=spec}{status:colour=Green|title=diff}{status:colour=Red|title=mig}{status:colour=Red|title=rforms}

h3. 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.
{code}
<obj/2926/acquisition/1/price> crm:P2_has_type rst-currency: . # "Price"
<obj/2926/research/1> crm:P21_had_general_purpose rkd-res_type: . # "Research"
{code}

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

{status:colour=Red|title=spec}{status:colour=Red|title=diff}{status:colour=Red|title=mig}{status:colour=Red|title=rforms}

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)

{status:colour=Red|title=spec}{status:colour=Red|title=diff}{status:colour=Red|title=mig}{status:colour=Red|title=rforms}