compared with
Current by Vladimir Alexiev
on Feb 19, 2015 09:44.

This line was removed.
This word was removed. This word was added.
This line was added.

Changes (36)

View Page History
- Mitac makes changes to EntityAPI (hopefully not many will be needed)

A lot of these are changes marked +WILL+ (then +DID+) in [Rembrandt Mapping Review]. Some were investigated in [RS-323@jira]
Some were investigated in {jira:RS-323}

h2. Color Status
- 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]:
x rso:P46_has_proper_part y := x crm:P46_is_composed_of y AND NOT (x rdf:type crm:E78_Collection)

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

h2. Update properties.txt

{jira:RS-92} uses a file of "business meaningful properties" to collect a complete Museum Object.
- {jira:RS-934}
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


h2. {{rdfs:label}} vs {{crm:P3_has_note}}
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, so we need a different criterion.

The FR rules internally use rso:FC70_Thing. We define this criterion for searchability ([FR Implementation#FC70_Thing for RS|FR Implementation-old#FC70_Thing for RS]):
- rso:E22_Museum_Object, OR
- crm:E22_Man-Made_Object, and the current keeper or owner is the BM
{status:colour=Green|title=spec}{status:colour=Gray|title=diff}{status:colour=Gray|title=mig}{status:colour=Green|title=FR rules}

h2. Disentangle P2_has_type by introducing sub-properties
h2. Disentangle RKD types

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")
- Image: {jira:RS-627}
-- rso:P129_has_iconclass (rst-iconclass)
-- rso:P129_has_keyword (rkd-keywords)
-- (!) TODO Vlado: add clause "P129_is_about E55_Type" to FR2_has_type, else we can't search by IconClass/Keywords
-- Added clause "P129_is_about E55_Type" to FR2_has_type, so we can search by IconClass/Keywords
- Frame: rso:P2_has_object_type (rkd-object)
- File:
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} {status:colour=Green|title=spec}{status:colour=Green|title=diff}{status:colour=Green|title=mig}{status:colour=Green|title=rforms}

h3. Disentangle BM Types
77 occurrences of P2_has_type in config.xml. (!) indicates conflict
||N||term: comments||
|22|thesauri/production/authoring..writing: production type|
| 1|thesauri/production/retail: activity type (?)|
| 2|thesauri/production/\{mus_object_production_person_association},
production probably/unlikely (!)|
|13|dimension/circumference currency curvature depth diameter die-axis height length percentage thickness volume weight width|
| 8|identifier: bigno cmcatno codexid grcatno otherid prn regno serialno|
| 6|thesauri/(x12541,x5827,x6411,x6596,x6622): part type (bell, case, dial...)|
| 5|find/\[CEF]: Discovery type|
| 4|acquisition/association/\{bm_acq_name_ass} (Acquired From, On Loan From, Acquired Through, Motivated By)|
| 3|thesauri/authority/\{bm_as_(name,place,authority)_ass}: production P17_was_motivated_by person,place,authority|
| 3|thesauri/association/(associatedwith,namedinscription): depicted/named place/person (P65_shows_visual_item/P138_represents)|
| 2|thesauri/association/\{bm_as_title_ass}: title type|
| 2|thesauri/production/AJ: production by Related Group (Circle)|
| 2|inscription/lettering type (IR, LE)|
| 1|modification/RP (repaired)|
| 1|aspect/\{mus_obj_parts} (E25_Man-Made_Feature)|
| 1|acquisition type (Treasure Trove)|
| 1|thesauri/\{mus_object_name_th_i}: object type (!)|
| 1|thesauri/\{bm_ware_th_i}: ware (!)|
| 1|thesauri/\{bm_escapement_th_i}: clock escapement (!)|

Josh, you need to introduce 3 subprops of P2_has_type for the last 3 thesauri, eg
bmo:PX_object_type, bmo:PX_ware, bmo:PX_escapement.
Else we'll have trouble displaying the object type (see next section):
if we fetch the superprop P2, we'll get not only BM type&ware&escapement, but also RKD type&shape (see prev section)

h3. Single-out Object Type

We display the object type (painting, coin, etc) as one of the display fields ([RS-690|RS-690]). fields: {jira:RS-690}.
For this reason it needs to be singled out amongst all other E55_Type's. How can we do that?
# We could leave it as the only field per node mapped to P2_has_type.
-- BTW Josh you *will* have to do the same disentangling as we did (eg by defining BMO extension properties of P2), else data annotation won't work over BM data. See the detailed explanation below.

(!) Jana, can you Let's explain here *why* one property should not have multiple properties from several thesauri?
- Jana: The reason was a design decision that I have never been too happy with - to recognize thesaurus for new values from the existing values.
-- That is, if we need to propose a new value for has_current_keeper, for example, we fetch existing values, get the thesaurus they belong to and present the user with autocomplete component that searches values exactly from that thesaurus.
Now that I asked the question explicitly, I can answer it myself ;-) There's no problem to propose a new value, but two new values will get tangled. The system cannot know whether new1 applies to value1 or value2, since the association is by rdf:subject and rdf:predicate, but not by thesaurus.
- Jana: "value new2 for value1" sounds fine if we replace the value. When we propose an addition (or create data from scratch) this won't work. Otherwise, we link new1-value1 in an annotation as new/old values. The new values are not shown in rforms anyway until they get accepted and replace the old values.
- Introducing P2_has_object_type -- Introducing P2_has_object_type seems fine to me. Not because of the new value problem above (we may run into it at many other places) but because we clearly put some specific semantics there - like planning for different rforms templates per type or searching by type.
- Jana, please comment which alternative above you prefer. Jana: P2_has_object_type
-- I prefer P2_has_object_type


h3. Unchangeable P2_has_type
h2. Business-specific sub-properties

Maria {jira:RS-273}:
Maria [RS-273@jira]: we 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.
- Make business-specific sub-properties
- change P11 to P14 for auction house:
{code}<obj/2926/acquisition/1> crm:P14_carried_out_by <obj/2926/acquisition/1/house>.{code}
- (!) Maria/Jana to specify whether more sub-properties are needed
- Maria/Jana may specify more sub-properties, if needed


h2. Thesaurus changes

(x) BM thesauri: [RS-700@jira] {jira:RS-700}

h1. Diffs