EXT_structural_metadata: Properties for structured data

[javagl]

The EXT_structural_metadata extension defines how fine-grained metadata can be stored within a glTF asset. It allows the definition of a metadata schema that describes the structure of metadata entities as classes, and their properties, including type definitions for these properties. The metadata storage defines how the metadata entities themself are stored inside the glTF asset. This is accomplished by storing the values as binary data in buffer views, using tables or attributes, or by storing the binary data in property textures.

---

Relation of this extension to EXT_mesh_features

The proposal "EXT_mesh_features: Features and Properties for structured data" presented an extension that allowed storing structured metadata that is associated with geometry and subcomponents of geometry within a glTF asset. The feedback from this PR suggested that there is a demand for separating the functionalities:

• Assigning IDs to features of a glTF asset like (vertices or texels)
• Associating features within a glTF asset with structural metadata

Therefore, the original EXT_mesh_features extension has been updated to only handle the definition of feature IDs for features within a glTF asset. The definition of metadata storage and its structure is now defined in a new EXT_structural_metadata extension that is presented here, and which has largely been extracted from the original EXT_mesh_features extension proposal.

The extensions are still designed to be interoperable, insofar that the IDs that are assigned to the mesh features with the EXT_mesh_features extension can be used for looking up the structural metadata that is defined via the EXT_structural_metadata extension.

[JMLX42]

Excellent idea!

If you don't mind me asking, what is the rationale against using XMP/JSON-LD like the KHR_xmp_json_ld extension does?

There are at least 2 reasons for using XMP/JSON-LD:

1. Having one single standard used to define rich metadata would be more convenient for implementation.
2. Unlike JSON Schema, the XMP/JSON-LD is not just a format/notation system. It builds on the semantic Web standards. As such, it already features a rich ecosystem that the proposed feature could leverage. Examples:
   • The ODRL standard could be leveraged to define per-vertex permissions
   • The Web Annotations standard could be leveraged to have per-vertex annotations

[javagl]

I added a response in the other PR. Maybe for the first iteration, this can be kept in one place.

[lilleyse]

A couple high level questions:

• Should "Property Tables", "Property Attributes", "Property Textures", and "Assigning Metadata to glTF objects" be separate extensions of a base extension? They are different encodings of the same schema system.
• Should property tables reference accessors instead of buffer views? Would depend on EXT_accessor_additional_types and possibly a generic accessor quantization extension.
• Clarify the use of non-8-bit-channels in property textures CesiumGS/3d-tiles#748

[CLAassistant]

All committers have signed the CLA.