Posts on the design, development and use of Sembl Museum.


Screenshot of The Museum Game sliding scale of interestingness. A convict love token is connected to Mary Gilmore's typewriter with the resemblance 'anti-establishment: he's a highway robber; she's a radical socialist poet

Cultivating conceptual propinquity

Dialogic thinking doesn’t only mean taking into account two different perspectives; it also means recognising the common ground between entities – what it is that makes them one. This post is a note about game mechanics to cultivate conceptual propinquity.

In Sembl games, players form associations between pairs of objects or concepts. Evaluating others’ moves according to a sliding scale of interestingness provides for a great gamey dynamic. It’s fun, and about as open and social a contest as you could imagine.

Screenshot of The Museum Game sliding scale of interestingness. A convict love token is connected to Mary Gilmore's typewriter with the resemblance 'anti-establishment: he's a highway robber; she's a radical socialist poet

Screenshot from the Museum form of Sembl showing the sliding scale of interestingness.

More importantly, the mission to associate, and the challenge to be interesting – both invoke and honour dialogical play, sparking all manner of logical and analogical associations between nodes. In aggregate, those associations form a new big picture of the networks we inhabit, which in turn can help us to communicate better via machines.

But to operate optimally, Sembl needs an additional filter.

Sembl’s true power lies in its capacity to surface similitude – links that are mutually applicable, or bi-directional. Such links do not make a comparison; they unite.

Having now observed dozens of games played at the Museum, I notice that players often deviate from my purist approach, and create links in the form of this-whereas-that, associating the pair by way of an opposition or a third element. Such moves can be highly humorous and thereby interesting, but asymmetrical links do not serve the purpose of drawing disparate objects and concepts together, so their interest is more fleeting. Asymmetrical linked data is also, as I have ranted earlier, subjective, sometimes objectionable – even authoritarian.

The act of perceiving a resemblance between things conceptually distant elicits understanding of important hidden-in-plain-sight patterns. A sense of connectedness – or the overview effect – is insightful and can fill us with wonder at the beauty and fragility of the Earth. Such a perspective can also yield understanding of the structures that divide us.

Beyond its liberatingly loose notion of interestingness, Sembl needs to surface higher-value, propinquitous links – those with a centripetal force – those that specify the nature of a similitude. I’m therefore thinking that… Players should be able to mark down links that don’t work both ways.


Thinking linking – Sembl data

Because Sembl will be a system for generating data, I’ve been worrying about how we can ensure that the data it generates is well-structured so that it is machine-readable and thereby linked to other data and reusable in aggregation. But because both linked open data (LOD) and Sembl itself are all about relationships, whenever I try to think it through my thoughts become tangled.

In this post I attempt to order my thoughts around linked data as it pertains to Sembl – specifically, I seek a better understanding of entities, identities and similitude. Whoa. We had better start with a picture.

This is a cannon in the collection of the National Museum of Australia. If you look at our information about the cannon,  you can see that it was:

and that there are various dates associated with it:
  • made circa 1725–50
  • used 1768–70
  • jettisoned 11 June 1770
  • salvaged 1969

It would be great if all those references – to the Endeavour, Cook, the Great Barrier Reef and all those dates – were linked to all the other references to those things on the web. Then, you could find out much more about the boat, the person, the place and the time.

That is the dream of linked data – to enable machines to recognise an entity wherever it is mentioned on the world wide web.

So what does it require of us as a web publisher or as a designer of a system for generating online data? Any time we publish a chunk of web content, we should bundle in with the publication a set of pointers to relevant places, times, people and organisations associated with the entities mentioned in that content. In this way, we forge a link between our mention of Captain James Cook and all his other mentions elsewhere on the web. Tools for doing this do exist, but they remain curiously rare. (Try searching for a WordPress plugin that adds linked data to your blog content.)

But actually, identity-tracking is only one part of the LOD dream; there are many kinds of relationships other than ‘is the same as’. Imagine if there was a universally comprehensible language for describing the various relationships one entity has with other entities.

In my description, the cannon was

  • ‘on board’ the Endeavour
  • ‘used by’ Cook
  • ‘jettisoned’ on the reef

But it could just as easily have been

  • ‘part of’ the Endeavour
  • ‘owned by’ Cook
  • ‘thrown onto’ the reef

How do we know how to cite the relationship so that the machines can parse it as we would want? That’s where ontologies and RDF triples (or quads!) come into the picture – whenever the relationship between two entities is more complex than ‘[x] [is the same as] [y] (according to [z])’. But that’s also where it becomes tricky to link data. We need a common vocabulary to describe and to arrange relationships that are not necessarily common or even clear to one person – let alone a global population!

There are many different ontologies out there and emerging; but so far none works especially well for museum objects. In fact, as I write this, there are discussions going on about sharing vocabularies for LODLAM (aka linked open data in libraries, archives and museums) as a step toward a shared understanding.

It’s difficult to imagine a single system for describing objects that would be universally agreeable. And as Tim informs me, the point is rather to connect the vocabularies rather than settle on one. But here’s a thought-stream about primary elements of museum object relationships: we would probably want to identify the object’s relationships to

  • people: ‘created by’, ‘used by’, ‘owned by’
  • places: ‘created at’, ‘used at’, ‘stored at’, and
  • events: ‘associated with’ – although vague, that concept seems important for museum objects whose potency is often by association with significant people or events
  • activities: ‘used during’ or ‘used for’
  • other objects: ‘made of’, ‘type of’, ‘part of’, ‘contains’, ‘used with’, ‘replaced’, ‘prototype of’

And so on. Although perhaps anything much more than that is more trouble than it’s worth? (I don’t know!)

And… Sembl data?

In the case of Sembl, data that players generate is intrinsically linked: the challenge of the game is to find a way in which one object relates to another. As a player you might draw on the machine-readable ‘other objects’ links; but if you relied solely on them, you might not fare very well in the game because to win points the relationship has to be ‘interesting’ – as defined by the other humans playing the game.

You might improve your chances if you identified a less direct relationship through a series of steps through the linked data. For example, you might find out that the seed object was used by someone who was the daughter of someone who was integral to an event that is represented by an object that you then select to play in the game. But that’s still a machine-like relationship and therefore a bit… uninteresting.

Part of the game’s awesomeness is that players generate new kinds of relationships – relationships that fit no predetermined ontological structure and which, sometimes, make you think differently. One key to this novelty is that players forge connections not from one thing to another but from one facet of a thing to another facet of another thing.

Triad of images and the resemblances between them

Whaleboats and thylacine are not intrinsically linked; the link coalesces between a particular facet of each thing. Players identify (describe) those facets as part of the game, as illustrated above.

As well as faceted, connections can be figurative or playful. In one game the above Thylacine ‘puppet’ was linked to a Welsh organ because the former is organ-less. In another game, 10-year-old children linked the Welsh organ to a set of convict leg irons because both work with keys.

Imagine trying to develop an ontology that worked for all those different linguistic twists. It would be as mind-melting as that Chinese animal taxonomy that Borges described; and it would be ever inadequate. Similitude resists containment.

So… Sembl and linked data?

After all this thinking – and the above is a lot clearer, I believe, than the crazy diagram I made when I started thinking this through – I reckon: we should not worry about creating linked data within the Sembl app. We should, however, endeavour to do the following:

  • Make the Museum’s collection database do the work of adding linked data about entities mentioned in the description of collection objects. (That’s big, and well beyond me and my Sembl project; but the wheels are in motion.)
  • Find a way to link representations of collection items created during gameplay to their entry in the collection database. (Again, this will not be easy although Tim’s object type browser might be a valuable first step.) Maybe the game app can award extra points to teams that link their proposed object to its authoritative Museum representation.
  • Capture the descriptive and relational information that players generate and connect it to the relevant fields in the collection database. So in the collection database, each object that has been used in Sembl will have player-generated descriptive and relational augmentation.

Those, then, are my thoughts – de-fuzzed to a degree by what felt like some strenuous mental exertion! What do you reckon? Can you spot any flaws in my thinking? (If so, please share!) Is this post useful for others thinking through linked data in relation to their own collections and applications?

The backstory: transmit history, avert apocalypse

So where have the devices come from? Who made them and why? Thinking on this, I came up with a backstory:

A set of devices has been sent back from the future, after the apocalypse, when people have forgotten about the time before, what the world contained, how things worked, and what it all meant. They yearn to know of the richness and diversity of their former world; they want to learn about the past — our present – in an organic but semi-systematic way.

So they created a game-in-a-box that we past people can enjoy playing and which streams its generative data back into the future, through a hub device that orchestrates and prevents random data entry. The more games are played, the more the future folk remember and understand.

There is an ulterior motive, but it is not evil: it is only to prevent the apocalypse. Yes, the future folk hold firmly to a fragile hope that if people in the past could understand things better – if they would only pay more attention to how meaning is made – then the apocalypse may never happen. The future folk must be subtle; they must not reveal the disaster ahead – the past people must not be afraid! So they operate under a guise of intriguing frivolity, and own only half their purpose.

And why did they choose to send the devices to the National Museum of Australia? Well, that will be the subject of a future post…

A steampunk device

Very early on, our trusty developers had the idea to figure Sembl as a machine. Seeing as it’s an iPad app, we started to think about it as a handheld device, made of wood and metal, so *of course!* it wasn’t long before we started to draw on the wonderful steampunk zeitgeist for inspiration.

I wondered how faithful we could be to the figure of the device – how plausible (in a non-slavish way, of course) – so I started to sketch.

Hand-drawn sketch of a device with a button, a slot, an aperture and a key

Above is a rough (and dodgy!) early sketch of the spine of the device, where teams will register to play. Below is me dreaming up how a node on the gameboard might change as it becomes available and then filled with an object.

Hand-drawn sketch with notes of three connected nodes, one 'locked', one with an aperture and one filled with an image

These are early ideas; they may well be superseded by those of the visual designers… but drawing in this way helped me to think through the visual dynamics of gameplay and, yep, fed my already substantial enthusiasm for this project!