Skip to content

NOTE: Data model component reusability

Ari Keränen edited this page Jan 17, 2019 · 1 revision

Re-usability is useful for data models because it saves effort when creating new models, enables re-use of tools and processes, facilitates interoperability, etc. When designing or evolving a data model, how can we achieve "best" re-usability?

Some relevant questions

  • What (level) should the atomic, re-usable pieces be in a "good" data model?

  • At the first IoTSI workshop we discussed atoms, molecules, and quarks of data models. What practical instances do we have for these?

  • Re-usability is often a trade-off: the more generic the more re-usable the atoms are but the less you can tell useful things about a specific case. Where is/are the sweet spot(s)?

  • What kind of characteristics should we fix in a re-usable component?

  • How can we achieve re-usability across data models?

Example: IPSO / LwM2M data model

Set of resources grouped into objects. Object can have mandatory and optional resources. Devices/things modeled as a set of objects. Numeric IDs are used for objects and resources and used as path components in URIs. Instance IDs used for having multiple instances of objects and resources. Composite object option for grouping objects.

The resources store and expose atomic values (string, float, Boolean, time, etc.). Resources have a defined name, data type, operation (read, write, execute), and description. Optionally also defined range and unit, and information of is this mandatory resource and can the resource have multiple instance.

Resources can be specific to an object or reusable across objects. Different numeric ranges are used depending if it's specific or reusable resource.

Examples of re-usable resources include current value, min value, max value.

Re-usable resource characteristics are fixed after registration. E.g., if range is defined, it can’t be re-defined in a new object.

Objects support versioning: minor version for backward compatible changes (e.g., adding optional resource) and major versions for backward compatibility breaking changes.

References: