The previous post detailed (without going into code) how I imported the Tate’s metadata into a Neo4j database, and that is still a work in progress. And the Tate metadata is only the starting point. I plan on adding many more node types as I develop an overall social media platform with elements of crowdsourcing and gamification. However, there is already some highly-connected data to play around with. While most of the queries I can run on this data using Neo4j’s Cypher language could also be done using SQL, I can still do some interesting discovery in a very visual way – a way which SQL doesn’t lend itself to.

Example 1: Shortest paths between the artists William Johnstone and John, Augustus, OM (not sure how to rearrange that particular name).

What’s returned in visual format by the Neo4j browser is the following graph (you really need to click on the image to expand it):

The code snippet allshortestPaths((a1)-[*]-(a2)) retrieves all paths with a length equal to the length of the shortest path. In this case there are actually 570 possible paths with a length of 4 involving 82 separate nodes and 267 relationships.

Visually, we can immediately see what links the two artists. That they might have something like paper, oil paint and canvas in common is not a surprise or particularly useful, but that they share hope, cloud, tree and hill might be interesting.

The Cypher query is pretty dynamic. I don’t need to specify the types of nodes (using their labels) in between the two artists. With SQL, I would need to specify all the tables I wanted to join in the query.

It would be entirely possible to do this one in SQL in a relational database using multiple joins. It would likely be slower to run, though, and would lack the visual element of the CypherQL query. Just look at the MATCH criteria:

The (a) in the middle are the artists we want to match. We go in 2 directions from the artist: to the place of birth and to the subject via the artworks. SQL isn’t as semantically rich, lacking the arrows / connectors of CypherQL.

Example 3: Some recommendations.

Though the social aspect of the platform has yet to be developed, and it’s from this that much of the recommendation engine will be based on, we can make some initial additions to the artists and artworks recommendation engine. For example, if we were viewing an artwork featuring a bridge (let’s go with “Oriana”), we may be interested in other artworks featuring a bridge.

There are, however, 3,742 other artworks featuring a bridge, so you can see that the algorithm is a bit simplistic so far.

We could increase the connectedness of the current artwork and recommended artworks. For example, what about ones that share the same movements? We can extend the previous example (i.e. we are currently viewing the artwork Oriana which features a bridge).