An introduction to oneM2M's FlexContainer
This article gives an introduction to the <flexContainer> resource type in oneM2M and how to create your own specializations for your data models.
What is a FlexContainer?
In oneM2M there are two main types of resources that can store data.
The first category includes resource that store data in an opaque format, such as ContentInstance. Here, the application is responsible for defining the data structure and how to interpret the data. Here, the data is stored in a single dedicated attribute of the resource called content.
The second category are resources that store data in a structured format. One of these resource types is the <flexContainer>.
A <flexContainer> is a resource template that can be used by applications to either reuse standardized data models or to define their own ones by adding custom attributes.
Resources that inherit from the <flexContainer> resource type are called Specializations. Their names are wirtten in square brackets to distinguish them from normal resource types, e.g. [MySpecialization].
<flexContainer> specializations may have other <flexContainer> specializations as children. This allows to create complex, hierarchical data models.
How to Specify a FlexContainer Specialization?
A <flexContainer> is a normal resource that includes all the common attributes of a resource, and also adds a few resource specific ones to help to manage the stored data. In addition to these attributes, the <flexContainer> can have any number of additional custom attributes.
A <flexContainer> specialization adds these custom attributes to the FlexContainer resource type. This includes the definition of the attribute names, their data types, and the cardinality of these attributes. A schema definition then describes these atributes. This schema definition is identified by a reference stored in each <flexContainer> instance so that applications can interpret the stored data correctly.
FlexContainer and Specializations
A <flexContainer> is never instantiated directly. Only derived specializations can be created, updated, etc.
Example: Specialization [Colour]
Figure 1 shows the structure of a <flexContainer> specialization. The [color] specialization is from oneM2M's "common domain" and is called [colour], which results in the specialization shortname "cod:color"1 in the figure's grey part.
The yellow and green parts show the common, universal and resource-specific attributes. In the figure, the containerDefinition attribute with the schema identifier is shown.
The blue part shows the custom attributes that are defined for this specialization. In this example, the custom attributes are "red", "green", and "blue" that define the RGB color values.
oneM2M Information Model (TS-0023)
oneM2M specifies a fairly large number of specializations in its specification TS-00023 "SDT based Information Model and Mapping for Vertical Industries". These specializations can be re-used and combined to create more complex data models, for example to describe whole devices or systems.
The underlying idea is that a single specialization semantically represents a single functionality, such as a colour or a binarySwitch. Together, they are part of a deviceLight device.
An application may use only the specialization from TS-00023, or choose to combine them with new domain-specific specializations to represent a specific data model. Ideally, these new specializations are also published in the oneM2M specification to allow for interoperability between different implementations.
Conclusion
The <flexContainer> resource type is a powerful tool to create structured data models in oneM2M. It allows to define custom attributes and to combine them with standardized or custom data models to create more complex information models. This is especially useful when creating data models for devices or systems that are not covered by the standardized data models in oneM2M.
by Andreas Kraft, 2024-08-30
-
For specializations, the rule for the length of shortnames is 5 characters. See TS-0023, clause 5.2.2, "Description rules for Module Classes and DeviceClasses" for more information. ↩