<?xml version="1.0" encoding="UTF-8"?>
<TEI xml:space="preserve" xmlns="http://www.tei-c.org/ns/1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.tei-c.org/ns/1.0 https://raw.githubusercontent.com/kermitt2/grobid/master/grobid-home/schemas/xsd/Grobid.xsd"
 xmlns:xlink="http://www.w3.org/1999/xlink">
	<teiHeader xml:lang="en">
		<fileDesc>
			<titleStmt>
				<title level="a" type="main">The Interplay between Shape and Feature Representation</title>
			</titleStmt>
			<publicationStmt>
				<publisher/>
				<availability status="unknown"><licence/></availability>
			</publicationStmt>
			<sourceDesc>
				<biblStruct>
					<analytic>
						<author role="corresp">
							<persName><forename type="first">Emilio</forename><forename type="middle">M</forename><surname>Sanfilippo</surname></persName>
							<email>sanfilippo@loa.istc.cnr.it</email>
							<affiliation key="aff0">
								<orgName type="department">ISTC-CNR Laboratory for Applied Ontology</orgName>
								<address>
									<settlement>Trento</settlement>
									<country key="IT">Italy</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Ferruccio</forename><surname>Mandorli</surname></persName>
							<affiliation key="aff1">
								<orgName type="institution">Polytechnic University of Marche</orgName>
								<address>
									<settlement>Ancona</settlement>
									<country key="IT">Italy</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Claudio</forename><surname>Masolo</surname></persName>
							<affiliation key="aff0">
								<orgName type="department">ISTC-CNR Laboratory for Applied Ontology</orgName>
								<address>
									<settlement>Trento</settlement>
									<country key="IT">Italy</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Matteo</forename><surname>Ragni</surname></persName>
							<affiliation key="aff2">
								<orgName type="department">Department of Industrial Engineering</orgName>
								<orgName type="institution">University of Trento</orgName>
								<address>
									<settlement>Trento</settlement>
									<country key="IT">Italy</country>
								</address>
							</affiliation>
						</author>
						<author>
							<affiliation key="aff3">
								<orgName type="laboratory">ISTC-CNR Laboratory for Applied Ontology</orgName>
								<address>
									<addrLine>via alla cascata 56/c</addrLine>
									<postCode>38123</postCode>
									<settlement>Povo</settlement>
									<region>Trento</region>
								</address>
							</affiliation>
						</author>
						<title level="a" type="main">The Interplay between Shape and Feature Representation</title>
					</analytic>
					<monogr>
						<imprint>
							<date/>
						</imprint>
					</monogr>
					<idno type="MD5">4329CE9A7F9ECA4A995716553715BA32</idno>
				</biblStruct>
			</sourceDesc>
		</fileDesc>
		<encodingDesc>
			<appInfo>
				<application version="0.7.2" ident="GROBID" when="2023-03-25T08:35+0000">
					<desc>GROBID - A machine learning software for extracting information from scholarly documents</desc>
					<ref target="https://github.com/kermitt2/grobid"/>
				</application>
			</appInfo>
		</encodingDesc>
		<profileDesc>
			<textClass>
				<keywords>
					<term>Shape modeling</term>
					<term>feature</term>
					<term>CAD systems</term>
				</keywords>
			</textClass>
			<abstract>
<div xmlns="http://www.tei-c.org/ns/1.0"><p>When we approach shape representation, we need to choose which modeling constructs to adopt, e.g., low-level geometric elements like edges and (sur)faces, or more general elements like protrusions, bumps and holes, among others. The latter can be described as spatial configurations of the former satisfying unity and, possibly, identity criteria. However, once these are brought into the picture, we need to understand what they are, how they relate to their shape, as well as how complex shapes result from the combination of simpler ones. We address in the paper these issues and sketch an initial approach based on patterns.</p></div>
			</abstract>
		</profileDesc>
	</teiHeader>
	<text xml:lang="en">
		<body>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1.">Introduction</head><p>When we model shapes, we need to choose which modeling elements to adopt. Consider, e.g., the three-dimensional object (partially showed) in Fig. <ref type="figure" target="#fig_0">1</ref>. We can describe it as being characterised by a U-shape or by referring to more functional elements, e.g., two protrusions, a slot, etc. This scenario is typical of what happens in the context of Computer-Aided Design (CAD) where we can rely on different approaches for shape representation, e.g., by considering pure shapes or by including features.</p><p>These representational alternatives are all viable but we need to recognise (i) that they capture different information and perspectives about the object and (ii) that they have a technical impact on the choice of the modeling language. For instance, once we explicitly use protrusions or slots, we can characterise them by means of functional properties but we also need to add them into our domain and to understand what they are.</p><p>We take here a knowledge engineering stance and focus on the choice of which elements to adopt for shape modeling. In Sect. 2 we introduce two approaches for shape representation that are common in CAD contexts. These approaches provide the basic concepts which are further discussed in Sect. 3 where a notion of 'structured shape' is proposed. Sect. 4 analyses the notions of protrusion, hole, slot, etc. from an ontological perspective, sketching what are the advantages of having these entities in the domain of discourse but also highlighting what are the difficulties to properly account for them. </p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2.">Representing Shapes in CAD Systems</head><p>The wing rib showed in Fig. <ref type="figure" target="#fig_1">2</ref>, a structural element of the skeleton of an airplane wing, is a more realistic case of the U-shaped object in Fig. <ref type="figure" target="#fig_0">1</ref>. From an engineering perspective, CAD systems for mechanical design (MCAD) allow to represent the wing rib by means of basic elements such as faces, edges and vertexes, as well as geometric and topological constraints. The resulting morphology is then mapped into an appropriated data structure called boundary representation (B-rep) <ref type="bibr" target="#b8">[9]</ref>. However, even in MCAD systems, the final B-rep of the wing rib can be obtained in different manners, e.g., by means of low-level modeling constructs (faces, edges, vertexes, etc.), or by composing various and possibly simpler shapes, which can recursively result from other constructs. In the latter case, the choice of which shapes to adopt is not straightforward and different modelers may easily come to the same final shape by means of different (simpler) ones.</p><p>Pure morphological (B-rep based) approaches run the risk of not making explicit relevant information. Looking at Fig. <ref type="figure" target="#fig_1">2</ref>, for example, we may want to acknowledge for holes and mid ribs. As suggested in Jowers and Earl <ref type="bibr" target="#b4">[5]</ref>, this means that we identify in the wing rib those (generally speaking) structural aspects that are relevant for some reasons. The recognition of holes and the like however presupposes that certain modeling constructs are given some kind of unity and are identified as entities of certain types, therefore satisfying identity criteria. On the other hand, this knowledge is not necessarily represented in morphological approaches and needs to be explicitly taken into account.</p><p>In engineering, feature-based approaches have been proposed with the purpose of developing product models by abstracting from low-level geometric elements and relying, instead, on features (e.g., things like holes and ribs, among others) <ref type="bibr" target="#b8">[9]</ref>. Accordingly, features are whole entities that can be associated with disparate properties-e.g., shape or functional properties-and are commonly understood as modeling constructs to represent "the engineering significance of the geometry of a part" <ref type="bibr" target="#b1">[2]</ref>. <ref type="foot" target="#foot_0">2</ref>The introduction of feature-based approaches has been an important improvement of engineering 3D modeling. MCAD systems, however, only include macro-modeling elements to ease model creation but neither provide explicit feature definitions, nor their geometric/topological properties are preserved along the overall modeling process. Moreover, CAD systems are not per se helpful to decide whether the representation of some features should be preferred over the others. Feature representation is indeed contextdependent and different experts recognize the presence of different features in the same model <ref type="bibr" target="#b4">[5]</ref>. For example, looking again at Fig. <ref type="figure" target="#fig_1">2</ref>, from a mechanical perspective the tradeoff between deformation and weight explains a section shape that minimizes the deformation on a prescribed axis, therefore the presence of the mid ribs, as well as the several holes on the lateral surface and the one at the center. From a manufacturing perspective, the object is machined from a blank, therefore by removing material until reaching the described product. It becomes clear that the two interpretations specify different features: structural features in the first case, machined features in the second one.</p><p>Understanding (i) how a complex shape results from the composition of other, simpler, shapes, (ii) what are the ontological properties that these shapes carry, especially when they are looked from a feature perspective, and (iii) how to make sense of multipleperspectives on the same shapes/features are problems that are not restricted to the engineering domain, but more generally apply to the overall context of shape representation. We shall address the first two issues in the remaining sections, while leaving the third one to future work.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.">Structured Shapes</head><p>In cognitive science, the model of geons of Biederman <ref type="bibr" target="#b0">[1]</ref> and the hierarchical model of cylinders of Marr and Nishihara <ref type="bibr" target="#b5">[6]</ref> have been widely used to specify complex shapes. In these approaches, the overall shape of an object is approximated by a primitive shape (e.g., a cylinder or a parametric volume) that can be decomposed into smaller onesapproximating the shape of some relevant parts of the whole-structured in a given way. The decomposition process can be recursively applied. <ref type="foot" target="#foot_1">3</ref> One could think to apply this idea to shape modeling in general, i.e., complex shapes could be represented by considering the way in which basic shapes are recursively (geometrically, topologically, mereologically, etc.) structured. For instance, one could think that the shapes of the objects represented in Fig. <ref type="figure" target="#fig_0">1</ref>-2 are complex, and therefore structured in simpler (basic) ones. Hence shapes could be understood as sorts of distributional properties <ref type="bibr" target="#b7">[8]</ref>, e.g., in the case of colors, being polka-dotted.</p><p>As observed by Jowers <ref type="bibr" target="#b4">[5]</ref>, the way the designers build complex shapes starting from simple ones is important for the understanding of the design itself since it may reflect, for instance, functional requirements or the way in which designers think about the shapes themselves. Let us consider the object in Fig. <ref type="figure" target="#fig_0">1</ref>. Fig. <ref type="figure" target="#fig_2">3</ref> shows different shapes that describe the morphology of this object. As in the case of the hierachical model of Marr and Nishihara, we assume that, at a given level of granularity, the shape of the whole object is 'approximated' by a basic one, which we assume to be a B-rep. In Fig. <ref type="figure" target="#fig_2">3</ref>.a one has a single basic (unstructured) shape, a single level of granularity, i.e., a single B-rep (dots represent edges, while lines represent faces). Vice versa, Fig. <ref type="figure" target="#fig_2">3</ref>.b depicts the case of a complex shape obtained by structuring the basic shapes A b <ref type="foot" target="#foot_2">4</ref> and B b according to a given geometrical pattern represented by the dotted line. First, note that the shape B b is used two times in Fig. <ref type="figure" target="#fig_2">3</ref>.b, i.e., the spatial pattern requires the same shape B b to be linked in two different ways to A b . In terms of colors, one can think to the pattern of red/blue/red strips, where red occurs twice. Second, the existence of the shape does not necessarily implies the existence of an object with this shape, i.e., the designed product may be still atomic (i.e., without any component), hence the existence of a component for each basic shapes is not mandatory. Third, the shape in Fig. <ref type="figure" target="#fig_2">3</ref>.b is intended to capture two levels of granularity. The finer one is given in terms of the spatial distribution of the shapes A b and B b . The coarser one is just a basic shape that is implicit in the picture, and which corresponds to the B-rep in Fig. <ref type="figure" target="#fig_2">3</ref>.a. One can thus think that the shape in Fig. <ref type="figure" target="#fig_2">3</ref>.b is a refinement of the one in Fig. <ref type="figure" target="#fig_2">3</ref>.a because it adds some structural information that A a discards. Clearly, A a can be refined in alternative ways, e.g., in Fig. <ref type="figure" target="#fig_2">3</ref>.c one starts from different shapes and a different pattern. Note that the shapes in Fig. <ref type="figure" target="#fig_2">3</ref>.b and Fig. <ref type="figure" target="#fig_2">3</ref>.c are different even though at the coarser level they coincide with A a . We can re-iterate the process of decomposition introducing more refined shapes distributions.</p><p>Considering features, one can think that, e.g., a parallelepipedic protuberance or a parallelepipedic hole are specific kinds of shapes that differ from other parallelepipedic shapes, because of the way in which they are related to other shapes. Following this reasoning, a parallelepipedic protuberance can be defined as a parallelepipedic shape plus a pattern specifying how the shape must be linked to another one. Fig. <ref type="figure" target="#fig_2">3</ref>.d shows the graphical notation for a protuberance where the depicted pattern means that the lower face of B d must be connected (in a certain way) to a face of the host-shape. Holes are more complex than protuberances, since to obtain the B-rep that approximates a complex shape with a hole the B-rep of the hole has to be discarded from the whole. In Fig. <ref type="figure" target="#fig_2">3</ref>.e, we represent (basic) holes with grey edges and surfaces. If the design explicitly refers to holes, the shape A a can be refined as in Fig. <ref type="figure" target="#fig_2">3</ref>.e, where C e is a (basic) parallelepipedic hole. Accordingly, the upper face of C e is not part of the B-rep in A a . Furthermore, the pattern that specifies the hole includes also constraints on the way the three shapes it plugs-in are connected.</p><p>In this view, shapes do not reduce to B-reps; they are rather recursively structured into simpler 'building blocks' linked according to given patterns. However, once we bring these building blocks into the picture, we want to make sense of their differences in terms of a reference ontology for objects' representation. Especially when we move from the specification of abstract shapes to engineering modeling, we are interested in making explicit the distinctions, e.g., between a shape construct referring to a material product, and one referring to a (physical) hole or a protrusion. For instance, looking again at Fig. <ref type="figure" target="#fig_2">3</ref>.e, one may wonder why a shape for a hole must be necessarily related to a shape referring to some (material) object. We shall see in the next section that this choice, enforced by means of a suitable pattern, relies on the ontological assumptions about what holes are.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4.">An Ontological Framework for Feature Representation</head><p>For our purposes, we adopt a minimal ontology distinguishing between objects, parasitic objects (parasite, for short) and qualities. Objects are extended in space and are possibly made of some material; an example is the physical counterpart of the wing rib showed in Fig. <ref type="figure" target="#fig_1">2</ref>. Parasitic objects are objects that ultimately depend on non-parasites, i.e., they cannot exist if detached from the latter, e.g., the head of a bolt. <ref type="foot" target="#foot_3">5</ref> Qualities are objects characteristics, e.g., the weight of a wing rib, or the pitch of a threaded screw.</p><p>In terms of this framework, (physical) holes or protrusions fit well with the notion of parasite. E.g., to be a protrusion (or a hole) means to be a protrusion in something else. By 'objectifying' features, we have the possibility of representing them along with their characterising qualities without however reducing them to qualities themselves. Additionally, we reflect engineering theories treating features as objects satisfying unity and possibly even identity criteria. We will therefore adopt this approach from now on.</p><p>Looking at the ontological dependence of parasites, it can be understood as being either specific or generic. In the first case, a feature f depends on a specific individual o, so that if o ceases to exist, then f ceases to exist, too. In the second case, f depends on some entity (of a certain type), so that f can survive the replacement of its host. <ref type="foot" target="#foot_4">6</ref>Despite this distinction finds its place in ontology <ref type="bibr" target="#b6">[7]</ref>, it is not straightforward to establish the kind of dependence that a parasite satisfies. Consider, for instance, the hole at the centre of the wing rib in Fig. <ref type="figure" target="#fig_1">2</ref>, call it h. On the one hand, we can assume that as far as h maintains its identity, it keeps existing although the radical changes that its host may undergo. For example, assume that persistence conditions of the wing rib are given in functional terms, so that it ceases to exist when it cannot exhibit its functionality. If generic dependence is adopted, then h may continue to exist when the wing rib 'passes away'. On the other hand, if specific dependence is adopted, then h stops existing along with the wing rib. Since from an ontological perspective both views are well motivated, the choice of which kind of dependence to adopt relies on background domain assump-tions. In the case of CAD modeling, for instance, specific dependence may be better suited, since each feature is intentionally attached to individual products.</p><p>We now need to make sense of the fact that some features are ascribed with materiality. We therefore introduce the notion of material parasite, that is, a parasitic object made of some material. Conversely, an immaterial parasite lacks material constitution. Consider now holes: <ref type="foot" target="#foot_5">7</ref> are they material or immaterial parasites? Both views are found in philosophical ontology <ref type="bibr" target="#b2">[3]</ref>, as well as in engineering. On the one hand, it is indeed common to refer to holes as voids, which are often ascribed with the functionality of accommodating some other entity, e.g., screws. <ref type="foot" target="#foot_6">8</ref> On the other hand, a hole in an object is understood as set of surfaces with a characterising shape. Take again the hole h in the wing rib. From the latter perspective, h is the cylindrical surface of the wing rib located in a certain spatial position (within the spatial system relative to the wing rib). From the former perspective, h is the cavity which is (topologically) connected to some of the wing rib surfaces. It is hard to discard one of these views, since-looking at a hole-one may need to represent both a cavity (e.g., in which something can be accommodated) and a surface (possibly made of some material) to which the cavity connects. From an ontological stance, these are however two different entities. We therefore propose to distinguish between cavity-like (or void-like) features as immaterial parasites and the (material) objects to which they connect.</p><p>Admittedly, this ontological framework is still general and more specific constraints should be added, e.g., to characterize features with respect to functional properties. The introduced distinctions are however helpful to shed some light on the high-level properties that features satisfy, and to support the development of patterns for shape modeling that are coherent with these properties. For instance, if we consider components as products intentionally designed to be possibly related to some other product, then features cannot be components. Indeed, it is reasonably to assume that a component can exist on its own, whereas-as we saw-the existence of features depends on other entities. <ref type="foot" target="#foot_7">9</ref></p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="5.">Conclusions</head><p>We addressed some general issues concerning shape modeling. In particular, we saw that shapes can be represented by means of different modeling constructs at different representational layers. B-rep models can be taken as the lowest representational level since they provide a precise specification of morphological properties in terms of vertexes and other low-level geometric constructs. We saw that this approach comes with its own costs, e.g., it does not allow to refer to a certain portion of the shape at stake to attribute it some functional property. Following cognitive science theories and engineering modeling approaches, we considered how to build a more strctured, coarse-grained representational level on the top of B-rep constructs. Accordingly, an overall shape results from the composition of multiple (simpler) shapes, which are spatially arranged according to given patterns. In other words, in this second level structured collections of B-rep ele-</p></div><figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_0"><head>Figure 1 .</head><label>1</label><figDesc>Figure 1. Sketch of the section of a 3D object</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_1"><head>Figure 2 .</head><label>2</label><figDesc>Figure 2. 3D model of wing rib</figDesc><graphic coords="2,198.43,412.50,198.43,109.42" type="bitmap" /></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_2"><head>Figure 3 .</head><label>3</label><figDesc>Figure 3. Different shapes for the object in Fig. 1</figDesc></figure>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="2" xml:id="foot_0">'Part' is synonym of 'product' in this sentence.</note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="3" xml:id="foot_1">Approximation and granularity play a central role in the process of recognizing and representing shapes.</note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="4" xml:id="foot_2">A x denotes the basic shape indicated with A in Fig.3.x. In general A x and A y are different in case x = y.</note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="5" xml:id="foot_3">For the sake of the example, we assume that when the head of a bolt is detached from the bolt, it stops existing as 'the head of the bolt'. In this sense, the head is a 'parasitic part' of the bolt.</note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="6" xml:id="foot_4">We call host the entity upon which a parasite depends.</note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="7" xml:id="foot_5">The same considerations can be done for features like slots, pockets, etc.</note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="8" xml:id="foot_6">See the modeling element IfcFeatureElementSubtraction in the Industry Foundation Classes (IFC); http://www.buildingsmart-tech.org/ifc/IFC4/Add1/html/, last access on July 2017.</note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="9" xml:id="foot_7">We assume here a rigid<ref type="bibr" target="#b3">[4]</ref> notion of component. This means that an object is a component for the entire duration of its life, independently from the fact that it is not attached to some other product at a certain time.</note>
		</body>
		<back>

			<div type="acknowledgement">
<div xmlns="http://www.tei-c.org/ns/1.0"><p>ments are explicitly selected and composed. On the top of structured shapes, we built an ontological level to characterise the ontological nature of features in the scope of a larger ontology for objects' representation. In particular, we sketched a way to distinguish protrusions and holes, which are usually considered in CAD-based design.</p><p>Even though the choice of which building blocks to adopt is up to modelers and their use may rely on different requirements such as the optimisation of the design process, or the specification of functional properties, by explicitly representing this choice and the way the object under design is structured, we think that the proposed approach may facilitate the integration between different designs as well as their conceptual clarification.</p></div>
			</div>

			<div type="references">

				<listBibl>

<biblStruct xml:id="b0">
	<analytic>
		<title level="a" type="main">Recognition-by-components: A theory of human image understanding</title>
		<author>
			<persName><forename type="first">I</forename><surname>Biederman</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Psychological review</title>
		<imprint>
			<biblScope unit="volume">94</biblScope>
			<biblScope unit="issue">2</biblScope>
			<biblScope unit="page">115</biblScope>
			<date type="published" when="1987">1987</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b1">
	<analytic>
		<title level="a" type="main">Feature modelling and conversion. Key concepts to concurrent engineering</title>
		<author>
			<persName><forename type="first">W</forename><surname>Bronsvoort</surname></persName>
		</author>
		<author>
			<persName><forename type="first">F</forename><surname>Jansen</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Computers in Industry</title>
		<imprint>
			<biblScope unit="volume">21</biblScope>
			<biblScope unit="issue">1</biblScope>
			<biblScope unit="page" from="61" to="86" />
			<date type="published" when="1993">1993</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b2">
	<monogr>
		<title level="m" type="main">Holes and other Superficialities</title>
		<author>
			<persName><forename type="first">R</forename><surname>Casati</surname></persName>
		</author>
		<author>
			<persName><forename type="first">A</forename><surname>Varzi</surname></persName>
		</author>
		<imprint>
			<date type="published" when="1994">1994</date>
			<publisher>Mit Press</publisher>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b3">
	<analytic>
		<title level="a" type="main">An overview of OntoClean</title>
		<author>
			<persName><forename type="first">N</forename><surname>Guarino</surname></persName>
		</author>
		<author>
			<persName><forename type="first">C</forename><surname>Welty</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Handbook on ontologies</title>
				<editor>
			<persName><forename type="first">S</forename><surname>Staab</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">R</forename><surname>Studer</surname></persName>
		</editor>
		<imprint>
			<publisher>Springer</publisher>
			<date type="published" when="2009">2009</date>
			<biblScope unit="page" from="201" to="220" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b4">
	<analytic>
		<title level="a" type="main">Shape interpretation with design computing</title>
		<author>
			<persName><forename type="first">I</forename><surname>Jowers</surname></persName>
		</author>
		<author>
			<persName><forename type="first">C</forename><surname>Earl</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Design Computing and Cognition&apos;12</title>
				<imprint>
			<publisher>Springer</publisher>
			<date type="published" when="2014">2014</date>
			<biblScope unit="page" from="343" to="360" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b5">
	<analytic>
		<title level="a" type="main">Representation and recognition of the spatial organization of three-dimensional shapes</title>
		<author>
			<persName><forename type="first">D</forename><surname>Marr</surname></persName>
		</author>
		<author>
			<persName><forename type="first">H</forename><surname>Nishihara</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Proceedings of the Royal Society of London B: Biological Sciences</title>
		<imprint>
			<biblScope unit="volume">200</biblScope>
			<biblScope unit="page" from="269" to="294" />
			<date type="published" when="1140">1140. 1978</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b6">
	<monogr>
		<title level="m" type="main">WonderWeb deliverable D18</title>
		<author>
			<persName><forename type="first">C</forename><surname>Masolo</surname></persName>
		</author>
		<author>
			<persName><forename type="first">S</forename><surname>Borgo</surname></persName>
		</author>
		<author>
			<persName><forename type="first">A</forename><surname>Gangemi</surname></persName>
		</author>
		<author>
			<persName><forename type="first">N</forename><surname>Guarino</surname></persName>
		</author>
		<author>
			<persName><forename type="first">A</forename><surname>Oltramari</surname></persName>
		</author>
		<imprint>
			<date type="published" when="2003">2003</date>
		</imprint>
		<respStmt>
			<orgName>Laboratory for Applied Ontology ISTC-CNR</orgName>
		</respStmt>
	</monogr>
	<note type="report_type">Technical report</note>
</biblStruct>

<biblStruct xml:id="b7">
	<monogr>
		<author>
			<persName><forename type="first">J</forename><surname>Parsons</surname></persName>
		</author>
		<title level="m">Distributional properties. Lewisian themes</title>
				<imprint>
			<date type="published" when="2004">2004</date>
			<biblScope unit="page" from="173" to="180" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b8">
	<monogr>
		<title level="m" type="main">Solid modelling and CAD systems: How to survive a CAD system</title>
		<author>
			<persName><forename type="first">I</forename><surname>Stroud</surname></persName>
		</author>
		<author>
			<persName><forename type="first">H</forename><surname>Nagy</surname></persName>
		</author>
		<imprint>
			<date type="published" when="2011">2011</date>
			<publisher>Springer Science &amp; Business Media</publisher>
		</imprint>
	</monogr>
</biblStruct>

				</listBibl>
			</div>
		</back>
	</text>
</TEI>
