Properties and Data Types

1. Overview / Introduction

This document explains how attribute values and data types are handled in the SBE Platform. These types form the lowest unit of expression in the platform's Digital Thread and support ingestion, manipulation, and distribution of data through models and their properties. As of platform v6.4, there are three broad categories of types:

• Native types: Fully supported, universally interoperable types.

• Power types: Recognized but not universally supported types.

• Custom types: Flexible, user-defined types for special use cases.

These categories help ensure flexibility and extensibility across heterogeneous digital tools and data sources.

2. Conceptual Role

Properties in the platform represent data attributes of models. The type system gives structure to these values, ensuring interoperability, validation, and consistent behavior across services like UI, search, SDK, and adapters. Types encapsulate the nature and constraints of data values and define their treatment across all system boundaries.

Without a strong type system, the SBE platform would not be able to reliably serialize/deserialize, diff/merge, search, or validate attribute values across the digital thread.

3. Design Rationale

The categorization into Native, Power, and Custom types was introduced to meet growing needs for expressiveness and compatibility:

• Native types (boolean, string, integer, float, timestamp) are fully supported across all platform services.

• Power types support complex representations (e.g. 3DPoint, Matrix, Image) using JSON or Base64, enabling richer semantics but with limited platform-level support.

• Custom types provide user-defined value types that are ingestible and transportable but lack deep platform support (e.g., search, UI editing).

This layering of support allows developers to trade off between convenience, interoperability, and specificity.

4. Relationship to Other Resources

Data types are deeply integrated into the following system components:

• Clazzes: Properties are defined on a clazz using property specifications. Every property has a type and format.

• SDK & Adapters: Responsible for serializing/deserializing data according to the type definitions.

• Models: Models contain a list of available properties as defined by the model’s origin reference. A model may contain values for each property. The value is restricted to the type and format assigned to the property.

5. Conceptual Usage Patterns

Native Types

Formats

Formats are the containers to internal representation of the value object. Native Types have their own formats and also support the array format. Following are all the types (and characteristics) that work with platform today:

Formats for Types

Capabilities

The table below gives a high level information of how the various types/formats work with various facets of the platform.

• Interop > Defines if the type can be processed by interop layer (publish/refresh/sync)

• Search > Defines if these can be used within search parameters based on the type

• UI > Defines if these can be accurately rendered or modified via SBE UI

• DT > Defines if all digital thread operations like diff-merge are supported. Some partial support can be expected for all formats

• SDK > Defines if SDK can parse these objects and send it to platform in an processable manner

Note that the platform can and will only verify if the payload is well formed in case of user defined types like JSON or BASE64 encoded byte[].

Power Types

Formats

Power Types have 2 available formats – JSON and Base64.

Power types following are a list of custom types that have been identified and examples of their corresponding JSON formats. Some of these have been gleaned from SysML value types, OWL value types and MATLAB datatypes.

Types

{
    "x": 1.2,
    "y": 3.4
}

{
    "x": 1.2,
    "y": 3.4,
    "z": 5.6
}

{
    "m": 2,
    "n": 3,
    "value": [
        [1,2,3],
        [4,5,6]
    ]
}

{
    "xx": 1.0,
    "xy": 1.1,
    "xz": 1.2,
    "yy": 2.0,
    "yz": 2.1,
    "zz": 2.2
}

{
    "real": 3.14,
    "imaginary": 1
}

{
    "value": "0.04445205780538396",
    "precision": 16,
    "scale": 8,
    "roundingMode": "HALF_EVEN"
}

{
    "mediaType": "text/uri",
    "encoding": "base64",
    "value": "GZkc2Z…yBm"
}

{
    "mediaType": "text/html",
    "charset": "UTF-8",
    "encoding": "base64",
    "value": "GZkc2Z…yBm"
}

{
    "mediaType": "image/svg+xml",
    "encoding": "base64",
    "value": "GZkc2Z…yBm"
}

    {
        "colorModel": "RGB",
        "name": "dark blue",
        "r": 232,
        "g": 120,
        "b": 3,
        "a": 1
    }
    
    {
        "colorModel": "CMYK",
        "name": "magenta",
        "c": 232,
        "m": 120,
        "y": 3,
        "k": 234,
        "a": 1
    }
    
    {
        "colorModel": "HSL",
        "name": "dark blue",
        "h": 232,
        "s": 120,
        "l": 3,
        "a": 1
    }
    
    {
        "colorModel": "HEX",
        "name": "blue",
        "hex": "67CAFF",
        "a": 1
    }

{
    "hh": 10,
    "mm": 10,
    "ss": 10,
    "sss": 10
}

Capabilities

Below table gives a high level information of how the various types/formats work with various facets of the platform.

• Interop > Defines if the type can be processed by interop layer (publish/refresh/sync)

• Search > Defines if these can be used within search parameters based on the type

• UI > Defines if these can be accurately rendered or modified via SBE UI

• DT > Defines if all digital thread operations like diff-merge are supported. Some partial support can be expected for all formats

• SDK > Defines if SDK can parse these objects and send it to platform in an processable manner

Custom Types

Custom Types can be defined with 2 available formats – JSON and Base64.

These are defined, serialized and de-serialized by adapter developers with any associated contracts on schema and behavior agreed via any out of band mechanism. The platform will treat it like raw byte[] or schema-less JSON document for transport.

6. Common Pitfalls, Misunderstandings, and Troubleshooting

• Any value/attribute/property set with an empty/default value (like "" for STRING) is treated as an unset (equivalent to null) within the platform. This is due to the strongly typed nature of transport mechanism across many parts of the platform.

• Power types have limited support in the SBE UIs. A value for a power type may not be editable. It may also be shown it its raw, encoded value.

• Arrays of native types must follow strict formatting (comma-separated, validated).

• Custom types are opaque to the platform; SDKs must handle them manually.

• Forgetting to base64-encode values for formats like HTML, Image, and URL.

• Missing dataformat annotations cause misinterpretation during serialization.

8. Further Reading

• Ontologies

• Models