Skip to content
Snippets Groups Projects
Commit 4fbee7bd authored by Joerg Swetina's avatar Joerg Swetina
Browse files

misplaced README_Base_Ontology_SAREF.md deleted

parent eb6ea9ae
No related branches found
No related tags found
1 merge request!12Example usage of the base ontology
This commit is part of merge request !12. Comments created here will be created in the context of that merge request.
Show whitespace changes
Inline Side-by-side
README_Base_Ontology_SAREF.md deleted 100644 → 0
+ 0
− 133
View file @ eb6ea9ae
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
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment