The Two Laws Of Dimensional Ontology

The Two Laws Of Dimensional Ontology

• Law I
  • "One and the same phenomenon projected out of its own dimension into dimensions lower than its own is depicted in such a way that the individual pictures contradict one another."
• Law II
  • "Different phenomena projected out of their own dimension into one dimension lower than their own are depicted in such a manner that the pictures are ambiguous."

I think this is two laws somehow explain what happens when we try to use a model to describe stuff in the real world, we end up representing things inaccurately and incompletely... the funny things that sometimes we seem to somehow change our angle of perspective, and then we realize that the our model is wrong... and try to fix it, and after that we believe that now it is right, but we will never have it right because the map is not the territory. Perhaps a similar problem arises when we try to use ObjectRelationalMapping, we simply lose some of the information because of the perspective we choose to use... Object Orientation forces a particular structure it may not exists... and Relational... trying to see things from a neutral point of view end up not being helpful enough: it seems that humans tend to need to see things from a particular hierarchical perspective at a time, and find it hard to grasp things from all points of view at the same time.

I started to think about this, because as a software engineer I am sometimes asked to create documentation about the software I am building (you know, the typical use cases stuff), and when you have to write a document of the kind a lot of times, the company where you work typically already have some document templates... now, typical document templates have a hierarchical (object oriented?) structure:

• UseCases
  • UseCase1
    • Scenario 1
    • Scenario 2
    • Actors that participate in the use case
    • Classes (sterotyped as boundary in RobustnessAnalysis) that participate in the use case
    • Classes (sterotyped as control in RobustnessAnalysis) that participate in the use case
    • Classes (sterotyped as entities in RobustnessAnalysis) that participate in the use case
    • ActivityDiagram?

But then, they realize that some times, (for example to decide what uses cases will be affected by the modification of an entity class) they also need a document like this:

• Classes
  • Classes (stereotyped as boundary in RobustnessAnalysis) that participate in the use case
    • Class 1
      • Use case 1
      • Use case 2
      • Actors interacting with the class
    • Class 2
      • etc,etc.

Both documents have kind of the same internal model, but represent (view it?) form a different perspective, now, the strange thing, is that I do not know of a commecially successful desktop publishing and/or word processing application that allows you to specify such a model so that you can describe your system once and only once and produce documents with several perspectives (I know products like Adobe FrameMaker are supposed to help you with this kind of semantical document structure, but, since they are (AFAIK) internally based on hierarchies, and not relational theory, they do not really allow the user to use all the power of the relational manipulation of data) I think that the problem might be that humans usually organize their ideas following some kind of hierarchical structure... or at least thats the way we are thought to do it at school, perhaps because of the limitations of printed material (a book made of paper can not be queried and reshaped relationally). But, now that we have all this electronic power to help us, we still try to organize stuff in hierarchies (or in messy graphs) and not relationally (internet is a messy graph, no a relational database... am I wrong? XHTML/XML are hierarchical, nobody would accuse them of being relational). We simply find it easier to organize stuff in that way... is it really because that is the natural way in which we think? or is it because we still do not have good enough relational tools to deal with knowledge? is relationally actually about creating a model that is valid from any perspective? or it is more about easily changing the perspective? (But if we build those model from particular perspective, how can we expect relational to produce a model that is valid for more than one perspective?) And finally, why we do not have any Relational Word Processor/ Relational Document Standard

Life is a Wicked Problem

Yesterday I was reading about studying online (in the OpenUniversity), I was gladly surprised to see that some of their courses are now available on line for free, and, that you can even remix the content using a free software for mind maps built bye the Compendium Institute, the funny thing is that I ended up finding information wicked problems (and currently I have one, choosing the java frameworks we will use at my current job)... wicked problems are those that (from Wikipedia):

1. There is no definitive formulation of a wicked problem
2. Wicked problems have no stopping rule
3. Solutions to wicked problems are not true-or-false, but good-or-bad
4. There is no immediate and no ultimate test of a solution to a wicked problem
5. Every solution to a wicked problem is a "one-shot operation"; because there is no opportunity to learn by trial-and-error, every attempt counts significantly
6. Wicked problems do not have an enumerable (or an exhaustively describable) set of potential solutions, nor is there a well-described set of permissible operations that may be incorporated into the plan
7. Every wicked problem is essentially unique
8. Every wicked problem can be considered to be a symptom of another problem
9. The existence of a discrepancy representing a wicked problem can be explained in numerous ways. The choice of explanation determines the nature of the problem's resolution
10. The planner has no right to be wrong (Planners are liable for the consequences of the actions they generate)

And it turns out that:

• Software development is a wicked problem (and that is my job)
• Life is a wicked problem (and... well, I am alive)

One thing I specially liked was a document explaining in a very detailed how wicked problems happen (read it here), and it turns out that a really good way to explain it is with a graphic, like this one.

Now.. that image can be produced, by thinking that each person participating on the solving of a wicked problem has his own "pendulum" and moves from "solution thinking" to "problem thinking" on his own, not synchronized way... if find this funny... because a few days ago I was seeing Kent Beck's presentation "Ease at Work", where he describes how a lot of software developers feel (one day we are super wizards... the next we are crap.... the next we are wizards again), but we are not hired and fired in perfect sync with how we feel (sometimes we are even treated as wizards while inside we feel like losers and vice versa), and in his presentation Kent Beck says that software development is not only about programmers, that is about people, people interacting to get a problem solved (you can't have a software business without software developers, but you also can't have it without managers, even if it just a "change of hat"), so, this got me thinking... that the problem Kent Beck is describing, is precisely, a Wicked Problem. What do you think?

Objecthood!

According to the wikipedia, objecthood is: "is the state of being an object." I particularly liked that article, specially the part that says that:

"Theories of objecthood address two problems: the change problem and the problem of substance."

The answer to change problem is the answer to the following question, if object manifest themselves as cluster of properties... if you remove all the properties... what remains? According to substance theory, the answer is a substance (that which stands under the change)... if we apply this to Object Relational mapping... then.. the objectId (primary key) is the substance? Could this be used as a philosophical justification for the immutability of the primary key?

Then the text in the wikipedia continues: "Because substances are only experienced through their properties, a substance itself is never directly experienced." Is that a justification for never using the id (keeping it private)? Of course, there is another theory, the theory that since substance can not be experimented... then it doesn't exist, that is the "bundle theory".

In bundle theory all objects are merely a cluster of their properties and therefore... everything changes always... and no such thing as object ids/ primary keys really exist in the real world. This has an impact in relationships too, because we usually define a relationship as something that binds together 2 or more objects (at their substance level?)... but since object's substance doesn't actually exist then there isn't such thing as a "relationship" between two objects..

According to this relationships can only exist as something defined at the "property cluster level".. two (or more) objects aren't really related at the substance level... they simply "share a property" (is that why in SQL there isn't a way to make queries taking advantage of the integrity relationships? is "shared property" a better name for integrity relationships?)

And the thing gets worse: "Whether objects are just collections of properties or separate from those properties appears to be a strict dichotomy. That is, it seems that objects must be either collections of properties or something else." Is that the philosophical foundation for the "object/relational impedance mismatch"?

It seems that the conflict between a relational (bundle theory) and object (substance) worldview is there since way before a relational database or an object oriented language was invented...

I wonder what else could I learn from reading about this philosophical theories... (could there be a third one? is there a software programming paradigm for it?)