Keywords

Artificial Intelligence and Design

The significance and the paradigmatic relevance of Artificial Intelligence in Modern Design is intertwined with Herbert Simon’s original articulation of the Science of Design [41, 42] and in the words of Baldwin [4], Simon’s interpretation of design as a “decision-making process under constraints of physics, logic and cognition”. This view of the scientific design process underlies much of what artificial intelligence has to offer by way of its formal representational and computational apparatus to the domain of design.Footnote 1 From a topical viewpoint, the knowledge representation and reasoning area within artificial intelligence has been the cornerstone of most formal AI inroads in so far as problem-solving for design is concerned. In the last two decades, several interdisciplinary initiatives comprising of computer scientists, engineers, psychologists and, designers have addressed the application of artificial intelligence techniques for solving problems that accrue at several stages of the design process: design conceptualization, functionality specification, geometric modelling, structural consistency & code-checking, optimization, collaborative (design) workflow management, design creativity, and a plethora of other issues.Footnote 2

Situated within this AI-centric view of the science of design, we present our perspective on spatial computing for design. Strongly influenced by the need to formally define, model, and reason about (structural) form & (artefactual) function, our interpretation of spatial computing encompasses three aspects we regard as crucial:

  • semantic modelling, spatial abstraction, & multi-perspective representation

  • design analysis by inference patterns supporting diagnostic & hypothetical reasoning

  • assistive feedback/communication with designers

  1. 1.

    The aspects deemed essential correspond to problems that accrue within a conventional ‘iterative refinement by automated design assistance’ workflow, and are identifiable with respect to the modelling–evaluation–re-design phases in intelligent design assistance, for instance, as interpreted within a Function-Behaviour-Structure (FBS) [23, 26] model of the design process. With respect to the refinement work-flow, the basic research questions within the context of spatial computing include: Semantics: formal modelling of design requirements, and the role of knowledge engineering in that regard

  2. 2.

    Spatial abstraction: abstraction of CAD-based geometric information into the qualitative domain via the use of formal spatial representation and reasoning techniques

  3. 3.

    Qualitative spatial reasoning: the application of spatial consistency as a basis for checking for design requirement consistency

  4. 4.

    Hypothetical reasoning: the role of hypothetical reasoning (e.g., by abduction) as a means to support a diagnostic and recommendation function within a logic context

  5. 5.

    Assistive feedback: visualisation modalities as a means to interact & communicate assistive feedback with the designer

The above problem aspects have fuzzy boundaries and many interrelationships. However, the paper attempts to characterize each one of them rather independently via running examples. The paper is organized as follows:

The next section is an exposition of the philosophy that underlies our approach to spatial computing. The points raised condition the basic premises of our overall approach, especially our propositions on hypothetical reasoning for design. The next section provides an overview of the iterative refinement cycle in design. Here, we exemplify the key aspects of spatial computing for design vis-a`-vis the iterative refinement cycle. In the next section, we define spatial computing and present the issues that we deem to be within its scope. Key representational and computational modalities are discussed, and we also attempt to ground the earlier discussion with examples that further illustrate the agenda of spatial computing, and the problems that may be solved therein. This section can be considered to be our statement of the work-in-progress in spatial computing for design. Finally, we summarize and at the same time, also reflect upon some of the issues raised by Gero [24] in his statement of “Ten Problems for AI in Design”.

The Philosophy of Spatial Computing, for Spatial Design

In architectural design, we are faced with structures in physical space. Much of the design considerations in architectural design are directly constrained by intrinsic properties of physical space. Unlike some abstract spaces, the dimensions of physical space are strongly interrelated. This has to do with the fact that the three spatial dimensions are of the same quality: an object that is long in the x-dimension will be long in the y- or z-dimension simply by changing its orientation; one does not have to change the (nature of the) object itself. In color space, for example, we cannot maintain such constancy by moving an object, as each dimension of color space refers to a different quality or feature. On the other hand, the number of spatial dimensions is limited to three; thus, in whatever ways we move objects in space, we will stay within the interrelation of three spatial dimensions.

Besides these intrinsic spatial constraints, we have physical constraints due to mechanical properties of physical objects. In particular, there is a correlation between length, width, and height due to mechanical requirements: longer objects need to be made thicker for maintaining stability properties; thicker objects may become larger to maintain proportions, etc.

Human perception also treats the three spatial dimensions in similar ways: for manipulable objects the perception of length, height, and width can be transformed by changing the orientation of the objects; for large-scale objects like buildings and mountains, the vertical dimension may not be perceived identically to the two horizontal dimensions.

The main message of these considerations is that physical dimensions are strongly inter-related and that physical space is severely constrained. This can be viewed as a strong limitation in comparison to abstract spaces in which arbitrary configurations of feature values and arbitrary transitions between them are conceivable. From the perspective of design, however, these constraints can be considered a great advantage, as they considerably reduce the space of design decisions.Footnote 3

These considerations not only have implications on the spatial structures to be designed but also on the structures of design computers. Today’s general purpose computers represent spatial entities and environments in the conceptual framework of unconstrained abstract spaces; thus, the intrinsic properties of physical space must be explicitly coded into the system to make sure physically realizable designs result from the computational process.

In other words, computation needs to be invested to reduce the set of conceivable designs to the set of realizable designs. This is not the case when the designer works directly with spatial models, as these maintain the spatial constraints inescapably.

We use the notion of spatial computing in a way that exploits the intrinsic constraints of spatial structures in such that only those structures will be generated that are realizable in physical space and that do not require a computational reduction from conceivable structures to physically realizable structures.

Assisted Iterative Refinement in Spatial Design

Spatial design as a problem-solving activity typically consists of the Conception—Modelling—Evaluation—Re-modelling cycle. Essentially, a designer in this case is considered to be an agent of change, who in the absence of any computational assistance, may be intuitively regarded as traversing a complex configuration space of possibilities, and selecting one course of action (guided by domain knowledge, expertise, cognitive capabilities, specialized requirements, aesthetic preferences and so forth) that produces a desired product/design.

A Design Task. As a basic use-case, consider an architect/engineer specialising in the design and development of building automation systems and smart environments. A typical design challenge would be:

Design the layout of an office environment to satisfy structural and functional requirements that collectively aid and complement (and never hinder) the building’s automation systems (monitoring devices, sensors, etc.), and which, by implication, facilitate the intended smartness of such automation systems.

From the viewpoint of the overall design requirements, aspects of this problem explicitly pertain to the functional aspects (e.g., security, privacy, building-automation, accessibility) of the space being modelled, structural code-checking with respect to building regulations, and also possibly specialized client demands. Some example requirements follow in (R1–R3):

R1:

certain areas within a building/floor/room should (not) be trackable by sensing devices such as cameras, motion-sensors

R2:

regional statutory requirements that stipulate structural constraints and other categorical specifications, e.g., disability access codes, design guides

R3:

client specification: as much as possible, the operation of doors should be non- interfering with the functionality of nearby utilities/artefacts

Figure 1 is a schematization of the consistent and inconsistent models of the example requirements/scenarios in (R1–R3). The following aspects, marked as [14] in Figs. 1a and b, make the plans of Fig. 1 (in)consistent with respect to (R1–R3):

Fig. 1
figure 1

Design requirements: example spatial interpretations. a Inconsistent plan. b Consistent plan

  • the sensor/camera is placed at a place where a private area such as the wash-room is within its range (No. 1)

  • the operating space of the door of the wash-room interferes with the functional area of the wash-sink, and this arrangement is also not conducive, given disability access requirements (No. 2)

  • the operation of the main entrance door interferes with the function of the telephone next to it, and from a structural viewpoint, is also not an ideal placement given its proximity to the staircase (No. 3, 4)

From the viewpoint of spatial computing, one may imagine the search space to consist of spatial configurations—topological, orientational arrangements—and the spatial trans- formations that are possible, e.g., with respect to a movement taxonomy, as the available actions that produce a re-arrangement. The objective of iterative refinement in general, be it automated or human, is to create consistent models that fulfill the requirements as they are conceived at design time. Albeit a bit limiting, for this particular case, the automation necessary to realize the re-configuration may be identified as a limited form of assistive spatial design intelligence that guides the designer toward a solution that meets the pre-specified requirements, such as those stipulated in (R1–R3).

Automated Design Refinement

Figure 2 illustrates our interpretation of this process of iterative refinement, as it is applicable to the ‘spatial computing for design’ framework (Sect. 4) laid out in this paper. The following aspects of iterative refinement (A1–A3) are deemed crucial:

Fig. 2
figure 2

Iterative refinement by intelligent design assistance

A1:

Modelling—Design Abstraction: this aspect encompasses issues ranging from se-mantic specifications, taxonomic representations, qualitative abstractions of geometric models, and modularity of information representation

A2:

Convergence—Reasoning: this aspect constitutes the various modes of inference that constitute the computational manifestations of the assistive design support

A3:

Assistive Feedback—Visualization: this aspect constitutes mechanisms and modalities to provide diagnostic feedback and other forms of support within a conventional CAAD workflow

Indeed, the possibilities to broaden the interpretation of this manner of intelligent assistance are rather extensive, ranging within a wide array of techniques from the computing, cognitive, psychological, and aesthetic disciplines. Our preliminary focus in spatial computing is centred on spatial cognition, and is guided by the aim to formally and computationally understand the relationship between the “structural form” and “artefactual function” within the domain of spatial design. Further elaborations are presented in Sect. 4.

A Characterization of Spatial Computing for Design

We characterize spatial computing for design in two ways: firstly, by the scientific questions that it must address from a representational and computational viewpoint and their relationships to the domain of artificial intelligence & design in general, and secondly, by the outcomes that a paradigm such as this is expected to produce. Spatial computing for design is defined as:

  • that body of work that is concerned with the use of formal methods in knowledge representation and reasoning in general, and terminological and spatial representation and reasoning in specific, for solving problems in modelling (e.g., spatial semantics, modularity, requirement constraints) and validation (e.g., diagnosis, hypothetical reasoning) in the domain of spatial design

  • that body of work whose aim is to develop the generic apparatus—application framework, methodology, tool-sets—that may be used as a basis of providing assistive design support within a conventional CAAD-based spatial design workflow

We now elaborate on the representational and computational aspects of the above definition.

Modelling Form and Function

Form follows Function” [44] and “Ornament is Crime” [35]—these two doctrines have been the cornerstones of the modernist tradition in engineering design.Footnote 4 Restricting the application of this doctrine to the domain of architectural design, the interpretation that it leads to is that the structural form, i.e., shape, layout, connectivity, of a building should be primarily (or more rigidly: solely) determined by its practical function or purpose. Much of the literature in the philosophy of design and architecture [48], and the ensuing debates thereof, have focused on the semantics of functions with respect to design artefacts and the causal link between form and function, stressing the question of whether or not form should, or indeed does, wholly or in part follows function.Footnote 5

Structural Form and Artefactual Function in Spatial Computing: Spatial computing is primarily concerned with the issues surrounding the formal interpretation of the terms “spatial/structural form” and “artefactual function”, in particular with respect to the interpretation of these concepts in the context of a CAAD-based workflow. This is crucial, since it is necessary to explicitly put these notions into practice by investigating what precisely does it mean to model form and function within an intelligent architectural design assistance system.

Example 1. Bremen (Germany) Building Code [12]:

(a). Staircase/Treppen (§ 35 (10), p. 24):

Steps of a staircase may not be connected directly to a door that opens in the direction of the steps. There has to be a landing between the staircase steps and the door. The length of this landing has to have at least the size of the door width.

We note some examples:

Example 2. US Courts Design Guide 2007 [47]:

(b). Barrier-Free Accessibility (p 4–3):

Courtroom areas used by the public must be accessible to people with disabilities. Private work areas, including the judge’s bench and the courtroom deputy, law clerk, bailiff, and court reporter stations, must be adaptable to accessibility. While all judges benches and courtroom personnel stations do not need to be immediately accessible, disabled judges and court personnel must be accommodated

(c). Psychology, Culture and Aesthetics (p. 3–1, 4–4):

The architecture of federal courthouses must promote respect for the tradition and purpose of the American judicial process. To this end, a courthouse facility must ex- press solemnity, integrity, rigor, and fairness.

All architectural elements must be proportional and arranged hierarchically to signify orderliness. The materials employed must be consistently applied, be natural and regional in origin, be durable, and invoke a sense of permanence.

The height and location of the judges bench expresses the role of the judge and facilitates control of the court. Generally, the judges bench should be elevated three or four steps (21–24 inches or 525–600 mm) above the courtroom wall.

(d). Visibility (p. 3–2, 16–9):

The entrance or entrance vestibule should be clearly visible and recognizable as such from the exterior of the building. The vestibule should be a minimum of 7 feet in depth and able to handle the flow of traffic at peak times.

A duress alarm must be easily accessible and visible to all occupants.

Example 3. A Pattern Language [2]

(e). Sunny Counter (p. 16–918):

Place the main part of the kitchen counter on the south and southeast side of the kitchen, with big windows around it, so that sun can flood in and fill the kitchen with yellow light both morning and afternoon

At this stage, we leave the readers with their imagination as to the formal interpretation of the above examples—some have a clear and well-defined spatial structure within a design, whereas others are only indirectly specifiable. Spatial computing in design should be concerned with the extent to which functional aspects such as those exemplified herein could be formally interpreted in strictly semantic and spatial terms; from a computational viewpoint, it is clear that adequate conceptual, spatio-linguistic and qualitative modelling techniques are necessary for representing and reasoning about design artefacts and patterns entailed by designer expertise.

Design Artefacts: Conceptualization and Formal Representation

Spatial computing involves an interplay between the designer’s conceptualization, the handicaps of the computational constructs of the design tool, and the limitations of the bridges that connect that conceptual with the computational: professional design tools simply lack the ability to exploit the expertise that a designer is equipped with, but un- able to communicate to the design tool explicitly in a manner consistent with its inherent human-centred conceptualization, i.e., semantically and qualitatively. Modelling for spatial computing in design has to be focussed on representation of design semantics, artefactual modelling capability and support for multi-perspective modularity.

Design Semantics

An expert’s design conceptualization is semantic and qualitative in nature—it involves abstract categories such as Rooms, Doors, Sensors and the spatial (topological, directional, etc.) relationships among them, e.g., ‘Room A and Room B have a Door in Between, which is monitored by Camera C’. Whereas this example is rather specific, typical real-world constraints are mostly underspecified or fuzzy (e.g., see Sect. 4.1). Therefore, any vision of specialised spatial computing for design has to handle to the modelling of designer/design semantics in an explicit manner, e.g., using formal knowledge engineering constructs such as ontology modelling languages.

Spatial Artefacts

A crucial aspect that is missing in contemporary design tools is the support to explicitly characterize the artefactual aspects, and the functional requirements ensuing therefrom, within a design. Semantic descriptions of designs and their requirements acquires real significance when the spatial and functional constraints are among strictly spatial entities as well as abstract spatial artefacts. For instance, although it is possible to model the spatial layout of an environment at a fine-grained level, it is not possible to model spatial artefacts such as the range space of a sensory device (e.g., camera, motion sensor, view-point of an agent), which is not strictly a spatial entity in the form of having a material existence, but needs to be treated as such nevertheless. In general, architectural working designs only contain physical entities. Therefore, it becomes impossible for a designer to model constraints involving spatial artefacts at the design level. For instance, consider the following constraint: ‘the motion-sensor should be placed such that the door connecting room A and room B is always within the sensor’s range space’. Bhatt et al. [13] identify three types of spatial artefacts:

A1:

the operational space denotes the region of space that an object requires to perform its intrinsic function that characterizes its utility or purpose

A2:

the functional space of an object denotes the region of space within which an agent must be located to manipulate or physically interact with a given object

A3:

the range space denotes the region of space that lies within the scope of a sensory device such as a motion or temperature sensor, or any other entity capable of visual perception. Range space may be further classified into other categories, such as observational space (e.g., to model the concept of the isovist Footnote 6).

Figure 3 provides a detailed view on the different kinds of spaces we introduced. From a geometrical viewpoint, all artefacts refer to a conceptualised and derived physical spatial extension in Rn. However, they do differ from an ontological perspective and the manner in which their geometric interpretations in Rn are derived. The derivation of an interpretation may depend on object’s inherent spatial characteristics (e.g., size and shape), as well as additional parameters referring to mobility, transparency, etc.

Fig. 3
figure 3

Spatial artefacts are entities, which unlike regular spatial objects, do not have a physical manifestation in reality (or within a design), but need to be treated as such for all practical/reasoning purposes. (Illustration adapted from: Bhatt et al. [13])

Multi-Perspective Semantics & Representational Modularity

An abstraction such as a Room or Sensor may be identified semantically by its placement within an ontological hierarchy and its relationships with other conceptual categories. This is what a designer must deal with during the initial design conceptualization phase. However, when these notions are transferred to a CAAD tool, the same concepts acquire a new perspective, i.e., now the designer must deal with points, line-segments, polygons and other geometric primitives available within the feature hierarchy of the design tool, which, albeit necessary, are in conflict with the mental image and qualitative conceptualization of the designer. Given the lack of semantics, at least within contemporary design tools, there is no way for a knowledge-based system to make inferences about the conceptual design and its geometric interpretation within a CAAD model in a unified manner.

As an example, consider a binary relation ‘connects’ that links entities from the conceptual, qualitative, and quantitative levels of Fig. 4; a Floor at the conceptual level is abstracted as a Region at the qualitative level of a reasoner and as a ClosedPolygon thereby preserving the geometry at the quantitative level of a CAAD-based feature model:Footnote 7

1

BinaryLink: Domain:

integration module: connects quantitative level: architectural feature

 

 Range:

qualitative level: functional structure

 

 Inverseof:

integration module: connectedby

2

Class: subclassof:

quantitative level: convexpolygon

connects exactly 1 qualitative level: region

3

Class: subclassof:

conceptual level: floor

connects exactly 1 qualitative level:region

Fig. 4
figure 4

Multi-perspective representation & modularity

Spatial Representation and Reasoning

The field of Qualitative Spatial Reasoning (QSR) investigates abstraction mechanisms and the technical computational apparatus for representing and reasoning about space within a formal, non-metrical framework [18, 21]. Relational formalizations of space and tools for efficiently reasoning with them are now well-established [40]. In QSR, spatial information representation corresponds to the use of formal spatial calculi such as the Region Connection Calculus [39] (RCC), Single-Cross and Double-Cross Calculi (SCC, DCC) [22], Oriented Point Relation Algebra (OPRA) [37] (see Fig. 5).

Fig. 5
figure 5

Topological and orientation calculi

Within spatial computing for design, the use of formal qualitative spatial calculi and conceptual design requirements serve as a link between the structural form of a design and the differing functional capabilities that it affords or leads to. Therefore, a very important goal in spatial computing is to formally and computationally investigate the link between structural forms, as denoted by specific spatial configurations of domain entities, and the behaviours/functions that they are inherently capable of producing with respect to a pre- specified set of requirements conceptually expressed by an architect or a designer.

Artefactual Constraints, Structural Form and Design Function

Spatial artefacts such as those introduced in (A1–A3) are usable towards formulating functional requirement constraints for a work-in-progress spatial design. Constraints, emanating from the requirements such as in (R1–R3; Sect. 3) may need to be satisfied by a design:

C1:

The FunctionalSpace of the Door of every Office should overlap with the RangeSpace of one or more Camera or MotionSensor.

C2:

The StairWay should be topologically non-overlapping with the FunctionalSpace and OperationalSpace of other entities

C3:

People should not be harmed by Doors opening up. In general, the OperationSpace of a Door should be non-interfering, i.e., not overlap with the function/operation (i.e., functional/operational space) of surrounding objects.

The schematization in Fig. 6 is a continuation of the example requirements introduced in (R1–R3), and semantically expressed constraints in (C1–C3). To consider two of the three consistent/inconsistent cases from Fig. 6, namely (C1, C3), below is a semantically grounded semi-formal representation of a requirement constraint:

Fig. 6
figure 6

Design requirements: example spatial interpretations

C1

Class:

Qualitative level:DoorFunctionalSpace

 

SubClassof:

qualitative level:FunctionalSpace, space:topology:proper part of some (qualitative level:SensorRangeSpace)

C3

Class:

qualitative level:PhoneFunctionalSpace

 

SubClassof:

qualitative level:FunctionalSpace, not (space:topology:overlaps some (qualitative level:DoorOperationalSpace))

The remaining example from Fig. 6, corresponding to (C2), too may be modelled in a similar manner, namely, as a topological constraint among the primitive conceptual/qualitative/quantitative entities within the design model. Clearly, there are many more possibilities to model requirement constraints on the basis of other aspects of space, e.g., orientation, cardinal directions, metric/fuzzy distances. In this manner of modelling, it must be emphasised that the resulting functional consistency is interpreted strictly with respect to the structural form of the design.

4.4 Design Intelligence—Modes of Inference

The term design intelligence is rather open and subject to diverse interpretations; its scope and definition are only limited by the range of the inference patterns that may be operationalised computationally. From the viewpoint of this paper, we have rather specific inclinations with respect to the reasoning capabilities that must be the focus of spatial com- puting for design.

Conceptual Reasoning

Conceptual reasoning corresponds to the ontological reasoning patterns that are available within the framework of a terminological reasoning system grounded to the semantics of a Description Logic (DL) [3]. Ontology reasoning systems such as RACER [28], PELLET [43] support typical DL inference tasks at the terminological (subsumption, satisfiability, equivalence, disjointness) and instance levels (instance checking, data consistency, realisation, retrieval). For example:

  1. 1.

    Retrieval task: identify all concrete entities/geometric features (e.g., ‘polygons’) from instance data coming from a CAAD model that correspond to a design abstraction/artefact such as ‘FunctionalSpace’ or ‘MovableEntity’

  2. 2.

    Instance checking: given a set of geometric features within a CAAD model, what is the most general/specific abstract ontological category that the identified feature belongs to from the conceptual/artefactual viewpoint of the designer

From a conceptual reasoning viewpoint, another important reasoning task is determining whether or not the requirement constraints, functional or otherwise, specified by a designer may possibly be satisfied by a model per se. This form of reasoning is useful to check if a given set of design requirement are mutually consistent.

Functional Consistency

The example scenarios in Sect. 4.3 illustrated the extent and manner in which functional requirement consistency may be modelled with respect to the structural form of design. This is the form of consistency that has been discussed and il- lustrated throughout this paper. However, the notion of functional consistency transcends beyond the purely spatial aspects of a design, and also includes semi-spatial aspects that include the material and constitution of design artefacts, aspects such as weight, colour, physical characteristics, and artistic aspects that may be beyond the domain of space. Regardless if what precisely what these aspects are, the inference patterns required to ensure functional consistency, in so far as it is formalisable, is essentially some form constraint reasoning approach over a spatial or non-spatial domain, which is the forte of the state-of- the-art in AI research (see Sect. 5).

Hypothetical Reasoning

Reasoning about conceptual & functional consistency is only a starting point: for spatial computing, the real challenge of intelligent design assistance is the capability to reason about not what is, but instead about what could be. This form of inference is referred to as hypothetical reasoning. In general, within a decision-support or design assistance tool, metrical changes in the structural layout or changes in the relative spatial relationships of the design elements—i.e., qualitative changes along the conceptual space of the designer—will directly or indirectly entail differing end-product realizations in terms of spatial design requirements, building construction costs, human-factors (e.g., traversability, way-finding complexity), aesthetics aspects, and energy efficiency and long- term maintenance expenses thereof. As such, commonsensical and hypothetical reasoning at the qualitative level about physically realizableFootnote 8 and functionally consistent structural forms represents a useful solution approach that is useful for providing the designer with creative design recommendations.

Alternate recommendations are derivable by hypothesizing the possible/potential spatial re-configurations/transformations (e.g., by translation and deformation actions) at the qualitative level; by not discretizing the space and considering the full range of quantitative possibilities, the problem of hypothetical reasoning is in full generality infinitesimal and intractable. As an example, consider the illustration in Fig. 7. The situation-based history < s0, s1,… , sn > represents one path, corresponding to an actual time-line < t0, t1,… , tn >, within the overall branching-tree structured situation space that could be representative of a space of design evolutions at the qualitative level.

Fig. 7
figure 7

Branching/Hypothetical situation space

Therefore, the objective of hypothetical reasoning about the ‘design space’ is to infer/hypothesize (e.g., by abduction) physically plausible qualitative variations in a design that are also essential or functional requirement fulfilling. Indeed, hypothetical reasoning may also take into consideration domain-specific heuristics/physical attributes that determine aspects such as movability, deformability, stability. Such a logic-based approach may also work as a complementary technique to other approaches such as generative and emergent computations.

Assistive Feedback Mechanisms—Design Simulation

Assistive feedback mechanisms by visualisation and simulation have to be provided in or- der to communicate diagnostics and other forms of design support within a conventional CAAD workflow. Conventional CAAD tools have remained focussed on providing capabilities for aesthetically appealing 3D visualisation of floor-plans. State-of-the-art tools also allow easy placement/visualisation of third-part 3D models of common interior arte- facts, thereby enhancing the 3D visualisation experience. The human-computer interaction aspects involved in the communication and interaction between the a designer and next- generation CAAD tools is an open topic of research. It is not our objective here to speculate on the future directions of this field of research. The visualisation and simulation aspects pointed out in the following are some benchmarks that have been set for our working pro- totype DSim [12]. DSim attempts to operationalize the concept of being able to “live your design”:

  • Semantic browsing vis-a`-vis the structural hierarchy of the design

  • Real-time spatial artefact simulation (e.g., sensors, camera; see Fig. 8)

    Fig. 8
    figure 8

    3D realizations of the functional , operational and the range spaces of the architectural entities. System DSim. [12]

  • Inconsistency pinpointing at the structural and semantic level

  • Hierarchical and selective zooming for specific requirements

  • Automatic reconfiguration and placement of design artefacts

We consider the above features to be crucial and necessary for next-generation CAAD tools that not only support the 2D/3D spatial modelling, but also provide the conceptual spatial modelling and functional reasoning capabilities, such as those described in this paper.

Discussion and Summary

We have addressed two themes in this paper: spatial computing for design on the one hand, and the design of spatial computing itself on the other. The main focus here has been on introducing spatial computing for design as a paradigm, the representational and computational aspects that it needs to addresses as a body of work, and finally the concrete application scenarios that it needs to solve. Our notion of spatial computing (for design) is firmly grounded in the AI/KRR-centred perspective, as enshrined in the initial foundations laid out by early pioneers in the field. Gero [24] positioned “Ten Problems for AI in Design”.Footnote 9 With respect to the scope of spatial computing, as addressed in the present paper, we relate to some of them:

  • Representation in design, Design semantics—“What is it that the designer knows and how do we get a computer to know it?”

  • Inference in design—“much of design inferencing has to do not only with deductive inference but with abductive infe rence which is concerned with what might be rather than what is

  • Combinatorial explosion in design—“as soon as a system deals with what could be it could go on indefinitely

The problem of representation in design and design semantics is related to the modelling of multiple-perspectives and the explicit representation of requirements as per their conceptualization by a designer. The problems of reasoning about what could be and combinatorial explosion in design are two sides of the same coin: hypothetical reasoning (by abduction or otherwise), as positioned in this paper, within a qualitative context, and under additional constraints of physical realizability and architecture domain-specific heuristics is an interesting approach that merits further treatment.

Much has changed in AI since the early 90s. Frame-based systems and semantic net- works have evolved into a range of description logic based ontology languages that are tailored to different levels of expressivity and computational properties [3]. Practical ontology reasoning systems such as Racer [28] and Pellat [43] have also come to the fore. The field of qualitative spatial representation and reasoning has emerged has a new discipline within KRR in the last decade—specialized (in- finite domain) spatial reasoning systems SparQ [50] and GQR [51] now support constraint reasoning and additional application-support services that make it possible to model and reason about spatial knowledge in ways that has not been possible before. Similarly, the evolution of Logic Programming (LP) to Constraint Logic Programming (CLP) [32] and other powerful computational embodiments of the default and non-monotonic reasoning paradigms by way of Answer-Set Programming (ASP) [49] are developments that have only found limited attention in the design community. High-level formalisms to reason about action and change such as the Situation Calculus [36], Event Calculus [33], Fluent Calculus [45], and other more specialized formalisms also similarly grounded in mathematical logic [19], have progressed to the point where prototypical languages (e.g., Indigolog [27], Discrete Event Calculus Reasoner [38], FLUX [27]) allow high-level specification and projective/abductive inference capabilities about dynamic process-like phenomena. These developments open up interesting new possibilities and programming paradigms not only for solving design problems hitherto considered to be computationally intractable, but also for integration, in fundamental ways, of generalised logic-based reasoning on the one hand, and specialized spatial reasoning techniques on the other [10].

The progress made in the last two decades within the knowledge representation and reasoning community in general, and the field of spatial reasoning in specific, warrants a re-visitation into the ‘design as problem-solving’ approach of Simon [41]. In spite of garnering initial momentum and interest in the ‘AI for Design’ community, this approach failed to make an impact by way of practical industrial applications. This paper is partly a statement of our work-in-progress, and partly an attempt to revive some of the basic questions underlying AI in/for design in the context of the specialization we refer to as Spatial Computing.