UI layout is a combination of 2D, graphs and hierarchies and is best handled at the ontologies level. UI layout includes both hierarchy relationships, graph relationships and 2D positioning. Each level has a native organizational paradigm. For example the RDB level has relations. The object oriented level has hierarchies of classes, and the Endemes level has lists (and perhaps more, this is still being researched). The knowledge representation / ontologies level focuses on handling all kinds of relationships. Its native organization paradigm is probably the graph, but I see it as being the managing level for all other relationships.
For example, to efficiently, productively and beneficially do dynamic SQL generation in the OO layer, you need to have information about what each table, column, and relationship are and what these relationships all mean. This means one of the information levels. The endemes level does not seem to tend in this direction, so I proposed that these relationships be managed at the ontologies level. As ontologies are all about relationships, it makes sense that handling various kinds of relationships would dwell best at that level. Not just graphs.
Once you start using the ontologies level for UI management, then you can start including arrows in your UI’s much more frequently. In this way diagrams go from being very difficult to display and represent to manageably easy. Much of the time a diagram is the best way to represent some information. using the ontologies level for UI allows that.
Handling the way various components in a UI relate to each other is a form of information. This information is usually hard coded in a user interface layout and code. This means that users that want to see things differently can’t. This means that reorganizing a UI layout is done in code. The ontologies layer can move this into data and allow these sorts of changes to be handled by data.
So the best level for handling the complexities of the hybrid hierarchy and graph nature of user interfaces would best be handled at the level that handles relationships best – the ontologies level.
Here are some common organization paradigms and their native levels:
- graph [ontologies level] – A -> B [is a]
- subclass [ontologies level] – A .. B [inherits from] information ‘subclassing’ through information parameters and implementation
- hierarchy [object oriented level] – A: -B [has a] information ‘grouping’ through some generic structure
- list [endemes level] – A – B [after a] lists orderable by information
- Relations [RDB level] – A -< B [relates to a] table/column is addressable and characterizable, and business-rule-able