Comments on: Transmedia Notation

By: David Beard

David Beard — Mon, 26 Oct 2009 01:02:22 +0000

Examples of our approach are shown in the video of Lances PTTP presentation. It’s applied as annotations within the script, production notes, creative specs and other documentation. So it’s actually pretty simple to implement. The parties who perform the annotation don’t need to know anything about formal ontologies.

By: Rob

Rob — Sun, 25 Oct 2009 01:20:08 +0000

Hey David, thanks for continuing the discussion.
I also thought that someone must have solved this problem before and researched different methods including UML and FSMs etc. The problem I feel with these formal languages is that while they might most accurately and succinctly describe the system, nobody without a formal education in these languages can understand them.
What I feel would be nice is to find a way to communicate the solution to as many people as possible (e.g. client, creative team). Once the media asset has been identified then that can be described with the an approach most appropriate to the media and those going to create it (e.g. script for a movie).

Any chance you might post an example for your ontological approach? From your description it sounds a little complicated for someone arriving at transmedia from the entertainment industry.

By: David Beard

David Beard — Sat, 24 Oct 2009 22:26:12 +0000

There are graphical modeling formalisms, like UML, that can be useful for depicting the constituents, structure, sequence, states, interactions, and activities of a transmedia program. These are used when designing and analyzing systems, typically software architectures.

Here’s a simple introduction – http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/diagrams.htm

By: David Beard

David Beard — Sat, 24 Oct 2009 20:12:47 +0000

I like that density bar representation.

The approach that we’ve taken to the description, modeling, and visualization of transmedia programs is to utilize an ontological representation of the storyworld and program elements, and to derive these aspects from this base representation. So any documentation, model perspectives, diagrams et al. are composed from the ontology.

In this way, the world and program representations are not limited by the specification of their presentation type (e.g. the conventions of flow diagramming, or a specific documentation template scheme). We can render these formats by mapping to them from our ontology. This technique also supports abstraction, which allows us to simplify the representation and adapt it to its application.