Ideas for structuring Metadata Semantics

[javagl]

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...

[lilleyse]

Related issue: #574