Introduction

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

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

The next section talks about how we nest the uncorrelated events for Production and Acquisition events under 'parent nodes'

Translated Code in Sub-Events

Mainly applies to Production & Acquisition
Here is an example of how some events are modeled due to the fact that BM data has multiple acquisition / production events which hold the issue of being uncorrelated in the Merlin database:

Here is a practical example:
PDB13646
Merlin says this about the acquisitions:

• Association: B (Bequeathed by)
  Name: French, Cecil (Cecil French)
  Comment: See Acquisition Comment
• Association: A (Purchased through)
  Name: Barbizon House
  Comment: Christie's, London, 9 xii 1932/88
• Association: PO (Previous owner/ex-collection)
  Name: Poynter, Edward John (Edward John Poynter)
  Comment: See Acquisition Comment
• Acquisition Comment: Purchased by French, through Barbizon House, at Christie's, London, 9 December 1932, lot 88 (anonymous vendor).

Here is how this will be modeled (Vlado: this graph does NOT express what the Acquisition Comment says):

This graph correctly represents the comments above (we can additionally say that acquisition/1 is likely before acquisition/2, and acquisition/2 is before acquisition/3).
However, it cannot be deduced from the source since Merlin only has a bag of Acquisition associations, not proper Acquisition events

Translated Code In Reified Association

When an Association Code is about the degree of participation 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 Probably/Unlikely Produced By:

which is depicted below:

How to Display Events

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 or in Sub-Event (TODO: illustrate this last case)

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)

Merged Association Codes

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". However to keep some transparency with Merlin, the codes have been used since each term has a meaningful name in skos:prefLabel. See the last column in the tables in the following sections.
• ConceptSchemes:
  • Terms with related meaning should be in the same scheme
    Eg both "lustred" and "decorated" should be inScheme thesauri/production
  • Terms with the same meaning should be merged
    Eg both "Lustred by" and "Lustred in" describes the same technique, so they should be mapped to thesauri/production/technique/lustred. The distinction "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 )

BM association terms are 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)

Acquisition & Findspot Association Codes

Production Association Codes

Associated Person/ Place/ Event Codes

Associated Title Codes

Inscription Subject Codes

Inscription Type Codes

Association Mapping

General note about Acquisitions

• If there is no Acquisition Name / Person for an object, then BM will be the OWNER of the object.
• If there is an Acquisition Name / Person which will either produce BM as OWNER or correctly state the BM is NOT the owner then do nothing. Otherwise, whether BM is the owner is not stated in the record and therefore we'll just assume that BM is the owner.
• Since the BM only record one date for the acquisition, this will be modeled as a timespan on the main <obj/acquisition> node.

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

The types should be taken from: Acquisition & Findspot Association Codes

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.

The types should be from: Acquisition & Findspot Association Codes

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

The types should be from: Acquisition & Findspot Association Codes

Acquired Through (intermediary)

A: Purchased through
BT: Bequeathed through
V: Donated through
EC: Exchanged through

The types should be from: Acquisition & Findspot Association Codes

Acquired Through (contributor)

CF: With contribution from
FU: Funded by
S: Sponsored by

All of the above codes imply that BM received ownership

The types should be from: Acquisition & Findspot Association Codes

Acquisition Motivated By

IH: In Honour of
IM: In Memory of

The types should be from: Acquisition & Findspot Association Codes

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 types should be from: Acquisition & Findspot Association Codes

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 and out of this RDF extraction

General note about Productions

• The Production date will probably apply to the over set of sub events that are in the main production node, therefore the timespans will apply to that.
• For objects with parts, each part will have a root production node and a single sub event will contain the actual details of the part's production.

Production Person

Produced By Specific Process

This code will re-use types derived from existing codes:

These codes mean the same:

These codes mean the same:

The types should be from: Production Association Codes

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)
O: Official/Office/Dept: unsure what's that, there are only 3 objects
W: Workshop of

The types should be from: Production Association Codes

Produced By Closely Related Individual

N: Pupil of

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:

Therefore the types will be (used with bmo:PX_likelihood -> subProp of P2_has_type): Production Association Codes

Inscription Created By

IR: Inscription by
LE: Lettering engraved by

The types should be from: Production Association Codes

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

• It has been advised that the 'Part Made By' and 'Part Made In' are generally the same production instance when recorded in Merlin (as the association code is so specific). Therefore the production events will be merged by assigning the same URI the production node: <obj/production/PART-NAME>
• In order to maintain the production of the part and to reduce the number of production events here is the proposed modelling:

Here the type translation removes "made by" and leaves only the part type (eg Bell).
Therefore the types will be (and the relevant PART-NAME): Production Association Codes

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

The types should be from: Production Association Codes

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

The types should be from: Production Association Codes

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:

The types should be from: Production Association Codes

Produced At

F: Factory in
W: Workshop in

Similar to Produced By Closely Related Group (place of):

The types should be from: Production Association Codes

Retailed In

RT: Retailed in

Similar to Retailed By

The types should be from: Production Association Codes

Probably Produced At

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

The types should be from: Production Association Codes

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:

The types should be from: Production Association Codes

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.
The types should be from: Associated Person/ Place/ Event Codes

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

The types should be from: Associated Person/ Place/ Event Codes

Person Depicted and in Inscription

II: Named in inscription & portrayed

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

For the Image and the Inscription nodes, we will use existing types (see: Associated Person/ Place/ Event Codes):

Made For Person

F: Made for
PP: Authorised or patronised by
Map the same as Production Motivated By
The types should be from: Associated Person/ Place/ Event Codes

Repaired By

RP: Repaired by

The types should be from: Associated Person/ Place/ Event Codes

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

The types should be from: Associated Person/ Place/ Event Codes

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 and using type as defined in Made For Person

Therefore the types will be:
The types should be from: Associated Person/ Place/ Event Codes

Place in Inscription

NI: Named in inscription
Map essentially the same as (and using the type defined in) Person in Inscription

The types should be from: Associated Person/ Place/ Event Codes

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

The types should be from: Associated Person/ Place/ Event Codes

Repaired In

RP: Repaired in

The types should be from: Associated Person/ Place/ Event Codes

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

Therefore the types will be:

Associated Title

EI: Title
IT: Associated Title (will use <type> thesauri/association/AW (Associated With) 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

The types should be from: Associated Title Codes

Findspot

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

The types should be from: Acquisition & Findspot Association Codes

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:

The types should be from: Inscription Subject Codes

Inscription Type

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

The types should be from: Inscription Type Codes

Ethnic Group

Referred Group

AW: Associated with
Similar to Referred Place

Depicted Group

IR: Representation of

The types should be from: Associated Person/ Place/ Event Codes

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.

TODO:

• Mint (email Julia)

PRNs:

• MCC2540
• EAF8510
• MCN1456