Like yesterday, summaries of two papers and a book. Classification of construction works
A paper by Anders Ekholm from 1996 called a conceptual framework for classification of construction works, introducing a lot of the research that ended up in iso 12006-2, let's say the SfB system. A general conclusion of the study is that the proposed framework is useful as a foundation for identifying classes for construction works.
He quotes Bunge, his favorite philosopher, by saying that conceptual representations of real things have shortcomings; they are incomplete and at best "fairly faithful". His suggestion is that to overcome these problems it is necessary on the one hand to make several different representations of the same thing, where each representation focuses on different aspects; and, on the other hand, to improve te existing representations by recurring research efforts.*
His focus is mostly on the design stage. According to Eastman, he quotes, a dynamic application of different aspect models in a design situation is the only viable approach to provide the building product model needed. So: mixing and matching. There is not one single perfect model of reality. We should live with that restriction, not try to come up with that single impossible model. We should describe concepts, viewed from a certain angle. A concept therefore represents certain properties of an object.
When having multiple concepts, described from different views, using those different views is a bit of a problem. In order to achieve clarity in communication, research and technical development it is necessary to have a common conceptual framework where basic terms and concepts such as property, thing, system and level are defined and related. Such a framework is of an ontological nature and represents the basic structure of reality, the concrete world of things. (Again some Bunge behind the scenes). So: some top-level description of very, very basic terms.
The rest of the paper discusses some proposed top-level concepts.
Again Anders Ekholm, together with Sverker Fridqvist (email ). A dynamic information system for design applied to the construction context, a short summary would be that in the design phase you need something way more flexible than a fixed set of objects.
An information system for design must support dynamic schema evolution. One way of formulating the critisism is that the traditional approach to product modelling is class centered, ant that it must be abandoned for an object centered approach. Why? Well, building design is an example of both routine and innovative design, the latter especially during early stages. The approach to building product modelling today, e.g. in CAD programs, does not support innovative design and is best suited for the later stages of the design process.
The rest of the paper delves a bit deeper into the theory (well readable!) and shows a prototype implementation.
One illustration inside the paper is especially well-done. Look at the pdf, page 6, figure 2. That's how you should make illustrations!
From Johan Veenbaas (colleague; sorry, no link: stabu.org website is horribly IE-specific) I got a book by Taeke de Jong (article in Dutch about his views). It is about a method for research with a big design component. Below you find some cherries I picked out of the book.
There are three kinds of future.
A lot of the "normal" research focuses on the probable future: based on facts you predict the future. You create new facts and all in all figure out how things are or how they are going to be.
You can present this also a bit differently. In Dutch it is a play with words: kunnen, kennen, kiezen. In English it is can, know, choose. Not three "c"s, but close :-)
There is a level of friction between "technical" and "science". "Design" and "Research". I'm doing research at a technical university, so I feel a bit of this friction. On the one hand you have to be really scientifically careful, on the other hand you need to think about new things, new possibilities. In the end you can only proof that your solution works by making a prototype or writing something really convincing. You cannot wait 10 years for an idea to prove itself in practice before getting your PhD...
If somebody has some more input on above paragraph, feel very free to email me
Something else: difference. Unity in difference. Things can be different. But you need some unity in their difference to be able to set them apart. Something cannot be redder than round or rounder than red. You can seperate blue balls from the red balls. If you make a difference, on what grounds do you make a difference?
When making differences, you're also saying some things are just the same (from your current viewpoint). Separating blue items from red items means that everything falls into the category "item".
When dealing with categories you're mostly looking at things that are the same, grouping them in that way. There are differences between the groups, but the similarities inside the group are more important.
On lower levels, below the classification level, you're in contrast more focused on the differences. You've gotten to a set of items belonging to a certain category ("reclining chairs"), now it's time to focus on that particular chair that will most fulfil your wishes.
My name is Reinout van Rees and I program in Python, I live in the Netherlands, I cycle recumbent bikes and I have a model railway.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):