An Ontology Design Pattern and its use case for modeling material transformation

Abstract

In this work we introduce a content Ontology Design Pattern (ODP) to model and reason about material transformations, a concept that occurs in many different domains ranging from computational chemistry, biology, and industrial ecology to architecture. We model the relationships between inputs, outputs, and catalysts in the transformation process as well as the spatial and temporal constraints necessary for a transformation to occur. Both a graphical illustration and a formal axiomatization are provided, and the commonalities and differences to similar ontologies and patterns are discussed. Usage of the pattern is illustrated by applying it to an intuitive and familiar example and by discussing how the pattern is able to address a set of competency questions. Additionally, we present a detailed use case from the domain of sustainable construction that leverages the material transformation pattern in combination with the already-existing semantic trajectory ontology design pattern.

1. Introduction

This paper presents an ontology design pattern to model and reason about material transformations. This is an important modeling challenge for two reasons. First, material transformations occur in many different contexts from a wide variety of domains. For example, the well known chemical reaction combining sodium hydrogen carbonate (baking soda) and acetic acid (vinegar) to produce carbon dioxide and sodium acetate is a material transformation. So is the fusion process within the stars, which converts hydrogen to helium and releases light and heat (and eventually heavier elements). The same is true for the bio-chemical process of photosynthesis consisting of a complex, multi-step, set of material transformations. In these examples, there is some fundamental change in identity of the constituting “parts” in material objects between the input and output of a transformation process. While the provided examples highlight the role of material transformation in multiple domains, a second argument can be made from the perspective of ontology engineering: the notion of material transformation with its inputs, outputs, and catalysts, as well as their spatiotemporal dependencies is challenging to axiomatize. Material transformations involve both spatial and temporal restrictions (i.e., the inputs must be at the same location at the same time), they can occur at widely different scales, from atoms to stars, they frequently involve both matter and energy, and they often require the presence of components that are not directly part of the transformation as such (e.g., a catalyst, tool, or environmental conditions). As one of the goals of developing ODPs is to encode best practices for difficult and recurring modeling tasks, an ODP for material transformation is well warranted.

People and organizations are generating increasingly large amounts of data, but this data is only useful if it can be combined and analyzed in ways that improve our understanding. This can be quite challenging however, because data is often stored in individual databases, spreadsheets, or tables within HTML documents. Moreover, these data collections are all created by different people, with different ways of looking at the world and different applications in mind. Many researchers and practitioners have attempted to unite disparate data sources by aligning them to a single ontology. An ontology is a representation of the concepts in a domain and the relationships between them. Ontologies are often likened to database schemas, but modern languages for representing ontologies, such as OWL, allow designers to express much richer relationships among entities than is possible in a database.

Unfortunately, it turns out to be quite difficult to align existing data sets to large monolithic ontologies that attempt to represent entire domains. Individual data collections have widely varying existing structures, and fitting them all into a single worldview is like trying to push as many square pegs into a single round hole. Logical inconsistencies almost inevitably result. Knowledge modeling researchers and practitioners are increasingly turning towards ontology design patterns (ODPs) as an alternative. An ODP-based strategy avoids a single over-arching view of a domain in favor of smaller, modular pieces. Similar to the software design patterns by which they were inspired, an ODP is a reusable solution to a data-modeling problem that occurs frequently in many different datasets with a domain (or across several domains). Examples are entities such as Person or Event that need to be represented in many different situations. These key concepts allow various datasets that contain them to be used in analyses without the need for complete agreement or conformance on all parts of a domain model. An ODP makes only the minimum number of ontological commitments necessary to describe the concept it represents, thereby respecting the heterogeneity of existing data schemas to the maximum degree possible.

There are several existing ontologies and ontology design patterns related to material transformation. Some of these are more specific, representing material transformations in particular fields. For instance, the Cell Cycle Ontology can be used to represent cell division, a particular type of material transformation within the biology domain [11]. Similarly, mason is an ontology describing manufacturing and can be used to describe many of the processing steps that transform raw materials into finished goods [9]. Other existing ontological models describe similar but more general concepts. For instance, the Transition pattern on ontologydesignpatterns.org1

¹

http://ontologydesignpatterns.org/wiki/Submissions:Transition.

is meant to represent the transition of objects from one state to another. This transition may or may not be physical. The pattern proposed here differs from previous efforts in that it is domain-agnostic and focuses on modeling the common core necessary to reason about the physical transformation of matter. Further, we present a full axiomatization that goes beyond mere surface semantics (e.g., in contrast to a mere subsumption hierarchy) [8]. It should be noted that the Reactive Process pattern, also on the ODP website,2 ²

http://ontologydesignpatterns.org/wiki/Submissions:Reactor_pattern.

seems to have the same topic as the one addressed in this paper, in that it seeks to represent “reactive processes that consume inputs and produce outputs under specific environmental conditions and on being triggered by certain events”. Our material transformation pattern differs by focusing on axiomatizing the conditions for such a transformation (or reaction) to take place. In particular, we seek to model temporal and spatial conditions necessary for the transformation to occur. While there is always a tradeoff between the number and strength of ontological commitments made by a pattern and the number of situations in which the pattern can be applied, we argue that the temporal and spatial constraints are fundamental aspects of a material transformation.

Several upper ontologies define the concepts of material entities, physical objects and constituting matter [10,14]. Formalization of the constitution and structure of physical objects is complex and outside the scope of the current pattern, but has been explored in previous publications [1,6,13]. The presented pattern is agnostic with respect to the choice of a potential upper ontology alignment, but for the purpose of discussion, we use dolce as an exemplar upper ontology. According to dolce , material entities are Physical-Endurants that are fully present at points in space and time, of which Physical-Object is a specialization of and is constituted by an Amount-of-Matter. Physical-Objects may be constituted by other Physical-Objects, naturally occurring or man-made at varying degrees of granularity.

This work builds upon an initial pattern short paper [15] by significantly expanding the discussion of how the material transformation pattern is being used in a current research effort to answer questions related to the embodied energy of construction materials in order to facilitate greener construction practices, by providing a full axiomatization, by relating the pattern to previous work, and by providing examples for the use of the pattern and its interaction with other patterns, in this case the semantic trajectory pattern [7].

In the following section we will clarify our definition of a material transformation and delineate what is in versus out of scope for the pattern. Next, Section 3 then presents the pattern in both an intuitive graphical manner and via a formal axiomatization. The pattern is also applied to an example that is familiar to everyone – baking a cake – in order to further illustrate its intended use without requiring domain expertise from the reader. Section 4 contains an in-depth use case involving an ongoing research effort related to sustainable construction. This use case highlights the power of leveraging multiple ODPs to structure disparate data in a way that facilitates analysis of cross-domain questions. Finally, Section 5 concludes the paper with a summary and a discussion of future work.

2. Problem statement

Intuitively, we require that a material transformation must involve at least one material, and that material must undergo some transformation. This has several implications: the transformation has inputs and outputs, at least one input is not among the outputs (because it has been transformed), and at least one output is not among the inputs (because it was produced during the transformation). Further, at least one input must be a material thing. Based on this definition, we consider transformations involving only energy, such as a drop in air temperature, to be out of scope for the work at hand. Also out of scope are transformations involving non-physical entities such as opinion in an electorate or the balance in a bank account. Some borderline cases are possible. For instance, a person aging over the years has certainly undergone a material transformation, but is this true of a person who has aged a second? Are they the same person? In one sense yes, but at a cellular level there have been many changes. In cases like this, the applicability of the pattern depends on the time scale involved or the degree of detail present in the model. It should be also noted that there may, and in many use cases will, be incomplete knowledge of the fine grained mechanisms in a transformation process and intermediate steps along a process. As such, a transformation pattern should be capable of describing various levels of granularity, but concern itself with changes between observed inputs and outputs much as conservation laws are formulated in the physical sciences. By repeated application of the pattern, one could in principle achieve whatever stepwise granularity is desirable to describe the process. In general, however, we will leave such more philosophical arguments aside and focus on a data-centric modeling and application of the pattern.

The material transformation ODP should be capable of answering at least the following competency questions:

What inputs are required to produce an output?

Which of those inputs are consumed during the transformation process?

What is the minimum time required to produce an output?

Given a set materials and their locations, is a particular transformation possible at a given moment in time?

3. The pattern

In the following, we discuss the pattern, its axiomatization, and give an example of its application. An OWL implementation of this pattern is available at the ontologydesignpatterns.org website.3

³

http://ontologydesignpatterns.org/wiki/Submissions:Material_Transformation.

3.1. Description

Fig. 1.

This depicts the Material Transformation ODP with the corresponding axiomatization. The prefix time: refers to “http://www.w3.org/2006/time#” namespace.

A graphical representation of the material transformation pattern is shown in Fig. 1 together with the axiomatization in Description Logic (DL) notation. In the figure, we introduce a number of vocabulary terms for material transformation, which consist of classes (depicted using yellow nodes) and object properties (depicted by blue arrows). Each blue arrow goes from the domain of the corresponding object property towards its range. Axioms (1)–(4) are domain restrictions for each of the four object properties in the pattern, whereas (5)–(8) are the corresponding range restrictions. Note that the aforementioned domain and range restrictions are given as guarded restrictions, which are preferable to the unguarded versions (i.e., of the form $\mathsf{dom}\mathrm{(}\mathit{P}\mathrm{)}⊑\mathit{A}$ and $\mathsf{range}\mathrm{(}\mathit{P}\mathrm{)}⊑\mathit{B}$ ) because they enforce weaker ontological commitments and thereby foster wider reuse.

The notion of material transformation itself is represented by the MaterialTransformation class. In this pattern, a MaterialTransformation is understood as a space-time entity occurring within some spatial confine during a certain time interval. This is asserted in axioms (9) and (10) using the classes Neighborhood and time:Interval. The Neighborhood class encapsulates some topological definition of nearness in a manner and granularity appropriate for the transformation being modeled. Possibilities include relational calculus [2], positional coordinates, a bounded area on a map, or a named region such as a place (e.g. a city or factory). Because the appropriate definition of a neighborhood varies widely depending on the particular application, such details are not restricted in the pattern to foster reuse and adaptability. Meanwhile, the time:Interval class from the W3C’s OWL Time ontology4 ⁴

http://www.w3.org/TR/owl-time/.

is used to represent the time interval in which a transformation occurs.

In addition to its spatial and temporal aspects, a MaterialTransformation takes in at least one Input and produces at least one Output as stated in axioms (11) and (12). The inputs and outputs have to be material, hence Input and Output are subclasses of the MaterialObject class, as given by axiom (13). The class Catalyst represents inputs of a MaterialTransformation that are neither consumed nor changed during the transformation – hence also among the transformation’s outputs. Examples include traditional catalysts, such as chlorine in the transformation of ozone to oxygen, as well as tools used in a transformation process, such as a soldering iron used to assemble components (together with solder) into a finished product. Axiom (14) asserts that Catalyst is a subclass of both Input and Output. The classes Input, Output, and Catalyst are intentionally generic to accommodate possibly different granularities in the use cases.

The axiomatization also needs to express that a MaterialTransformation has at least one input that is not part of the output and at least one output that is not part of the input (i.e. that something was transformed). Using first-order logic, these can be expressed as the following two formulas: $$\begin{array}{ll}\hfill \forall \mathit{x}.\mathrm{(}& \mathsf{MaterialTransformation}\mathrm{(}\mathit{x}\mathrm{)}\to \\ \hfill & \exists \mathit{y}.\mathrm{(}\mathsf{hasInput}\mathrm{(}\mathit{x}\mathrm{,}\mathit{y}\mathrm{)}\wedge \neg \mathsf{hasOutput}\mathrm{(}\mathit{x}\mathrm{,}\mathit{y}\mathrm{)}\mathrm{)}\mathrm{)}\\ \hfill \forall \mathit{x}.\mathrm{(}& \mathsf{MaterialTransformation}\mathrm{(}\mathit{x}\mathrm{)}\to \\ \hfill & \exists \mathit{y}.\mathrm{(}\mathsf{hasOutput}\mathrm{(}\mathit{x}\mathrm{,}\mathit{y}\mathrm{)}\wedge \neg \mathsf{hasInput}\mathrm{(}\mathit{x}\mathrm{,}\mathit{y}\mathrm{)}\mathrm{)}\mathrm{)}\end{array}$$ Unfortunately, the above formula cannot be expressed strictly within OWL 2 DL, though there are extensions of DL that can express them, e.g., using Boolean constructors on properties as described in [12], we arrive at axioms (15) and (16). Since we go beyond OWL 2 DL with the above axioms, we do not include them in the OWL implementation referred to at the beginning of this section, and any typical use of OWL 2 reasoner on the OWL implementation will of course not take the axioms above into account. On the other hand, this issue will not impact querying use cases since these axioms are used as constraints for checking integrity on the data used to populate the pattern. The latter requires a closed-world reading of the axioms, which are not part of OWL 2 standards, and there exists reasoners possessing features, e.g., Pellet, that allow us to perform this special task.

3.2. Extension with energy information

Fig. 2.

This depicts an extension of the Material Transformation ODP with energy information, together with the axioms (in addition to the ones in Fig. 1). The prefix xsd: refers to the XML schema namespace given by the URI “http://www.w3.org/2001/XMLSchema”.

The Material Transformation ODP depicted in Fig. 1 is intended to be generic as no other property is introduced for the classes in it except the ones essential to the conceptualization of material transformation. This allows one to freely introduce adornments to the classes in the pattern according to the needs of a particular example or use case. In this section, we illustrate how the pattern can be extended by introducing adornment to some of the classes in the pattern.

As illustrated by the use case in Section 4.2, a major motivation for the development of the Material Transformation ODP is to assist domain experts to model the energy required for a transformation or assembly of materials into the desired artifact. An extension of the pattern that achieves this objective can be obtained by adorning the pattern with energy information according to Fig. 2. The axiomatization is extended with additional axioms given in the same figure. In this adorned Material Transformation ODP, we define an object property called usesEnergy with the MaterialTransformation class as the domain and Energy as the range. The guarded domain and range restrictions for this object property are given in axiom (17) and (18).

Meanwhile, our formalization of the notion of energy in this extension of the Material Transformation ODP is rather simplistic and essentially inspired by the modeling of quantities in the QUDT ontology.5 ⁵

http://qudt.org/.

Here, the class Energy itself is just an abstraction of the notion of energy. So, instead of directly attaching energy value to the MaterialTransformation class, we employ an instance of the Energy class, which can even be anonymous or an RDF blank node. This instance of Energy acts as a hook to which the energy value and indirectly, the energy unit are attached. Like the instance of the Energy class, instances of the EnergyValue and EnergyUnit classes can also be simply RDF blank nodes to which numeric and literal values are attached. This demonstrates a flexible modeling approach and allows for further enrichment if necessary, for example, by augmenting it with information about the degree of uncertainty of the energy measurement or controlled vocabulary for the energy unit.

For the axiomatization, we assert that every instance of Energy must have an EnergyValue, which must have a numeric value and an EnergyUnit. An instance of EnergyUnit itself must have, in this model, a string literal representing the energy unit. All of these are asserted in axiom (19)–(30).

3.3. Example

Fig. 3.

Instantiation of the material transformation pattern to illustrate mixing cake batter.

In order to illustrate the usage of the pattern, we now show how it can be applied to represent a material transformation familiar to everyone – baking a cake.

Simple White Cake6 ⁶

Based on the recipe found at http://allrecipes.com/recipe/simple-white-cake/.

Ingredients:

• 1 cup sugar

• 1 1/2 cups flour

• 1/2 cup butter

• 1 3/4 teaspoons baking powder

• 2 eggs

• 1/2 cup milk

• 2 teaspoons vanilla extract

Directions:

1. Mix all of the ingredients together in a medium bowl and pour the batter into a 9 × 9 inch pan.

2. Bake in oven for 30–40 minutes at 350 F.

There are two steps in this simplified recipe, each corresponding to a material transformation: mixing the ingredients to make the batter, and cooking the batter to make the cake. Figure 3 shows the first of these steps. Each ingredient is an instance of the Input class and the range of the hasInput property. Note that if we wanted to represent the amount of each input, we could extend the pattern by adding a hasAmount property to Input with a range of InputAmount, along with a corresponding InputUnit. This approach is analogous to EnergyValue and EnergyUnit in the extended pattern. Figure 3 shows the instantiation of a particular time a cake was prepared, rather than illustrating the general process of making a cake. Therefore, the time interval begins and ends at specific points in time and the kitchen specified as the neighborhood is a particular kitchen. A medium bowl and a spoon are instances of Catalyst for this transformation, because they are required for the process but are not altered by it.

Fig. 4.

Instantiation of the material transformation pattern to illustrate baking a cake.

Figure 4 illustrates a second instantiation of the pattern that captures the transformation from cake batter to finished cake. Note that the product cake_batter from the Fig. 3 is an input here. This is a key aspect of the material transformation pattern – it can be used recursively to model the construction of a complex product from raw materials, to intermediate components, to finished product. Figure 4 uses the energy-related extensions to the base pattern. The energy used is what was required to maintain a temperature of 350 degrees Fahrenheit in the oven for 35 minutes (the time it took to bake the cake in this instance).

4. Use case

According to the United Nations, the construction industry and related support industries are leading consumers of natural resources. The industry has consequently focused on using more environmentally friendly building practices and greener construction materials. However, metrics and data are needed to determine if one particular construction material has less environmental impact than another. When trying to compare two options, one key criteria is the “embodied energy” of each material. Embodied energy is a life cycle inventory of the sum of all energy used to produce something as well as the energy to dispose of the artifact after its useful life is completed. In the cake example from Section 3.2, the embodied energy of the cake would obviously include the energy required to heat the oven to 350 degrees and keep it there for the time required for baking. Perhaps not so obviously, the embodied energy would also technically include the energy required to plant and harvest the wheat, mill the wheat into flour, and transport the flour to the grocery store.

Fig. 5.

Sources of embodied energy in a building through its entire lifecycle in space and time. Edges represent transport of architectural artifacts. Nodes represent transformation of architectural artifacts.

Clearly, it is very difficult to accurately calculate embodied energy even for very simple products. The challenge is significantly greater for complex architectural structures like buildings. As Fig. 5 shows, the energy embodied in a building comes from a wide variety of sources and throughout all phases of its lifecycle. Even determining the amount of embodied energy in base construction materials is difficult, due to poor quality data sources, regional and international variation in data, incomplete secondary data sources, and variation in manufacturing technology, all of which lead to significant variation in calculated values [3]. The Green Scale Project7 ⁷

http://www.greenscale.org.

is studying the feasibility of creating a knowledge base (KB) to mitigate some of these challenges [5]. The KB would contain data on energy and fuel production in different geographical locations in the form of linked open data. It would also contain information related to processes that impact the embodied energy of building components. These include initial manufacture of materials, prefabrication, assembly, renovation, refurbishment and demolition [4]. This KB will enable a systematic “cradle to grave” life cycle analysis of the energy embodied in construction products. It will also support the comparison of different options for construction material sources and their effect on the embodied energy of the final product (e.g. the building).

The Green Scale project plans to use ontology design patterns to structure its knowledge base and is influenced by the data and analysis workflows currently used by the research team. It is believed that application of the ODP will make it easier for the many datasets relevant to the computation of embodied energy to be brought into the KB. Each dataset provider can align their data to the relevant ODPs without needing to “buy in” to a monolithic foundational ontology or change the way their data is stored internally. Furthermore, an ODP-based approach can help to bridge differences in the level of schema, abstraction and measurement units used by different datasets.

The different stages in the construction process (e.g. prefabrication, assembly, etc.) are predominately composed of two types of steps: transportation and transformation. First all of the materials needed to manufacture a component are brought to the same place, and then the component is crafted. That component may then be transported somewhere else, where it is used in the construction of a more complex product. Transportation events are illustrated by the edges of the graph in Fig. 5. Transportation of a manufacturing component from location to location and the energies associated with that transportation can be modeled via the already-existing Semantic Trajectory pattern. This pattern is described briefly in the following section, and more detail can be found in [7]. One of the primary goals of the Material Transformation ODP presented in this paper was to fill the missing hole by allowing domain experts to model the energy required for transformation or assembly (nodes of Fig. 5) of one or more components into the desired manufactured artifact.

Fig. 6.

Semantic Trajectory Ontology Design Pattern.

The ultimate goal is to chain together instantiations of the Material Transformation and Semantic Trajectory ODPs to represent a limited subset of the manufacturing process – those portions of the manufacturing value chain that involve the creation of a new material or component by bringing together input resources in the presence of one or more catalysts. It should be noted that the pattern is not intended to model the process plans, agents and other aspects of the manufacturing process outside the scope of pattern development. However, this pattern may be used in concert with other patterns to answer broader questions related to the manufacturing process. The following discussion is a demonstration of how the ODP may be used to compute the total energy embodied in the output product by aggregating the energy embodied in the input components and the catalysts, the energy used to transport these items to the same location, the energy required by the material transformation itself, and the energy used to transport the output of the transformation to the location at which it will be used. This cannot be done directly with OWL, but can be done by implementing a computational procedure in the corresponding application that makes use of the necessary information easily retrievable from the populated pattern. Note that in order to be able to account for the embodied energy in the input components and catalysts, we also need to add an adornment with energy information similarly to the way the MaterialTransformation class was adorned as was described in Section 3.2.

4.1. A related pattern: Semantic trajectory

An ontology design pattern to represent the semantic trajectory of a moving object (Fig. 6) is presented in [7]. That work defines a trajectory as “a path through space on which a moving object travels over time”. At its most basic, a trajectory specifies a chronologically ordered series of positional Fixes. The “semantic” modifier is used to single out trajectories in which the fixes have some intrinsic meaning, as opposed to being artifacts of the positioning technology or other technical limitation. The fixes are connected by Segments, which are traversed by some MovingObject. The axiomatization of the pattern insures that a semantic trajectory has exactly one starting and ending fix and at least one segment, that every segment joins exactly two fixes, and that every fix in the trajectory is either the starting point or ending point of a segment.

4.2. Modeling embodied energy in concrete

In order to support environmentally friendly construction practices, building industry professionals need to be able to evaluate the embodied energy in different construction materials when making purchasing decisions. This example focuses on evaluating a concrete supplier’s new hybrid product. All concrete is produced in a similar way: stone is mined from a quarry and transported to a processing facility, where in this new product, it is combined with polymer generated at an oil refinery. The “concrete product” is then transported from the processing facility to the construction site at which it will be used. Figure 7 depicts this general process.

Fig. 7.

Overview of the concrete production process.

Fig. 8.

This is the instantiation of Material Transformation and Semantic Trajectory ODPs for concrete production. Labels in parentheses indicate the type (i.e., class) of the corresponding node. Each node represents an instance of a class in an ODP. Nodes without a label correspond to RDF blank nodes. Some instances are shared by classes belonging to different pattern instantiations, to illustrate the chaining of the ODPs. Purple nodes are part of the Material Transformation ODP, whereas yellow, green, and blue nodes are respectively part of the three instantiations of the Semantic Trajectory ODP. The nodes dupont_node, polymer, and concrete are shared by two neighboring pattern instantiations. The node processing_facility is shared by all four pattern instantiations.

Some concrete suppliers market their product as “green” due to efficiencies in their processing method. However, if the green processing facility is far away from the construction site, the energy saved in the transformation process might be offset by increased energy expended when transporting the concrete to the site. Our goal is to model the concrete production process in a way that supports comparison between two different suppliers. This comparison will be based on the energy embodied in the concrete when it reaches the construction site. Here we model the process for one concrete supplier, using real world data. The cities involved have been anonymized. Figure 7 shows that there are four pattern instances involved in modeling this process: three instances of Semantic Trajectory and one of Material Transformation. Figure 8 provides the instantiations of the four patterns. The MovingObjects in the first two transportation instances, stone and polymer, are Inputs in the transformation. Similarly the Output of the transformation (concrete) is the MovingObject in the final transportation instance. The energy values in the transportation instances are based on the fuel used to transport the materials by truck from one location to another. The trucks used by this supplier run on diesel fuel at the rate of six miles per gallon and can move 28 tons at a time. The energy required for the processing step is based on using up all of the inputs transported in a truckload. This takes 12 hours and uses natural gas at the rate of 1100 cubic feet an hour. Of course, the embodied energy computed in this case would need to be normalized in order to compare it that of another supplier.

This example illustrates the power of combining different ontology design patterns to model complex processes. By modeling the concrete production process for different suppliers using this approach, we can answer questions about the absolute amount of energy embodied in the concrete used for a building, as well as do “what if” analyses involving different concrete suppliers or potential improvements to different parts of the concrete production process. The semantic trajectory and material transformation ODPs provide some structure that helps to ensure that all relevant energy expenditures are considered. For instance, when modeling the concrete processing step, it becomes obvious if the energy expended to transport an input to the processing facility has not been modeled.

5. Conclusion and future work

This paper presented an ontology design pattern to represent a material transformation. An intuitive description of the entities in the pattern and the relationships between them was given, as was a full axiomatization to provide formal semantics. Additionally, the pattern was applied to a familiar transformation to illustrate its use. This pattern is particularly interesting in that it can be used in a somewhat recursive fashion to represent the transformation from raw materials, through intermediate components, to finished products. The paper also showed the application of the material transformation pattern, together with another pattern representing semantic trajectories, to an important real-world analysis problem from the domain of sustainable building construction. This combination of multiple ontology design patterns is a step towards creating applications that leverage the full power of the ODP approach to modeling.

Our future work in this area will build upon the proof of concept presented here by working with domain experts to align information and data about their processes to the semantic trajectory and material transformation design patterns. Applications can then be developed that leverage this knowledge base in order to facilitate informed decision making regarding construction projects. Additionally, we would like to work with experts from other domains to insure that the material transformation ODP is general enough to apply beyond our current use case.