Example usage of the base ontology
Compare changes
- Joerg Swetina authored
README_Base_Ontology_SAREF.md deleted
100644 → 0
+ 0
− 133
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.
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):
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.
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: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: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