Skip to end of metadata
Go to start of metadata

review Martin Doerr, 09 Feb 2012. Replies Vladimir Alexiev, 07 May 2012


Rembrandt Mapping Review

·                   Martin Doerr, 09 Feb 2012: Attached my completed comments about susana.html.   I have incorporated expansions of the topics mentioned in Vladimir's minutes. Please let me know, if you need more details or justification.

·        Vladimir Alexiev, 07 May 2012: replies.

·                   I'll post a separate discussion on [skos:Concept vs Person-Place]

·                   WILL (in uppercase) indicates a change we intend to do. Developers, please review and provide comment/estimate. (The biggest change is to get rid of part/1 and use "part" only for the frame).
This will be part of a task "Rembrandt mapping adjustments" in RS3.4 that will also include "untangling" types and some sub-properties for better display.

·                   Josh, please review as you may find something useful for the BM mapping too.

·                   Dominic, how/when/do you want me to discuss this further with Martin? Also see next email on "harmonization"


### <record>

<obj/2926> a rso: E22_Museum_Object ;

  crm: P2_has_type rkd-object: painting ;

# part1: painting; part2: frame

  crm: P57_has_number_of_parts 2;

    # same as the long form "2"^^xsd:integer, see sec 2.4

  rso: P46_has_main_part <obj/2926/part/1> ;

  rso: P46_has_other_part <obj/2926/part/2> .


·                   Rename rso:E22_Museum_Object to Inventory Object: There is no recognizable substance what makes an object a “museum object”. The notion of “Inventory Object” represents the functional units by which museums verify the integrity of their holdings. How many things are comprised under one inventory number is a question of acquisition history and curation. All museums identify their holdings as inventory objects by persistent identifiers for all their lifecycle. Museums may also talk about : exhibition objects, packaging units for transport, historical objects and assemblies. These have all n-n relations to each other, and could be regarded “museum objects”

·        Actually it should be something like E22_Searchable_Object, since that's what the class is used for: to indicate which E22 can be searched and displayed in a result list (RS currently cannot display sub-objects like <obj/2926/related/1>)

·        This interacts with C1.Thing from your FRthing.docx (which I've called FC70_Thing in my FR-implementation)

·        And it's related to the question "where to find the basic display fields of each object" (title, author, year, thumbnail).
The actual reason we can't display sub-objects is because they lack some of these fields, especially thiumbnail
In RSO we've added rso:E38_Main_Image rdfs:subClassOf crm:E38_Image . to indicate which image to use for thumbnail.
In BM data they would be somewhere else

·        So overall, I think we WILL remove rso:E22_Museum_Object and use some different criterion for searchability

·                   Following the discussion with the curator, the painting (“main part”) should be regarded as the whole, and the frame as a non-essential accessory (part).

·        Yes, BM data doesn't include parts, so they'll remove the part/1 thing.

·        For harmonization we DID the same for Rembrandt data: equate the painting to the object, and represent the frame as a single accessory (insignificant) part/1.

·        Please confirm that in this case P57_has_number_of_parts= 1 ; and for an object that has no accessories, we simply omit number_of_parts



# <priref>

<obj/2926> crm: P48_has_preferred_identifier <obj/2926/priref> .

<obj/2926/priref> crm: P2_has_type rst-identifier: RKD_priref ; crm: P3_has_note "2926" .


·                   Change crm:P48_has_preferred_identifier to crm:P1_is_identified_by, because we can't say priref is more preferred than any of the others. P48 should only be used if the implicit data curator of the rdf instance is fixed and known. ResearchSpace as aggregator may have a preferred identifier. An “identifier preferred by a contributor” is complex construct that we currently model in the FRBR-CRM Harmonization work. It is relative to people and time. Better ignore, or use the E15 assignment type to express an “preferred identifier assignment” event.

·        The record in question is RKD's information about the Susana painting, and in RS we currently don't have requirements to merge records about the same painting, coming from different instutitions. (We have requirements for researchers to annotate and change single fields, but based on one record). Because priref is the primary key in RKD's database, I think it's correct to state it's preferred.

·                   The idea to classify identifiers by their creators is not bad, but in case a rich provenance discourse is described, as it seems here to be the case, the CIDOC guidelines and the CIDOC CRM clearly recommend to associate each identifier with an assignment event (E15, P37 assigned (was assigned by): E42 Identifier), be the date known or not, and the institution that created it (P14 carried out by (performed): E39 Actor).

·        I went for the simpler represenatation since there are no requirements to search for identifier assignment events and actors.

·        Come think of it, I think we should definitely add a FR "has identifier"



# <benaming_kunstwerk> object title, <title>

<obj/2926> crm: P102_has_title <obj/2926/title/primary> .


  crm: P2_has_type rst-note: title-primary ; crm: P3_has_note "De badende Suzanna" @nl, "Susanna" @en.

# <andere_benaming> other/former title, <title.other_older>

<obj/2926> crm: P102_has_title <obj/2926/title/1> .

<obj/2926/title/1> crm: P2_has_type rst-note: title-other ; crm: P3_has_note "Batseba (heette ten onrechte)" @nl. # Bathsheb a (was wrong name)

<obj/2926> crm: P102_has_title <obj/2926/title/2> .

<obj/2926/title/2> crm: P2_has_type rst-note: title-other ; crm: P3_has_note "Suzanna en de ouderlingen" @nl. #  Susann a and the elders


·                   It might be a better practice to use rdf:label uniformly to represent the content of whatever non-globally unique identifier and title from a mapped source, rather than P3. Note that the abstract CRM is not defined in RDF, but the respective RDFS is an interpretation as a database schema, albeit be called “ontology”. There seems to be a good practice to use rdf:label in this sense, for instance in SKOS. This should be a guideline for CRM-SIG to publish.

·        I agree and BM partially went for this, but:

·                   Does that mean the RDF property crm:P3_has_note will be abolished altogether, and rdfs:label used instead?
E.g. BM still uses "a crm:E54_Dimension; crm:P3F_has_note "Dimension :: 278.00 ::" should this also be replaced with rdfs:label?

·                   Shouldn't we also replace crm:P90_has_value with rdf:value?

·                   The CRM-SIG must publish a recommendation on this

·        Overall, I think the CRM-SIG should spend more time pondering the Primitive Values and standardize appropriate RDF representations for them, since rdf:literal is not enough.

·                   Erlangen published a " Recommendation for the representation of the primitive value classes of the CRM as data types in RDF/OWL implementations " saying:
"We recommend to leave the range of these data type properties undefined, i.e., not to impose any restriction on possible data types. If data type restrictions are necessary in a certain implementation, we recommend introducing typed sub properties, such as "P57a has number of parts [XSD integer]" or "P57b has number of parts [XSD unsigned byte]" as sub properties of "P57 has number of parts".
I think this is misguided: leaving something undefined strays away from standardization, and creating a proliferation of sub-properties for the same data is bad practice. You can easily convert between data types. Even if you need to represent several data types, you can use the same property:
P57_has_number_of_parts "1"^^xsd:integer, "1"^^xsd:byte.
and then filter by datatype in SPARQL.

·                   My questions re representation of approximate numbers remain unanswered (e.g. see email "PROPOSAL: subclass Linear Dimension" of 10/26/2011)

·                   Crm:P102_has_title has a property “P102.1 has type: E55 Type”, the role of the title. This should be used to subtype P102 in RDF according to local practice. It should not be moved to classify the title itself, because the very same title may apply to hundreds of things, derivatives or not, but the role may change.

·        I disagree:

·                   In our use cases the title belongs to one object and never needs to be shared, since we don't need to track the "etymology" of titles or relations between titles. Even if we did, I'd model this with explicit links between titles

·                   We have a use case where a researcher can fix a typo in a title, while its nature (type) and object stay the same. Sharing titles would make this complicated

·                   I am against using sub-properties to implement Pnnn.1, see below

·                   By the way, not subtyping a CRM property in order to keep the schema small, or because it is “not standard” is to my understanding a misinterpretation of triple stores by ideas from Relational technology. Subsumption both ensures access by the standard and more subclasses make indexing more effective!

·        I know perfectly well that adding a few nodes or properties doesn't impact the performance of a good triple store (like OWLIM!) significantly. My motivation for using types instead of sub-properties is completely different:

·        This approach works fine for a small fixed set of subproperties. However, it becomes unwieldy if the property types are numerous and come from a thesaurus.

·                   E.g. Getty ULAN includes numerous subtypes for artist relations (associatedWith), such as: teacherOf, patronWas.

·                   E.g. P14F.carried_out_by often needs to be qualified by a type that is likely to come from a thesaurus, e.g. CRM gives the example P14.1_in_the_role_of "Master Craftsman".

·                   E.g. BM has a thesaurus for mus_object_production_place_association (Attributed in, Claimed to be From, etc). Following the sub-property approach leads to a long switch that converts data (flexibility) to schema (fixedness): if 'A' then PX.attributed_in, if 'CF' then PX.claimed_to_be_from, etc etc

·        RDF schemas are flexible, but a thesaurus is more flexible still. If a data source adds another property type, what are we supposed to do: extend our ontology, and edit our mapping to use the new sub-property? That's error-prone and hard to maintain.

·        And for Searching, it's better to let the user select (or multi-select) from a thesaurus, not from a list of sub-properties.

·                   Do not concatenate title translations in one note. Rather provide a set of labels each with a different language attribute.

·        We know that the NL and EN primary titles are translations of each other, so following common RDF practice I attach the two literals to the same node (we have no knowledge or need to track which is a translation of which other). We don't know that re other titles, so I put them on separate nodes.




·                   Following the discussion with the curator, the painting (“main part”) should be regarded as the whole, and the frame as a non-essential accessory (part). To create a whole containing possibly only one part is a philosophical overkill, that does in the end not solve anything and makes display confusing.

·        Agreed, see above. I've always liked the idea of putting the "important info" at top level, not at a part/1

·                   "P46B forms part of" is timeless, so it means "X was part of Y at some point in time". You should represent the dynamics with events E79 Part Addition, E80 Part Removal; and from that you can deduce the specific part decomposition at any given moment, as long as the information is complete enough.

·        We don't need this since we don't have info about multiple frames (unlike the Rafael database that has a whole section "Framing"). It's enough to display the frame date as part of the frame production event.

·                   There is no silent or explicit assumption that a part is produced together with the whole. Note that a knowledge aggregation service such as ResearchSpace is not an AI expert system geared to make logically correct deductions, but to serve recall of relevant facts. Therefore any reasonable assumptions about how parts, wholes and events may relate for specific classes of objects can be implemented as default reasoning increasing recall. For instance, for paintings, the frame does not inherit the production event from the whole. For an industrial car, you may assume that part assembly is inherited from production of the whole to all parts, etc. Users should be taught not to expect “correct results” from ResearchSpace. It is the users’ job to find out what is correct. It is mandatory that the user can learn the provenance of each fact, if she wants, not as default. Reasoners are a source among others. 

·        Got it. It’s reassuring to know that if I put Rembrandt as creator of <obj/2926> (the whole thing), that won't imply he had anything to do with the frame.

·        When I say <obj/2926> crm:P45_consists_of rkd-support:panel-oak, that won't contradict that the frame is made of gilded wood.

·        But how about dimensions? If the data says "painting is 38.6x47.2 cm" and I put this at top level, it would be a slight mis-statement since it won't account for the frame width (but we don't know that width anyway).


# <datering> = <date>

<obj/2926/part/1/production> crm: P4_has_time-span <obj/2926/part/1/production/date> .

<obj/2926/part/1/production/date> crm: P82_at_some_time_within "1636" ^^xsd: gYear .

  # Note: gYear not date, since only YYYY-MM-DD is a legitimate xsd:date


·                   Use the recommendation by CRM-SIG: P82a/b etc. a: 1.1.1636-0:0, b: 31.12.1636-12:00

·        Disagree. For display purposes it’s important to retain the original info: a) Distingish cases P82 only vs P82a+P82b, b) Retain the original precision.


### Support and Medium/Technique

# See

# <drager> = <>

<obj/2926/part/1> crm: P45_consists_of rkd-support: panel-oak .

<obj/2926/part/1/production> crm: P126_employed rkd-support: panel-oak .

# <materiaal> medium/technique = <object.technique>

<obj/2926/part/1/production> crm: P32_used_general_technique rkd-technique: oil-paint .


·                   P126 may be inferred from P45, but not vice versa: Employed materials may not be incorporated into the product. However, incorporated materials may be result of a later modification event…

·        I state P126 for symmetry with P32: both are attached at Production. And I state P45 exactly for the reason you describe


### IMAGE (conceptual object)

# Question: bind to the museum object, or to its part1 (as below)? Doesn't matter much, as soon as everyone follows it

<obj/2926/part/1> crm: P65_shows_visual_item <obj/2926/part/1/image> .

<obj/2926/part/1/image> a crm: E38_Image ;

# For original painting, Image's E65_Creation coincides with Part1's E12_Production. For a reproduction that won't be the case

  crm: P94i_was_created_by <obj/2926/part/1/production> ;


·                   Correct!


# <iconclass_code>

  crm: P2_has_type rst-iconclass: _71P412 ; # Susann a bathing, usually in or near a fountain and sometimes accompanied by two female servants

  # Note: I think someone mis-applied the following code. I see no fucking lion in the painting

  crm: P2_has_type rst-iconclass: _11H_JEROME_51 ; # St. Jerome pulling a thorn out of the paw of a lion


·                   ICONCLASS is a “subject authority”, should be related by “P129 is about”, not P2. Object classification by subject terms is not current practice in libraries and museums, even though this would be a possible interpretation. ICONCLASS is a language to compose themes. Byzantine iconography may be different. The themes have proper names such as “The Sweetly-Kissed Madonna”, which implies a complex, precisely prescribed structure each.

·        DID map it to sub-property of P129_is_about. Now WILL add clause "P67_refers_to E55_Type" to FR2_has_type, else we can't search by IconClass

·        For IconClass we currently have URI and label, but not the code. DID add the code as SKOS Notation (underlined below):


rst-iconclass:_11H_JEROME_51 a crm:E55_Type, skos:Concept;

  skos:inScheme rst-iconclass:; crm:P2_has_type rst-iconclass:;

  skos:notation "11 H (JEROME) 51"^^rst-iconclass:;

  rdfs:label "St. Jerome pulling a thorn out of the paw of a lion"@en.


# <plaats> depicted location

  crm: P138_represents rkd-plaats: geertruidenberg ;

  # P138_represents is too strong: Geertruidenberg may be in the background, but it's not a picture of that place!

  # Should be super-property P67_refers_to; but we cannot tell from the data


·                   I think P138 is correct. P138 is not subproperty of P129, hence does not imply that it is a major subject.


# <RKD_algemene_trefwoorden> RKD keywords

  crm: P2_has_type rkd-keywords: oude_testament_apocriefen .


·                   Better use “P3 has note”

·        Disagree, this is an array of fixed keywords, and it goes against good IT practice to concatenate them

·        DID map to sub-property of P129_is_about


# <lijstmateriaal> material of the frame

<obj/2926/part/2> crm: P45_consists_of rkd-support: wood--gold_plated .

<obj/2926/part/2/production> crm: P126_employed rkd-support: wood--gold_plated .


·                   good



# <artistiek> relation to other artistic object

<obj/2926> crm: P130i_features_are_also_found_on <obj/2926/related/1> .

<obj/2926/related/1> a crm: E22_Man-Made_Object ;

# <beschrijving_verband> description of relation

#   "monogramme on drawing: W.D.P:/f.1636., in the collection of the State Museum of Berlin - print room"@en

  crm: P3_has_note "tekening gemonogrammeerd: W.D.P./f.1636, in de verzameling van de Staatliche Museen zu Berlin - Kupferstichkabinett" @nl;

# <opmerking_artistiek_verband> comment on artistic context

#   "The figures of Nicolaes Tulp and the body are taken"@en

#  crm:P3_has_note "figuur van Nicolaes Tulp en het lijk zijn overgenomen"@nl;

# <artistiek_verband> artistic context: copied by, signed by, put into print by

  crm: P2_has_type rkd-artistic_context: signed_by .


·                   I do not understand this: P2 ..”signed_by”.

·        I had the same problem J . This is a drawing that bears features of the painting, created and signed by Willem De Porter. Both fields "description of relation" and "artistic context" belie their names: they describe the drawing, not its relation to the painting. So I just attached them to the drawing in the simplest possible way, without trying a deeper CRM interpretation.



# We don't use BIBO since the data is not structured.

# <literatuur> literature

<obj/2926> crm: P70i_is_documented_in <obj/2926/reference/1> .

<obj/2926/reference/1> crm: P2_has_type rst-reference: literature ;

  crm: P3_has_note "K. Bauch, Rembrandt GemГ¤lde, Berlijn 1966, nr. 18" @nl.

# <bronnen> sources: is split in two fields but both are unstructured (eg "dl. 6, nr. 57") so we concatenate them

<obj/2926> crm: P70i_is_documented_in <obj/2926/reference/13> .

# <standaardbron> & <standaardbron_deel_pagina>: concatenate

<obj/2926/reference/13> crm: P2_has_type rst-reference: source ;

  crm:P3_has_note "Hofstede de Groot 1907-1928, dl. 6, nr. 57"@nl .


·                   A citation within a book can be taken as an Information Object, which is part of the book. If this is simplified to referring via P70i to the book as a whole, the note specializing page, paragraph or chapter should be attached to the object (domain) and NOT to the book (range) for obvious reasons: If one book is referred to multiply by P70i, the notes appear out of context and become meaningless.

·        From the free text we have no clue whether that's a book, catalog, periodic journal, or article in any of these. Each literature source is embedded in the painting data, not shared between paintings. So I could map it to Document or Information object, but there cannot create more elaborate structure.



# i.e. all but the last one. We show the 3rd one since it has both entry and exit

# <begindatum_in_collectie> : object entry in collection

<obj/2926> crm: P111i_was_added_by <obj/2926/collection/3/entry> . # range crm: E79_Part_Addition

<obj/2926> crm: P30i_custody_transferred_through <obj/2926/collection/3/entry> . # range crm: E10_Transfer_of_Custody

<obj/2926> crm: P24i_changed_ownership_through <obj/2926/collection/3/entry> . # range crm: E8_Acquisition


  crm: P110_augmented rkd-institution: WillemV ; # domain E79_Part_Addition

  crm: P29_custody_received_by rkd-institution: WillemV ; # domain E10_Transfer_of_Custody

  crm: P22_transferred_title_to rkd-institution: WillemV ; # domain E8_Acquisition

  crm: P4_has_time-span <obj/2926/collection/3/entry/date> .

<obj/2926/collection/3/entry/date> crm: P82_at_some_time_within "1768" ^^xsd: gYear .


·                   Better P82a/b. Otherwise temporal queries become a nightmare!

·        Disagree:

·                   For display purposes it’s important to retain the original info (P82 only vs P82a+P82b)

·                   Because P82a/b are declared sub-properties of P82, we always ask for P82 and it works out beautifully:
where (<start> <= crm:P82_at_some_time_within and crm:P82_at_some_time_within <= <end>)

·                   Be careful: transfer of title is not implied per default by entering a collection! Do the source data allow for that assertion? Otherwise delete the property.

·        Yes, in this case Prince Willem V has obtained both custody and title.

·        In another case they differ:
# It is peculiar since the owner (Rijksmuseum, Amsterdam) is different from the keeper (Mauritshuis, The Hague).
# Rijksmuseum bought it in 1816 but gave it to Mauritshuis for keeping, where it has been ever since.
#   <bruikleen_naam> loan giver name: OWNER (has title)
#   <collectienaam> collection name: KEEPER (has custody)

·                   Collapse instances of E79,E10,E8 into one instance!

·        They are one instance <obj/2926/collection/3/entry>, and these 3 classes are implied by the incoming and outgoing properties. The comments simply explain why the 6 properties can be used.

·                   Here you can enter the date of Identifier assignment!

·        We have identifiers only from the last keeper. Prince Willem V did not assign any identifiers.


### Former (historic) facts:

# custody->keeper, Acquisition(title)->owner, collection.location->location

# We should do this even if <begindatum_in_collectie> is missing, since <collectie> itself implies them


·                   This is a bad argument: The question if an event should be represented has nothing to do with the question if any date is known. Even if the context does not imply a date you must model the event, because a) there are other inferences about events and b) some other source may know the date. For instance, the lifetime of the acquisition owner is a P82 for the acquisition, and the acquisition is a “has met” for the participants….

·        I make exactly the argument that we should record, even if begin_date is missing



# i.e. the last one.

# It is peculiar since the owner (Rijksmuseum, Amsterdam ) is different from the keeper (Mauritshuis, TheHague).

# Rijksmuseum bought it in 1816 but gave it to Mauritshuis for keeping, where it has been ever since.

#   <bruikleen_naam> loan giver name: OWNER (has title)

#   <collectienaam> collection name: KEEPER (has custody)

# Got it? If not, read again and do not proceed until you get this!


# <begindatum_in_collectie> : object entry in collection

<obj/2926> crm: P111i_was_added_by <obj/2926/collection/5/entry> . # range crm: E79_Part_Addition

<obj/2926> crm: P30i_custody_transferred_through <obj/2926/collection/5/entry> . # range crm: E10_Transfer_of_Custody

<obj/2926> crm: P24i_changed_ownership_through <obj/2926/collection/5/entry> . # range crm: E8_Acquisition


  crm: P110_augmented rkd-institution: Koninklijk_Kabinet_van_Schilderijen_Mauritshuis ; # domain E79_Part_Addition

  crm: P29_custody_received_by rkd-institution: Koninklijk_Kabinet_van_Schilderijen_Mauritshuis ; # domain E10_Transfer_of_Custody

  crm: P22_transferred_title_to rkd-institution: Rijksmuseum ; # domain E8_Acquisition

  crm: P4_has_time-span <obj/2926/collection/5/entry/date> .

<obj/2926/collection/5/entry/date> crm: P82_at_some_time_within "1816" ^^xsd: gYear .


·                   Add identifier assignment here….

·        There is no evidence they were assigned at the time of acquisition (1816), so we should not use the same event.

·        As for whether we should record the assigning Agent, see discussion about priref on top


<obj/2926> crm: P54_has_current_permanent_location rkd-plaats: Amsterdam .

  # Mariana discovered the meaning of P54: location of the owner:

  #  "The object may be temporarily removed from the permanent location,

  #  for example when used in temporary exhibitions or loaned to another institution.

  #  The object may never actually be located at its permanent location."

  # Vlado thought it's location of the keeper, but stands corrected


·                   Better do not “discover meaning” of properties ;), but read the definition of the CRM. The RDFS is NOT the definition of the CRM!!

·        With so much volume it sometimes takes some discovering J . Of course, RDFS cannot add meaning



# <tentoonstellingen>

<obj/2926> crm: P12i_was_present_at <obj/2926/exhibition/1> .


  crm: P2_has_type rst-event: exhibition ;

  a crm: E7_Activity ;

# <> page and catalogue number

  crm: P3_has_note "pp. 196-199 25"@nl ;

# <titel_tentoonstelling> exhibition title

  crm:P1_is_identified_by <obj/2926/exhibition/1/name>.

<obj/2926/exhibition/1/name> crm:P3_has_note "Rembrandt: De meester & zijn werkplaats - schilderijen"@nl.


·                   Be careful not to put notes on the wrong side, or complement them adequately: the note “ "pp. 196-199 25"@nl will appear out of context ! Compose a note by adding the inventory number of the object and attach it to the exhibition event. Or add the exhibition event to the note and add it to the object.

·        This note is attached to the exhibition event <obj/2926/exhibition/1>

·        In addition to data, we display field names (using RForms templates), something like this, which I think is clear:

·        Exhibition name               Rembrandt: De meester & zijn werkplaats - schilderijen
Page and catalogue number               pp. 196-199 25

·        The inventory number (issued by the owner or custodian) has nothing to do with the catalog number (issued by the exhibitor), and will not clarify things



<obj/2926/acquisition/1> crm: P2_has_type rst-event: auction ;

# <veilinghuis_zc_nw> auction house

# P11 since the seller and buyer are the most important P14

<obj/2926/acquisition/1> crm: P11_had_participant <obj/2926/acquisition/1/house> .


·                   No:   crm:P14 carried out by . Auctionists retain enough money, and organize the transfer.

·        DID . Note: P22,P23 both imply P14, so all of auctioneer, buyer and seller will be related through P14.


# Given the stupid value, it's doubtful it's from a thesaurus

<obj/2926/acquisition/1/house> crm: P3_has_note "veilinghuis onbekend" @nl. # "unknown auction house" @en


·                   In that case, the mapping may better omit the whole link. Never produce “unknowns”, except there is more knowledge about the thing from the particular context, such as the seat of the company etc.

·        Agree in general, but I don't want to veer off into interpreting stupid notes to figure out they mean nothing.


# <veilingtitel> auction title

<obj/2926/acquisition/1> crm: P1_is_identified_by <obj/2926/acquisition/1/name> .

<obj/2926/acquisition/1/name> crm: P3_has_note "Collectie Snijers" @nl.

·                   Better use rdf:label


# <lotnummer> lot number

<obj/2926/acquisition/1> crm: P48_has_preferred_identifier <obj/2926/acquisition/1/lot> .

<obj/2926/acquisition/1/lot> crm: P2_has_type rst-identifier: lot_number ; crm: P3_has_note "15" . # in quotes, since it may not be an integer


·                   Better use rdf:label. I believe P48 does not offer any advantage over P1. Type “lot_number” is enough.

·        Yes, when there's a sole identifier, it's a matter of taste whether you call it "preferred"

·        For display purposes it makes no difference, and "lot number" is the important indication

·        For search purposes it would make a difference only if someone wants to search "by preferred identifiers only" which is far-fetched

·        The difference is very small anyway, since P48 implies P1

·                   May be the overall auction should be a super-event of the acquisition “nr. 15”?

·        That would be the more appropriate elaborate modeling, but each auction is embedded in one painting record (auctions are not shared between paintings), so there's no point.


# auction price

<obj/2926> crm: P39i_was_measured_by <obj/2926/acquisition/1> .

<obj/2926/acquisition/1> crm: P40_observed_dimension <obj/2926/acquisition/1/price> .


  crm: P2_has_type rst-currency: ; # qudt also includes unit: CurrencyUnit but not HFL

# <munt> monetary unit

  crm: P91_has_unit rst-currency: HFL ; # qudt doesn't have HFL (Holland Florin, old style Netherlands currency)

# <bedrag> amount of money

  crm: P90_has_value 157 .


·                   Well, I’d prefer a P3_has_note. The CRM still lacks a model of business transactions as exchange, but it is neither a focus of cultural-historical reasoning. Avoid dimensions, if you have no evidence that someone will query for value ranges for a reasonable search problem.

·        The MFPMFP project (whose PM is the RS "senior client" and on the steering board) has a need to track sales of broken-up compound objects (e.g. tryptichs) across Europe. Don't know if they'll want to display sale price and currency separately, but it seems prudent to save it in a structured way since we have it structured in the source DB. (E.g. maybe they'll want to filter by currency..)

·        I think the above is an appropriate model of representing "sale price".
I thought it should be "acquisition has_dimension price" (see email " ISSUE: "P43 has dimension" should apply to E1 Entity, not E70 Thing " of 18 Nov 2011).
But Stephen Stead vehemently argued that events should not be measurable.
So at the end I settled to this interpretation "acquisition measured object, observing dimension price"


### RESEARCH <link_research_record>

<obj/2926> crm: P12i_was_present_at <obj/2926/research/1> .

<obj/2926/research/1> a crm: E7_Activity ;

  crm: P21_had_general_purpose rkd-res_type: ;

# <research.type>

  crm: P2_has_type rkd-res_type: X-radiography ;

# <research.reason_objective>

  crm: P17_was_motivated_by rkd-res_obj: cat_Rembrandt_in_the_Mauritshuis_1978 .


·                   Could be a Condition Assessment

·        Yeah, but we don't have data to form any meaningful E3 Condition State, which is the most salient "sub-object" of E14 Condition Assessment




·                   Part-removal, Measurement/ Condition Assessment. In principle, the location of the sample taking could be modeled, but I cannot imagine a question: “Give me all events from the lower half of this painting” etc. Use better a P3 for that.

·        We could create Image Annotations from these, because we can locate  the exact spot (it says how many cm from the corner). But before that, we need to correlate Image Annotation to the painting itself (since sampling is on the painting itself).


### DOCUMENTATION <link_documentation_record>

<obj/2926> crm: P70i_is_documented_in <obj/2926/document/1> .

<obj/2926/document/1> a crm: E31_Document, crm: E84_Information_Carrier ;

  # a document is a conceptual object (E31).

  # But because the db also speaks of its location, it also has a physical embodiment (E84)

  # I don't think it's wrong to mix the two, since they have common parent crm:E71_Man-Made_Thing

  # TODO: M.Doerr 23-Nov-2011: "impossible combinations like E18-E28"

  crm: P128_carries <obj/2926/document/1> ; # the physical document (E84) carries its conceptual self (E31)

# <doc.type>

  crm: P2_has_type rkd-documentation: X-ray_film ;


·                   It’s not wrong to identify a digital object with a URL as a representative. If you take something to be E18-E28 simultaneously, you must be sure in the future you will never have to distinguish between two carriers of the same thing. The reason is not that E71 is a common parent – I cannot be a lion either – the question is if the lifecycles of the information and the carriers mess up or not on the conflated instance. Good ontological distinction are all about behavior.

·                   So, as long as the X-Ray film, the E18, is used as only source of the information, everything works fine. If you digitize the film, then it may become messy, but if digital representations are regarded to “show features of” the original, we do not run into a problem with the E18-E28 compound.

·        All good points, and well taken. I agree that "common parent" is not a strong argument, yet I'm relieved that E18-E28 don't have to be disjoint.




  crm: P9i_forms_part_of <obj/2926/research/1> ;

# TODO: P9 or P10_falls_within? The research includes other activities, not only doument creation, so maybe P10


·                   P9, not P10! P10: “I broke my glasses putting the object under the X-Ray scanner….”

·        ok


## FILE that has "<file.application>http"

<obj/2926/document/6> crm: P70i_is_documented_in <obj/2926/file/3> .

<obj/2926/file/3> a crm: E31_Document ;

# <file.application>

   rso: P3_has_url "" .


·                   If you want to start reasoning about the last copy available, for instance for Digital Preservation, then you may better identify a URL with an E18. Otherwise, take the document as immaterial.

·        This particular one is a digital-born document.


## FILE that has <file.image>

<obj/2926/document/6> crm: P138i_has_representation <obj/2926/file/6> .

<obj/2926/file/6> a crm: E38_Image ;

   rso: P3_has_image_file "mh0147_back_nl_2002.jpg" ;

# <file.spec.object_status>

  crm: P2_has_type rkd-objectstatus: BEFORE_TREATMENT ;


·                   I would not create a type “BEFORE_TREATMENT”. Link treatment and image creation by P119 or P120.

·        Disagree: we don't have any data about conservation/treatment, so it seems an over-complication to create two "empty" events (Image Creation and Treatment) and link them using the appropriate Allen temporal operator. Certainly the user will more readily understand the thesaurus labels (before/during/after) rather than having to analyze the property linking two events.


Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.