Introduction

Nowadays “quality” is an increasingly quoted, sought after and desired word after its popularity in the Scholastic period when St Thomas Aquinas defined it “recta ratio factibilium” – the proper way to do things. Its fortunes declined above all in the period running from the Enlightenment to Positivism when the measurement of performance and acceptability thresholds prevailed.

At the beginning of the 1970s new problems arose that were difficult to model and techniques were developed for multi-criteria analysis to define the quality as the complexity of the phenomena did not allow them to be reduced to a single function. At the same time, quality was rediscovered in everyday and technical language, both during the enthusiastic and pioneering computer era (Pirsig, 1974) and that of the Free Software Foundation founded by R. Stallman in 1983 (FSF, 1983) and by standards entities with the ISO 9000 series in the 1990s.

Be that as it may, whatever the philosophical stance adopted (including Plato and Aristotle), quality is not intrinsic to the object or to the examining subject, but is dependent on both. Rather, it also depends on the context. And this is what happens in the design process: the design solution is dependent on the context, on the actors and on the design proposals of the design/construction (Carrara and Fioravanti, 2002) (Fig. 1).

Fig. 1. The project can be seen as an intersection set of Actors, Context and Process

The design method best suited to meeting the challenges of our times is that of Collaborative Design (Kvan, 2000; Carrara and Fioravanti, 2001; Borkowski et al., 2001; Cheng, 2003).
The quality of the building is thus defined as the intersection among the qualities that the individual actors associate with the building itself from their own point of view: the perspectives of quality. This is valid both in design practice in which each actor “cultivates” his/her own idea of quality, deriving from the current regulations governing his/her own specialist professional sector and his/her own experience and sensitivity, and in the training of students in the architecture and civil engineering faculties who must learn to make a global assessment of a project or a building construction. The best way of attaining this objective is for the student to gain experience in performing the various different roles in the design process, so as to be able to view the project itself from different standpoints: from that of the Architect, of the Structural Engineer, of the Energy- plant Engineer and of the Quantity Surveyor. The greater the awareness of the problems that arise in other disciplinary fields as a result of one’s own choices pertaining to one’s own design purposes the more the overall quality is enhanced, avoiding the most common design errors which it is difficult to correct later. At the same time, knowledge obtained through role reversal of the other design aims extends the student-actor’s field of knowledge, and they can thus propose innovative solutions.
To this end, in our department, research has been undertaken to develop a software environment that can be used in Collaborative Design. It has been illustrated in one of its simplified forms – c-House – in Fioravanti and Rustico (2006) and in Carrara and Fioravanti (2007).

Approach to the scientific problem

The field of research in Collaborative Architectural Design is extremely vast in scope and here we shall be examining only the aspects listed above. However, several general considerations must be made concerning building design and construction in our times (Fig. 2), which have guided the research programme. The latter is based on the following observations:

• buildings are the result of an increasingly complex design/ construction process which is affected by the continuous expansion of specialist regulations, new materials, specialist technical information, and innovative production/ construction technologies;

• the creation of new highly specialized professional skills or the further refinement of existing ones as a result of the preceding point;

• a general decrease in practice in the quality of architecture and in the performance of the interventions from the conceptual design phase to the preliminary and detailed ones, accompanied, in the construction phase, by an increase in the cost of the end product of up to 50% of the originally allocated cost;

• the growing new needs and new expectations of building must meet, in terms of sustainability, energy, habitability, safety, and conformity with changing business activities.

Fig. 2. Complexity of building design in our times – Opera House in Taichung, Toyo Ito, 2006 project – in construction

The fundamental components of these design problems lie in a low and selfish collaboration among actors. To overcome this limitation we need to deal with:

a) the lack of suitable education in cross-disciplinary collaboration in the various specialist courses in universities;

b) the lack of suitable ICT tools enabling collaboration to be practiced in the design of complex buildings.

In order to allow an efficient and efficacious collaboration aimed at enhancing the overall design quality the research is developing:

a) teaching-training methodology to increase the aptitude for collaboration on complex building projects, which can be validated through the creation of a network of specialist students located in different universities;

b) innovative tools based on advanced ICT technology which can define, transmit, interpret and explain the basic knowledge underlying the project, shared by all the operators involved, thus establishing the technical and infrastructural conditions required for design collaboration among specialists in different fields.

Research method

The research group, in order to successfully tackle what has been outlined above, points out that as far as aspect “a)” is concerned, collaboration does not automatically emerge from the mere availability of an adequate technical-instrumental tools, but demands adequate training in order to: explain the need, develop the necessary aptitude, learn the techniques, develop its practical skills.

To this end the student-actor must participate in the principal roles of the design process in Collaborative Design: it is like a compulsory role play on the Internet. This training will increase his/her capacity to devise different strategies depending on the specialization selected.

It has also been found essential that this training in cross-disciplinary group work should be carried out in parallel with “traditional” specialist technical training, so as to ensure each future professional gains the capacity to apply his/her own technical knowhow with an awareness of the complexity of the collaborative process and with respect for the different cultural backgrounds of the other potential students. Moreover the software environment uses the students’ enthusiasm for the Internet, their curiosity in exchanging roles in the design process and the eagerness of mutual teaching on equal terms, for a more effective and involving professional training.

As far as the aspect “b)” is concerned, it is necessary to develop technical-instrumental tools in order to allow collaboration among diverse specialist skills. Although professional S/Ws work very effectively in the specific domain for which they have been conceived they are actually of no help in a true design collaboration. Indeed software specialization increases the difficulty of communication and reciprocal understanding among the various actors using it as the data required by the different programs differ from one actor to the next.

Moreover, each type of software described above demands the input of data that must generally be inferred from the interpretation of the design solutions of other actors. Indeed these ones, by failing to interact with each other, continue to develop their own specific design solution which is often later found to be incongruent with that of the other actors.
Our ICT system is based on a product/process model (4D) that allows the formalization of:

• the technical knowhow involved in the project;

• the structure for managing the collaborative design process.

The latter two points represent the core of the present paper.

The first feature – the set of technical knowhow – is formally expressed in Knowledge Bases (KBs) and is subdivided into a Common Knowledge Base (CKB) agreed by all the specialist student-actors involved in the design process, and as many forms of Specialist Knowledge Bases (SpKBs) as there are knowhow forms specific to each disciplinary field (Zang and Norman, 1994). This is a multi-agent system as can see in Tessier et al. (2001).

The CKB refers to the spatial and physical entities that make up the object of design and contains all the necessary and sufficient information for each student-actor to understand the significance and the essential characteristics of the entity considered. Moreover, the process rules, student-actor hierarchy and the communications rules are defined in the CKB.

Each SpKB contains the characteristics (and/or the methods of their determination, calculation and verification) of the entities of interest to the specialist student that are not necessary to or understandable by the other student-actors.

The second feature – the management of the design process – is carried out in the Design Workspace (DW) that is part of the Collaborative Environment. Much like the partitioning of the KB into CKB and SpKBs, the DW too is comprised of an Overall Design Workspace (ODW) and a Personal Design Workspace (PeDW) (Fioravanti and Carrara, 2007).

Each specialist student-actor develops his/her part of the overall building within his/her own PeDW, using his/her tools and methods. Once sufficiently developed, each specialist student-actor’s partial solution can be translated into the CKB format and published in the ODW, where it is rendered visible and comprehensible to the other student-actors by means of a second translation into their own SpKB format.

This procedure is very difficult to implement using existing specialist applications S/Ws, each of which has its own BIM (Khemlani, 2008) and has different compatibilities with the different versions of the IFC specifications.

Filter development

In addition to the above-mentioned difficulties involved in making the SpKBs shareable and integrable in a CKB related to the interoperability at code level between application S/Ws, there are others that are even harder to solve: those at the level of “concepts”.

Indeed, the current software programs, even when based on systems with a single central DB cannot be understood by some specialist student-actors as the meaning of the entities (building components, procedures, etc.) shared by the designers are different. And they are different not so much at the level of entity in its own right as rather an entity included in a complex system – a Relation Structure (RS) – (Carrara and Fioravanti, 2001) with the other entities: it goes to make up a ‘finalized system’ for the comprehension and the resolution of problems in a given specialist field. Each specialist field has its own customary RS.

This is the main reason for the relative lack of correspondence of the current professional applications with the acronym CAD, namely, it is precisely the “D” of Design that is missing (and not the “D” as in Drawing).

To be able to design it is necessary to possess an overall conception of the building organism; this is missing in current professional applications or, at best, it is conceived of solely as an assembly of components. In order to obtain a tool capable of designing a purpose-oriented system, that is, one that can be of help to the student-actor, it is necessary to have an interlocutor at his/her same level, which possesses all the degrees of abstraction relevant to the case: in order to be able to collaborate with the others it is first necessary to be able to collaborate with one’s own student-actor.

This interlocutor has been called Intelligent Assistant, and is made up of a KB, an RS and an Inference Engine (IE). The system therefore consists of a series of Intelligent Assistants – IAs – each of which assists the corresponding specialist student-actor, supporting him with its knowledge and acting as a communications environment between the student-actor and the others, by means of the CKB and by other IAs.

In order to approach the problem correctly it is necessary to consider the model of the “variable intelligence level stratification”, that has been focused on the lower part of the layer pile (Fig. 3) as illustrated in Carrara and Fioravanti (2005, pp. 214-215), and that takes in the higher part elements of logic.

Fig. 3. Intelligence-abstraction level stratification – the lower part: “vertical” interfaces

Therefore the KBs defined previously (CKB and SpKBs), viewed from close up, may be subdivided into a set of levels:

• the simple knowledge level (lower level ontology, data of properties of the entity);

• the ontology level (definition of entities and reciprocal relations);

• the semantics level (meanings, modes of behaviour).

Above these levels there are:

• the objective rules level (upper level ontology, RS and systemic relation);

• the logic level (ie – how to associate the underlying entities and infer or deduce new rules).

Over the top level there is the belief one that is out of our interests (Fig. 4).

Fig. 4. Intelligence-abstraction level stratification – the higher part: “vertical” mapping

This overview shows how it is impossible to solve the problem of the interoperability of both data and concepts by solely operating at data level or even at the lower level ontologies; it is necessary to consider the entire pile of intelligence levels so that the student-actors may understand each other effectively.

In order to achieve this result a dual mapping is required to relate:

• “vertically” the same entity which can thus be given a complete description of its disciplinary “section”;

• “horizontally” so as to link the same entity to several student-actors at the same level of intelligence-abstraction (ontology with ontology, datum with datum).

“Vertical” mapping is the easier solution as in a specialist field substantial agreement exists on the taxonomy of the entities, on their hierarchic structure, on their meaning and on the aims pursued in the discipline involved, even though it is possible to modify within reasonable limits the position of an entity in the “vertical section”.

“Horizontal” mapping is more difficult and is associated with the more general problem of Perspective (Arciszewski and Mustafa, 1988; Reich, 1994). We plan to address this problem thanks:

• the ontologies that are disseminated on the Web by OWL, in architecture and building by aecXML, in industrial standards by IFC, and in several digital libraries, etc.;

• the filters that can relate the CKB in which the common entities and their characteristics are present with the corresponding ones in the respective SpKBs.

Filters, as many as there are SpKBs are translator of concepts of entities from SpKBs to CKB and vice-versa. The aim of the filters is to allow through only the common entities and characteristics of an SpKB when they are exported into the CKB and to enhance with the specific characteristics of the SpKB an entity when it is imported into the SpKB. The filters are dynamic in that they depend on the student-actors, on the process and on the context.

The problems we face with are very similar to those St Thomas Aquinas had: same code (Latin alphabet), a sharp formalism (Latin syntax), a robust and clear structure (structuring questions and answers) and a procedural rule system (scholastic method) (Fig. 5).

Fig. 5. Example of high structured formal dissertation of a scholastic thesis

Very Light Object

The design environment is modelled by various and specialist student-actors that in the design process of architecture are helped by their own Intelligent Assistant (IA). Each IA is made up of its own SpKB, its own Inferential Engine, and its own interface with the customary specialist student S/W tools, with the CKB and with other student-actors. All the above takes place at the prototype object level (classes), although it must be considered that the project is one instance of them: semantic data (Fig. 4).

Therefore also the filters, like the other prototype objects (components, rules, properties, procedures, etc.) are instantiated in filter instance objects at the time of the instantiation (Fig. 6).

Figure 6. Classes and instances “horizontally” mapped with corresponding Common ones by means of Filters

It is necessary to describe in detail how the project’s data message mechanism works (e.g. when a constraint is violated) among the various student-actors via the IAs. This interface is active at the data level of the project (its instances) as well as at that of the CKB through the filter instance and the filter prototype object, respectively. The mechanism is governed by the type of representation of the prototype objects (classes) of the CKB in the various SpKBs, which are essentially two in number: exhaustive representation (all the properties and attributes of the class) and essential representation (only the properties deemed to be indispensable) (Carrara and Fioravanti, 2001).

Again, both may be subdivided with respect to the Workspaces PeDW/ODW if a mirroring representation exists (all the properties and characteristics present in the CKB classes are present in all the SpKBs), or else only a few of the characteristics present in the CKB are present also in the various SpKBs, as proposed in Fioravanti and Carrara (2007).

The latter approach has been developed further with respect to that defined as “lean object” (Fioravanti and Carrara, 2007) in which the CKB classes in any case contained not only the name of the class and of its superclass(es), but also the principal properties and attributes of the class itself which is shared by all the SpKBs. The efforts are now directed towards a representation that we call a “Very Light Object” with which each class is defined only, as well as by its name and its superclass(es), by the georeferenced coordinates, by time and by the actors that have some authority to control it (or, can have links to it). All the properties and attributes are obtained with links to their respective SpKBs. In this way it is simpler to use both the usual S/W tools with their respective primitive graphics and to have a simpler central Common DB to handle its consistency more effectively.

To attain this goal the system uses a syntactic and semantic translation, and of formalization of entity classes that represent the process/ product model by OOP techniques (Carrara et al., 2004, pp. 114-116) (Fig. 7).

Fig. 7. Syntactic and semantic translation between two PeDW by means of the XML language

The chosen applications environment to test the system is that of hospital design. A hospital is a particularly complex structure even in the case of reduced physical size, has similar requirements in all the EU countries and demands the contribution of numerous highly differentiated specialist skills that must be melded into an organic and balanced solution.

The program envisage the creation of a network of Schools of Architecture and Engineering in various European Universities for the purpose of reappraising current teaching syllabi with a view to teaching design in a collaborative and cross-disciplinary form so as to supersede anachronistic teaching in a disciplinarily delimited and closed form (however in-depth and updated).

Conclusions

In this way, each student can evaluate the result of the integration of the partial specialists’ solution and the effects of his/her own proposed contribution, together with that of other students’, on the project as a whole, while at the same time identifying errors and inconsistencies, as well as potential innovative lines of development of the project, and thus can proceed to make modifications or suitable refinements.

The expected results will consist of an enhancement of the collaborative capacity of future designers, a greater homogeneity of Collaborative Design groups in the European area, the consequent facilitation of the mobility of professionals in EU countries and a boost to the search for innovative solutions.

The fallout of the research will have a favourable impact on the following categories: University faculties of Engineering and Architecture, the professionals involved in various ways in the design of territorial interventions, building constructors in various executive specializations, the building products industry and the final users of the interventions.

Acknowledgements

The research was partially funded by MiUR (Ministry of the University and Research), Project of Research of National Interest 2005: “A Model of cross-cultural collaboration for integrated design in architecture”.

References

Arciszewski, T. and Mustafa, M.: 1988, Inductive Learning Process The User's Perspective, in R. Forsyth (ed.) Machine Learning: Principles and techniques, pp. 39 - 61. Chapman & Hall, Ltd. London.

Borkowski, A., Branki, C., Grabska, E. and Palacz, W.: 2001, Towards collaborative creative design, Automation in Construction, 10(5), pp. 607-616.

Carrara, G. and Fioravanti, A.: 2007, c-House - a Game to Improve Collaboration in Architectural Design. How to distill a CD Based Model into an E-learning Tool, in: Joachim B. Kieferle and Karen Ehlers (eds), Predicting the Future. 24th eCAADe Conference. Frankfurt. 26-29 Sep 2007. Kanne Graphischer Betrieb GmbH, Ginsheim-Gustavsburg, pp. 141-149.

Carrara, G. and Fioravanti, A.: 2005, The Quest for the Holy Grail - Holistic Collaborative Design. How to enhance communications among tools of semantic different level in a cross-culture design, in J.P. Duarte, G. Ducla-Soares and A.Z. Sampaio (eds) Digital Design: The Quest for New Paradigms. 23rd eCAADe, Lisbon, 21-24 Sep 2005. Dossier, Comunicaçao e Imagem, Lda, Lisbon, pp. 211-218.

Carrara G, Fioravanti A and Nanni U: 2004, Knowledge Sharing, not MetaKnowledge. How to join a collaborative design Process and safely share one’s knowledge, in J Pohl (ed.) Intelligent Software System for the New Infostructure, 16th Focus Symposium and InterSymp-2004 Conference Proceedings, Baden-Baden, 30 July 2004, pp. 105-118.

Carrara, G. and Fioravanti, A.: 2002, ‘Private Space’ and .Shared Space’ Dialectics in Collaborative Architectural Design, in J. Pohl (ed.) Collaborative Decision-Support Systems, Focus Symposium and InterSymp-2002 Conference, 29th Jul - 3rd Aug 2002, Baden-Baden, Cal Poly, San Luis Obispo, pp. 27-44.

Carrara, G. and Fioravanti, A.: 2001, A Theoretical model of shared distributed Knowledge bases for Collaborative Architectural Design, in J.S. Gero and K. Hori (eds) Strategic Knowledge and Concept Formation III Conference, pp. 129-143.

Cheng, N.Y.: 2003, Approaches to design collaboration research, Automation in Construction, 12(6), pp. 515-723.

Fioravanti, A. and Carrara, G.: 2007, Collaboration, New Media, Design – An Integrated Environment for Supporting Collaboration in Building Design, in Pawlak, A., Sandkuhl, K. and Indrusiak, L.S. (eds), Coordination of Collaborative Engineering – State of the Art and Future Challenges. GI-Edition Gesellschaft fur Informatik, e.V, Köllen Druck + Verlag GmbH, Bonn, pp. 143-160.

Fioravanti, A. and Rustico, R.: 2006, c-House game - A Space for simulating a Collaborative Working Environment, in Architecture, in V Bourdakis and D Charitos, Communicating space(s), 24th eCAADe Conference. Volos 6-9 Sep 2006, pp. 506-511.

FSF - Free Software Foundation: 1983, [online], Available from: < http://www.fsf.org/> , [Accessed 15th May 2008].

Khemlani, L.: 2008, Technology Product Highlights from AIA 2008 Convention, [online]. Available from: < www.aecbytes.com/newsletter/2008/issue_34.html >, [Accessed on 26th May 2008].

Kvan, T.: 2000, Collaborative design: what is it?, Martens, B (guest ed.), Special Issue eCAADe ’97, Automation in Construction, 9(4), pp. 409-415.
Pirsig, R.M.: 1974, Zen and the Art of Motorcycle Maintenance, Italian translation in 1981, Lo Zen e l’arte della manutenzione della motocicletta, edition 1990. Adelphi Edizioni, S.p.A., Milan.

Reich, Y.: 1994, Macro and micro perspectives of multistrategy learning, in R.S. Michalski and G. Tecuci (eds), Machine learning. A multistrategy approach, vol. IV, pp. 379-401. Morgan Kaufmann, San Francisco, CA.

Tessier, C., Chaudron, L., Müller, H.-J. (eds): 2001, Conflicting Agents. Conflict Management in Multi-Agent Systems, Kluwert Academic Publishers, Norwell.

Zhang, F., Norman D.A.: 1994, Representations in Distributed Cognitive Tasks, Cognitive Science, 18, pp. 87-122.

Download at PDF
Загрузить в PDF

Issue contents
Содержание журнала