Posts

A dialogic order of knowledge

/3 Comments/in , /by

This post is a provocation, triggered by Mike Bergman‘s clear and interesting talk on the semantic web in use. It follows some earlier, fuzzier thinking of my own on Sembl and linked data. I now understand where Sembl fits in relation to the semantic web. The answer is that it doesn’t, not really, because Sembl triples are quintessentially different to RDF triples. Different and, I contend, better.

Here’s the problem – just reiterating here, for people who are unfamiliar with ‘the semantic web’. We made a beautiful web, huge and full of knowledge, but it’s too big for humans to use well. We need machines to process the bulk data so we can extract the most relevant gems of knowledge. But for machines to understand the whole web of human knowledge, they need the parts to be arranged in a more orderly way. Is this thing the same as that? If not, what’s the relationship between the two? Machines fail to articulate the parts, and humans are never sure we’ve got the best part of the big picture.

What we need is an authority file for What Each Entity Is and How It Relates to Other Entities; an agreed way to inform machines of the complex variations and dynamics of human knowledge.

Semantic web proponents have succeeded in creating an agreed process for defining and agreeing on What Each Entity Is. Mike Bergman describes the use of URIs to identify data as the semantic web’s ‘crowning achievement’. But the second part of the challenge – How Each Entity Relates to Others – is critical, and tricky. And the current approach – build and/or mash up and apply ontologies, vocabularies, thesauruses, schemas and taxonomies – feels labour-intensive and ineffective.

The web is about as non-linear and dynamic a system of knowledge as you can get, yet we try to describe it in terms of the sum of its components.

What if we’re going the wrong way in our mission to understand things in relation to other things? What if the basic building block of the semantic web structure, the triple, is sub-optimal? At the very least, it is insufficient. Consider:

This entity
[subject]
↓
has this relationship to
[predicate]
↓
that entity
[object].

Let’s face it: triples are reductive and authoritarian. Always starting with the subject and ending with the object, they seek out and cultivate otherness. Whatever the part in the middle is, the subject gets to co-opt the object into a relationship that is always already from the subject’s perspective. Sometimes the subject’s defined relationship to the object is consensual. And sometimes it’s inappropriate. The thing is, even if you carefully pass all your triples through the complex regulatory system they necessitate, you can never be sure you’ve got the relationships right. And if they are validated at one point in time, they may later need updating.

In short: triples are intended to impose order, but they tend to create conflict.

Triples are not evil. Often the predicate is unifying, a form of equivalence, something along the lines of ‘is the same as’. Too often, according to Mike, who lamented the ‘SameAs’ relationship’s overuse. He also showed us a list of various terms for defining the near-identity of different entities – my personal favourite is ‘somewhatSameAs’:

A list of terms for 'almost the same as'

Different ways to describe near-identity

Evidently there is a reconciliatory bent among the seekers of the semantic web, a force resisting the oppositional stretch of the triple :)

And… therein lies an answer to the problem of imposing order without generating disagreement.

Instead of trying to map the complete tangle of relationships, we could focus on crafting resemblance. We could ditch the one-way triple in favour of a mutual one:

This thing
[subject]
↓
shares this resemblance with
[predicate]
↑
This thing
[subject].

Resemblance is by nature imprecise, but because its perspective is mutual, it is never wrong. The spectrum of resemblance runs from fairly uninteresting (eg a glass and a bowl both have a round rim) to the startling, insightful, poetic. And whether humans like the resemblances or not, every single one will help the machines to understand – whether they are written in ‘proper English’, vernacular, or any other language.

Resemblance is a very human approach to structuring knowledge. It is generative rather than reductive, and it is intrinsically attractive – both conceptually, in the sense of drawing two entities closer together, and emotionally, in the sense that it feels better to seek similarity than to define difference. We are naturally dialled-in to similarities and patterns. And this capacity is extremely useful for seeing how the parts relate to the whole. Which is, I recall, the mission of the semantic web.

Obviously, there will still be difference. In fact, it turns out that to identify sameness is to explore difference. As soon as you find a resemblance between two things, a difference pops up. Intriguingly, difference seems to make more sense, and be more palatable, in the context of resemblance. It’s kind of beautiful.

To create an online version of the Sembl game – a Sembl Web – we will need to use stable URIs or to create them if they don’t exist. By default, I’d like to link Sembl entities to Wikimedia. But can we hack the RDF triple and forget the vocabularies and ontologies?

Freed from having to define and structure all the possible relationships in advance, we could invest energy in exploring the territory of relatedness at our leisure, and begin to work out a pattern language for them. We’d be building a knowledge system based on consensus instead of authority.

Wikipedia changed how we create and access shared knowledge. Sembl could change how we create and access shared knowledge of how it all fits together.

The semantic web is big, in theory. There are over 7 billion RDF triples already, though according to Mike ‘very few’ are put to use. Sembl Web doesn’t yet exist, but when it does, it will constitute a humane generator of mutual triples – triples that:

  • are always already in use
  • bring joy to the people that create them
  • fit the dynamic non-linearity of the web

Sembl is poised to create complex, chaotic flow among disparate parts of the web. And that flow is the point. That’s what converts knowledge into understanding.

…..

Disclaimer: I’m no expert on the semantic web. If I have overlooked something critical in the above, I’d appreciate you letting me know. On the other hand, if you see value in this approach, please let me know where and how. Ie, comments appreciated!

Thinking linking – Sembl data

/16 Comments/in /by

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?