Categories

Semantic Forget-Me-Nots

Before we begin this post, I’d like you to learn the following information. There will be a test, of sorts:

  • Roses are red
  • Roses are puce
  • Koalas are not bears

Done? Good stuff – now forget them. Take whatever strong alcoholic beverage, blunt instrument, or designer drug you fancy, and carefully forget everything up to here. I’ll put an arrow where you should start reading again.

→ So now you most likely have a bit of a headache, even if you aren’t quite sure why you have one – it’s all in the name of science. You probably also have an odd gap of a few minutes, which you can’t quite explain. This is normal. So what happened?

At the beginning of this post, I introduced three pieces of information, which you dutifully retained. Some neurons joined up (I am not a neuroscientist) in interesting ways, possibly reluctantly. Following that, you carefully undid all those intricately arranged connections and forgot the information. These things happen – both accidentally and deliberately: you forget someone’s name, or you realise that the world isn’t flat after all.

Let’s get a bit more technical. You are, unless you’re a Google Bot, a Being. You have a name, friends, etc, and are a unique snowflake in the gigantic universal triple store. The information above is also in this triple store, whether it’s correct or not. At a certain instant in time, just now, the Being that is you committed this information to memory, and then a bit later lost it. If this information above was referenced by a graph URI, we could define it like this:

<http://example.com/memorygain>
 mem:agent <http://example.com/you>;
 mem:information <http://example.com/somegraph>.

<http://example.com/memoryloss>
 mem:agent <http://example.com/you>;
 mem:information <http://example.com/somegraph>.

Here the subjects are a subclass of Event (be it the OntoMedia Event or the Event Ontology Event), so they can have some timing or positional data. They might be called RetainEvent and DisposeEvent, or something like that, with a possibility of a RecallEvent when prior information is referenced. We can now query for any knowledge you may have gained or lost during some time period, though it needs a little post-processing to be useful.

Now, let’s extend what we have to cover a bit of Doctor Who. A character gains a large amount of information, chooses to purge it from her memory, and then sees a video of herself recorded during the erased event. Here we have four Events: One in which the character learns the Horrible Truth; one in which the character creates a recording; one in which the character erases her memory; and finally one where she sees the recording. The first is a RetainEvent, with the information being that ‘some nasty Events occurred before now’ – at least, that’s all the viewer knows. The second is a bit odd, as it’s an ActionEvent resulting in the creation of another representation of that Event (the recording). The third is a DisposeEvent, in which knowledge of both the information and the occurrences of the events are lost. Then, finally, the character gains memory of the recorded Event. If we were to request all memory events prior to her reclaiming her memory, we would effectively have a gap in our Timeline.

As a second use case, we can go one step higher. A popular approach in television recently has been to show a dramatic event at the beginning of an episode, such as a lead character dying. Then you get a ’24 Hours Earlier’ caption, and the rest is filled in. So, when you see the shooting take place, you gain a memory of the event and of the character’s state at the end of the scene. If you were a hardy TV watcher, you may choose to accept the memory of the event as fact, but disregard the character’s state (‘I know what’s going to happen!’). Once the episode then goes back in time, and you see the character alive, you store this piece of knowledge away. So now the character is both ‘alive’ and ‘dead’, in a nice Schrödingery way, and if someone were to turn the episode off, you’d likely be horrified. But, when it’s revealed that the character was faking his death, you can discard the ‘dead’ information and be happy that everything’s resolved. The hardy watcher, of course, would know that the character was alive all along.

This may be, and I suspect it is, a total abuse of graph URI use, but it really opens up potential for interesting queries: Can we spot when a character is lied to, and knows it? Can we spot plot twists based on the number of beliefs that are altered? Is a ‘filler’ episode something that doesn’t change any memories that you’ve built up prior to that? And will it make Eraserhead make sense? Maybe.

Leave a Reply

  

  

  

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>