Workshop 3: Geographies and networks of style and subject matter

Team members:Weixuan Li, Richard Zijdeman, Liliana Melgar, Ivo Zandhuis, Hugo Huurdeman, Thijs Boers


Links to the RKD and Wikidata enable us to harvest large amounts of data (including images) on works of art. In theory this provides us with an opportunity to create huge geographies and social networks of style and subject matter. In this workshop we will explore the practical feasibility of such an operation and discuss its theoretical and methodological implications.


The assignment to provide a geographical represenation of Subjectmatter (the topic type of a paining, e.g. portrait or landscape) seemed fairly straightforward:

  • determine a relevant period in time;
  • retrieve all painters
  • retrieve all painters' works:
    • and their time of creation;
    • and their location of creation;
    • and their subjectmatter. Next, aggregate the result by geographic location. As a baseline we used the period 1630-1660 and naively assumed that in more urban areas portraits would be more common, while in rural areas landscapes were more common.

First attempt:

We started out by eyeballing the Ecartico database webinterface, specifically a certain person called Rembrandt Harmensz. van Rijn. From this page, it became obvious that while there were no specific works of art, there was a 'Attribute' table which had a category called 'Subject of Painting' with attributes like 'Landscape' or 'Portrait'. We also notice that for these attributes dates were missing, but we reasoned, we could always aggregate our way around that.

In recipe format we aimed to:

  • retrieve all persons born < 1610 && died > 1640
  • with occupation "kunstschilder"
  • count number of attributes by place (actually place-type: urban/rural, which we figured out to do some way or another)

However, we quickly noticed that the whilst the subject matter of painting categories are visible in the Ecartico database webinterface, they were not in the linked data/RDF version of the data (not added yet to that dataset).

Despite this we would like to share two queries. The first retrieves all persons born before 1610 and who have died after 1640. The query is an exemplifies how to work with 'dates' in SPARQL and can be executed directly via Yasgui and grlc. The latter also allows you to generate an API or to colloborate on the query. The queries are extensivly commented, so you'll get a feel what of each line in the query is doing.

The second query, we would like to share is the one occupation, specifically the occupation of 'painter'. Obviously painters come in all types, some producing fine art, others fine buildings. The creator of the Ecartico database, therefore created an 'overall painter' occupation, that has specific subclasses, like 'fine arts painter' or 'house painter'. We can thus ask for the 'subclasses' of 'painter' to retrieve all relevant paint jobs (pun intended). This annotated query shows you how that's done, and ofcourse it's also available via grlc.

Unfortunately this is how far we got with the 'Ecartico-only' approach, as it appeared that the Attribute data on paintings available from the webinterface, did not make it to the rdf representation of the database. But one of the great assets of the Ecartico database is that it has multiple person identifiers from other databases, so we can retrieve information on the Ecartico persons from those other databases.

Second attempt

So one obvious choice for retrieving information on artists is the RKDartists database. Unfortunately, we chose poorly. To explain why, we need to expand a little on the difference between a unique ID and a uri. To get the easy stuff out of the way: a unique ID is a unique number or combination of characters that identifies a specific person, event, object, etc. For example, Hendrik Willem Mesdag is identified by the number '55468' in RKDartists. URI's are a bit like unique ID's and a bit different. The purpose of URI's is the same: to unequivocally represent a specific entity, e.g. a person like Mesdag. Now because, someone else in the world might also be counting things there could be another entity that is identified by the number '55468'. A uri, looks like a web-address and immediately solves this problem. RKDArtists uses the uri Moreover the people hosting the database have made sure if you click on this link, it redirects to the webpage on Mesdag.

So, we can use this identifier, or 'permalink' as its called on the RKDartists website, to identify a particular person. Let's see whether we can find Mesdag at the SPARQL endpoint for RKDartists. We, again provide an annotated query via Yasgui or grlc.

Those with a keen eye may now have discovered why we got stuck. The Ecartico database went through great length to adopt the RKDartists uri's and adopted those, for example for Mesdag: However, the Linked Data representations of RKDartists provides a different uri for the same person: Thus the identifier in the Linked Data representation is different from the original database. Clicking on the identifier also redirects to a different database. So there is no way for us to retrieve data on RKDartists, since the identifiers differ between the datasets.

Really no way? Well not quite. For example, we could have created a mapping table, made link data out of that, could have loaded that to an endpoint of our own and then have written a federated query. We could also have filtered out the unique ID from both URI's and match results based on that, a computing intensive query. With less than 20 minutes on the clock, we chose to press on and pursue a final dataset.

Second approach Use RKD to derive painting subjects of artists in the same period Problem 1: Identifiers/URIs in Ecartico do not correspond anymore with actual RKDartists URIs (though the number in the URL is still the same) Solution 1: create a TTL script which maps the new URI to the new one Third approach Use Wikidata to derive the genres of paintings Query:

Third attempt



or from endpoint:

PREFIX wd: <>
PREFIX wdt: <>
PREFIX xsd: <>
PREFIX owl: <>
PREFIX schema: <>
PREFIX rdf: <>
PREFIX rdfs: <>
  ?person a schema:Person ;
                schema:birthDate ?birthDate ;
        schema:deathDate ?deathDate ;
        schema:name ?personName ;
        schema:workLocation/schema:workLocation ?place .

    ?occType rdf:type schema:Occupation ;
      rdfs:label "painter"@en ;
      owl:superClassOf* ?paintersAndSuch .

   ?person schema:hasOccupation/schema:hasOccupation ?paintersAndSuch .
   ?paintersAndSuch rdfs:label ?occupationalTitle .

  FILTER (?birthDate < "1630-01-01"^^xsd:date)
  FILTER (?deathDate > "1640-01-01"^^xsd:date)
  FILTER (lang(?occupationalTitle) = "nl")

  ?person owl:sameAs ?archiveID .
  FILTER regex(?archiveID, "", "i")
   SERVICE <> {
   # ?archiveID wdt:P31 wd:Q5 ; # look for human
   ?archiveID wdt:P136 ?genre. }


results matching ""

    No results matching ""