Thoughts on how to build an API for a media franchise

Preliminary reading: Why media networks should create APIs for their franchises

Disclosure: This is a first attempt to layout elements a franchise API should gather in order to be useful for fans. It is a work and progress meant to start a conversation about the topic. All feedback and comments are welcome!

Web APIs – Definition

API stands for Application Programming Interface. Web APIs are used in hardware and software development.  The Wikipedia definition states:

“An application programming interface specifies how some software components should interact with each other. (…) In practice, many times an API comes in the form of a library that includes specifications for routines, data structures, object classes, and variables.”

Kin Lane, from APIEvangelist – a great resource to learn all about APIs – explains:

An API — Application Programming Interface — at its most basic level, allows your product or service to talk to other products or services. In this way, an API allows you to open up data and functionality to other developers, to other businesses or even between departments and locations within your company. It is increasingly the way in which companies exchange data, services and complex resources, both internally, externally with partners, and openly with the public.

APIs for franchise development

In the context of a media franchise, an API would be generated by the franchise owner, and aimed at anyone willing to create derivative work based on the franchise’s story world. The purpose of a story API is to publish documentation and resources about a specific story world for fans to use. The idea isn’t to open source intellectual property, but to see franchises as platforms that embrace co-creation and derivative work.

Each API will be specific to the needs and vision of the franchise owner. Some will be more open than others. It goes without saying, but there is no universal API. The suggestions that follow are only meant to provide general guidelines and ideas about what a media franchise’s API could look like.

Franchise API documentation may include:

Graphic and narrative “source code”

Graphic or narrative elements of a story world, typically downloadable files of character designs, scripts or bibles that anyone can use to create derivative work.

Story “data sets”

Background documentation on the existing story world. All the available “data” on characters, timelines, events, geography, and other facts.

Note – Fan wikis provide exactly that: large amounts of data about a specific universe. Franchise owners would need to find a way to leverage existing Wikis. The question is: what data do franchise owners have that fans do not? Would it add value to existing Wikis?

Example – A lot of Game of Thrones fans created maps of Westeros. Being able to check facts in order to create an accurate map is crucial.

Story world rules & production guidelines

Guidelines that all derivative work must respect in order to be endorsed by the franchise owner. Those can relate to the story itself, or the production of derivative work (All videos must be in 16:9 and HD for instance.) The goal of these guidelines isn’t to establish universal rules about how fans should use a story universe, or to restrict the community’s creativity. Rather, they are a way for franchise owners to establish standards for derivative work it is to officially endorse.

Example – AMC: Breaking Bad has a specific color code for each character. Mary is purple, Hank is orange, Walt is green, Skyler is blue, etc. AMC could require derivative video work to respect this color code in order to get an official license from AMC.

Protocols

About how derivative work should interact with the original story world, or with the real world in order to be endorsed by the franchise owner. For instance, protocols on how to place spoiler alerts in mobile apps based on a story world. If a network possesses multiple franchises, they might want to include guidelines on whether those shows can or cannot be mixed together in derivative work.

Example Amazon Kindle Worlds asks all fan fiction authors not to use elements from 2 different stories in their fan fiction piece. Each fan fiction must be based on 1 world only.

Example – HBO: HBO could require all mobile apps based on Game of Thrones to include a spoiler-free navigation tool. Users must be able to navigate content either based on the Song of Ice and Fire books (by chapter), or on the HBO series (by episode).

Licensing model, royalties and copyrights rules. 

APIs must include detailed rights and publishing agreements.

ExampleAmazon Kindle Worlds terms.

Header image source: Everythings comin up Milhouse by Terryv83, through Popped Culture.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s