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 https://github.com/OpenAssetIO/OpenAssetIO-TraitGen/issues/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.