SDO was created as an abstraction that would be closer to the real world usage of data. This would free developers from the complexities of the underlying data repository. This abstraction maps very well to the abstraction of knowledge of OWL. Therefore, this makes SDO an excellent approach for accessing ontology information.
In addition, the real world view of SDO maps very well to the OWL classes expression. The mapping is actually quite direct. It’s as though the designers of SDO and the designers of OWL had the same understanding of information structure.
The direct mapping is shown in the following table. In this table, elements of graphs formed from an OWL class expression shown in the first column are mapped to elements of SDO in the second column:
|OWL Class Expression Graph||Service Data Objects|
|Class expression graph||Datagraph|
|Root node||Root node|
|Object property||Data Object property|
|Data property||Data property|
|Properties as a list of individuals||Property as a list Data Object links|
|Properties as a list of data values||Property as a list of data values|
Given the following class expression graph:
The mapping is shown below:
|Service Data Objects||Class Expression Graph Example|
|Datagraph||Class expression graph|
|Root node||Node labeled “Root”|
Root, Node1, Node2, Node3, Node4
|Data Object property||Functional object properties:
|Data property||Functional data property:
|Property as a list Data Object links||Object property with a set of individuals:
|Property as a list of data values||Data properties with a set of data values:
The mapping does not come entirely from the class expression. The constraints included in the OWL document also contribute. In OWL, a property may be defined as “functional”. In SDO, this means that the property will only have a single value. If it is not “functional”, then the property may have multiple properties.
This direct mapping provides the SDO capability to create, access, and update graphs defined by an OWL class expression.