1 Introduction

The script provides the narrative of a movie – its characters, plot, locations, necessary props, and more – but it doesn’t tell you how to turn it into a finished product, which is both a creative process and a logistical and organizational project. Getting to the things you need to organize and run a complex production process is currently a mostly manual undertaking developed through years of experience, aided and abetted by spreadsheets, emails, and many conversations to resolve any discrepancies between the various organizations and departments involved. This blog series is a guide to using the MovieLabs Ontology for Media Creation (OMC) in the production process to support automation and reduce miscommunication among the people and organizations involved. It starts with the script breakdown and goes through pre-production and planning phases, filming, and a bit of the editorial process. OMC has other uses too, for example in distribution and analytics.

The OMC provides a common data model with clear meanings and common data formats. This makes it easier for applications to exchange data with less effort and fewer errors, which in turn simplifies integration and automation. If each piece of the common data is managed consistently, e.g., in a common data store, there is much less chance of data drifting; many common data errors are easy for humans to understand, but hard for automation. Just as importantly, an ontology also provides relationships, which are well-defined connections between one thing and another. Relationships make it easy to understand dependencies, see the potential consequences of changes, and discover connections that may not have been obvious.

We expect the initial uses for the OMC to revolve around data exchange, but over time we expect applications will be available that use OMC to transform the script into data and information for department production plans and provide intuitive user interfaces for creation and visualization of the concepts described here. In fact, this blog series can be thought of as a roadmap for organizations interested in building those services.

Part 1 of this 3-part blog series describes how to use the Ontology for Media Creation to do a script breakdown and assumes some familiarity with the concepts in OMC. Since we’ll be discussing the breakdown processes at the conceptual level, we make no assumptions about the implementation mechanism (OMC is available as both RDF and JSON).

To ground this process in reality we wanted to use an actual production and script so during our series we’ll illustrate the examples using “HyperSpace Madness” (available here). HyperSpace Madness (HSM) was written as a fully animated short film, but here it’s treated as a live-action short to illustrate various aspects of using OMC. We focus on how components come into being and the connections between components, so some of the detailed data for individual items will be glossed over.

Start With the Script

Producing a narrative work, whether film or television, starts from the script. There will be many iterations on the script, but eventually parts of it will be stable enough to start production of some or all of the creative work. The production process is built out of lots and lots of components – some large, some small, but all important – and all of these eventually tie back to the script. There are many ways to turn a script into a finished production. This blog shows one way of doing it and doesn’t attempt to cover all of the complexity and possibilities.

Notes on Flow and Format in the Blog

• The diagrams start with representing simple things as spreadsheet rows, progress to graph-based representations of simple things, and finally to fully connected views of everything discussed
• Definitions of the form “Term: definition” are taken from the OMC documentation.

2 The Script and Narrative Elements

Ezekiel cried dem dry bones
Ezekiel cried dem dry bones
Ezekiel cried dem dry bones
Now I hear the word of the Lord

The script provides the bones of the movie. It is about the narrative world: the action is in outer space or an exoplanetary jungle, even if it is filmed someplace else; the characters Sven and Keira are romantically inclined, even if the actors portraying them have never met each other. The production process brings it to life and needs to draw the viewer in — something that provokes Coleridge’s “suspension of disbelief.”

There is a lot of freedom in the narrative world. You can change the names of characters, add scenes, change props from metal to plastic, all with little apparent cost. However, every one of those changes will make its way through to the rest of the production, requiring new dialog, new locations, and new physical or computer-generated props. The connection between the narrative world and the production world underpins many of the relationships in OMC.

All of the necessary production information has to be extracted from the script and shared with the people and organizations involved in the production. The process is called ‘breakdown’ and each department handles it differently with each needing different information. This information is usually shared in spreadsheets, for which there is no standard format, and no standard naming of things. OMC provides a common model for both structure and terms as well as the means to represent the elements from each departmental breakdown and their relationships with each other.

In this post we’ll turn a portion of the script into its components. In the ontology, these are called “narrative elements.”

Which narrative elements do we get out of the script?

• Narrative Scene: Taken from the narrative itself and traditionally defined by creative intent and various kinds of unity (e.g., time, place, action, or theme).
  Character: A sentient entity (usually a person, but not always) in the Script whose specific identity is consequential to the narrative. A Character is generally identified by a specific name.
• Narrative Prop: A named object related to or interacting with characters that is implied or understood to be necessary for the narrative
• Narrative Location: A location specified or implied by the narrative.
• Narrative Wardrobe: The clothing for a Character in the narrative.
  It sounds simple enough. What follows, however, shows mistakes that can happen when these elements are extracted manually.

It sounds simple enough. What follows, however, shows mistakes that can happen when these elements are extracted manually.

For HSM, we’ll deal with Narrative Scenes 2 and 3. (The narrative scene number is in the left margin of the script, following usual practice.) These narrative scenes don’t have names in the script, so we will provide some:

What Characters are in these Narrative Scenes?

There are two Narrative Locations.

And one Wardrobe item.

There are several things to notice here:

• For some things (e.g., a Character that appears in more than one scene) readers have to decide whether to add multiple rows (as above), risking copy and paste mistakes and making the spreadsheet longer; add multiple columns, e.g., a single row for a character with a column for each scene, which requires rejigging things when someone appears in a new scene; or having a single row per character with all the Narrative Scenes in it with some kind of separator, which requires agreeing on the separator and editing lists when something changes. All of this is do-able in a small production but adds risk, overhead and chances of discrepancy in a large one.
• There is an explicit relationship between the prop (or wardrobe) and the character using it. This forces the same decisions and adds the same risks as Characters in Narrative Scenes and adds complexity when a Narrative Prop is used in more than one scene or by more than one character. In addition, there’s an implicit relationship with Narrative Scenes lurking in the Character information anyway.
• Whoever did the Wardrobe piece followed a different convention (Narrative Scenes all in one column) from whoever did the Character piece (one row per narrative Scene).
• Whoever did the Narrative Location piece used scene names, not scene numbers, and followed the “multiple scene per column” convention.
• Sven’s name appears in three different forms.

All of this could be managed by standard conventions, iron discipline, and pivot tables, but the first two are hard to enforce and the last is hard to maintain – what if different departments do pivot tables differently?

What we need is a representation that has one data object per narrative element (character, wardrobe, narrative scene, etc.) and shows the connections between them. With that, things like a Character’s name only need to be done in one place and it is easy to see what is connected to what. This also deals with the problem of how to reference things: narrative elements connect to narrative elements, without having to worry about whether to use a scene number or a scene name.

A partial diagram for what we’ve been looking at is:

For simplicity, the diagram doesn’t show that Sven is wearing his space suit in a particular scene, but the ontology can express that. For showing “Sven uses the prop in narrative scene 2’, the prop is connected to both Sven and the scene, but the underlying ontology allows stating that as one fact, which is useful if someone else uses it in another scene (or even the same scene.)

The end goal is to get a first pass of this automatically from the Script. As a starting point, an application that allows a user to construct an editable, extendable graphical diagram of the elements and their relationships can be built with existing technology. The application can automatically provide the necessary identifiers and provide access to the elements in a common format. Such an application still requires a person to break down the script, but the results are more consistent and easier to share than breakdown done by spreadsheet and email. Scripts often adhere to one of a set of standard conventions (for spacing, character names, scene boundaries, and so on.) Because of this, a bare-bones structure can be produced using simple text processing, which is a possible next evolutionary stage. In the longer term, AI and machine learning have the potential to automate this even further.

Even so, sometimes spreadsheets are useful for sharing information. The information in the ontology can be turned into tabular data as needed.

Conclusion

This blog has shown how to use OMC to turn a script into data representing narrative elements. These data elements can improve communication, reduce errors, and encourage better collaboration and automation. In Part 2 we’ll look at the transition from narrative elements to production elements, and in Part 3 we’ll take those production elements from filming through post-production.

If you found this blog series useful then let us know, and if you’re interested in additional blogs or how-to-guides let us know a specific use case and we can address it (email: office@movielabs.com).

There’s also a wealth of useful information at mc.movielabs.com and movielabs.com/production-technology/ontology-for-media-creation/.