We’ve been experimenting lately with something we’re calling “Property First Design.”  We’ve been noticing a kind of a slow unfolding of an idea that seems to be at the center of ontological design. 

In a traditional (relational or object oriented) design it is quite normal, in fact encouraged by the design methodologies to start your design with entities or classes.  Once you have your classes you can start putting properties (relationships and/or attributes) on them.  Indeed in a traditional design there isn’t much else you could do, because there would be no place to put the properties.

So, with Semantic Technologies properties are first class objects.  We could start with the properties.  But old habits die hard.  If you’ve been doing traditional design for decades, as we have, the habits are ingrained.  You will design the classes and add the properties to them.

There’s nothing wrong with that per se, but it blinds you to what could be.

We’ve been experimenting a bit with forcing ourselves to consider properties at least on a par with if not superior to classes.

Besides just the idea that it is probably worthwhile to challenge your own habits there is another reason to look at the problem differently.  With Semantics we’re in the business of attempting to generate consensus by leveraging a small number of shared concepts.  There is a rich pallet of options to do that when defining a class, but precious little when defining a property.  In other words it is possible to define a class in terms of other classes and properties, but you pretty much have to agree on the meaning of properties “out of band.”

An ontology with a lot of properties is one that you have to learn by either reading the comments or hoping there is a high correspondence between the label and what was intended. That’s our motivation for rethinking how we look at and approach ontological design.  In the next installment we’ll look at a couple of approaches we tried.