Provide a xmp_json_ld metadata editor and storage

[fire]

Describe the project you are working on

A social vr project that wants to store an 3d asset inventory to do tagging and filtering for maps, props and avatars

Describe the problem or limitation you are having in your project

I want to store metadata in a standardized format during pipeline processing between editor upload, server storage and player browser preview.

Noticed other projects in the Godot Engine ecosystem:

• multiple NFT metaverse projects that can store copyright and other metadata in a gltf file for interoperability
• Studios want to itemize every single copyright in their game

Describe the feature / enhancement and how it helps to overcome the problem or limitation

I propose to create a system to store xmp_json_ld in the metadata section of objects and if the gltf export sees this metadata it will export gltf in a way that is compliant with the KHR_xmp_json_ld spec.

I also propose to have a xmp_json_ld editor for Godot Engine.

References

1. https://github.com/KhronosGroup/glTF/tree/main/extensions/2.0/Khronos/KHR_xmp_json_ld
2. https://docs.godotengine.org/en/latest/classes/class_object.html#class-object-method-set-meta

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

In Godot Engine objects:

1. Store in the metadata property of the Object class. Alternatively we can have a explicit xml_json_ld property since this data isn't related to the metadata section since it has a schema.
2. Name the variable "xmp_json_ld"

   [...]
   var scene_root : Node3D
   var xmp_json_ld : Dictionary = { "packets": Array[Dictionary] } 
   root.set_meta("xmp_json_ld", xmp_json_ld)

3. Show an editor for xmp_json_ld for the basic packet types in https://github.com/KhronosGroup/glTF/tree/main/extensions/2.0/Khronos/KHR_xmp_json_ld#implementation-notes

Since there is a limited time budget, I recommend we pick only a few of these. Let me know which ones are important.

XMP is an extensible metadata format by design. In order to achieve better readability and interoperability across the industry, we recommend glTF creators to use the following preferred list of namespace prefixes and URIs.

Preferred prefix	Namespace URI	Usage
dc	http://purl.org/dc/elements/1.1/	Dublin Core
xmp	http://ns.adobe.com/xap/1.0/	Basic Descriptive Information
xmpGImg	http://ns.adobe.com/xap/1.0/g/img/	xmp:Thumbnails
xmpMM	http://ns.adobe.com/xap/1.0/mm/	Media Management, used by Digital Asset Management systems
stRef	http://ns.adobe.com/xap/1.0/sType/ResourceRef#	xmpMM:DerivedFrom, xmpMM:Ingredients, xmpMM:ManagedForm
stEvt	http://ns.adobe.com/xap/1.0/sType/ResourceEvent#	xmpMM:History
stVer	http://ns.adobe.com/xap/1.0/sType/Version#	xmpMM:Versions
xmpRights	http://ns.adobe.com/xap/1.0/rights/	Legal restrictions associated with a resource
rdf	http://www.w3.org/1999/02/22-rdf-syntax-ns#	Resource Description Framework; Primarily used for Language Alternatives in XMP JSON-LD

See Krita's copyright screen for a possible design:

5. If a suitable metadata is found, a gltf document extension in gdscript can be written

@tool
class_name GLTFDocumentExtensionXMP # From @aaronfranke 
extends GLTFDocumentExtension

func _import_preflight(_state: GLTFState, extensions: PackedStringArray) -> int:
    if extensions.has("KHR_xmp_json_ld"):
        return OK
    return ERR_SKIP

func _parse_node_extensions(state: GLTFState, gltf_node: GLTFNode, extensions: Dictionary) -> int:
    if not extensions.has("KHR_xmp_json_ld"):
        return OK
    var xmp = extensions.get("KHR_xmp_json_ld")
    if not xmp is Dictionary:
        printerr("Error: KHR_xmp_json_ld extension should be a Dictionary.")
        return ERR_FILE_CORRUPT
    register_copyright_data_to_database_could_be_an_autoload_singleton_or_something()
    return OK

If this enhancement will not be used often, can it be worked around with a few lines of script?

This is not a few lines of script.

Is there a reason why this should be core and not an add-on in the asset library?

This can be an official addon and be on the asset library. I like writing design docs :D

[YuriSizov]

This is definitely perfect for an addon. I'm also wary of adding it in any generic way, because users will figure out how to abuse it for their own means, and we'll have to support it beyond the presented use case.

What could be interesting, if the goal is to power exporting Godot scenes as GLTF, is an introduction of a generic and native way to attach some authorship, version, copyright, etc information to PackedScenes. Then the GLTF export could read that info and generate the necessary XML JSON file/data structure as needed. This way it could be useful to a broader audience and won't introduce yet another meta format to the engine.

I can then envision an editor setting that automatically feels these fields for the scenes that you create or last edit locally.

[fire]

Well RDF and xmp (as specified above) is the result of decades of bikeshedding on the names of the metadata fields, I don’t think we can do better. I don’t think it’s simpler to redefine our own.

If we were to do it I would pick one of the metadata tag layouts in the table.

[aaronfranke]

@YuriSizov I had the same thought, already discussed with fire privately, thus the text at the bottom of the proposal:

This can be an official addon and be on the asset library.

Handling asset copyright information does not need to be in the core engine, but it would be nice to have it be an official add-on so that it can be more easily standardized for those who with to use it.

[YuriSizov]

@aaronfranke Well, I think what I describe could be made a part of the main distribution and either enable that plugin or even allow us to including this feature into the built-in GLTF exporter without burdening the core...

[aaronfranke]

Here is an add-on in the asset library for writing KHR_xmp_json_ld data on export, and reading on import: https://godotengine.org/asset-library/asset/2309 Requires Godot 4.3 or newer with #79316 merged.