Looking for collaborators with an interest in KHR_xmp_json_ld

[andybak]

Open Brush and Open Blocks is going to need something like this to track authorship and licences in assets composed of multiple assets.

We don't have the resources to do this alone and I'm trying to resist the temptation to solve this in an ad hoc way.

So - this issue is a intended as a placeholder to see if anyone else has an interest in this and might want to share the burden.

For future reference - this might be useful to refer to: https://github.com/aaronfranke/godot-gltf-khr-xmp-copyright

[hybridherbst]

Consider us interested!

We probably should align on what properties make sense to expose in a nice way (the potential space of properties is very large), do you have an initial idea already on which you'd use the most?

[andybak]

We probably should align on what properties make sense to expose in a nice way (the potential space of properties is very large), do you have an initial idea already on which you'd use the most?

For us it's almost entirely about licence and attribution at the moment. But I can imagine other features we might want to propagate into the GLTF in the future (tagging is an obvious one. Our current schema can be seen here: https://api.icosa.gallery/v1/docs#/Assets/icosa_api_assets_get_asset )

Here's the Godot UI for reference:

( cc @aaronfranke )

There's a few related issues:

1. What validation on the JSON should be do (if any)?
2. How do we handle round-tripping?
3. How do we handle merging of metadata?
4. What Editor UI do we want to provide?

I raised a ticket on the Godot repo to discuss merging. It currently doesn't seem to do any (which is of course a valid design choice)

aaronfranke/godot-gltf-khr-xmp-copyright#2

[hybridherbst]

I understand the points about license and attribution, but which license and attribution namespace and schema would you want to use? XMP has multiple as far as I know :) We could default to Dublin Core?

Examples of XMP namespaces

• Dublin Core (probably? the most useful right now)
• XMP Rights (used for basic DRM)
• XMP Dynamic Media (used for creative works)
• XMP iptcExt (typically used for photographic work but has a wide range of properties applicable to other creative work)
• XMP Basic

And an attempt to answer your questions

1. I believe structurally it should just match the schema declared here https://github.com/KhronosGroup/glTF/blob/main/extensions/2.0/Khronos/KHR_xmp_json_ld/schema/glTF.KHR_xmp_json_ld.schema.json (which is "pretty much everything", which to the best of my understanding is intended)
2. We probably want a component for this, that can be added by the importer, that contains the full metadata as structured data in Unity to use at runtime
3. I believe it would become multiple packets of metadata that are then referenced from the respective data pieces
   1. How to connect metadata to data in the glTF is defined here, we'd have to decide on granularity: https://github.com/KhronosGroup/glTF/blob/main/extensions/2.0/Khronos/KHR_xmp_json_ld/README.md#instantiating-xmp-metadata
   2. This namespace is referenced from the glTF XMP_json_ld spec: https://github.com/adobe/xmp-docs/blob/master/XMPNamespaces/xmpMM.md
4. We'd probably want some "nice" UI similar to what you linked from Godot for commonly used properties (e.g. for Dublin Core properties), and then maybe just key-value foldouts for the rest

[andybak]

but which license and attribution namespace and schema would you want to use? XMP has multiple as far as I know :)

Ugh. This feels like something that should be part of the extension spec itself (or at least recommended within the extension spec)

What happens if we go ahead and stick attribution in one place and another extension puts it somewhere else? At the very least we need to have some consensus between all the client apps and libraries we want to honour our attribution data.

I'm honestly a bit stuck at this point. I almost feel like a separate "licence and attribution" extension would solve the problem better if XMP is so broad as to allow everyone to make difference decisions on where to store things.

Maybe I'm overreacting. Is there a de facto consensus on this that we can adhere to?

[andybak]

Maybe I'm overreacting. Is there a de facto consensus on this that we can adhere to?

Re-reading your post - do you think Dublin Core is a good bet here?

[aaronfranke]

Dublin Core is what I implemented in Godot, and it's what Khronos uses as the example.

[hybridherbst]

Thanks for confirming!

So the "probably useful subset" is Dublin Core Elements 1.1 with its 15 properties.

• This Dublin Core article has some interesting example snippets for how users might mix different metadata types and so on
• Don (cc @donmccurdy for visibility) has some info on the gltf-transform page, including additional relevant XMP namespaces
• Khronos has some 3D metadata recommendations

API-wise, that means we likely still want to retain all/most of the existing metadata in a file upon import, and reassemble it on export if desired. And the UI / no-code editing interface would be the XMP Dublin Core properties.

[hybridherbst]

An additional thought: a lot of assets already have metadata in asset.extras.

For example, all GLBs downloaded from Sketchfab (which in my experience ends up being a considerable chunk) have metadata like this:

"asset": {
    "extras": {
      "author": "re1monsen (https://sketchfab.com/re1monsen)",
      "license": "CC-BY-4.0 (http://creativecommons.org/licenses/by/4.0/)",
      "source": "https://sketchfab.com/3d-models/customizable-looped-animated-flag-16275de2d84a4727aee4812fc65f8181",
      "title": "Customizable Looped Animated Flag"
    },
    "generator": "Sketchfab-16.60.0",
    "version": "2.0"
  },

Potentially, some of these well-known metadata formats should be imported into the same "Metadata Component" and subsequently exported as KHR_xmp_json_ld. This would allow assembling a scene in UnityGLTF from Sketchfab assets (and of course other sources) and the new exports would track which resource in the new file came from where.

[donmccurdy]

In glTF Transform's CLI there's a gltf-transform xmp in.glb out.glb command with some interactive prompts for the most common (Dublin Core, mainly) XMP properties. Other namespaces can be used through the scripting API linked above. I've shared a few more details on how to use the scripting API with XMP in this thread:

• How to add multiple xmp properties? donmccurdy/glTF-Transform#1610 (comment)

Potentially, some of these well-known metadata formats should be imported ...

An easy way to convert these asset.extras properties into well-known XMP properties would be a good thing, agreed!