The MovieLabs Ontology for Media Creation (OMC) is a comprehensive model of the entities and relationships involved in the production of audiovisual content. It covers the entire lifecycle of a media asset, from its inception to its distribution, and during that journey we know that assets are rarely deleted. We work in a primarily non-destructive workflow as we tend to create a new version of a file which allows us to compare one version with another, rather than delete or overwrite files When there’s potentially millions of files in any given production the proliferation of versions and respective version control can become a massive challenge.
“Version” also means different things in different parts of the workflow and versions can be created for different reasons. For example, a version can be an intermediate revision of, say, a piece of concept art or a CG prop. It can also mean an asset that can be used in a particular context, for example a shiny new suitcase and the same suitcase but old and battered after a difficult journey. A medium-resolution proxy of an editorial sequence is also thought of as a version, which is confusing if “version” is also used to refer to the sequence before and after an editorial change. Sometimes we also use versions as a useful way of categorizing and tracking assets.
In this blog post, we will explain what we mean by “version” in the OMC, and how versions can help to manage and track the evolution of media assets. OMC also assists by providing a common way to describe and annotate chains of versions. We will also provide an example of how to use OMC to describe the versions and provenance of media assets in a consistent and interoperable way.
So, let’s dig in with some definitions…
What is a “version” in OMC?
A version is a term that can mean a lot of different things in the context of media creation. It can refer to a change in something, like a CG model, a different form of something, like a proxy for a higher-resolution video, a modification to something that lets it be used in a different way, like a rusty car vs. a shiny car, or a choice among several things, like three different proposals for concept art.
All the uses of “version” we found can be grouped into five different kinds:
- Revision: an incremental change to something, in such a way that it can still be used in the same context as its predecessor, e.g., in Hyperspace Madness1 a revision of an asset could include rounding the edges in a CG model like the communicator that is a prop.
- Variant: a change that results in a new thing that is intended to be used in a different context from its predecessor, e.g., a CG model of a damaged communicator, based on the model of the working one.
- Derivation: something that clearly comes from something else, but is enough of its own thing to qualify as something new, e.g., the communicator in Hyperspace Madness: The Next Generation is derived from the communicator in the original Hyperspace Madness, or a fitted surface is derived from a point cloud.
- Representation: something that is strictly a format variation of something else, e.g., a low-resolution version of the high-resolution image of a communicator, or a different encoding of a piece of video (for example the proxy is a representation of an original camera file). Different parts of the production workflow can use different representations as they choose, but the underlying asset does not change in any way.
- Alternative: a choice of something from a set of somehow-equivalent things, e.g., deciding which of two concept art sketches of a communicator to use, or picking one of three identical physical communicators to use on set.
Each of these kinds of versions has a different impact on the identity and meaning of the underlying asset. For example:
- A revision does not change the identity of the asset, but it may affect its quality or appearance.
- A variant changes the identity of the asset, but it still has some resemblance or similarity to its predecessor.
- A derivation creates a new identity for the asset, but it still acknowledges its origin or source.
- A representation does not change the identity or meaning of the asset, but it may affect its usability or performance.
- An alternative does not have a clear predecessor, but it may have some criteria or constraints that define its equivalence or suitability. Each alternative has its own identity, and any one of them can be used in a given circumstance.
Calling all these things a “version” overloads the term and loses the subtle distinction in the relationships between them, and as the OMC is concerned with defining relationships, we all need to be more precise in what we mean by a version and which kind of version it is.
There is one more complication with versions which we need to discuss; a version can often be associated with a ‘state’, as in the asset has been ‘approved’, ‘rejected’, ‘in-review’ etc. Sometimes people refer to the state when they say things like “use the approved assets” when they really are referring to a specific version, in essence what they mean to say is “use version X.Y of the assets, which was the version approved by the director.” State, how we define it and how we use that in the OMC, is a subject for an entirely different blog but suffice to say here that versions and state are often interrelated and sometimes confused but are distinct.
Provenance and OMC versions
Provenance is the information that describes the history and origin of an asset and its versions. It can include the events, agents, and sources that contributed to the creation, modification, or selection of the asset. Provenance can help understand the context, quality, and reliability of an asset, as well as to trace its evolution and dependencies.
In OMC, a version is represented by two main elements:
- Asset: the Asset that is a version
- Predecessor: the Asset that is the source or origin of the Version
Versions can contain other information, such as a version number, e.g., “2.1” or a UUID used for tracking the version in applications that don’t use OMC. It can also provide a human-readable description of the version, e.g., “made the helmet less shiny.”
In OMC, provenance is represented by a structure that is connected to a media asset and/or its versions. The structure consists of three main elements:
- Asset: the asset or version that is the subject of the provenance.
- Source: the media asset that is the origin or predecessor of the asset, or the set of media assets that are the candidates or options for the asset.
- Descriptive information: including things like who produced the version, when it was produced, and why it was produced.
Provenance can also contain information about when the item was created, who created it, and why it was created.
Taken together, versions and provenance give a picture of where assets come from and how and why they have changed over the course of the production. Versions and provenance can be combined by nesting and chaining to represent complex chains of derivations, dependencies, and sources. For example, you can describe a derivation of a variant of a revision of an asset, all with provenance, or indicate a choice of alternatives among several representations of an asset.
Using Versions in the OMC
OMC versions can be applied to Assets and Asset Groups as well as other elements. This example shows version information about two pieces of concept art for a prop and the CG model based on the approved concept art.
- A Prop needs some Concept Art, and there are two competing visions for it: Asset ID: A and Asset ID:B. The production team has to choose one of these, so they are alternatives of each other. They are grouped together in an Asset Group to make It easier to find and manage them.
- Asset ID:A is a revision of an artist’s original version, Asset ID:C
- Asset ID: D Thumbnail is a representation of Asset ID:A – it is just a smaller image used in a dashboard.
- The production team approves Asset ID:B as the final Concept Art for this prop. The CG department starts from the approved concept art and produces a model, Asset ID: E, which is a derivation of Asset ID: B.
- Asset ID: F is another CG model that represents the same prop after it has been through a series of unfortunate appearance-altering events. It is a variant of Asset ID: E.
This example is extremely simplified. In a real implementation, some of the versions can relate to Asset Structural Characteristics rather than a complete Asset. Please contact info@movielabs.com if you’d like more details about how that works or would like to see additional technical blogs on versions and versioning in OMC.
Next Steps
If you want to learn more about OMC, you can visit the MovieLabs Media Creation documentation site at https://mc.movielabs.com/ where you can find the full specification, documentation, examples, and resources. You can also follow our GitHub repo at https://github.com/MovieLabs/OMC.
Thank you for reading, and happy media creation!
PS. If you didn’t like this version of the blog, just wait for the revision version.
