About the file: BO_SAREF.owl
After the Release 3 version of the oneM2M base ontology (version 3.6.0) had been finalized in TS-0012, the BO_SAREF.owl file in this directory gives an example how it can be used in practice. As a natural candidate for that exercise SAREF (Smart Appliances Reference Ontology) has been chosen. The attached BO_SAREF.owl file imports both ontologies through reference:
<owl:Ontology rdf:about="https://git.onem2m.org/MAS/BaseOntology/raw/master/BO_SAREF.owl">
<owl:imports rdf:resource="https://git.onem2m.org/MAS/BaseOntology/raw/3_6_0/base_ontology.owl"/>
<owl:imports rdf:resource="https://w3id.org/saref"/>
</owl:Ontology>It contains sub-classing and sub-Properties relationships between SAREF and the oneM2M base ontology. By creating this sub-classing and sub-Properties relationships all SAREF classes (and any potential sub-class of SAREF classes) can be istantiated as oneM2M resources, using the instantiation rules in TS-0012 and TS-0030.
Not all classes / properties of SAREF could be described as sub-classes / sub-properties of base ontology (BO) classes / properties.
In most cases this is not an issue, since all classes / properties of SAREF indeed can be implemented as RDF data in <semanticDescriptor> resources, using the rules of TS-0012.
However, in oneM2M Solutions, that do not make use of <semanticDescriptor> resources, SAREF (or SAREF based) ontologies, devices and their services can still be instantiated with oneM2M resources, using TS-0030 as mapping rule.
Devices, Input/output datapoints can be implemented, however some other semantic information might be lost.
Problems found, but not yet resolved:
A particular problem arose with "saref:Property ". SAREF uses this class sometimes as classification:
- Device SubClassOf :IsUsedFor only (:BuildingObject or :Commodity or :Property)
Where "saref:Property " has sub-classes saref:Energy, saref:humidity, saref:Power, …
Sometimes SAREF uses this "saref:Property " class as in/output parameters of services.
- saref:Service SubClassOf :hasOutputParameter only (:Property or :State)
This seems to be an inconsistent use of "saref:Property " in SAREF and makes the sub-classing difficult.
Another problem was found in the oneM2M base ontology (BO) itself: The problem relates to the mapping of information contained in instances of "BO:Aspect" (e.g. the quality or kind of a BO:Variable) and " BO:MetaData" (e.g. measurement units) into oneM2M resources (<container>s or <flexContainer>s). The problem arises only for oneM2M Solutions, that do not make use of <semanticDescriptor> resources. The input/output parameters of a device (classes BO:Input/OutputDataPoint and BO:OperationInput/Output) and the properties of a thing (class " BO:ThingProperty") are derived from class " BO:Variable". Currently the class " BO:Variable" is related to classes " BO:Aspect" and " BO:MetaData" via relations (i.e. object properties):
- A " BO:Variable" " BO:describes" an " BO:Aspect"
- A " BO:Variable" " BO:hasMetaData" " BO:MetaData"
"Aspect" and "MetaData" are also related via:
- An " BO:Aspect" " BO:hasMetaData" " BO:MetaData"
While TS-0030 specifies how input/output parameters of a service of a device are instantiated as customAttributes of <flexContainer> service resources of the resource it does not specify how " BO:Aspect" and " BO:MetaData" should be instantiated.
According to section 7.1.1.2 of TS-0012 the resource types for instantiating these two should be the <semanticDescriptors>s of some <container> or <flexContainer>. The <semanticDescriptor> of the input/output parameters of a service contain the information where the <semanticDescriptors>s of " BO:Aspect" and " BO:MetaData" can be found.
If no <semanticDescriptors>s exist " BO:Aspect" and " BO:MetaData" can still be instantiated as <container> or <flexContainer>, however the linking between input/output parameter " BO:Variables" and related " BO:Aspect" and/or " BO:MetaData" is not specified. This remains to be solved in the future.
The following tables give an overview on sub-classing and sub-Properties relationships contained in BO_SAREF.owl:
Classes:
| SAREF Class | Is subClassOf Base Ontology Class | Comment |
|---|---|---|
| saref:BuildingObject | BO:ThingProperty | subClass relationship implemented in BO_SAREF |
| saref:BuildingSpace | BO:Thing | subClass relationship implemented in BO_SAREF |
| saref:Command | BO:Command | subClass relationship implemented in BO_SAREF |
| saref:Commodity | BO:ThingProperty | subClass relationship implemented in BO_SAREF |
| saref:Device | BO:Device | subClass relationship implemented in BO_SAREF |
| saref:DeviceCategory | BO:ThingProperty | subClass relationship implemented in BO_SAREF |
| saref:Function | BO:Function | subClass relationship implemented in BO_SAREF |
| saref:FunctionCategory | BO:Aspect | subClass relationship implemented in BO_SAREF |
| saref:Profile | BO:Thing | subClass relationship implemented in BO_SAREF |
| saref:Property | No subClass relationship implemented in BO_SAREF. -Could be mapped to "BO:Aspect" when used as: saref:SensingFunction SubClassOf saref:hasSensingRange some saref:Property Or mapped to "BO:Variable" when used as: saref:Service SubClassOf saref:has[In/Out]putParameter only (saref:Property or saref:State) Or mapped to "BO:ThingProperty" (i.e. a subclass of "BO:Variable"), when used as: saref:Device SubClassOf saref:IsUsedFor only (saref:BuildingObject or saref:Commodity or saref:Property) Or as: saref:Profile SubClassOf saref:hasProduction only (saref:Energy or saref:Power) and saref:Profile SubClassOf saref:hasConsumption only (saref:Energy or saref:Power) | |
| saref:Service | BO:Service | subClass relationship implemented in BO_SAREF |
| saref:State | BO:Variable | subClass relationship implemented in BO_SAREF |
| saref:Task | BO:ThingProperty | subClass relationship implemented in BO_SAREF |
| saref:UnitOfMeasure | BO:MetaData | subClass relationship implemented in BO_SAREF |
Object Properties:
| SAREF Object Property | Is subPropertyOf Base Ontology Object Property | Comment |
|---|---|---|
| saref:hasCategory | BO:hasThingProperty | subProperty relationship implemented in BO_SAREF |
| saref:accomplishes | BO:hasThingProperty | subProperty relationship implemented in BO_SAREF |
| saref:actsUpon | Inverse of: BO:exposesCommand | subProperty relationship implemented in BO_SAREF In BO an Input/OutputDataPoint or an Operation of a Service exposes a Command => In SAREF " saref:State " seems to be the counterpart to BO: Input/OutputDataPoint. saref:Command SubClassOf saref:actsUpon only saref:State =>Note: there exists no concept of an "Operation" in SAREF! |
| saref:consistsOf | No subProperty relationship implemented in BO_SAREF Either "BO:consistsOf " when used among devices as: saref:Device SubClassOf saref:consistsOf only saref:Devic Or " BO:hasThingRelation " when used among Profiles as: saref:Profile SubClassOf saref:consistsOf only saref:Profile | |
| saref:contains | BO:hasThingRelation | subProperty relationship implemented in BO_SAREF |
| saref:hasCommand | BO:hasCommand | subProperty relationship implemented in BO_SAREF |
| saref:hasConsumption | BO:hasThingProperty | subProperty relationship implemented in BO_SAREF |
| saref:hasFunction | BO:hasFunction | subProperty relationship implemented in BO_SAREF |
| saref:hasInputParameter | BO:hasInputDataPoint | subProperty relationship implemented in BO_SAREF Because saref:Property and saref:State are mapped to BO:Variable (which is parent of BO:InputDataPoint) Note: saref:Service SubClassOf saref:hasInputParameter only (saref:Property or saref:State) =>Note: there exists no concept of an "Operation" in SAREF! |
| saref:hasMeterReadingTime | No subProperty relationship implemented in BO_SAREF ??? unclear in SAREF ?? This and the next SAREF property defines a relation between a saref:Function and a saref:Property, which is mapped to BO:Variable. saref:MeteringFunction SubClassOf saref:hasMeterReadingTime min 1 saref:Time (which is a saref:Property) In the Base Ontology a BO:Function has BO:Commands but no Variables | |
| saref:hasMeterReadingValue | No subProperty relationship implemented in BO_SAREF ??? unclear in SAREF ??? saref:MeteringFunction SubClassOf saref:hasMeterReadingValue only (saref:Commodity or saref:Property) Wouldn't a Function have a Command which would actUpon a state. The state would then have a value and a time | |
| saref:hasOutputParameter | BO:hasOutputDataPoint | subProperty relationship implemented in BO_SAREF See: saref:hasInputParameter |
| saref:hasPrice | BO:hasThingProperty | subProperty relationship implemented in BO_SAREF |
| saref:hasProduction | BO:hasThingProperty | subProperty relationship implemented in BO_SAREF |
| saref:hasProfile | BO:hasThingRelation | subProperty relationship implemented in BO_SAREF |
| saref:hasSensingRange | No subProperty relationship implemented in BO_SAREF Because mapping of saref:Property is unclear e.g. saref:SensingFunction SubClassOf saref:hasSensingRange some saref:Property | |
| saref:hasSensingTime | No subProperty relationship implemented in BO_SAREF Because mapping of saref:Property is unclear | |
| saref:hasState | BO:hasThingProperty | subProperty relationship implemented in BO_SAREF saref:Device SubClassOf saref:hasState only saref:State (saref:State is mapped into BO:Variable) |
| saref:hasThreshold | No subProperty relationship implemented in BO_SAREF | |
| saref:hasTime | BO:hasThingProperty | subProperty relationship implemented in BO_SAREF |
| saref:hasTypicalConsumption | BO:hasThingProperty | subProperty relationship implemented in BO_SAREF |
| saref:isAccomplishedBy | Inverse of: BO:hasThingProperty | subProperty relationship implemented in BO_SAREF See: saref:accomplishes |
| saref:isCategoryOf | Inverse of: BO:hasThingProperty | subProperty relationship implemented in BO_SAREF See: saref:hasCategory |
| saref:isCommandOf | Inverse of: BO:hasCommand | subProperty relationship implemented in BO_SAREF See: saref:hasCommand |
| saref:isLocatedIn | BO:hasThingRelation | subProperty relationship implemented in BO_SAREF |
| saref:isMeasuredIn | BO:describes | subProperty relationship implemented in BO_SAREF |
| saref:isOfferedBy | Inverse of: BO:hasService | subProperty relationship implemented in BO_SAREF Inverse of: saref:offers See: saref:offers |
| saref:IsUsedFor | BO:hasThingProperty | subProperty relationship implemented in BO_SAREF |
| saref:offers | BO:hasService | subProperty relationship implemented in BO_SAREF |
| saref:represents | Inverse of: BO:exposesFunction | subProperty relationship implemented in BO_SAREF |
Data Properties:
| SAREF Data Property | Is subPropertyOf Base Ontology Data Property | Comment |
|---|---|---|
| saref:hasDescription | BO:hasThingAnnotation | subProperty relationship implemented in BO_SAREF |
| saref:hasManufacturer | BO:hasThingAnnotation | subProperty relationship implemented in BO_SAREF |
| saref:hasMeterReadingType | No subProperty relationship implemented in BO_SAREF | |
| saref:hasModel | BO:hasThingAnnotation | subProperty relationship implemented in BO_SAREF |
| saref:hasName | No subProperty relationship implemented in BO_SAREF | |
| saref:hasSensorType | No subProperty relationship implemented in BO_SAREF | |
| saref:hasSpaceType | BO:hasThingAnnotation | subProperty relationship implemented in BO_SAREF |
| saref:hasTask | No subProperty relationship implemented in BO_SAREF | |
| saref:hasValue | No subProperty relationship implemented in BO_SAREF | |
| saref:isFlexible | No subProperty relationship implemented in BO_SAREF | |
| saref:isInterruptionPossible | No subProperty relationship implemented in BO_SAREF |