Tuning Fork, by Toby Esterhase, via Flickr – Creative Commons
Part three of my investigation into fictional content modelling. See the previous two posts for the background to the project. Thanks to those who’ve been discussing the ideas – I think it’s coming along nicely. I’ve been playing around with writing some RDF, trying to link up various ontologies, and explaining what I’m trying to do as I go along. Here’s a plain text file of quasi-RDF within comments – see what you think…(UPDATE: Now here in beautiful RDF format 🙂 )
One thing that has come up in the discussions, though, is that there’s perhaps two elements to what I’m trying to achieve. The first is to link existing ontologies and, if needed, build a new one, to help describe the narrative content of ‘stories’ within the context of television and radio programmes. The second is to experiment (and for me to learn) with existing ontologies, again, linking them up, to build dynamic and interesting webpages that work on linked data principles.
So I’m interested in the ontology *and* what kind of cool stuff we could build on top of it (which includes ideas around remixing narrative, and audience story-telling). I haven’t got any definite plans on top of that at the moment, but I think the key is to see where it takes us. Well, I have an image in my mind of the types of things we could do, but again, it will be easier to describe them by prototypes. Something that might help is if I was to link to this diagram, from the aforementioned Tristan Ferne’s Radio Labs blog, describing similar things to do with the Archers – except linking that up with linked data/ontology work…
Which would lead to something like the diagram below. Again, it isn’t a complete set of what I want to do, but it shows the types of objects we’re talking about, the relationships between them, and where they link to ontologies:
Actors – Using FOAF, with possible extensions, this would be a URL for each actor who appears in a BBC show. This page could pull in a biography from WIkipedia, for instance, but mainly it will show the audience all the programmes that the actor has appeared in. Linking Actors to Characters, all the way through to Episodes, would allow us to auto-generate the cast lists for the /programmes episode pages. However, one problem in an early implementation might be that if we only record ‘significant’ events within an episode, the cast lists won’t represent everyone – but over time, this could be improved (the rest of the cast could possibly be listed manually against the episode, greyed-out, until they have their own URL).
Portrayal – This would allow an Actor to play many Characters, and a Character to be played by many Actors. Here I’m thinking more of ‘flashback’ scenes where you see a character as a child, but as Tom pointed out in the comments, this could be used to handle the different actors playing the Doctor. BUt how then would you deal with the different ‘characterisations’ of the same character?
This is where the recursive relationship around ‘Character’ comes in – I haven’t worked out exactly what to call this yet, but it would allow both the foaf:knows relationship, and potentially use the owl:sameAs to link different Doctors? (Perhaps not – but something along those lines).
Again, a many-to-many resolver is needed between Characters and Events, which I’ve called ‘Action’ – I’m not sure whether these many-to-many objects would need to be made explicit and have their own URLs, but the main objects certainly would, as they could have useful pages for the audience to explore.
Events would be pages that would describe a significant event in the episode, something that would be worth describing, for instance an event which is part of a wider story arc – we would then need a URL to link these together, so you could say that ‘Someone points out that Donna has something on her back’ is part of the ‘Donna/Time-Beetle’ story arc (apologies for the random example!). This is, though, where the main value of the project would be for the audience. BY giving an event a URL, the user could trace storylines throughout the episodes, outside of the confines of the episode structure – making the fictional universe more cohesive, rather than restricting our view to the episodes, which are like ‘windows’ onto the fictional universe.
Similarly, if a user then wanted to write a story featuring some of the characters, they could refer to the character’s URL (which would then allow us to have something on the character’s page to say ‘others have written stories using this character’ – linking out onto the web, and promoting new writers and stories. The users could equally refer to events, perhaps building events into their owns stories, taking them as cues for new stories etc. Again, it all fits in with the idea of giving our audience the tools to be creative, whilst using the advantages of the BBC website’s exposure to promote audience creativity.
There’s one many-to-many resolver which I’m not sure about at the moment – between Events and Episodes – what if the same event was shown, or even just referred to, in more than one episode? We would need some way of defining this – but I’m not sure of the correct term for it yet, hence the ‘???’ object.
So – events could be described using the Event Ontology. Actors and Characters would use the FOAF ontology. Episodes would use the Programmes Ontology. We therefore just need a way of tying them together, and then once we have some examples, it would be good to start thinking about what new things we might need from a new ontology.
On the subject raised in the comments about expressing a person in FOAF as fictional or real – I’d side withi Tom in saying that it would be better to label the individual people as fictional, so that it was explicit which FOAF people were characters or not – and then you’d also have the issue of characters being used to represent, for instance, historical figures such as Charles DIckens…
Anyway, that’s enough for this entry. I hope I’ve got a little further in both clarifying the two strands of the idea, and exploring the breadth and potential of it. Comments, discussion, etc. encouraged! I’m hoping to present the idea in a meeting this coming Tuesday as a possible 10% time project, so I will keep you posted…