Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current  |   View Page History

Notes from May-Jul 2013


Lec: (Our mapping) is same as Dominic's manual (to best of our understanding)
Vlado: Does it comply with BM's latest changes to modeling Association codes (esp re Acquisition, Production)? BM Association Mapping v2. Dominic's document probably reflects this, but these are recent changes and I haven't checked.

YCBA uses the following systems:

  • BededWork = calendaring
  • TMS = art collections
  • Drupal = website, exhibitions etc
  • Orbis = books etc

Getting Yale On-board

Lec: If there is something else you need to get this to work with Research Space please let me know
Vlado: Once it's compliant, we should:

  • try loading the data
  • load your thesauri. Complete Getty or only the subset used by your objects? How about Broader terms?
  • implement Image Annotation over your DeepZoom images (we use IIP Image for RKD images, while you use IIIF)
  • coreference some of your terms to enable cross-collection search
  • create RForms for your objects

See RS Plan 3.7#Get Yale on-board with ResearchSpace for details. As of 08-Jul-2013, this iteration is under planning and the exact scope and start is not clear. I think we can get Yale on board before mid-Sep (the Getty meeting), but it depends on the exact scope.

It appears that Yale is not the bottleneck: starting the RS3.7 iteration is. So please let's not rush this review process!


Please don't use color or strikethrough, use the following symbols for easier tracking (easiest to edit them in Wiki Markup mode):

  • open issue
  • resolved issue
  • issue under discussion


Lec: I am reviewing for any typos, missing types...

  • Have you tried Eyeball? See here: RDF Validation and Conversion#Eyeball
    Lec: We tried Eyeball, no luck have to contact dev community as we were not able to install it after number of tries. TBD..

General Problems

  • STRONGLY Suggest to have 1 URI per object, not 3 sameAs URIs
    Lec: BM has multiple, followed their lead
    Vlado: RS currently cannot work with these sameAs (eg would return results in triplicate). BM puts sameAs in separate files that we don't load
    Lec: we still need to figure this out (don't want to publish two data sets one for RS and one for the world) - not pressing low priority
    Vlado: this is high priority since RS cannot work with 3 sameAs URLs. And there's no good reason to publish your objects under 3 URLs: please explain why you want to do this
  • don't emit prefixes you don't need: lccn, oclc, ycba_aat, etc etc
  • crm:PX_* (e.g. crm:PX_display_wrap) is wrong, should be bmo:PX_*
    Lec: fixed with
    Vlado: Please use bmo:PX_* and not ycba:PX_*: don't create a second property with the same purpose.
  • Same holds about classes: use bmo:EX_Association not ycba:EX_Association: don't define your own class for the same purpose.


These issues are not about the mapping, but how RDF is presented by Pubby.
If you switch to Forest / OwlimWorkbench, they'll go away (and probably be replaced by different issues )

  • low prio Pubby prefixes are not setup: shows "?:..."
    Lec: does same for BM, will try to fix

Link to download Turtle file

I'm now getting actual RDF and Turtle files for the sample set on

Better to fix this on Pubby & VUFind:

Inverse links considered harmful

I cannot examine a URI like because pubby tries to show "is P51_current_keeper of" all objects and that takes forever.
Is there a way to switch these inverse links off?


Whole Getty or Parts


Currently you emit thesaurus data together with the object, and only the terms used in the object:

  • This way you miss Broader terms, so eg a search for "Animal" or "Mammal" won't find FR Transitivity
    • Lec: regarding Places, why don't we use Geographic Coordinates (included by Yale) and search by a bounding box?
    • Vlado: RS currently doesn't have bounding box search, because BM Places thesaurus doesn't include Geographic Coordinates.
      RS has place name search, that uses the place hierarchy.
  • This way you repeat data about the same term in many objects
  • If you start emitting objects in separate graphs like BM does (to be able to easily replace/delete), the term data will be duplicated in each of these object graphs
    As you can see already happens about YCBA itself:
    <> a crm:E74_Group , skos:Concept ;
      skos:prefLabel "Yale Center for British Art" ;
      skos:inScheme <> ;
      a crm:E74_Group , skos:Concept ;
      skos:prefLabel "Yale Center for British Art" ;
      skos:inScheme <> .
  • In several cases these in-object ad-hoc terms don't satisfy Thesaurus Requirements (see next section)

My strong recommendation is to export the complete Getty thesauri

  • we shouldn't wait for Getty to do an official mapping, since it'll take a few months for TGN and ULAN, and it won't satisfy the requirement to publish as CRM (see next section)
  • I can do this mapping. I'll also be involved in the Getty's mapping, so that's a good synergy
  • Getty's committed to publish as LOD, so hopefully they won't object, as soon as we mark our export as Unofficial
  • use a separate thesaurus export config, like BM does

Lec: I export terms within objects because they are present in the LIDO XML.
But to export the complete tehsauri, I would need to get someone to export from RDBMS, and we cannot do this right now


  • For the time being we'll stay without Broader terms
  • Dominic and Vlado to try to expedite the Getty export by Getty

Thesaurus Requirements

You must comply with BMX Issues#Thesaurus requirements
Each term should be both a CRM entity of appropriate type, and skos:Concept.

  • You have this for some (eg Agents) but not others (eg Title Type).


Each thesaurus (ConceptScheme) used by Yale should be described in Meta-Thesaurus and FR Names#YCBA Thesauri (this section will be merged to the rest of the table)

This applies to both Getty and YCBA local thesauri.

  • future extend RS to handle AAT as one ConceptScheme that includes a number of facets (hierarchies) for object type, material, technique, etc
  • Export AAT terms to scheme aat: and a different concept scheme per Facet. Use the actual AAT Facet (top-level) URL as concept scheme (I may be recommending something similar to Getty as well), but isolate in a prefix definition:
    @prefix aat:            <> . # all of AAT
    @prefix aat_objects:    <> . # Objects facet
    @prefix aat_materials:  <> . # Materials Facet
    @prefix aat_activities: <> . # Activities Facet, includes Processes and Techniques
    @prefix aat_periods:    <> . # Styles and Periods Facet
    <> skos:inScheme aat:, aat_objects:    . # paintings (visual works)
    <> skos:inScheme aat:, aat_materials:  . # canvas
    <> skos:inScheme aat:, aat_activities: . # oil golding
    <> skos:inScheme aat:, aat_periods: .    # British (modern)
    <> skos:inScheme aat:                  . # horses (animals). prefLabel=Equus caballus (species)

The last example (Agents Facet> Living Organisms> ... > horses) shows that there's no way to define a Subjects scheme narrower than aat: itself, because subjects can come from any AAT Facet. In particular, this branch (facet) is not enough:

@prefix aat_concepts:   <> . # Associated Concepts

You already do this for Technique but use a Yale URL for the scheme (may be ok for now, but need to change in the future)

aat:230058 a skos:Concept; skos:prefLabel "oil gilding";
  skos:inScheme <yale/thes/technique>.

Emmanuelle: It would be helpful to briefly go over the definitions for searchable and tagable.

  • Searchable is a thesaurus that can be used in FR search. The list of FRs is Meta-Thesaurus and FR Names#FR Names Table and the detailed definitions are FR Implementation. Examples:
    • BM Object is searchable using FR2_has_type "is/has/about" because it's mapped to P2_has_type of the object
    • BM Ware and BM Currency are searchable using the same FR because they are sub-properties of P2_has_type
    • BM Aspect is not searchable because it's P2_has_type of E55_Type of a E25 Man-Made Feature on the object (side of coin)
    • If IPTC code is similar to "subject", it should be searchable
    • BM Unit and BM Dimension are not searchable because they are attributes of a Dimension of the object, and there's no FR defined for dimensions
    • BM Place is searchable, even in a hierarchical way
    • BM Place Type (town, village) and BM Place Name Type (modern, archaic) are not searchable because FRs don't reach into the properties of a place
  • Taggable: whether the thesaurus is "interesting enough" to be used as a source of tags. Tags are general categories to be used for categorization of research questions and comments. See Tags Spec

Term Distribution

  • Yale: 99% of Yale terms come from TGN, AAT, and ULAN.
    1% of terms come from ODNB, IconClass, YCBA Local terms (Frames, ...)
  • Yale: example of a lesser known person (Elihu Yale) who's found in ODNB, VIAF, DBPedia but not ULAN:
    • Vlado: such "local heros" are a typical pattern for any museum. BM People also has "local heros" that are not found in ULAN.
  • Lec: will it be helpful if we make connections to ODNB, VIAF, DBPedia?
    • Vlado: yes, assuming you can easily export such term data according to Thesaurus Requirements. If you source it from these external sources, you'd need to make the same SKOS & CRM mapping as for the rest, and register in the Meta-Thesaurus.
      If these are indeed less than 1%, I'd source them from a single thesaurus YCBA Local.

There will be a meeting at Getty in September 2013, with 1/2 day discussion on Vocabularies

Term Code Discrepancy

Your LIDO has some AAT codes that are truncated compared to the original. Eg object/7:

The original codes are aat:300015050 and aat:300014078. I have seen the same for "oil gilding": "230058" vs aat:300230058.

You map "canvas" to a local term (instead of AAT), and skip "oil paint" altogether:

<> a crm:E57_Material , skos:Concept ;
  skos:prefLabel "canvas" ;
  skos:inScheme <> .

Don't know how this happened but it is crazy. Can you fix it in the conversion script?

Local Terms

don't export a term as "-1", eg

  • Lec: Emmanuelle, please have some students go through TMS, I exclude now anything that has -1
  • Lec: Emmanuelle, there are cases where subjects are TGN where conceptID=0, I will try to ignore. Example: object/34
  • Vlado: in chat Emmanuelle said "-1" come from Yale local terms. Then emit them as such, don't look them up in AAT.
    You absolutely must emit the local terms, else you'll be missing important data.


  • remove crm:E55_Type: a Group is not a Type
    <thesauri/nationality/British> a crm:E55_Type , crm:E74_Group , skos:Concept ;
  • SKOS says one prefLabel (per language). If you don't have a flag in TMS, call the first one prefLabel and the rest altLabel
    <person-institution/142> a crm:E21_Person , skos:Concept ;
    	skos:inScheme ycba:person-institution ;
    	skos:prefLabel "Robert Smirke I" , "Robert Smirke R. A." , "Robert Smirk" , "Robert I Smirke" , "Robert Smirke" ;

    Lec: Awaiting Emmanuelle confirmation if subjectActor will have multiple names, currently not in LIDO
    Emmanuelle: yes a fair number of our subjectActor have alternate names in addition to their preferred names.

  • you don't have any date (P82_at_some_time_within) for <person-institution/142/birth/date>. This makes all the following statements useless, so kill them.
    Lec: we now have P82 and are taking into account both person and groups
    	crm:P92i_was_brought_into_existence_by <person-institution/142/birth> ;
    <person-institution/142/birth> a crm:E63_Beginning_of_Existence ;
    	crm:P4_has_time-span <person-institution/142/birth/date>
    • Same for death
  • If you know whether it's a person or institution then use the respective specific subprop & subclass instead of the generic P92i, E63:
    Person: P98i_was_born, E67_Birth
    Group: P95i_was_formed_by, E66_Formation

Lec: we have more variety in Person dates. Emmanuelle to provide some more examples

Lec: LIDO may not contain the correct data in the eraliestDate and latestDate in vitalRecord for all dates esp., most of these above are in Display, so I recommend we ignore for time being

Thesaurus URIs

  • Use more logical URIs that reflect the nature of the resource or type, and don't reflect their genesis in existing systems:
    <thesauri/event/exhibition_history> -> <thesauri/event/exhibition> (an exhibition is NOT "exhibition history")
    <event/some-exhibition/TMS/exhibition_history> -> <event/some-exhibition/identifier> (an identifier is NOT "exhibition history")
    <thesauri/identifier/TMS/exhibition_history> -> <thesauri/identifier/exhibition> (doesn't matter your system is called TMS)

    Lec: this may need further discussion, we may have other types of events with IDs from other systems, however made changes per suggestion
    Vlado: you have a point. If you have 2 exhibition IDs then you need to add the system acronym

Exhibition URIs

  • We need to make decision on URI for exhibition, originally we had a short identifier, BM suggested title, this does not always work well, eg see: ObjectID 34
  • Vlado: Yes, pretty long titles in
    Exhibition :: An American's Passion for British Art - Paul Mellon's Legacy, 2007-2008
    Exhibition :: Great British Paintings from American Collections: Holbein to Hockney, Thursday, September 27, 2001 - Sunday, December 30, 2001
    Exhibition :: J. M. W. Turner - A Selection of Paintings from the Collection of Mr. and Mrs. Paul Mellon, 1968-1969
  • RS doesn't care what the URI is
  • Lec: updated with standard ID based URIs

Getty URIs




Title Types

  • Why do you need these duplicate types?
    crm:P2_has_type <thesaurus/title/Alternate-title> , <thesaurus/title/alternate> .
  • I'm not sure what "Repository title" is. But if it means Preferred, then this is also unnecessary duplication:
    crm:P2_has_type <thesaurus/title/Repository-title> , <thesaurus/title/preferred> .
  • Emmanuelle: the capitalized title types talk about the purpose of the titles, not their ranking. Here are all title types possible: Alternate, Collective, Creator's, Exhibited, Foreign language, Former, Inscribed, Repository, Verso.
  • Emmanuelle: The lowercase title attributes (alternate and preferred) talk about the ranking/preference of the titles.
  • Can an object have different Repository title and Preferred title?
    Emmanuelle: no, all Repository titles are always the preferred ones. But the alternate titles are not all of the type Alternate.


  • CRM has no notion of "preferred title" (unlike P48_has_preferred_identifier)
  • RS prints the titles in order, together with the title type
  • Luckily Lec also emits rdfs:label equal to the preferred title, so we use that in result lists

I propose to merge the two sets of values because preferred/alternate is already covered by Repository/all-the-rest:

  • Emit "Preferred" instead of "Repository"
  • Emit the titles in order, the Preferred one first
  • Don't emit "alternate"
  • shorten the term URL a bit since the thesaurus URL already says "title":

Duplicate Titles

  • these two titles are duplicated. Keep just one of them: I suggest <title/1> for uniformity with the alternate title(s)
    <object/19850/title/1> a crm:E35_Title ;
      rdfs:label "Malvolio Dancing" ;
      crm:P2_has_type <thesaurus/title/Repository-title> , <thesaurus/title/preferred> .
    <object/19850/title/primary> a crm:E35_Title ;
      rdfs:label "Malvolio Dancing" ;
      crm:P2_has_type <thesaurus/title/Repository-title> , <thesaurus/title/preferred> .

Title Language

  • (optional) Indicate the title language:
    <object/19850/title/1> a crm:E35_Title ;
      rdfs:label "Malvolio Dancing"@en ;
      P72_has_language <thesaurus/language/english>.
  • Emmanuelle: we indicate the language of the titles only if they are in foreign language <thesaurus/title/ForeignLanguage-title>, and probably not consistently. All the other titles are understood as being in American English, the official language of the YCBA.
  • Vladimir: fair enough! So indicate language only for that type, and say it's translation of the Preferred one:
    <object/19850/title/N> a E35_Title;
      rdfs:label "Malvolio Danse"@fr ;
      P2_has_type <thesaurus/title/ForeignLanguage>;
      P72_has_language <thesaurus/language/french>;
      P73i_is_translation_of <object/19850/title/1>.

    (Actually it's more likely this is the original title, so you may want to use P73_has_translation instead of P73i)

Related Resources

List all URLs closely related to the object: web pages, LIDO XML, etc.
Eg for "Mrs. Abington as Miss Prue in Love for Love by William Congreve" this includes:

Representing Related Resources

An important question is how to represent these related resources and how to link them to the object. CRM doesn't have specific classes for "web page" or "XML record" but E31_Document is appropriate: "identifiable immaterial items that make propositions about reality. These propositions may be expressed in text, graphics, images, audiograms, videograms or by other similar means. Documentation databases are regarded as a special case of E31 Document." (Therefore a single XML record is also E31_Document). See document_references@crmg, reference@crmg

It's also nice to include the media type of these documents (dc:format).

  • for web pages that's "text/html"
  • for LIDO we use "text/xml". There's no registration for LIDO specifically, so we follow RFC 3023: XML Media Types: "If an XML document – that is, the unprocessed, source XML document – is readable by casual users, text/xml is preferable. Application/xml is preferable when the XML MIME entity is unreadable by casual users."


<> P70i_is_documented_in
  a E31_Document; dc:format "text/html"; P2_has_type <thes/document/home-page>.
  a E31_Document; dc:format "text/xml"; P2_has_type <thes/document/lido-xml>.
  a E31_Document; dc:format "text/html"; P2_has_type <thes/document/ydc-page>.
  a E31_Document; dc:format "text/html"; P2_has_type <thes/document/google-art-page>.

Optionally, you could add Creation records to state who created the above documents.

We already use E31_Document for Bibliography. For symmetry, we should add P2_has_type:

  crm:P70i_is_documented_in <>.
<> a crm:E31_Document ;
  P2_has_type <thes/document/bibliography>;
  rdfs:label "David Lee, Ladies of the Knight, Arts  Review, Vol. 47, May 1995, pp. 26-29, N1 A792 + (A & A)" .

The type terms mentioned above:

<thes/document/home-page> a E55_Type, skos:Concept; skos:inScheme <thes/document>;
   skos:prefLabel "Home page (VUFind record)".
<thes/document/lido-xml> a E55_Type, skos:Concept; skos:inScheme <thes/document>;
   skos:prefLabel "LIDO XML record".
<thes/document/ydc-page> a E55_Type, skos:Concept; skos:inScheme <thes/document>;
   skos:prefLabel "Yale Digital Collections Center page".
<thes/document/google-art-page> a E55_Type, skos:Concept; skos:inScheme <thes/document>;
   skos:prefLabel "Google Cultural Institute (Google Art) page".
<thes/document/bibliography> a E55_Type, skos:Concept; skos:inScheme <thes/document>;
   skos:prefLabel "Bibliography".

<thes/document> a skos:ConceptScheme; skos:prefLabel "Document Type".


Image Metadata

Yale keeps numerous image assets, and Yale ODAI provides extensive metadata about the images:

Description: I haven't read the documentation but here's what I see.

path/field eg description
X/derivatives/Y   X ranges over Image Views (0..M, 0 is Main View), Y ranges over Image Sizes (1,2,3,6,7)
./formatId 1 size id
./formatShort sm size name
./label Screen small size label
./url logical URL (request this)
./source physical URL (redirects to it)
./bucketDNS physical server
./bucketName physical server
./bucketPath 48/2f/482f519c-eebf-4596-819c-4c8197c4d3e5/ba-obj-7-0001-pub-sm.jpg physical path
./contentId 482f519c-eebf-4596-819c-4c8197c4d3e5 GUID
./filename ba-obj-7-0001-pub-sm.jpg file name
./unitAccessOnly false Only the Yale unit that created the image should have access
./cas false Login through CAS is required (campus-only access)
./captcha false protected by captcha? Only size 5 are
./format image/jpeg image format
./sizeBytes 33169 file size
./pixelsX 249 width
./pixelsY 186 height
X/metadata   describes Image View X
./caption cropped to image, recto, unframed enumerates Flags of the Image View
./source Yale Center for British Art credits
./imageCredit Digital Image: Yale Center for British Art credits
./webStatement redirects to
./usageTerms always same
./imageCopyrightNotice   always empty
./imageCopyrightMarked false always false
./assetId d70ae2b604a64bd24809441a5d24233a8d406925 another GUID
X/contentId 482f519c-eebf-4596-819c-4c8197c4d3e5 GUID, same as above


  • Are there other formats that we care about?
    • Lec: we only care about image/jpeg, image/tiff, image/jp2. In the longer future maybe pdf/a, mp3, mp4, 3D formats, TBD as they will have different viewers
  • What are unitAccessOnly and cas, and do we care?
    • Lec: Proxy, CAS, login + session ticket. We do care as Linked Data may not always be Open, we can have some LOD and some LD. I can imagine on the long run giving access to all data and those without access with only see LOD. For now you can ignore.
    • Vlado: Then these flags should be used to filter the dataset.
      If you publish something out, it becomes LOD even if your intent is for some of it to be non-open LD

Image URLs

ODAI has several URLs that redirect to the physical URL:

  1. Using object id:<objectId>/type/2/format/<Y>


    • Unfortunately such redirect is set only for the Main View (X=0) (I tried varying "type" but got nowhere).
      It's not suitable as a permanent URL, since if YCBA decides to remove one view from public access, all others after it in the sequence are promoted (decremented)
  2. Using repository name and filename:<filename1>/format/<Y>

    where filename1 is "filename" with "formatShort" chopped off and extension replaced with ".tif"

  3. Using ODAI GUID:

In the sections below we use these image aliases for brevity. In RDF the actual http URL should be used. Not a "made up" node with P1_is_identified_by pointing to the actual URL

Image Sizes

YCBA keeps images in many sizes. These sizes or "formats" are over 15 and include video, 3D models, etc.
The ones I've encountered for images are listed below ("width" is just an example):

url suffix size label width file use in RS
format/1 Screen small 250 jpeg result list thumbnail (or could use 2)
format/2 Screen medium 480 jpeg lightbox, object view, data basket preview
format/3 Screen large 1920 jpeg  
format/6 Print large 3000 tiff  
format/7 Zoom (JPEG 2000) 4279 jp2 This is the max available size. We don't use this URL for annotation since it serves the whole Deep Zoom Image

Deep Zoom Image

Many YCBA objects have Deep Zoom images (JPEG2000), sometimes even several per object.
Eg Miss Prue has:

This is an IIPMooViewer client using a Djatoka Adore IIIF server
(May 2013: IIP Server has beta support for the IIIF Image API)

RS implements Image Annotation over Deep Zoom images using the IIP Server protocol.
We need to implement IIIF support in RS Image Annotation, and multiplexing between IIP and IIIF

Image Metadata

Image Views

Image Views are different photographs of the same painting, using different modes (Flags).
Eg the lovely Miss Prue has 8 image views:

RS should display something similar on the Related Images tab (but not laid out in such an ugly way): all views, one format as image, all formats as links. See Image Derivation for the RDF data

Image Flags

The views have these comma-separated Flags:
0. cropped to image, recto, unframed (0 is always the Main View)
1. recto, unframed
2. framed, recto
3. framed, verso
4. detail, recto
6. detail, recto
6. Composite X-radiograph
7. cropped to image, recto, unframed

RKD has similar flags, broken into separate thesauri (BM doesn't have such flags):

  • area captured: overall, detail, from left, from bottom...
  • side captured: front, back
  • object status: before treatment, during treatment, after treatment
  • documentation type: X-ray film, action photograph, black and white detail photograph, black and white photograph, color transparency etc

Lec: these strings are not from a controlled thesaurus, so people can put anything.
Vlado: it still seems to me they are fairly consistent, so Yale represent this by breaking on space and making a thesaurus:
For now I think it's enough to lump them in one thesaurus, eg:

  PX_has_main_representation <>.
  PX_image_flag <yale/thes/image/flag/cropped_to_image>, <yale/thes/image/flag/recto>, <yale/thes/image/flag/unframed>.

<yale/thes/image/flag/cropped_to_image> a E55_Type, skos:Concept;
  skos:prefLabel "cropped to image"; skos:inScheme <yale/thes/image/flag/>.
<yale/thes/image/flag/recto> a E55_Type, skos:Concept;
  skos:prefLabel "recto"; skos:inScheme <yale/thes/image/flag/>.
<yale/thes/image/flag/unframed> a E55_Type, skos:Concept;
  skos:prefLabel "unframed"; skos:inScheme <yale/thes/image/flag/>.

Image Rights

YCBA doesn't claim copyright over any images, so we only need to point to a policy page.
See Object Rights for a more substantial discussion of public domain over copyrighted objects.

  • This has problems:
    <object/7/image/1> P104_is_subject_to <> # 0. has no fields
    <object/7/image/1> P70i_is_documented_in <object/7/image/1/terms_of_use>.  # 1. should be P104_is_subject_to
    <object/7/image/1/terms_of_use>                     # 2. not specific to this image, so don't use per-image node
      rdfs:label ""; # 3. should be URI not string, 4. this redirects, just use the final destination
      rdf:type crm:E62_String.                          # 5. means nothing. So-called "CRM Primitive types" should not be used
  • simply use this:
    <object/7/image/X/format/Y> P104_is_subject_to <>. # 6.
    <> a E30_Right; rdfs:label "See link for details".
    • don't use rdfs: label for an URL (label should be a readable string).
      <> a crm:E30_Right ;
      	rdfs:label "" .

      If you like you can make this an E42_Identifier, though I don't see what use that URL is

      <> a crm:E30_Right ;
        P48_has_preferred_identifier <>.
      <> a E42_Identifier.


  • All webStatement and usageTerms are the persistent link which redirects to
    • Lec: for now yes, but in the long run this may not be the case. This comes from Image Metadata (from Digital Asset Managment), so if YCBA's imaging/rights manager changes it, it will be reflected in this metadata
    • Vlado: ok, in that case different images could have different P104_is_subject_to.
    • Vlado: I don't see the benefit of using a "persistent link" since it is unreadable. The "image-use" URL doesn't say "public" or "copyrighted" so it doesn't reflect any policy, but at least it says what it is about. If you want to change the policy, just change the text on the page. This is in no way worse than redirecting the "persistent link" to a different URL
  • Emmanuelle: I have some contextual information regarding my modeling for image rights that might help, since we are doing things a bit differently from the BM on this I believe.
    • Vladimir: indeed, BM claims rights (eg images\assets_0.trig):
        crm:P138i_has_representation <>.
        crm:P105_right_held_by thesIdentifier:the-british-museum.
    • Emmanuelle: YCBA does not claim rights over images, just points to image use page, hence P70i_is_documented_in rather than P104_is_subject_to. YCBA does not say who owns the image rights.
    • Vladimir: My example above (6) says the image P104_is_subject_to a Rights object, which allows unrestricted usage. See the scope note to be convinced this is the right class to use: "This class comprises legal privileges concerning material and immaterial things". It doesn't say YCBA holds any rights.
    • Emmanuelle: OK, I see that P104_is_subject_to is good even when no image restrictions apply. Then let's use P104_is_subject_to

Image Representation

(See image aliases in the Image URLs table)

  • The correct properties to use are:
    <object/7> bmo:PX_has_main_representation <view0/format2> . # Main View
    <object/7> P138i_has_representation       <view1/format2> . # other views
    <object/7> P138i_has_representation       <view2/format2> . # ...
  • both of these are wrong, see image_objects_carriers@crmg
    <object/7> P62_depicts <object/7/image/1> .
    <object/7> P65_shows_visual_item <object/7/image/1> .

    Explanation: a thing (E24) can show many visual items (eg an inscription and a couple of images).
    But when you take a photo of a painting (E1), you create a unique Image (E38) that represents the painting.

  • No need to repeat since bmo:PX_has_main_representation is subprop of P138i_has_representation:
    P138i_has_representation       <view0/format2>
    bmo:PX_has_main_representation <view0/format2>

Image Derivation

We connect only format2 directly to the object (PX_has_main_representation or P138i) and declare all formats derivatives thereof (P130i).
This is a trick required by RS, so it can show only one format on screen, and provide links for the rest (as in Image Views):

<object/7> bmo:PX_has_main_representation <view0/format2> .
<view0/format2> P130i_features_are_also_found_on <view0/format1>, <view0/format2>, <view0/format3>, <view0/format6>, <view0/format7>.

<object/7> P138i_has_representation <view1/format2> .
<view1/format2> P130i_features_are_also_found_on <view1/format1>, <view1/format2>, <view1/format3>, <view1/format6>, <view1/format7>.


Image Creation

  • this is wrong
    <object/7/image/1> P108i_was_produced_by <object/7/image/1/creation>.   # images are conceptual, so use P94i_was_created_by
    <object/7/image/1/creation> P14_carried_out_by <object/thesauri/actor>; # Created by whom? If you have no info, don't output Creation
      rdf:type crm:E12_Production.                                          # E12_Produciton is for material objects
    • Emmanuelle: I was trying to express the fact that the image is supplied/was made by YCBA, hence P108i_was_produced_by.
    • Vladimir: ok, but use the correct type and properties for Image (a conceptual object), and YCBA's URL:
      <viewX/formatY> P94i_was_created_by <viewX/creation>.
      <viewX/creation> a E65_Creation; P14_carried_out_by <thesauri/ULAN/500303557>.

      Image Metadata shows that all derivations (formats) share the same source&imageCredit, but each view has individual source&imageCredit.

Image RDF

Tying it all together, this section defines the RDF mapping for images.

  • The first image view is the Main representation
  • We provide MIME type and pixel size using the same vocabularies as SharedCanvas: DC and EXIF, but skip filename and sizeBytes
  • We create subproperties of P2_has_type for various image characteristics
# Prefixes
#prefix crm:  <> .   # assumed by default below
@prefix dc:   <> .   # Dublin Core Elements
@prefix dct:  <> .          # Dublin Core Terms
@prefix exif: <> . # EXIF vocabulary
@prefix bmo:  <> .
@prefix rdfs: <> .
@prefix skos: < > .

# Properties
bmo:PX_image_flag   rdfs:subPropertyOf P2_has_type; rdfs:label "Image Flag"; rdfs:comment "eg recto, verso, cropped, X-Ray".
bmo:PX_image_format rdfs:subPropertyOf P2_has_type; rdfs:label "Image Format"; rdfs:comment "eg Small, Medium, Large".

# Thesauri
<yale/thes/image/flag/>   a skos:ConceptScheme; skos:prefLabel "Image Flag".
<yale/thes/image/format/> a skos:ConceptScheme; skos:prefLabel "Image Format".

# Terms
<yale/thes/image/flag/cropped_to_image> a E55_Type, skos:Concept;
  skos:prefLabel "cropped to image"; skos:inScheme <yale/thes/image/flag/>.
<yale/thes/image/flag/recto> a E55_Type, skos:Concept;
  skos:prefLabel "recto"; skos:inScheme <yale/thes/image/flag/>.
<yale/thes/image/flag/unframed> a E55_Type, skos:Concept;
  skos:prefLabel "unframed"; skos:inScheme <yale/thes/image/flag/>.

<yale/thes/image/format/sm> a E55_Type, skos:Concept;
  skos:prefLabel "Screen small"; skos:inScheme <yale/thes/image/format/>.
<yale/thes/image/format/med> a E55_Type, skos:Concept;
  skos:prefLabel "Screen medium"; skos:inScheme <yale/thes/image/format/>.
<yale/thes/image/format/large> a E55_Type, skos:Concept;
  skos:prefLabel "Screen large"; skos:inScheme <yale/thes/image/format/>.
<yale/thes/image/format/print-lg> a E55_Type, skos:Concept;
  skos:prefLabel "Print large (CAPTCHA protected)"; skos:inScheme <yale/thes/image/format/>.
<yale/thes/image/format/JP2000> a E55_Type, skos:Concept;
  skos:prefLabel "Zoom (JPEG 2000)"; skos:inScheme <yale/thes/image/format/>.

# Objects/Images
  PX_has_main_representation   <view0/format2>;
  crm:P138i_has_representation <view1/format2>.

# main view, main format
<view0/format2> a E38_Image;
  bmo:PX_image_flag <yale/thes/image/flag/cropped_to_image>, <yale/thes/image/flag/recto>, <yale/thes/image/flag/unframed>;
  P104_is_subject_to <> ;
  bmo:PX_image_format <yale/thes/image/format/med> ;
  exif:height 480 ; # is xsd:integer
  exif:width 359 ;
  dc:format "image/jpeg" ;
  P94i_was_created_by <view0/creation>;
  P130i_features_are_also_found_on <view0/format1>, <view0/format2>, <view0/format3>, <view0/format6>, <view0/format7>.

# other formats
<view0/format1> a E38_Image;
  bmo:PX_image_flag <yale/thes/image/flag/cropped_to_image>, <yale/thes/image/flag/recto>, <yale/thes/image/flag/unframed>;
  P104_is_subject_to <> ;
  bmo:PX_image_format <yale/thes/image/format/sm> ;
  exif:height 249 ;
  exif:width 186 ;
  dc:format "image/jpeg" ;
  P94i_was_created_by <view0/creation>.
# format3,6 are similar and differ only by size and dc:format

# Deep Zoom format. Same as above, with an extra statement
  a E38_Image;
  bmo:PX_image_flag <yale/thes/image/flag/cropped_to_image>, <yale/thes/image/flag/recto>, <yale/thes/image/flag/unframed>;
  P104_is_subject_to <> ;
  bmo:PX_image_format <yale/thes/image/format/JPEG2000> ;
  exif:height 4279 ;
  exif:width 3201 ;
  dc:format "image/jp2" ;
  P94i_was_created_by <view0/creation>;
  # It's on an IIIF server. Statement suggested by Michael Appleby
  dct:conformsTo <>.

# view0 Creation event (shared by all formats)
<view0/creation> a E65_Creation;
  P14_carried_out_by <ulan/500303557>; # lookup "source" in thesaurus
  rdfs:label "Digital Image: Yale Center for British Art". # imageCredit

# other views: similar, only Image Flags are different
<view1/format2> a E38_Image;
  bmo:PX_image_flag <yale/thes/image/flag/recto>, <yale/thes/image/flag/unframed>;
  P104_is_subject_to <> ;
  bmo:PX_image_format <yale/thes/image/format/med> ;
  exif:height 480 ;
  exif:width 438 ;
  dc:format "image/jpeg" ;
  P94i_was_created_by <view1/creation>;
  P130i_features_are_also_found_on <view1/format1>, <view1/format2>, <view1/format3>, <view1/format6>, <view1/format7>.

# view1/format1,3,6,7: same as above

# view1 Creation event (shared by all formats)
<view1/creation> a E65_Creation;
  P14_carried_out_by <ulan/500303557>; # lookup "source" in ULAN thesaurus
  rdfs:label "Digital Image: Yale Center for British Art". # imageCredit
  • Denote pixels as xsd:integer.
    Turtle allows a short way:
      exif:height 480 ; # is xsd:integer
      exif:width 359 ;

    If you prefer to use quotes, then you need to put the type explicitly:

    	exif:height "186"^^xsd:integer ;
    	exif:width "249"^^xsd:integer ;


Couple issues here:

  crm:P62_depicts <> , <> ...;
  crm:P62_depicts <> , <> ...;
  bmo:PX_display_wrap "Subject :: transportation" , "Subject :: workers" , "Subject :: boats"...;
  crm:P128_carries <> .
  a crm:E73_Information_Object ;
  crm:P129_is_about <> , <>...
  1. concept/1 is a useless intermediate node. Look at image_objects_carriers@crmg. According to VUFind, the places are Represented on the painting, which carries a Visual Object. So you should use P138 which is stronger than P129: but then you may as well use the shortcut P62_depicts. So it boils down to:
      crm:P62_depicts aat:55244, aat:25886...

    If you use P62 for the Subjects, why not also use P62 for the Places?
    BM didn't have that luxury since not all of their objects carry an Image, and not all Subjects are "represented": some are merely "about".

  2. (minor) Print out the Places in a PX_display_wrap
  3. image/X: don't use such made up nodes, use actual image URLs. See Image RDF


See Iconclass#IconClass Use at YCBA:

  • Emit P129 for each use
  • Emit Iconclass term data


  • The YCBA director does not want to publish which person gave up the object.
    Emmanuelle: Right now, we absolutely cannot publish who were the previous owners of our objects, no matter if they have passed or not.
  • This means you can skip E8_Acquisition altogether, since YCBA is stated as current owner and keeper. Kill this:
    <object/19850/acquisition> a crm:E10_Transfer_of_Custody , crm:E8_Acquisition ;
      crm:P22_transferred_title_to <thesauri/ULAN/500303557> ;
      crm:P29_custody_received_by <thesauri/ULAN/500303557> ;
      rdfs:label "Yale Center for British Art, Paul Mellon Collection" .
    • If not: format the label as "Transferred to ..." (now it reads as an Agent, not as a Transfer)
  • P30_transferred_custody_of is wrong direction
    Lec: Replaced with P30i_custody_transferred_through

YCBA sub-orgs

  • The acquisition label (and the Credit Line facet here) show that there are several "sub-orgs" (or sub-collections) under it: Paul Mellon Collection, Paul Mellon Fund, Gift of Mr. and Mrs. J. Richardson Dilworth, B.A. 1938, etc.
    If it's important to preserve this information in RDF, you could create sub-agents under YCBA, eg like this:
    <person-institution/ycba_mellon_collection> a E74_Group, skos:Concept;
      skos:inScheme <person-institution/>; rdfs:label "Yale Center for British Art, Paul Mellon Collection" ;
      skos:broader ulan:500303557; P107i_is_current_or_former_member_of ulan:500303557 .
    <person-institution/ycba_dilworth_gift> a E74_Group, skos:Concept;
      skos:inScheme <person-institution/>; rdfs:label "Yale Center for British Art, Gift of Mr. and Mrs. J. Richardson Dilworth, B.A. 1938" ;
      skos:broader ulan:500303557; P107i_is_current_or_former_member_of ulan:500303557 .

Current Owner, Keeper

  • If YCBA is incorporated, use E40_Legal_Body instead of the more generic E74_Group:
     <thesauri/ULAN/500303557> a crm:E74_Group , skos:Concept ;
      skos:prefLabel "Yale Center for British Art" .
  • This is probably wrong, it should describe the specific sub-organization (department):
      crm:P50_has_current_keeper <> ;

    If you don't have departments, say that YCBA is the keeper.

Current Location

You currently use per-object place representations. Such places are not searchable since they're not in a thesaurus.

<> a crm:E53_Place ;
	rdfs:label "Bay25" . # UnitType
<> a crm:E53_Place ;
	rdfs:label "401" .   # SubSite
<> a crm:E53_Place ;
	rdfs:label "Yale Center for British Art" . # Site
<> a crm:E53_Place ;
	rdfs:label "New Haven" .  # Geo location


  • it probably doesn't make sense to put location/1 and location/2 in a thesaurus, so they are correctly per-object. But add something to the label to explain what they mean. If there's a hierarchy between them and the coding won't get too complicated, something like this could be best:
      rdfs:label "Storage unit: Bay25, shelf: 401"
  • location/3: YCBA is an organization. Here you mean "the place of that org", which is a known conundrum. Since you already say "YCBA is current owner/keeper", just skip
  • location/4: A city is a well-known place, so just use the respective TGN URI

Object Rights

Public Domain

The majority of works in YCBA's collection are in the Public Domain. For example:

  • view:
    • shows "Public Domain"
    • images are available in various Image Sizes
  • Image Metadata:
  • RDF: has some problems:
      PX_has_copyright "Public Domain"; # 1. Unnecessary since you have it structured. To output a string, use PX_display_wrap
      P104_is_subject_to <>. # 2. Public Domain is the same, so shouldn't be per object
    <> a E30_Right;  # 3. Use CC, since CC is a stronger authority about PD than YCBA
      P2_has_type <>; # 4. Shouldn't be per object.
      P3_has_note "Public Domain".
  • Use this:
      PX_display_wrap "Rights :: Public Domain";
      P104_is_subject_to <>.
        # See and
        # Another option is CC0, see
    <> a E30_Right;
      rdfs:label "Public Domain Mark".


There are some objects that are copyrighted. Let's consider one:

  • view:
    • shows "© Estate of the Artist"
    • images are available only in Small size
  • Image Metadata:
    • webStatement and usageTerms are the same as for Public Domain. It was explained: "YCBA makes no assertion of copyright nor any denial of copyright we may have in our photograph/digital image of the underlying artwork". But YCBA restricts to Small size images only
    • images are available only in Small size (format/1). As the policy explains: "Thumbnail-sized images of copyrighted works are displayed under fair use".
      If you try a bigger format, you get nothing, eg:
    • imageCopyrightMarked is "", which means different from "false"

    This has various problems: legalBodyName/appellationValue is a proclamation not name, legalBodyWeblink is a name not url, legalBodyID is a proclamation page not organization's URL. But at least the data is present

  • RDF: has many problems:
      PX_has_copyright "© Estate of the Artist"; # 1. Unnecessary since you have it structured
      P104_is_subject_to <>.
    <> a E30_Right;
      P105_right_held_by <>; # 2. Hardcoded won't do
      P2_has_type <>; # 3. Shouldn't be per object
      P3_has_note "© Estate of the Artist".
    <> a E55_Type;
      rdfs:label "under copyright";
    <> a E39_Owner; # 4. No such type
      skos:prefLabel "Anna Katrina Zinkeisen", ... # 5. Many prefLabels to the same URL won't do
        "Estate of Anna Katrina Zinkeisen", # 6. (minor) This and the previous one should have been correlated
        "Estate of Augustus Edwin John",
        "Estate of C. R. W. Nevinson", ...
        "Transport for London", ...
        "Unknown rights administrator", # 7. Just don't emit any P105_right_held_by
        "Yale Center for British Art" # 8. For known organizations, use AAT terms
  • Use this:
      PX_display_wrap "Rights :: © Estate of the Artist";
      P104_is_subject_to <>.
    <> a E30_Right;
        # If it's known in AAT (eg YCBA, Transport for London), use the AAT term.
        # If it's in a local thesaurus, use the local term <id/person-institution/X>
        # If it's "Unknown rights administrator", skip P105_right_held_by altogether
        # ONLY if you need to make one on the fly, use this:
      P2_has_type <>;
      P3_has_note "© Estate of the Artist".
    # Only if you need to make an owner on the fly:
    <> a E39_Actor;
      rdfs:label "Henrietta Garnett".
    # redirects to this. I don't see the benefit of using a handle
    <> a E55_Type;
      rdfs:label "Under copyright".


When and why to use <obj/production/M/association> a ycba:EX_Association
That's defined by the specific sections in BM Association Mapping v2. The Intro section describes 3 patterns: code in Event, code in Subevent, code in Association, and the specific sections say which to use for which part of your data

  • No point using BOTH Subevents (parts) and EX_Association

Produced By Specific Process

Emmanuelle: What do I do for the following crm:P14_carried_out_by association codes? Do they become types or labels?
Vlado: These are all types of Production sub-events, because they pertain to the nature of the production process. See BM Association Mapping v2#Produced By Specific Process for the pattern:

  • AR-Artist
  • AU-author
  • FB-finished by
  • M-maker
  • R-printer (printed by)
  • PM-printmaker (print made by)
  • Z-publisher (published by)
  • TU-touched up by (print)

BTW: if you have just 1 code, it would be nice to optimize and not create sub-events, but BM doesn't do that

Formerly Attributed To

object/7: "Formerly attributed to Benjamin Williams Leader" is mapped without any mention of "Formerly attributed":

<> a crm:E12_Production ;
  crm:P14_carried_out_by <> .

Unknown Artist

postponed Some records say "production performed by Unknown Artist".

  • Lec: removed unknown artists, this will need to be communicated with Emmanuelle, she has some reservations about it. In effort to get our data to work with RS I made the change.
  • Vladimir's considerations:
    • RS is agnostic about this
    • CONS: If you say 10 paintings are made by Unknown Artist and use the same term, that's false because they may have been made by different people.
    • CONS: The sem web way of expressing that some info is missing is simply NOT to say anything.
    • PRO: if you want to search in RS for "paintings with Unknown creator", you can do it when mapped to an Unknown person or Unknown group. But you cannot currently search for "paintings that don't have creator info"
  • Ken: Interesting conundrum about "Unknown" but it seems to be exactly as we know the world in traditional data. If one searches simply for Unknown, one does get everything Unknown, and we realize the works are not all by the same maker and that isn't a problem because we understand that Unknown is a class not an individual.
  • Dominic: I am not sure that a person URI should refer to a generic 'unknown' which would be the same unknown person. Generally, if something is unknown it shouldn't have a triple. The absence of a triple means that it is not known. Producing triples that state a null doesn't seem useful. Is there a particular reason for specifically stating that an artist is unknown? A query for an object created in the 18th century, in the french style and that was produced by the technique of sculpting would return the result in the example. Further, if the person was unknown then you couldn't assume that s/he was French. In other words if there is a way to query to get the result required without a null then this seems preferable.
  • Emmanuelle: I agree with Ken. 'Unknown creator' for an art historian carries meaningful information. It is not synonym with a null value (of course since all works of art have creators). Rather it means that the attribution research has not come up with conclusive information for now, and that situation can last for many years even centuries.
  • Ken: Such a search however is usually combined with limiting qualifiers like "Unknown French 18th-century sculptor." Being unable to search in that fashion seems to me the much more limited option.
  • Vladimir: You can express "French" and "Sculptor". Here's how the BM thesauri are modeled:
      a crm:E21_Person, skos:Concept;
      skos:inScheme id:person-institution;
      skos:prefLabel "Alfonso Ruspagiari";
      bmo:PX_gender <>;
      bmo:PX_nationality <>;
      bmo:PX_profession <>.

    Nationality and Profession are modeled as Groups (Gender is not, it's merely a Type):

      bmo:PX_gender rdfs:subPropertyOf crm:P2_has_type .
      bmo:PX_nationality rdfs:subPropertyOf crm:P107i_is_current_or_former_member_of .
      bmo:PX_profession rdfs:subPropertyOf crm:P107i_is_current_or_former_member_of .

    In RS the search relation (FR) "created by" is transitive over P107i_is_current_or_former_member_of.
    So if you search by "French" or "scupltor" you'll find objects created by the respective nationality or profession.
    If the artist is unknown, you can still say that the E74_Group "French" and the E74_Group "scupltor" P14i_performed the Production, and the same searches will work.

  • Vladimir: As for "18th century": RS cannot currently search by dates of the creator (life and flourit), but it can search by creation dates, which I think is "close enough".

Closely Related Group

  • Emmanuelle: I think it would make sense to model 'unknown artist' as a group because it is a denomination that actually contains many different entities (all unknown artists are not the same), and also because traditionally when we speak we create a short cut but we actually cannot be sure that 'unknown artist' is only one artist for a work of art.
    • The National Gallery has grappled with this as well and models 'Unknown Artist' as a sub-group of E74:
      The production of a particular painting (E84) was carried out by an Unknown Artist (E21) who was known to be part of the EN41.Artist_Sub_Group of a known/individually defined Master (E21)
    • I have represented this logic in the attached graph. On the model of the NG I have also moved Circle of, Studio of and Workshop of to be Production association codes for E74_Group.
      YCBA Production2 unknown creator.pdf

  • Vlado: this closely follows BM Association Mapping v2#Production by Closely Related Group, and it's more faithful modeling than before. But it has implications for Search that need to be discussed with BM.
    Need to track the discussion at BM Association Mapping Problems#Closely Related Group.
  • Vlado: not all these codes are the same, and they map to different CRM constructs. I would group the NG codes as follows:
  • Some of these are subject to debate. Eg BM mapped two codes that sound similar to me onto different patterms:
    AJ: Circle/School of: BM Association Mapping v2#Production by Closely Related Group
    S: School of/style of BM Association Mapping v2#Influenced By
  • Ken: Interesting conundrum about "Unknown" but it seems to be exactly as we know the world in traditional data. If one searches simply for Unknown, one does get everything Unknown, and we realize the works are not all by the same maker and that isn't a problem because we understand that Unknown is a class not an individual.
    • Vlado: That's ok for this search case, as used by a person. But still there's a falsehood in the RDF, that all these paintings are by the same person. If you want to e.g. investigate painting similarity, this will trip you up. IMHO to avoid spurious unification, an Unknown should not be a known term or URI. Could be a blank (URI-less) node, which is by definition unique.
  • Emmanuelle: traditionally when we speak we create a short cut but we actually cannot be sure that 'unknown artist' is only one artist for a work of art.
    • Vlado: Exactly!
  • Vlado: seems to me there are different degrees of unknown that may need different modeling, e.g.:
    1. has 2 records:
        <object/7/production/1> crm:P14_carried_out_by <id/person-institution/1180> . # Formerly attributed to Benjamin Williams Leader
        <object/7/production/3> crm:P14_carried_out_by <unknown> .

      This says there were 2 painters, one is B.W.Leader and the other Unknown: which does not reflect the actual situation (there is 1 painter!)

    2. In another case there may be actual evidence of 2 producers (e.g. Rembrandt and someone unknown from his Workshop).
  • Vlado: The simplest solution could be to just mark with a flag "there's significant unknown info about the producer".

Curatorial Comment

  • Yale: PX_curatorial_comment needs date and author added to the data model
  • Vlado: easy to tackle with EX_Association, which is is a subclass of E13_Attribute_Assignment (see attribute_assignment@crmg and recorder@crmg):
      <obj> bmo:PX_curatorial_comment "comment".
      <obj/comment/1> a bmo:EX_Association;
        P140_assigned_attribute_to <obj>; P141_assigned "comment"; bmo:PX_property bmo:PX_curatorial_comment;
        P14_carried_out_by <researcher>;
        P4_has_time-span <obj/comment/1/date>.
      <obj/comment/1/date> P82_at_some_time_within "2013-07-06"^^xsd:gYear.
    • you could alternatively use P3_has_note instead of PX_curatorial_comment, to accommodate apps that know CRM and EX_Association but not PX_curatorial_comment. But I still think using the subproperty is better


Please include TTL samples with Inscription info.

  • Represent like this (a small part of mark_inscription@crmg)
      P65_shows_visual_item <>,
    <> a E34_Inscription;
      rdfs:label "Inscribed in black on proper left inside flap: [word BOOTS circled]";
      P2_has_type <thes/inscription/inscription>.
    <> a E34_Inscription;
      rdfs:label "Signed and dated on proper left inside flap: "2001 | SARAH LUCAS";
      P2_has_type <thes/inscription/signed-and-dated>.
    <thes/inscription/inscription> a skos:ConceptScheme;
      skos:prefLabel "Inscription Type".
    <thes/inscription/inscription> a E55_Type, skos:Concept;
      skos:prefLabel "Inscription"; skos:inScheme <thes/inscription/>.
    <thes/inscription/signed-and-dated> a E55_Type, skos:Concept;
      skos:prefLabel "Signed and Dated"; skos:inScheme <thes/inscription/>.
    <thes/inscription/marks> a E55_Type, skos:Concept;
      skos:prefLabel "Marks"; skos:inScheme <thes/inscription/>.
    <thes/inscription/lettering> a E55_Type, skos:Concept;
      skos:prefLabel "Lettering"; skos:inScheme <thes/inscription/>.
  • Inscription, Signed and Dated and Lettering should all be mapped to E34_Inscription


Marks are different: unlike E34_Inscription, E37_Mark is not a subclass of E33_Linguistic_Object (see cidoc_class_hierarchy@crmg) so they should not include label/transcription.
Eg object/14670 has LIDO:

and should be mapped to

<> P65_shows_visual_item
  <>. # "mark" would be more accurate but will complicate the mapping
<> a E37_Mark;
  rdfs:label "Paul Mellon collector's mark";
  P2_has_type <thes/inscription/marks>. # could skip since it says nothing more than E37_Mark
  • Emmanuelle: What about when the data only says ‘watermark’ or ‘stamp’?  Since it is not a transcription of the mark per se, do we still model as if it were a transcription?
    • Vlado: I think it would be too hard to determine from the word whether that's a true inscription, or a curator's description of a mark. So I suggest to rely on lido:type alone: map Marks to E37_Mark, and the other 3 types to E34_Inscription

Not Marked

"not marked" should be ignored (emit nothing), eg object/41229:

  • Emmanuelle: Two other similar fields are problematic in our data: Signed and Inscriptions.  They are problematic because, on the model of the marks field above, they record both the transcriptions of the signatures and inscriptions as well as the fact that we may have searched for a signature and inscription on a work but did not find any and consequently these fields may carry the value: not signed, not dated, no inscription.

    The variations on these 3 values are multiple, unfortunately (not inscribed,…)  In order to not emit administrative data about signatures and inscriptions (not signed, not dated, no inscription), we would need to filter out all of these variations
    • Vlado: I see the difficulty. Ok, let's not do such filtering, and just emit the strings as they are. (Semweb says not to record missing facts, but here you've recorded the fact that you searched for it and none was found)
  • all Signed and Inscriptions values that do not contain “”.  The double quotation marks are a sure sign that a transcription is recorded.  Is it possible?
    • Vlado: I think that giving meaning to punctuation is too brittle: maybe some curators didn't use them, or used slightly different punctuation...
      I say cancel this whole section


You state object dimensions (including their properties):

	crm:P43_has_dimension <> ;
	crm:P43_has_dimension <> ;
  • But you omit lido:extentMeasurements, i.e. don't state what was measured:
  • If you have data with lido:qualifierMeasurements, we should also consider it
  • I assume "Support (PTG)" is a (semi-)controlled value, so better make a term:
      P39i_was_measured_by <>.
    <> a E16_Measurement ;
      P2_has_type <thes/measurement/Support-PTG> ;
      P40_observed_dimension <> ,
        <> ;
      rdfs:label "12 1/16 x 16 inches (30.6 x 40.6 cm). Extent: Support (PTG)" .
    <thes/measurement/Support-PTG> a skos:Concept, E55_Type;
      skos:inScheme <thes/measurement/>;
      skos:prefLabel "Support (PTG)".


This ain't mapped: object/7:

Yale uses the field lido:culture and a term from the AAT Styles and Periods facet.
Previously we mapped BM's Period/Culture field to crm:E4_Period (see BMX Issues#Specific CRM Constructs and again BMX Issues#Period/Culture).
These are slightly different concepts but closely related, so the mapping is correct:

  • LIDO: culture: "culture, cultural context, people, or also a nationality"
  • AAT: Styles and Periods: "names of art and architecture styles, historical periods, and art movements. Names of cultures, peoples, individuals, and sites are included only if they designate styles or periods (e.g.g., Yoruba, Celtic, Louis XIV). Geographic descriptors are included only for broad cultural regions and nations."
  • CRM: E4_Period: "sets of coherent phenomena or cultural manifestations bounded in time and space. It is the social or physical coherence of these phenomena that identify an E4 Period and not the associated spatio-temporal bounds."

Map to:

<object/7/production/1> crm:P10_falls_within aat:300111159.
aat:300111159 a skos:Concept, crm:E4_Period;
  skos:inScheme aat: , aat_periods: ;
  skos:prefLabel "British".

The scheme is defined in Meta-Thesaurus.
Depending on a tech decision you may have to emit only aat_periods: and skip aat: )

Material and Technique

lido:termMaterialsTech has 3 types:

  • support (eg laid paper, wove paper, canvas)
  • medium (eg graphite, watercolor, oil paint, gold leaf)
  • technique (eg etching, mezzotint, original gilding, oil gilding)

Do you know of any other types?

You seem to map only "support". Maybe related to Term Code Discrepancy. Map all of them:

  • support and medium (AAT Materials facet) to P45_consists_of (E57_Material)
  • technique (AAT Processes and Techniques facet) to P32_used_general_technique (E55_Type)

For example:

    aat:300011914, # wood
    aat:300264831. # gold leaf
    aat:300230058, # oil gilding
    <thes/technique/original_gilding>. # original gilding

Object Type and Genre

Object Type and Genre (lido:objectWorkType) are missing, eg

  • There is a term for the 1st but it's not connected to the object.
  • You try to make a term for the 3rd but seem to look it up in the wrong thesaurus (it's local not AAT):
    <> a crm:E55_Type , skos:Concept ;
    	skos:inScheme <> ;
    	skos:prefLabel "architectural subject" .

Represent "Object name" as "type" (P2_has_type) and "Genre" as "subject" (P62_depicts):

  P2_has_type <>; # painting
  P62_depicts <>; # landscape
      <>. # architectural subject

<> a skos:Concept, E55_Type;
  skos:inScheme <>;
  skos:prefLabel "architectural subject".
  • Note1: BM has defined subprops of P2_has_type: PX_object_type, PX_ware (for pottery), PX_escapement (for clocks). But so far I don't see a need to do this for YCBA
  • Note2: don't be confused like me that "landscape" above means "painting in landscape orientation", which is a subtype (describes is-ness of the object).
    It means "a landscape is painted", as you can see in Abstract Landscape (Dark Fir Shoreham II Morning) which is in portrait orientation


  • Indicate the collection for each object, see collection@crmg
    <object/7> P46i_forms_part_of <id/collection/prints-and-drawings>.
    <id/collection/prints-and-drawings> a E78_Collection; rdfs:label "Prints and Drawings".
    • this won't let the user search by Collection since FR search doesn't concern collections.
      BM maps this to "department" (Agent) and the user can search by "keeper/owner".


LIDO XML has a field <lido:classification> that's similar to <lido:objectWorkType>. LIDO defines them like this:

  • objectWorkType: The specific kind of object / work being described.
  • classification: Concepts used to categorize an object / work by grouping it together with others on the basis of similar characteristics. The category belongs to a systematic scheme (classification) which groups objects of similar characteristics according to uniform aspects. This grouping / classification may be done according to material, form, shape, function, region of origin, cultural context, or historical or stylistic period. In addition to this systematic grouping it may also be done according to organizational divisions within a museum (e.g., according to the collection structure of a museum).

Which leaves me a bit puzzled how to map "classification": object type or "sub-collection".

  • I wrote a little script to extract these 2 fields from Yale data:
    code: Invalid value specified for parameter lang
  • For many Yale objects, objectWorkType and classification are the same (painting, scuplture, frame, etc)
  • For some objects (4 of 13) there are differences:
    object ObjectWorkType classification n
    4005 999 No ObjectWorkType for Record 300041273 Print 1
    15206 300033973 drawing; 300078925 watercolor 300033973 Drawing & Watercolor 2
    19850 300033973 drawing 300033973 Drawing & Watercolor 3
    21890 300041338 intaglio print 300041273 Print 4
    57163 300255019 cake; 300047090 sculpture 300047090 Sculpture 5

Analysis of the differences:

  1. Missing ObjectWorkType but Classification exists.
    Object type is a fairly important field, so it's not very good for it to be missing.
    If ObjectWorkType=999, use Classification for P2_has_type
  2. and 5. Several ObjectWorkTypes, Classification reflects just one of them.
    Perhaps Corresponds to interpreting Classification as "sub-collection".
  3. ObjectWorkType and Classification are the same, just that a different label "Drawing & Watercolor" has been used
    (the official AAT label is "drawings (visual works)")
  4. ObjectWorkType is a sub-division of Classification.
    Corresponds to interpreting Classification as "sub-collection"

As described in the prev section, none of these terms is connected to the object in RDF.

  • Check whether lido:classification is always consistent with the collection (eg classification="Sculpture" is always found in "Paintings and Sculpture")
  • Map lido:classification to a sub-collection (1)
    <object/57163> P2_has_type aat:300255019, aat:300047090; # cake, sculpture.
        <id/collection/sculpture>, # (1) comes from Classification
        <id/collection/paintings-and-sculptures>. # (2) comes from Collection
    <id/collection/paintings-and-sculptures> a E78_Collection; rdfs:label "Paintings and Sculptures".
    <id/collection/sculpture> a E78_Collection; rdfs:label "Sculpture";
      P46i_forms_part_of <id/collection/paintings-and-sculptures>.

If Classification is consistent with Collection then statement (2) is redundant because P46i_forms_part_of is transitive

Collections and Object Types

The above sections are written after examining a few Paintings only.
But YCBA has other object types (Prints, Drawings, Sculpture, Paintings, Frames, even Cakes!), for which the mapping could be slightly different.

  • : collection that is out of scope for now
    Eg see MARC21 and OAI_DC records for a book
  • Lec to include various object types in the samples

collection count search, browse
Paintings and Sculpture 2226 search browse
Prints and Drawings 48968 search browse
Rare Books and Manuscripts 15392 search browse
Reference Library 33173 search browse
Frames 1376 search browse

The available Search fields and Classification vary by collection

Paintings and Sculpture

  • Search fields:
    Subject Terms:
    Places Represented:
    Accession Number:
  • Classification:
    Painted Object
    Sculpture (and TODO)


Interesting example: a cake: VUFind, LIDO

  • Object name: cake, sculpture
    OK Object Type and Genre
  • Genre: portrait
    OK Object Type and Genre
  • Classification: Sculpture
    OK Classification
  • eventMaterialsTech: "Inkjet on iced fruitcake plus cardboard box"
    OK Material and Technique
    • technique: printing, ink jet
    • support: cardboard
    • medium: fruitcake
  • subjectConcept:
    • boxes (containers)
      NOK P62_depicts, since it includes a box as part of the object, it's not about boxes (is not about).
      But I don't see how we can recognize this as a part, given that it's mapped to subjectConcept
    • portrait
      OK P62_depicts
    • genre subject
      OK P62_depicts

Emmanuelle: Contemporary art always brings up challenging cataloguing and intellectual issues.
The cake titled 'Boots' is a 2001 work by Sarah Lucas, a contemporary British artist.  It is effectively a cake with an inkjet portrait of the artist on it (think edible frosting!) contained in a box.
Inside the box lies this rather intriguing inscription: "Cake (2001): a series of 12 iced fruit cakes with inkjet images. Each cake is an edition of 25. Produced by Cakes Direct, Ilford, Essex. This signed box certifies the authenticity of the artwork contained within. It must accompany the work through any changes of ownership. | Edition number 20/25 [hand written] Date 2001[hand written]" The inscription is followed by the signature of the artist.  So in fact the work of art 'Boots' is not only the cake, but the cake within the box. They cannot be separated. That is why we catalogued 'boxes (containers)' as a subject term.

Prints and Drawings

  • Search fields:
    Subject Terms:
    Places Represented:
    Accession Number:
  • Classification:
    Brass Rubbing
    Drawing & Watercolor
    Drawing & Watercolor-Architectural
    Drawing & Watercolor-Miniature
    Drawing & Watercolor-Sketchbook
    Paint Box
    Rare Book


  • search fields
    Style: (eg "Provincial Rococo"; Neoclassical; "Louis XIV style")
    Ornament: (eg acanthus; cartouche; rocaille)
    Accession Number:
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.