Investigate current state of MovieLabs Ontology

[SamCrooksFoundry]

What

Document the current completeness of the Ontology and create a rough plan for incorporating into Media Creation Traits Library.

Why

The MovieLabs Ontology could be a good basis for the traits of Media Creation Library.

Acceptance Criteria

Add a comment to this issue with the status and plan.

[feltech]

I made a brief start on this, with a view to de-risking OpenAssetIO/OpenAssetIO-TraitGen#80 - i.e. since we'll be doing a lot of code changes to TraitGen, should we also make changes, or at least leave the door open to changes, that better support the OMC?

I've been investigating the current JSON schema description of the OMC, and hackily probing it with Python scripts to see how easy it is to pull out the info needed to generate traits/specifications (TLDR: its quite difficult).

With regard to the current state of the OMC. As of now the CG Assets work (e.g. geometry) isn't in there. However, there is a lot of overlap with existing MediaCreation traits.

Structure

A summary of the structure, with some callouts to interesting definitions I found:

• Asset
  • AssetSC.structuralProperties.fileDetails - close to LocatableContentTrait - provides file info, interestingly not using URLs.
  • AssetSC.structuralProperties.dimensions - includes properties like height with explicit mention of pixels (though can be other units).
  • AssetSC.version - provides versionNumber as well as relationships (e.g. DerivationOf).
  • AssetSC.type - a string value, explicitly listing as an example "digital.image".
• assetFC.scd.functionalProperties - "Scene Chronology Descriptor" with properties like sourceStart, recordEnd, duration and a relationship to a (generic) Shot asset - definitely reminiscent of FrameRangedTrait
• Infrastructure
• MediaCreationContext
  • Slate - "key identifying information about what is being recorded on any given setup and take" - has properties like recordingFPS - but is about on-set metadata, not digital video metadata.
  • Sequence - "sequence of shots linked to creative intent" - no really useful properties, but works as a parent entity of shots.
• Participant
• Task
• Utility
  • identifier - OMC splits identifiers into identifierScope and identifierValue, but also has a combinedForm and aurl too. The url "can be used for resolving the Identifier within the Identifier scope", so not sure if that can be a file URL.
• core - can mostly be ignored, except:
  • reference - is the same as (has $ref to) Utility.identifier, but is used throughout OMC to document properties that are relationships (i.e. relationship traits).

Conversion

Conversion from OMC to traits/specification is a bit tricky.

The JSON schema makes heavy use of referencing ($ref) to compose "traits" together in a hierarchy. References are recursive in several cases

There are several traits that have multiple allowed alternative representations (oneOf, anyOf).

Some trait properties are arrays, which TraitGen doesn't currently support.

On hackily attempting (and largely failing) to parse this, I think a broad approach would be:

• Find the "leaf" traits (watching out for infinite recursion) - that is, the bottom-level objects that have "properties".
• Leaf traits that have primitive properties are entity traits.
• Leaf traits that hold a core.reference are relationship traits.
• The objects containing a set of leaf traits is a specification
• The objects containing a set of leaf traits may also be a trait, if they themselves have leaf properties. We have precedent for having traits and specifications with the same name, where in that case we call the trait a "family trait".
• Traits and specifications that have multiple possible representations (e.g. via oneOf) need to be either merged to a single trait/spec, or split into distinct traits/specs.
• The objects above the specifications are namespaces (mostly the top-level bullets in the structure summary above).
• Although the structure broadly mirrors namespace.specification.trait.property, in several cases nesting is deeper (e.g. Asset.AssetSC.structuralProperties.dimensions.width) or shallower (e.g. Utility.identifier.url), and so we need to identify these and either support additional namespaces, or use a naming convention.

[feltech]

To round this off, I went through all the MediaCreation traits to see what mappings are possible to the OMC as it currently stands.

In summary, there isn't much overlap, even where some traits seem superficially similar. Many traits can be modelled in an (overly-) generic way with OMC. Some callouts

• Broadly, most things are just Asset with the type being some arbitrary string e.g. "digital.image".
• LocatableContentTrait can be mapped to AssetSC.structuralProperties.fileDetails, but OMC doesn't use URLs for paths.
• Versioning is more elaborate in OMC, with different kinds of version e.g. Alternative vs. Variant, which overlaps a little with our Proxy relationship. However, there is no consideration of stable vs. unstable references (e.g. "v2" vs. "latest").
• Bear in mind the CG Assets portion of the OMC is still being worked on and isn't available in the current JSON schema.

The following bullets list the MediaCreation traits/specifications at the top level, and under each of these is a list of possible mappings to OMC traits.

Traits:

• color.OCIOColorManaged - none
• content.LocatableContent
  • Asset.AssetSC.identifier (URL, maybe, but seems more akin to entity reference)
  • Asset.AssetSC.structuralProperties.fileDetails (fileName, filePath, fileExtension, mediaType)
• application.Config
  • Asset.AssetSC.structuralType (e.g. "digital.image")
• application.Work - none
  • Asset.AssetSC.structuralType (e.g. "digital.image")
• identity.DisplayName
  • Utility.basicName (mixin, duplicated for various "name"-like properties)
  • Utility.completeName (mixin, duplicated for various "name"-like properties)
• imaging.Camera
  • Nothing explicit, closest is MediaCreationContext.Slate.cameraLabel / .cameraRoll / etc.
• threeDimensional.Spatial / .Geometry / .Lighting / .Shader / .IESProfile / .SourcePath / .SourcePaths - none
• timeDomain.FrameRanged
  • Asset.assetFC["scd"].functionalProperties ("Sequence Chronology Descriptor" - sourceStart, duration, etc - no framesPerSecond nor step)
  • MediaCreationContext.Sequence.SCD (relationship to above Asset.assetFC["scd"])
• twoDimensional.Image / .Planar / .Deep
  • Asset.AssetSC.structuralType (e.g. "digital.image")
• twoDimensional.PixelBased
  • Asset.AssetSC.structuralProperties.dimensions (width, height, depth - no aspect ratio, nor "display window")
• lifecycle.Version
  • Asset.Asset.version / Asset.AssetSC.version (no concept of stableTag vs. specifiedTag, but adds description and annotation as well as several relationships e.g. VariantOf).
• managementPolicy.Managed - none
• relationship.Singular / .Unbounded
  • Inherent in JSON schema via the container where the #/$defs/core/properties/reference mixin is placed. Some are arrays, others singular. E.g. Asset.Asset.version.VariantOf is singular, whereas Asset.Asset.version.Alternative is an array.
• representation.Proxy / .Original
  • Asset.Asset.version. / Asset.AssetSC.version. Derviation[Of] / Revision[Of] / Variant[Of]
• auth.BearerToken
  • Closest would be Asset.Asset.provenance with CreatedBy and Role relationships.
• audio.Audio
  • MediaCreationContext.NarrativeAudio
• audio.SampleBased
  • Via relationship MediaCreationContext.NarrativeAudio.Depiction.Depictor[Asset].AssetSC.structuralType

Specifications:

• audio.Audio / .SampledAudioResource
  • MediaCreationContext.NarrativeAudio.Depiction
• application.Workfile
  • Asset.Asset with appropriate AssetSC.structuralType / entityType property
• threeDimensional.Spatial / .SceneResource / .SceneGeometryResource / .SceneCameraResource / .SceneLightingResource / .ShaderResource / .IESProfileResource
  • Nothing explicit. MediaCreationContext.NarrativeObject.Depiction may be a generic alternative.
• twoDimensional.Image / .BitmapImageResource / .PlanarBitmapImageResource / .DeepBitmapImageResource
  • Asset.Asset with appropriate AssetSC.structuralType / entityType property
• lifecycle.EntityVersionsRelationship / .StableEntityVersionsRelationship / .StableReferenceRelationship
  • Nothing about stability of reference. Similar to corresponding traits, closest is Asset.Asset.version / Asset.AssetSC.version.
• representation.OriginalRepresentationRelationship / ProxyRepresentationRelationship
  • Simlar to corresponding trait: Asset.Asset.version. / Asset.AssetSC.version. Derviation[Of] / Revision[Of] / Variant[Of]