Traits and how they are used in AYON

[antirotor]

Hello everyone,

from various discussions I had in the past I'd like to present here a way how we've decided to go with traits internally in AYON. This is not meant to be a feature request or anything, I just wanted to present ideas we have and how we want to connect it all together.

Problem

Initial problem we were facing (are we still are, until this all is implemented and used) is that we don't have clearly defined metadata for anything we produce and then we load in DCC. There is a concept of representation in AYON: published version of model can have representation of FBX file and Alembic file and what not at the same time. We are storing that representation and loaders are using it to load published assets to the DCCs. During the years we had to add some metadata to this simple dictionary, like if it should be used to generate reviews, etc. but as we added more and more features, we've found out that it is not enough to just add stuff there and that it would be nice to have something more standardized. At that time OpenAssetIO came with idea of Traits and we thought that it is perfect solution for that.

We've found out that at the end we cannot use OpenAssetIO directly inside AYON (but we can still act as Manager) - the reason is that we are not in control over what Python hosts it will be running in - there are studios using super old DCCs or those with weird Python builds. So we cannot implement AYON as an OpenAssetIO host. There is also requirement to use more complex data types inside the traits (more on it later) and since we are pure Python project we can use something more Python "native".

Solution

We decided to use trait concept and keep it us much compatible with OpenAssetIO Media Creation traits so the Manager plugin should still be able to map traits together. But AYON traits are defined as Pydantic models. With that we can add field validators and we can handle serialization much easier - and with that we can map to OpenAssetIO traits. We used that to add some pipeline functionality in the traits themselves so every trait can implement validation that has access to all other traits on the representation, This way trait can say that it isn't compatible with other traits (like static image cannot be at the same time frame sequence) and therefor if both are set on the same representation then the representation itself can't be valid.

We've added some "metadata" traits like Tagged - just to be able to stick some simple strings to the representation, or SourceApplication that holds information about the producer application so you can tweak "consumer" logic for the representation, IntendedUse where the data itself isn't enough to decide how to work with it - imagine .txt file with track points that are ordered in some particular way so you might want to use this trait to hint how to work with the data.

We've also added Bundle trait that is basically list of list of traits and with it you can describe any hierarchy of related content - mostly useful for compound assets where individual file is not usable without others (or even folders) and you need to version it all together. As an example a shader, where you can have bunch of textures, and some shader definition itself (like .xml or .json). Then there is the Fragment trait where individual part can be used separately but you still want them to be associated in one version of one product. These are basically helpers to bypass relationship API.

There are some other changes defined by AYON core and the idea is that any addon in AYON can define their own traits if needed.

Since the traits in Media Creation are subset of our traits we hope that we can still be compatible (provided that some data conversion is done).

More in-depth document about AYON traits can be found here if you are interested.

Please feel free to post any feedback, hints or just discuss it here!

[feltech]

This is great feedback, thanks @antirotor. Many of the traits in the Ayon doc you linked should be brought across to MediaCreation. I really like the looks of your implementation - if only Pydantic generated C++ classes too (though a quick google reveals some projects that aim to do just that... 👀 )

SourceApplication that holds information about the producer application so you can tweak "consumer" logic for the representation

This is the sort of trait we'd expect a host to put on the Context.locale. However, we already have HostSession.host().identifier(), which provides the unique identifier of the host application. Is this insufficient for some use cases?

These are basically helpers to bypass relationship API.

Interested to find out more about this. Is there a particular reason you've avoided the relationship API for compound assets?

I note that you have separated MimeType from LocatableContent, whereas in MediaCreation mimeType is a property of LocatableContent. Is there a compelling reason for this, i.e. should we consider doing this in MediaCreation too?

Regarding the IntendedUse trait, is that just a kludge for cases where you don't have an appropriate trait (or set of traits) to describe some Representation? Or are there cases where it's the only solution?

[antirotor]

This is the sort of trait we'd expect a host to put on the Context.locale. However, we already have HostSession.host().identifier(), which provides the unique identifier of the host application. Is this insufficient for some use cases?

In this case we need to store the information along the representation. Sometimes it is impossible or very hard to get the information about producing application directly from the file format and whenever you want to work with this file you might want to apply some version/platform specific logic. There are also more complex scenarios where version consist of multiple files and each file can be produced by different application.

Interested to find out more about this. Is there a particular reason you've avoided the relationship API for compound assets?

Mostly because we don't have relationship API on this level. We have very powerful link system that can link virtually any entity together but with representation we need to deal with relationships within the representation itself. Yes, it could be solved by splitting any complex representations to simple ones and then link them together but that would need us to change a lot of internal logic inside. I think that for Bundle the relationship for OpenAssetIO can be provided by the manager plugin.

I note that you have separated MimeType from LocatableContent, whereas in MediaCreation mimeType is a property of LocatableContent. Is there a compelling reason for this, i.e. should we consider doing this in MediaCreation too?

That is pure mistake I need to fix 😃

Regarding the IntendedUse trait, is that just a kludge for cases where you don't have an appropriate trait (or set of traits) to describe some Representation? Or are there cases where it's the only solution?

I'd say both. It can serve as a hint how loader can use the data if there is ambiguity - for very real recent example: Mocha Pro, planar tracker can output tracked point in multiple format - some of them are simple .txt files but the points there are encoded very differently. It would be very difficult to describe it with regular traits to the point where you would have to reverse-engineer the file format itself to come with reasonable traits. It is therefor much easier to say - this .txt file has track point and is intedend to be used in After Effect CS6 for example. Or it might be two models in version - one "nice" and the other one triangulated so you might want to tag the triangulated one for "realtime use". In the last case it serves probably as a kludge for cases where you don't have proper traits defined (yet).