8 Ontology for the Home Appliance Information Model aligned with oneM2M Base Ontology

The following table shows a mapping of the Home Appliance Information Model 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 Home Appliance Information Model. Therefore, since any concept in the Home Appliance Information Model 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 Home Appliance Information Model
and the oneM2M Base Ontology

SDT Concept in the Home Appliance 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 writable
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" is implemented as a Service through CRUD operations on a [audioVolume] <flexContainer> specialization).