Composite Design Pattern in RDF/OWL

One of the strengths of RDF is that it encourages reusing ontologies through globally unique URIs and imports from the Web. There is a small but growing library of de-facto standard ontologies such as foaf, geo and dublin core that serve as building blocks for much larger ontologies. Standard building blocks support the development of generic tools and algorithms. For example, if an ontology uses the latitude and longitude properties from the geo ontology, then geo-aware tools can render the subjects on geographical maps. Without such standard properties, coordinates would just be plain numbers, and tools would need to guess whether they are intended to represent locations or not.

Taking this idea further, some RDF ontologies may even implement design patterns similar to those known from object-oriented systems. There is a well-known pattern called the Composite Pattern which can be used to represent part-of relationships. In a nutshell, this pattern defines a class Component and a class Composite, and a relationship between them to express a child-of relationship. This pattern is frequently used in user-interface libraries to represent the nesting of UI widgets inside of each other, creating complex hierarchies. When this design pattern is used explicitly, then development tools can render the structure of the hierarchy appropriately, e.g. in a tree view.

In the ontology/Semantic Web world, this pattern is also used very frequently. Several papers were written about representing part-of relationships. For our own work, we also re-invented this pattern numerous times. In addition to representing part-of relationships, we also find a recurring need to represent the ordering of the children. RDF is by definition unordered, and using rdf:Lists is often a pain to use. In response to these recurring requirements, I created a tiny RDF/OWL implementation of the composite design pattern, which can be found at

http://www.topbraid.org/2007/05/composite.owl

This is a trivial ontology, defining three properties only:

• composite:child is an object property pointing from a parent to a child
• composite:parent is the optional inverse of composite:child
• composite:index represents the index of each child among its siblings, typically starting at 0 for the first child

While this is a really tiny ontology, it can act as a quite powerful building block for larger models. In particular, TopBraid Composer 2.1 now has built-in support for this ontology. If you have imported the composite namespace into your model, then the form and the association tree will make use of the ordering using the composite:index property. In the following example, I have created a class Process with a property step which is a sub-property of composite:child. All children have an index attached to them, and the form will automatically order the children by their index. By default the ordering would have been alphabetically.

There are menu items to move children up or down. You can use the Associations View to display this relationship in arbitrary nesting:


We will add more support like that into future versions as we are exploring further design patterns. Feel free to reuse this composite ontology in your own projects and please let me know your comments (this blog does not allow comments since I received too much spam).