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