Sketch locale traits to aid entity resolution

[themissingcow]

What

The Context's locale serves to inform a manager about the nature of the host calling the API. One use of this is to hint the specifics of where a resolved entity may be used. This can be considered by a manager to adapt the data returned to the host.

Sketch locale traits that can be used to specify what data formats are supported by a host so a manager can make accurate choices about what data to return without specific knowledge of which host it is in.

Why

Many asset managers hold entities in a variety of formats to serve a variety of consumption environments. The host identifier could be used to select the most appropriate format, but this requires a lot effort, and of first-class support for each target application.

This defeats much of the point of OpenAssetIO - which aims to generalise these interactions to avoid needing application-specific logic.

There are many commonalities between DCCs, and so defining well-known locale traits that can refine what formats are supported in any given situation will greatly simplify the development of an efficient manager plugin.

[antirotor]

This is connected to an issue we are currently solving in OpenPype. As specific example - we have a model, that is represented by fbx, alembic, obj and lets say maya scene. It is part of the layout - basically description of what is located where together. Now - if you load such layout into one host, it is better to load all models in the layout as fbxes (for example in Unreal). But in another host it is preferable to get alembics and so on. We are solving it now with logic, that is inside each loader code - loaders can have preference over format they'll use. They themselves should know the best what is the most useful for its use inside that context.

So locale traits should provide information about requested use so the manager can perhaps use logic (if implemented) to do decide? Just a thought

[foundrytom]

So locale traits should provide information about requested use so the manager can perhaps use logic (if implemented) to do decide? Just a thought

Hey @antirotor - yeah - this would be ideal. Do you have any thoughts on how best to express this?

Are we aligned in hoping that over time, custom loaders would be replaced by native functionality in the hosts that resolved entities with the appropriate traits based on the most efficient or appropriate way to load the data?

One sketch we put together some time back as part of #4 was the idea of 'companion' locale traits that matched entity traits used for resolution. For example, the locatableContent entity trait (that resolves to a URL) could have a corresponding locatableContentAccess locale trait, that could have properties such as preferredMimeType or supportedMimeTypes.

An alternate idea was that we could add specific locale traits such as supportsUsd or usesOIIO and express things that way.

One consideration we could see with this is that many applications support plug-in extensions to what formats are supported, so it may be pipeline specific what the preferred format would be. Though I guess in that case it is easy enough to keep that logic in the manager plugin (either on the browse side, or the resolve side)?

[elliotcmorris]

I wonder now that mime type is in LocatableContent (https://github.com/OpenAssetIO/OpenAssetIO-MediaCreation/blob/8e3f932d7dbe4098683ed87dffce7bd0a1fa98fd/traits.yml#L65), is this enough information to solve these issues?

[feltech]

Putting supported file formats in the context has a big disadvanage if different parts of the application (e..g. different nodes) have varying support for file formats. In this case, the context locale would have to be mutated per node. This means batched queries would not be possible (or rather the batch would have to be split into multiple sub-batches).

One possibility is this is information could be encoded in the entity reference, as entered by the user or selected through an asset browser, making it pipeline problem, rather than a host or OpenAssetIO problem.

Another possibility would be to use relationships and have host applications query a top-level collection of files, all representing the same thing, for the child entity that represents a single format of that thing. However, this adds a lot of boilerplate and again affects batching optimisations.