thesis

Riya seems to be a pretty promising set of technologies, although whether or not it pans out to be a successful product is another story. At the core of Riya is a set of facial and text recognition algorithms that can intelligently identify people or keywords within photographs. Consequently as photos are added to the gallery rich meta-data can be passively pulled from the photos without any user interaction. In instances where a person or text cannot be identified it is possible to manually add this meta-data or have others supply further tags to your photographs to identify people in crowds or foreign words.

Fluxium caught my attention the other day as browsed through the articles in my newsreader. Initially what brought me to the site was a posting by Geoffrey Grosenbach referring to what Thomas Fuchs was doing that was to sensitive to comment on publically until very recently. The Quicktime promo movie looks very promising indeed especially for someone in the photographic industry. I really like the way resources can be easily tagged and shared between other people in a manner that seems more graphical and targeted than Flickr's generic gallery system. The graphical interface was very slick and entirely web (html/css/javascript) based. Of real interest to me was the obvious role of RSS in the application. Prominent RSS feeds were in the demo but the extents  of their functionality was unfortunately not covered in the demonstration. Given the intelligence of the developers I would not be surprised if RSS functionality was extensive and well thought out.

In order to test my assumptions regarding the digital habits of New Zealand architecture practices I put together a few questions and informally emailed a number of my friends. Thanks to the power of the forward button I got many more responses than I hoped. Below is the five quick questions I asked with the intention of justifying my own position on the subject matter:

1. When dealing with design variations (at a conceptual or development level) do you work on the same file or create a new file and keep the other versions for reference?

Ignoring front-end clients which could come in a multitude of formats (from web browser to CAD plugin) the backend application would be divided into three major backend pieces.  These pieces of functionality are divided in order to maximize deployment flexibility in a multitude of environments. The system uses two accepted methods of data transfer on the Internet: email and file transfer via a server (FTP/HTTP). By using a standard, non-proprietary means of data submission a multitude of clients can be supported or built using existing technologies. The three back-end components to the application are:

In previous meetings Mike and I have discussed how the system would operate (along with a lengthy discussion about Google Maps/Earth). One import issue Mike brought up was the role of versioning and how that would play out in the system. I think at this point there is a distinction to draw between the IT/programming concept of 'versioning' and one an architect may hold. In programming versioning is the process of tracking changes from a given point in time based on a set of very clearly defined parameters.

I often wonder what the Google founders were researching at University and if it had anything at all to do with Google or Internet search. Assuming they did and they decided to tackle the problem of 'relevant search' I am then left wondering how do you academically describe 'relevant' in a way that is testable.

My direction has been set primarily by a bunch of observations gathered from a number of other issues in the modern AEC environment. There are some clearly identified issues with the rigidness of the briefing process that are an ongoing concern within the industry. An issue I have been grappling with is how brief requirements and conceptual issues can be maintained and reevaluated throughout the design and construction process. Following a traditional process a briefing document is prepared and the architect responds to this with a set of working drawings. Other participants (contractors, engineers and consultants) typically only interact with these formal working drawings or the completed work. As a consequence of this reinterpretation the consumers (client/occupants) find it difficult to change their requirements whilst the producers are left with a partial understanding of the overall intentions and evolution of the project.

Solving this problem is reliant on clear and consistent communication. A major issue in communicating architectural ideas is the language in which this conversation takes place. An obvious focus for this debate is the richly detailed computer models that constitute a large portion of contemporary project documentation.  Building Information Model (BIM) theory is attempting to establish a unified 'model' in which the life-cycle of of building can be tracked and monitored. Unfortunately the structured nature of this model makes capturing and relating informal conversation about a project very difficult and time consuming as fitting these snippets of information into a highly structured model is very difficult (and adapting existing models to suit informal structures impossible).

Compounding the BIM advocates is the limited degree of Information Technology uptake throughout the AEC industry. Whilst proposing the use of highly technical BIM's may suit the management tier of a project (architects, engineers and consultants) it does not 'downsize' well into the production arena where technology skills and resources are low or enable those unaccustomed to the concept (clients and occupants) to participate at an even level. What is required is a lowest common denominator means of transferring and storing this informal conversation in a manner that facilitates later reuse in the design process or within a much higher level Building Information Model.

These issues all fall under the general umbrella of 'knowledge management' which is a formal term for 'stuff we should really note down and hopefully don't forget'. Whilst at the Manchester conference last year I sat through many (rather dull) presentations about the subject and how it fitted into the AEC industry. Given the level of interest at academic and even professional levels there is obviously some demand for knowledge management but I think it should be known more appropriately as information reuse. Knowledge is something that you have learnt over time through the process of doing and parsing different information sources.  

Over the past month Mike and I have had three meetings that for one reason or another I haven't documented. The weather has been very nice, usage of my Webmin Theme has taken off like a rocket (1,300 downloads and counting) and I bought the complete third and fourth seasons of the West Wing on DVD the other week.

Our meeting on the 20th of September primarily dealt with versioning and the problem of identifying when and how a change takes place. I have a post that is three-quarters written that deals with this subject so I will leave this topic for the time being. The next meeting covered the question of how whatever model come up with can be tested. Whilst the notion of making an interesting piece of software is worthwhile from a technical perspective through the academic lense such a folly is unjustifiable if the end result cannot be soundly analysed through critical testing.

AutoDesk have released a freely downloadable dwg viewer. Whilst it clocks in at a whopping 100meg and is Windows only it does finally provide a free way of natively reading dwg files using only AutoDesk software. Things could be a lot better but at least AutoDesk has a free product on the market for doing this (now they just need to do something that runs on OSX and Linux).

Last Tuesday Mike and I met for a discussion on things. I was meaning to put an overview of what we talked about online sooner but it slipped my mind. Actually a far more interesting thing entered it - the home theatre system I bought the next day...

For the most part we discussed how the concept of 'rich and unobstructive' connections could be made a reality. Definitely the 'tagging' concept so well implemented in systems like Flickr would be a real benefit in such a system especially when it comes to the difficult task of categorising resources (text, images and CAD files) for searching. The ability for users to easy tag resources (be it theirs or others) would enable a degree of human searching not present in a contemporary model. Once use instance of this could be the client tagging product fittings they like and then having the architect place style tags next to them (i.e. postmodern, classic). Using these tags you could then pull slices out of the conceptual work such as 'classic, low-cost fittings that we (as in the client and architect) like'. Alternatively in a construction scenario the ability for the contractor to tag documents pertanent to a specific contractor would ease some documentation headaches (if I change this drawing who will be effected?).

Before moving on I must say the last couple of weeks have been much better than previous ones. The once problematic client server is now behaving itself beautifully and I have even had a chance to document it all so I (or anyone else) can do the same thing all over again. Now back to more interesting things (if you do not consider SAMBA networking and Logical Volume Management boring)....

To recap this thesis aims to deal with the informal knowledge that slips between the cracks as an architectural project evolves. The process of architecture is very good at documenting the formal, whether is be in the form of a comprehensive brief or a set of working drawings. What I believe has been lost is the informal glue that holds all of these formal pieces together. Whether or not this informal glue ever existed is a matter for contention. The 1998 report by the UK Construction Task Force titled 'Rethinking Construction' sited major issues with the briefing process and the manner in which information from different strands of development failed to be applied in the final construction. The big issue here is that you have a lot of people doing many different things at the same time and most of it somehow impacts on the way others will be working or set-out to solve problems. When design or construction documentation is exchanged it forms the basis for a whole series of informal and formal discussions that in most cases remained contained within a particular group of people. At the moment, apart from sitting in on every meeting and listening to every conversation, there is no easy way of determining how the project is proceeding and what changes are taking place that my effect a particular aspect of the project.

A considerable amount of knowledge is also lost during transition phases like moving from design to construction or at the point of hand-over. At these times often documentation is paired down and tidied up to meet formal requirements (such as building handbooks). When applying a Building Life-cycle approach to this information it is only logical to consider how the informal discussions and decisions fit within this information puzzle.

In the late 1990's project intranets where targetted as a useful way of storing project pertanent information (Zarli, Richaud, Buckley. Requirements and Trends in Advanced Technologies for the Large Scale Engineering Uptake, 1998). Products like AutoDesk's Buzzsaw and CollaborIT. Given the amount of 'buzz' at the time very few projects adopted a project intranet style of approach. A primary reason for this limited uptake I believe is the potential productivity gains of using a centralised system are outweighed by the time and resources needed to setup the process. Tools like email can be easily applied within project groups as it is ubiquitous whilst more powerful groupware tools like Microsoft Exchange or Novell Groupwise could not.

A couple of weeks ago I talked with my supervisor Mike Donn about these things. In our discussions we talked about testing a pilot system out with students. The idea would be that a class would use an online information gathering system and then at the end of the process evaluate how their thoughts as recorded in the system influenced the outcome of a design produced by a second or even third person.

Mike also wondered what role the project schedule played in the system. This was an interesting angle that I had not considered. On thinking about it including the project schedule (both proposed and actual) made a lot of sense as much of the information gathered was time sensitive and related to the task at hand. The project schedule could also play a very useful role in passive data gathering. If a user's diary recorded they were working on a particular part of the building then any observations made by them at the time would more than likely be related to some aspect of that work.
He raised a number of issues related to my line of study and the potential outcomes of the research:
1. What are you trying to prove or demonstrate?
2. How will this change processes?
3. Where does Industry Foundation Classes and the Building Information Model concept sit in this picture?
4. How will this be tested and what will be tested? Obtrusiveness? Quantity of information? Quality of information?
5. What sort of numbers will you need to gauge a good response?
6. How will the relevance of any tests be proved in the real world?
7. What are people like Bentley and AutoDesk doing in this field?

I was not sure how to respond to many of those questions though I am pretty certain about a few.
I do not see Industry Foundation Classes or the Building Information Model playing much of a role in any of this higher level communication. For the most part I want to explore how RSS and the notion of intelligent blogging (blogging with a lot of passive meta-data attached) can effect the design and development process. In discussion between architects, builders and clients the applicability of complex, low-level data standards is almost zero. At this high-level text and basic images are about the lowest common denominator between the groups. When communicating this information I believe an abstracted IFC model just adds complications to what should be a simple process. Adam Bosworth (who works for Google) thinks the same way.

"As I said earlier, I remember listening many years ago to someone saying contemptuously that HTML would never succeed because it was so primitive. It succeeded, of course, precisely because it was so primitive. Today, I listen to the same people at the same companies say that XML over HTTP can never succeed because it is so primitive. Only with SOAP and SCHEMA and so on can it succeed. But the real magic in XML is that it is self-describing. The RDF guys never got this because they were looking for something that has never been delivered, namely universal truth." Adam Bosworth, ISCOC04