Mapping of BM Association Codes to CRM constructs

Introduction

We put Association Codes in two different nodes depending on what the code relates to. This is described in the next two sections.

Code In Reified Association

When an Association Code is about the role of an entity in an event, we put it in explicit bmo:EX_Association node (reification).
We use an extension of E13_Attribute_Assignment, adding a way to identify which property we are talking about:

For example the code:

is mapped to:

which is depicted below:

Translated Code in Event

When an Association Code is about an event, we put it directly on the event.
We translate the code to a thesaurus term that speaks about the event, not about an entity associated with the event. Often codes from different association vocabularies but having the same meaning, are collapsed to the same term, eg:

Note: we cannot collapse these two events into one, since we don't have info to correlate them: see next section.

Multiple Uncorrelated Events

In many cases we cannot correlate entitites, since such info is missing in Merlin. In such cases we use an independent counter (denoted M,N etc) to create unrelated nodes of the same type. Examples:

1. Production Person to Production Place, even when the two are of the same type (eg "lustred"): see prev section
2. Inscription to specific inscription creator (Inscription by)

   <obj/inscription/M> carries the properties of the inscription, and <obj/inscription/N> is an empty node that has only type and an attached creation event.

Exception: all Acquisition and Transfer of Custody data (see Acquisition Person) uses the same event URI <obj/acquisition>, since Merlin has data only about the last acquisition

Uncorrelated Events Display

The desired way to display multiple uncorrelated events of the same type is:

• group the events under the same heading (event type)
• append the association code (type) in parentheses, no matter whether it's In Association or In Event

Examples:

Production
  carried out by: Person (lustred)
  took place at: Place1 (lustred)
  took place at: Place2 (factory in)

Acquisition
  custody surrendered by: Museum1 (On Loan From)
  had participant: Person3 (Donated Through)
  was motivated by: Person4 (In Memory Of)

But where the hell do we put the Annotation Points, i.e. what can the user annotate and propose new values for?
I suggest we put AP only for the values (person, place, etc). If we also allow proposing new values for the codes:

• it'll get too complex (several APs in one line)
• Josh needs to split into sub-thesauri of "compatible terms", according to the sub-sub-sections of Association Mapping
  Example: the user shouldn't be able to propose <thesaurus/acquisition/donated_through> instead of <thesaurus/acquisition/in_memory_of>,
  since these terms go along with different CRM properties (P11_had_participant vs P17_was_motivated_by)
  and are listed in different sub-sub-sections (Acquired Through (intermediary or contributor) vs Acquisition Motivated By)

Association Terms and ConceptSchemes

What Terms and ConceptSchemes should be used in the sections below? Unfortunately this wasn't specified in detail until now (02-Nov-2012):

• Translated Code in Event says that terms should be merged when they express the same meaning
• later the spec uses <type-TRANSLATED> in various places, but leaves the details unspecified

Guiding Principles:

• URIs:
  • each term should have the ConceptScheme URI as a prefix
  • one ConceptScheme should not be prefix of another
  • preferably, term names should be meaningful and not codes.
    Eg "school-of" is preferred to "AJ".
    Since each term has a meaningful name in skos:prefLabel, this is a preference, not a requirement.
• ConceptSchemes:
  • Terms with related meaning should be in the same scheme
    Eg both "lustred" and "decorated" should be inScheme thesauri/production/technique
  • Terms with the same meaning should be merged
    Eg both "Lustred by" and "Lustred in" describes a technique, so they should be mapped to thesauri/production/technique/lustred. By/in is taken care of by different CRM relations

This would have impact on RS only if we care what New Values a user can propose, as part of Annotating an association code.
In that case all Terms in a given scheme should be "compatible" (last principle above).
But I don't think we should chase this now, since some of the codes are quite peculiar and the thesaurus becomes quite fragmented (many ConceptSchemes with just 1-2 values)
(This is in a similar train of thought as RS-716 )

Proposed schemes:

Association Mapping

Acquisition Person

Acquired From

B: Bequeathed by
D: Donated by
E: Exchanged with
F: From
P: Purchased from
T: Transferred from: this is transfer of ownership, and not merely custody
UI: Unclaimed item: the former owner brought it in for examination, and never reclaimed it. "Over time" BM became the owner, although its legal status is a bit unclear

Treasure Act

TT: Treasure Trove
TR: Purchased through the Treasure Act 1996
This says a treasure (eg gold) was found in the UK, and BM (or Department of Culture) purchased it from the land's owner under the Treasure Act.

• The institution mentioned in this association is usually Department of Culture, so we won't record it. Josh: I think we said we would record it as the DfCMS may not always apply.
• There'll be a separate association to say who it was purchased From.

TODO Josh: check/correct the two fixed URIs above. You should be careful that all Acquisition P2_has_type's come from the same thesaurus!
TODO Josh: Will also keep the current triple of saying the acquisition was motivated_by a URI which represents the Treasure Act / Treasure Trove. Will adjust the type from a E30_Right to a class which represents a law...

Former Owner

PO: Previous owner/ex-collection
All prev owners are listed with this code, and the last one is listed with an Acquired From code

Received Custody From

L: On loan from

Acquired Through (intermediary or contributor)

A: Purchased through
BT: Bequeathed through
CF: With contribution from
EC: Exchanged through
FU: Funded by
S: Sponsored by
V: Donated through

All of the above codes imply that BM received ownership

Acquisition Motivated By

IH: In Honour of
IM: In Memory of

Do all of the above codes imply that BM received ownership? I'm not sure

Found By

C: Collected by
EX: Excavated by

Discovery (Finding) is an important kind of event: for most archeological artefacts we don't know much about Production, but we may know about Discovery. So we define a sub-class for it.

• Finding an object tells us nothing about former or current ownership.

The place of finding (Findspot) is defined in a similar way.
It's mapped to the same node <obj/find>, though there may be some duplicate statements (eg bmo:EX_Discovery is stated twice)

Jointly Found By

DA: Division of Finds: BM and the other Person did a joint excavation, and divided the finds

Owned By

OB: Owned by
The object is not in the BM collection (and not owned by BM), even though it's in the Merlin database

• The motivation is to create cross-museum catalogs
• Such objects won't be found by RS (they are not marked FC70_Thing so are not searchable)
• They are filtered out of BM's Collection Online
• TODO Josh should filter them out of the .
• TODO Josh: adjust The export from Merlin to BM RDF data to leave out objects which have an association code 'OB'

Production Person

Produced By Specific Process

Josh: Ensure any harmonisation of these association codes are done with the ones in Production Place & relevant codes in Association

These codes mean the same:

TODO Josh: the type-TRANSLATION should map them to the same term.

These codes mean the same:

Produced By Closely Related Group

AG: Office/studio of
AJ: Circle/School of
F: Factory of: an industrial or mass product (eg ship, porcelain, etc)
N: Pupil of
O: Official/Office/Dept: unsure what's that, there are only 3 objects
W: Workshop of

Retailed By

RT: Originally retailed by: eg Barbie dolls are retailed by Mattell
TODO Josh: Create an Activity which represents the retail (use P2_has_type). The URI can be <obj/retail>. Confirm with Vlado

Probably/Unlikely Produced By

• Probably
  A: Attributed to
  AA: Attributed to an Apprentice/Pupil of
  AB: Ascribed to
  AC: Attributed to the Circle of
  AD: Assigned to
  AW: Attributed to the Workshop of
  CB: Claimed to be by
• Unlikely
  AE: Formerly attributed to: It was thought to be made by the person, but not anymore (there would be another Attributed association)

Before we used a (multi-inheritance) sub-property to indicate the uncertainty:

• Josh: Are we sure we want to sub-property CRM to indicate uncertainty? Would it not be better to have a subProperty of PX_probably which is in the BMO?
• Vlado: it is multi-inherited, once from CRM and secondly from PX_probably, so I'm not sure what is your question

Vlado: now I think it's better to put the uncertainty indicator directly on EX_Association:

• Otherwise a BMO-unaware app will not print it out.
• Property multi-inheritance is a bad idea: if the same Production and Person are connected by two properties (eg P14_carried_out_by, P15_was_influenced_by), the PX_probably and PX_unlikely may get mixed up.
• We'll replace 5 extension properties (bmo:PX_probably, bmo:PX_probably_carried_out_by, etc) by 1 (PX_likelihood), which is a good thing.

New Proposal

We define ext prop PX_likelihood and put the specific values in a thesaurus.
OPTIONALLY, we make a hierarchy under terms "likely/unlikely" (maybe that's an overkill!).

The data mapping then is very simple:

Inscription Created By

IR: Inscription by
LE: Lettering engraved by

Part Made By

MB: Bell made by
MC: Case made by
MD: Dial made by
ME: Ebauche maker
MM: Movement made by
MP: Watch pendant made by
MQ: Dust-cap maker

Here the type translation removes "made by" and leaves only the part type (eg Bell)

Influenced By

AF: Attributed to a Follower of
AI: Attributed to an Imitator of
AL: Manner/Style of
AM: Attributed to the Manner of
AT: After
C: Close to
CF: Compare with
CM: Connected with the Manner of
CW: Connected with
S: School of/style of
RE: Related to
NE: Near: means the same as "In the style of"
RC: Recalls

Production Authority

Production Motivated By

E: Eponym: according to wikipedia, it means something like Inventor, but BM uses it as the others below
G: Governor
I: Issuer
K: Ruler
Y: Magistrate

Notes:
M: Moneyer: is mapped the same as Production Person=G: Moneyer

Production Place

Produced By Specific Process At

D: Designed in
DE: Decorated in
I: Issued in
L: Lustred in
M: Made in
MI: Minted in
P: Painted in
PH: Photographed in
R: Printed in
Z: Published in

Similar to Produced By Specific Process:

Produced At

F: Factory in
W: Workshop in

Similar to Produced By Closely Related Group:

Retailed In

RT: Retailed in
TODO
Similar to Retailed By

Probably Produced At

A: Attributed at
CF: Claimed to be from
Similar to Probably Produced By (New Proposal)

Part Made In

MB: Bell made in
MC: Case made in
MD: Dial made in
ME: Ebauche made in
MM: Movement made in
MP: Watch pendant made in
MQ: Dust-cap made in

Similar to Part Made By:

Associated Person

Depicted Person

AB: Illustration of
IP: Portrait of
IR: Representation of
EE: Emblem of

We choose to state both the shortcut (P62) and longcut (P65-E36-P138) so we can use the intermediate node to attach the type:

Note about Emblem (eg coat of arms, company logo, etc): it's not a literal depiction, but still very closely related to the Person, so we map it like the rest.
We considered stating it's a conceptual object that belongs to the person (P105_right_held_by instead of P138), but decided that the association is more intimate than just holding a right.

Referred Person

PO: Associated with: the nature of association is unclear, so we use the weaker P67_refers_to

Person in Inscription

PI: Named in inscription

Person Depicted and in Inscription

II: Named in inscription & portrayed

The object has two P65_shows_visual_item: the portrait itself, and the inscription.

Made For Person

F: Made for
PP: Authorised or patronised by
Map the same as Production Motivated By

Repaired By

RP: Repaired by

Associated Place

Depicted Place

IT: Topographic representation of
PA: allegory/personification
EE: Emblem of: M.Doerr argues a place can have no emblem, but it's too complicated to make an anonymous group having its residence there

Referred Place

AW: Associated with: the nature of association is unclear, so we use the weaker P67_refers_to
Essentially the same as Referred Person

Made For Place

MF: Made for

Map essentially the same as Production Motivated By

Place in Inscription

NI: Named in inscription
Map essentially the same as Person in Inscription

Natural Source

NS: Natural source
A raw material used in the object comes from Place. This is complicated (and is used in only 13 objects):

• a Material is a conceptual thing, so it doesn't have a location
• we say the Material was Created at Place, although that sounds a bit silly
• we should say the Material was P126_employed in the object's Production, but that is too complex, so we just say the Material P45i_is_incorporated_in the object

Original From

OF: Original from

The object bears the features of an original that is from Place

Repaired In

RP: Repaired in

Associated Event

Made for Event

DF: Designed for

Used at Event

IU: Used at

Referred Event

IW: Associated Event
Similar to Referred Place

Commemorates Event

IC: Commemoration of

where bmo:PX_commemorates is a subprop of P67_refers_to

Event in Inscription

PI: Named in Inscription
Map essentially the same as Person in Inscription

Associated Title

EI: Title
IT: Associated Title (will use <type> thesauri/association/associatedwith which is the same as any other 'Associated With' code used)
TI: Inscription from

This code associates a free text, which is the Title of a work of art (eg Koran, Ramayana, etc). It's not the title of the object, yet is a title that the object carries

Findspot

E: Excavated/Findspot
F: Found/Acquired
Map similarly to Found By:

Inscription Subject

Strangely, Inscription Subject is a multi-value field independent from the actual Inscription records. So we replicate each Inscription Subject to every Inscription: in this case M iterates over Inscriptions, not over Inscription Subjects.
We use a sub-property, so as not to conflate P2_has_type for different purposes:

Inscription Type

We use a sub-property, so as not to conflate P2_has_type for different purposes:

Ethnic Group

Referred Group

AW: Associated with
Similar to Referred Place

Depicted Group

IR: Representation of

Made By Group

M: Made by

Location Availability

This association carries a free text describing the actual location. We should publish this text only:

• if the code is "G: on display", or
• if the department is Prints and Drawings

The code itself is not published.