Mapping of BM Association Codes to CRM constructs
- Introduction
- Code In Reified Association
- Translated Code in Event
- Multiple Uncorrelated Events
- Uncorrelated Events Display
- Association Terms and ConceptSchemes
- Association Mapping
- Acquisition Person
- Acquired From
- Treasure Act
- Former Owner
- Received Custody From
- Acquired Through (intermediary or contributor)
- Acquisition Motivated By
- Found By
- Jointly Found By
- Owned By
- Production Person
- Produced By Specific Process
- Produced By Closely Related Group
- Retailed By
- Probably/Unlikely Produced By
- Inscription Created By
- Part Made By
- Influenced By
- Production Authority
- Production Place
- Associated Person
- Depicted Person
- Referred Person
- Person in Inscription
- Person Depicted and in Inscription
- Made For Person
- Repaired By
- Associated Place
- Depicted Place
- Referred Place
- Made For Place
- Place in Inscription
- Natural Source
- Original From
- Repaired In
- Associated Event
- Associated Title
- Findspot
- Inscription Subject
- Inscription Type
- Ethnic Group
- Location Availability
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:
Acquisition Person | B: Bequeathed by |
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:
Association Vocabulary | Code | Thesaurus Term |
Production Person | L: Lustred by | <thesaurus/production/lustred> |
Production Place | L: Lustred in | <thesaurus/production/lustred> |
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:
- Production Person to Production Place, even when the two are of the same type (eg "lustred"): see prev section
- 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
- Terms with related meaning should be in the same scheme
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 (Section) | ConceptScheme/term |
Acquired From, Treasure Act | acquisition/from |
Former Owner | n/a: this has no association |
Received Custody From | custody/on-loan |
Acquired Through (intermediary or contributor) | acquisition/through |
Acquisition Motivated By | acquisition/motivated |
Found By, Jointly Found By, Findspot | acquisition/found |
Owned By | n/a: this has no association |
Produced By Specific Process, Produced By Specific Process At | production/process |
Produced By Closely Related Group, Produced At | production/group |
Probably/Unlikely Produced By, Probably Produced At | production/likelihood. Some of the codes also have a "group" aspect (eg AC: Attributed to the Circle of). TODO: map it too |
Retailed By, Retailed In | retailed |
Inscription Created By | production/inscription |
Part Made By, Part Made In | n/a: uses general "object type" thesaurus |
Influenced By | production/influenced-by |
Production Motivated By, Made For Person, Made For Place | production/motivated-by |
Depicted Person, Person in Inscription, Person Depicted and in Inscription, Depicted Place, Place in Inscription, Event in Inscription | represents |
Referred Person, Referred Place, Referred Event | n/a: maps to straight P67_refers_to |
Repaired By, Repaired In | modification/repaired |
Natural Source | n/a |
Original From | association/object/original |
Made for Event, Used at Event | n/a: maps to straight P19i_was_made_for, P12i_was_present_at |
Commemorates Event | n/a: uses bmo:PX_commemorates |
Associated Title | association/title |
Inscription Subject | inscription/subject |
Inscription Type | inscription/type |
Referred Group, Depicted Group, Made By Group | n/a: maps to straight CRM properties |
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
5: Drawn by | ID: Intermediary draughtsman |
AU: Author | J: Modelled by |
BC: Block cut by | L: Lustred by |
CA: Calligrapher | M: Made by |
D: Designed by | P: Painted by |
DE: Decorated by | PH: Photographed by |
DM: Medal designed and made by | SC: Scribe |
E: Engraved by | WR: Written by |
I: Issuer | Z: Published by |
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:
G: Moneyer |
T: Mint |
Production Authority: M: Moneyer |
TODO Josh: the type-TRANSLATION should map them to the same term.
These codes mean the same:
PA: Print artist |
PM: Print made by |
R: Printed by |
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
administrative | list |
anra motif | literary |
catalogue | magical |
commemorative | mathematical |
construction | medical |
dedicatory | motto |
educational | offering formula |
epistolary | omen |
epitaph | private |
financial | religious |
funerary | ritual |
invocation | royal |
legal | scientific |
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
annotation | maker's mark | retailer's mark |
bell maker's mark | mark | sacred monogram |
casemaker's mark | merchant's mark | seal |
control mark | mintmark | seal impression |
countermark | monogram | signature |
denominational mark | overstamp | signature and date |
dial maker's mark | owner's mark | signature/monogram |
dust-cap maker's mark | pewter mark | tamgha |
ebauche mark | pottery mark | trade mark |
hallmark | reign mark | vineyard mark |
inscription | repair mark | watch pendant maker's mark |
lettering |
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.