BM Association Mapping Problems

Version 10 by Vladimir Alexiev
on Aug 08, 2013 13:19.

<< Changes from 9 to 10

compared with

Current by Vladimir Alexiev
on Aug 12, 2013 17:12.

Key

This line was removed.

This word was removed. This word was added.

This line was added.

Changes (11)

View Page History

...

{excerpt}Review of [BM Association Mapping v2]{excerpt}
{toc}

h1. Association Mapping Problems

h2. Acquisition sub-event connected with inverse
- [BM Association Mapping v2#Acquisition Person]

Acquisition patterns (Transfer of Ownership and Change of Custody) connect *both* the main event and the sub-event to the object:
{noformat}
<obj> P24i_changed_ownership_through <obj/acquisition>.
<obj/acquisition> P9_consists_of <obj/acquisition/M>.
<obj/acquisition/M> P24_transferred_title_of <obj>. # not P24i
{noformat}

Why do you use P24 to connect the sub-event, instead of P24i that is used for the event?
This is a nitpicking since OWLIM infers P24i from P24, but for consistency and better interoperation with repos that don't infer inverses, it's better to use P24i in both cases.

h2. Acquisition sub-event not connected
- [BM Association Mapping v2#Treasure Act]

This one acquisition sub-event is not connected to the object (unlike all other sub-events)

h2. Production sub-event not connected
- [BM Association Mapping v2#Production Person]

Production patterns *don't* connect the sub-event to the object:
{noformat}
<obj> P108i_was_produced_by <obj/production>.
<obj/production> P9_consists_of <obj/production/M>.
<obj/production/M> P14_carried_out_by <person>. # P108i is missing
{noformat}

This is inconsistent with Acquisition, and makes it harder for us to find all sub-events. Please add P108i

h2. Association is redundant when using a sub-event
- [BM Association Mapping v2#Acquired Through (contributor)]
- [BM Association Mapping v2#Influenced By]
- [BM Association Mapping v2#Production Motivated By]
- [BM Association Mapping v2#Made For Place]

Why use *both* EX_Association and P9_consists_of sub-event? Just put P2_has_type into the sub-event, don't use EX_Association

h2. Closely Related Group
- [BM Association Mapping v2#Produced By Closely Related Group]

Take "produced by Workshop of Rembrandt".
- [Previously|BM Association Mapping#Produced By Closely Related Group] this was modeled as:
Produced by E21_Person "Rembrandt" with Association "Workshop of"
{plantuml}
hide empty fields
hide empty methods
hide circle
"<obj/production/M>" -> "<thes/person-instutution/Rembrandt>" : P14_carried_out_by
"<obj/production/M>" <-- "<obj/production/M/association>" : P140_assigned_attribute_to
"<thes/person-instutution/Rembrandt>" <-- "<obj/production/M/association>" : P141_assigned

class "<thes/person-instutution/Rembrandt>" {
a E21_Person
label "Rembrandt"
inScheme <thes/person-instutution/>
}

class "<obj/production/M/association>" {
a bmo:EX_Association
bmo:PX_property P14_carried_out_by
P2_has_type <thes/assoc/WorkshopOf>
}
{plantuml}
- [Currently|BM Association Mapping v2#Produced By Closely Related Group] this is modeled as:
Produced by E74_Group "Workshop of Rembrandt" with type "Workshop Of" and member E21_Person "Rembrandt"
{plantuml}
hide empty fields
hide empty methods
hide circle
"<obj/production/M>" -> "<obj/production/M/group>" : P14_carried_out_by
"<obj/production/M/group>" -> "<thes/person-instutution/Rembrandt>" : P107_has_current_or_former_member

class "<thes/person-instutution/Rembrandt>" {
a E21_Person
label "Rembrandt"
inScheme <thes/person-instutution/>
}

class "<obj/production/M/group>" {
a E74_Group
label "Workshop of Rembrandt"
P2_has_type <thes/assoc/WorkshopOf>
}
{plantuml}

The current way is more faithful to CRM, but it has some peculiarities/problems regarding *search*.
Remember that by [FR Transitivity], search by Dutch finds paintings by Rembrandt, and paintings by Rembrandt are counted in Creator=Dutch facet.

# If you search for Rembrandt, you *won't* won't find paintings by Workshop of Rembrandt since the transitivity works the other way around.

Don't know what to do, *need to discuss*

*Discussed: this is ok: user needs to select the more specific term "Rembrandt"*

# The Group is ad-hoc: it uses a local (per-object) URL and doesn't have the required attributes for a term (skos:prefLabel and skos:inScheme).
To be searchable, the Group should be associated with a thesaurus (inScheme) that itself is registered in the meta-thesaurus.

BM needs to *fix*

*BM needs to fix*

# If you search for Workshop of Rembrandt, you *will* will find paintings by Rembrandt.

This *may* be OK

*Disussed: this is ok*

# Paintings by Rembrandt will be counted in facets Workshop Of Rembrandt, School of Rembrandt, Circle of Rembrandt, and whatever other related groups are created.

This is probably *not OK*.

*Discussed. Dominic: factually this is true, so it's ok*

Vlado: Emmanuelle, forget about my suggestion yale:PX_is_founder_of, for now let's stick with P107 for consistency with BM

h2. Closely Related Individual
- [BM Association Mapping v2#Produced By Closely Related Individual]

...

This uses a property bmo:PX_pupil that is not a CRM extension. So a CRM-consuming application won't know about it.
I'd rewrite it to use the above pattern, i.e. a group consisting of a single person.

h1. Other Problems

These are not related to Associations. They have not been discovered until now.

h2. Bibliography

See eg [http://test.researchspace.org:8081/resource?uri=http://collection.britishmuseum.org/id/bibliography/148]:
- bibo:numPages is wrong, you should use bibo:pageStart and bibo:pageEnd for a continous page range.
- Or if you have one field in Merlin, at least use bibo:pages
- see [BIBO documentation|http://bibotools.googlecode.com/svn/bibo-ontology/trunk/doc/index.html]

h2. Ontology
- wrong label:
{noformat}
bmo:PX_physical_description rdf:type owl:DatatypeProperty ;
rdfs:label "physical exhibition"
{noformat}

h2. Poor Acquisition
For objects with little data about the acquisition, no proper E8_Acquisition record is made. You can find such objects with:
{noformat}
select * {?s a rso:FC70_Thing; crm:P50_has_current_keeper id:the-british-museum.
filter(not exists {?s crm:P52_has_current_owner id:the-british-museum)}
{noformat}
Examples: RFM1654 ([RDF|http://test.researchspace.org:8081/resource?uri=http%3A%2F%2Fcollection.britishmuseum.org%2Fid%2Fobject%2FRFM1654], [COL|http://www.britishmuseum.org/research/collection_online/collection_object_details.aspx?objectId=265472&partId=1]), WCO25205 WCO26021 WCO26113 WCO106044 RRM16709 ...

Eg RFM1654 has this acquisition data:
- Acquisition name: Previous owner/ex-collection: Elijah Dowpey (?)
- Acquisition date: 1920

Which is mapped to this RDF:
{noformat}
<object/RFM1654> crm:P50_has_current_keeper id:the-british-museum, <thesauri/department/W>;
crm:P51_has_former_or_current_owner <person-institution/9593>.
<object/RFM1654/acquisition> crm:P4_has_time-span <object/RFM1654/acquisition/date>;
a crm:E8_Acquisition.
<object/RFM1654/acquisition/date> crm:P3_has_note "1920 ::";
crm:P82a_begin_of_the_begin "1920-01-01"^^xsd:date;
crm:P82b_end_of_the_end "1920-12-31"^^xsd:date;
a crm:E52_Time-Span;
rdfs:label "1920".
{noformat}

And has these problems:
# The Acquisition is not connected to the object (no P24i_changed_ownership_through), so the Acquisition date won't be printed
# No statement is made that BM is the current owner (P52_has_current_owner)

The above is mapped according to section [BM Association Mapping v2#Former Owner], which comments: "All prev owners are listed with code PO "Previous owner/ex-collection", and the last one is listed with an Acquired From code". Section [BM Association Mapping v2#Acquired From] fixes the two problems above.
But in this case *there is no* Acquired From code in Merlin, which contravenes the comment, and leads to the missing statements.

The solution is to always emit these statements (from [BM Association Mapping v2#Acquired From]):
{noformat}
<obj>
P52_has_current_owner id:the-british-museum;
P24i_changed_ownership_through <obj/acquisition>.
<obj/acquisition> a E8_Acquisition, E10_Transfer_of_Custody;
P22_transferred_title_to <id:the-british-museum>.
{noformat}
I.e. we always know that the object must have been transferred to BM, even if there is no record from whom.