Ideas for structuring Metadata Semantics

Each property of a metadata class can have a Semantic. This is just a string that can be used to assign an application-specific meaning to these properties. A collection of semantics is currently summarized in the 3D Metadata Semantic Reference README.

This form of maintaining the semantics reference has some limitations:

It is not clear how clients/users could define their own custom semantics (e.g. whether there are naming conventions, or how to avoid ambiguities and name clashes)
It is never clear which set of semantics "exist" - where "existing" means "being defined in some README" or "being supported by some implementation"
The set of existing semantics is not structured. Currently, there are (soft) conventions for the existing ones: They are separated into "General" ones, some for "Tiles", and some for "Content", and what they refer to is indicated by a prefix of the name (namely TILE_* or CONTENT_*), but there is no concept for enforcing or extending this.
The types of the semantics are not known at runtime

(The list of available ones are known at runtime in CesiumJS - via the MetadataSemantic class. But this does not include real type information, and has to be aligned with the README manually, and is not a scalable solution).

One option to ~~solve all problems~~ alleviate some of these limitations could be to define the semantics in a schema. And this could actually be pretty much the 3DTILES_metadata schema. An example of two of the existing semantics and how they could be defined in a schema:

"schema": {
  "classes": {
    "CesiumContentMetadataSemantics": {
      "properties": {
        "CONTENT_BOUNDING_BOX": {
          "name": "Content bounding box",
          "description": "The bounding volume of the content of a tile, equivalent to tile.content.boundingVolume.box",
          "type": "SCALAR",
          "componentType": "FLOAT32"
          "array": true,
          "count": 12
        },
        "CONTENT_MINIMUM_HEIGHT": {
          "name": "Minimum content height",
          "decription": "The minimum height of the content of a tile above (or below) the WGS84 ellipsoid. ",
          "type": "SCALAR",
          "componentType": "FLOAT32"
        }
      }
    }
  },
}

The advantages:

The schema (and available semantics) could be maintained in a human- and machine-readable form
It could contain a name and (importantly: ) a description that corresponds to the current contents of the README
Loaders could just load the schema, and iterate over all semantics
The type information can be included and checked programmatically at runtime
There could be some sort of "namespacing": There could be a CesiumContentMetadataSemantics schema and a CesiumTileMetadataSemantics schema. Clients could create their ClientMetadataSemantics schema cleanly
The custom schemas could probably be easily loaded in CesiumJS, so that the corresponding custom behavior could easily be implemented on top of that
Yadda, yadda: The README could be auto-generated from that, if necessay, with some fairly simple "schema-to-markdown-table" tool

The limitation:

Currently, some semantics have different possible component types (e.g. FLOAT32 or FLOAT64). This is not possible with a schema.

This could be seen as a limitation. Or as a flaw in the current way of defining semantics 😬 At least I think that it could be nice to only allow one component type. In many cases, it should be possible to

resort to the "larger" type (i.e. use FLOAT64, and "downcast" at the point of using it, if necessary)
if absolutely necessary, one could define multiple semantics, like CONTENT_MINIMUM_HEIGHT_32 and CONTENT_MINIMUM_HEIGHT_64 - not pretty, but unambigious, at least...

CesiumGS / 3d-tiles

Ideas for structuring Metadata Semantics #643