Simplicity¶

Ontology/taxonomy simplicity¶

Basically, a catalogue with an item with components looks something like this:

Doorset (h=2.20m, b=2.40m)
*   Doorleaf  [2x] (h=2m, b=1m)
*   Doorframe [1x] (....)
*   Hinge     [6x]
*   ......

If this is the catalogue level, what’s needed at the definition level?

• Definitions of Doorset, Doorleaf, Hinge, etc.

• Properties h, b, etc. attached to the items where needed (see it as a service provided by the definition, it’s just plain handy).

• A unit should be attached to a property to prevent do-it-yourself-madness.

• Probably also needed is a way of saying whether a component is absolutely needed or not. A Doorset without a Doorleaf is pretty sad.

• Nice-to-have would be some level of “type hierarchy”, allowing you to select equivalent, but more specialised items instead of certain “base” types.

• Nice-to-have would be a grouping mechanism for properties, for instance for grouping all load-bearing-function-related properties.

Assumed mandatory is stuff like translations, textual explanations, synonyms.

There is no real need to restrict a lot of things. If somebody wants to put 428 hinges on one door then the definitions should allow it. The definition isn’t the one making the stupid catalogue and therefore isn’t the one to blame. The definition will be blamed if it’s too restrictive.

A logical result from the original emphasis on the resulting catalogue is that the list of properties attached to an object should be a list geared for normal usage. The list should not be excessively long, nor should it be restricted to the absolute minimum set of properties that really define the object.

Probably a system containing only above functionality won’t be able to handle a “full” taxonomy, that is, one big inheritance hierarchy encompassing all objects in the building industry.