8 Ontology for the Harmonized Information Model aligned with oneM2M Base Ontology

The following table shows a mapping of the Harmonized Information Model (HIM) to the oneM2M Base Ontology in oneM2M TS-0012 [i.5].

Table 8-1 only shows mapping of SDT concepts that are used to classify all concepts in the HIM. Therefore, since any concept in the HIM can be classified according to a specific SDT concept it also (transitively) maps to the related class of the oneM2M Base Ontology.

Table 8-1: Mapping between SDT concepts in the Harmonized Information Model
and the oneM2M Base Ontology

SDT Concept in the Harmonized Information Model Mapping relationship Class in Base Ontology Property in Base Ontology Comment
SDT: Device sub-class of Device

SDT: SubDevice sub-class of Device
The base ontology allows a Device to consist of (sub-) Devices
SDT: Action sub-class of Operation

SDT: Args (of an Action) sub-class of OperationInput

SDT: ReturnType (of an Action) sub-class of OperationOutput

SDT: Event sub-class of Operation

SDT: Data (of an Event) sub-class of OutputDataPoint

SDT: Module
sub-class of
Service

The base ontology allows a Service to have subServices. Each SDT:Module implements one SDT:ModuleClass.
Therefore SDT:Module can be considered a subclass of SDT:ModuleClass and therefore subclass of oneM2M:Service.
See note.
SDT: ModuleClass sub-class of Service
See note.
SDT: UnitOfMeasure sub-class of MetaData

SDT: DataPoint sub-class of InputDataPoint
If SDT:DataPoint is writeable
SDT: DataPoint sub-class of OutputDataPoint
If SDT:DataPoint is readable
SDT: Property (of a Device) sub-class of ThingProperty

SDT: Property (of a ModuleClass) sub-class of Aspect
Aspect (of the Functionality)
SDT: SimpleType
sub-property of

hasDataType
The base ontology's SimpleTypeVariable class has data properties:

  • hasDataType
  • hasDataRestriction
SDT: Constraint sub-property of
hasDataRestriction
NOTE: In RESTful technologies the Service (i.e. the electronic representation of a Functionality in a network) is implicitly bound to its Functionality by the naming of the used resources (e.g. the Functionality of ModuleClass "[audioVolume](../5.3/#5318-audiovolume)" is implemented as a Service through CRUD operations on a [audioVolume] <flexContainer> specialization).