WeeVis - Configuration Environments - Knowledge-based Configuration: From Research to Business Cases, FIRST EDITION (2014)

Knowledge-based Configuration: From Research to Business Cases, FIRST EDITION (2014)

Part V. Configuration Environments

Chapter 25. WeeVis

Stefan Reiterera, Alexander Felfernigb, Paul Blazekc, Gerhard Leitnerd, Florian Reinfrankb and Gerald Ninausb, aSelectionArts, Graz, Austria, bGraz University of Technology, Graz, Austria, ccyLEDGE, Vienna, Austria, dAlpen-Adria Universität Klagenfurt, Klagenfurt, Austria

Abstract

Configuration is a thriving application area for AI technologies. As a consequence, there is a need for advancing knowledge acquisition practices in order to make configuration technologies more accessible. In this chapter we introduce WEEVIS, which is a freely available Wiki-based environment for defining and solving basic configuration tasks. Like Wikipedia, knowledge bases are regarded as Wikis that can be created, edited, and versionized by a community of users. WEEVIS configurators can be integrated into standard Wikipedia pages and are thus more easily accessible compared to proprietary knowledge representations. WEEVIS technologies are easily accessible and therefore well suited for the application in educational contexts.

Keywords

Knowledge-based Configuration; Semantic Wikis; MediaWiki; Community-based Knowledge Engineering

Acknowledgments

The work presented in this chapter was partially funded by the Austrian research promotion agency (grant number: 827587).

25.1 Introduction

In the line of the Wikipedia spirit of allowing communities to cooperatively develop and maintain Wiki pages, we introduce the WEEVIS environment, which supports the development and maintenance of configuration knowledge bases on the basis of widespread and well-known Wiki technologies. WEEVIS1 has been developed on the basis of MediaWiki (www.mediawiki.org), which is the established standard Wiki platform.

For a long period of time the engineering of configuration knowledge bases required that knowledge engineers are technical experts (in the majority of the cases, computer scientists) with the needed technical capabilities (Fleischanderl et al., 1998; Stumptner, 1997). Recent developments in the field moved one step further and also provided graphical engineering environments (Felfernig, 2007; Tiihonen et al., 2003, 2013), which improve the accessibility and maintainability of knowledge bases (see, e.g., the configuration environments described in this book). However, potential users of these technologies still have to deal with additional tools and technologies, which is in many cases a reason for not applying configuration technologies.

The WEEVIS environment tackles this challenge by providing new technologies that allow users to develop and maintain knowledge bases without needing to get acquainted with the specific properties of a configurator development environment and a corresponding programming language. In its current version, WEEVIS supports scenarios where user requirements can be defined in terms of functional requirements (Mittal and Frayman, 1989) and the corresponding solutions (configurations) are typically selected from a set of predefined configurations. User requirements are checked with regard to their consistency and, in the case of inconsistent requirements, WEEVIS proposes a set of possible repair alternatives. This way, WEEVIS does not only support product selection but also consistency maintenance processes on the basis of intelligent repair mechanisms (Felfernig et al., 2009). Currently, WEEVIS does not provide a graphical development environment for configuration knowledge bases but relies on a textual knowledge representation language. The idea is that a community of engineers (users) cooperatively contributes to the development of a configuration knowledge base. The inclusion of graphical concepts supporting community-based knowledge base development and maintenance is within the scope of future work. WEEVIS comes along with the following innovations:

Knowledge Acquisition. WEEVIS users are enabled to articulate their domain knowledge by defining the basic properties of the configuration task in a Wikipedia style. WEEVIS provides a set of predefined tags that can be used for creating, defining, and maintaining a configuration problem definition. By exploiting the basic functionalities of the underlying MediaWiki infrastructure, configuration knowledge bases can be versioned and restored in the case of the creation of unintended versions.

Knowledge Distribution and Collaborative Development. WEEVIS users can develop and publish their configuration knowledge to a community of interested users. Other users interested in contributing to the further development of the knowledge base can engage in the development and maintenance process as is the case with standard Wiki pages. WEEVIS and WEEVIS knowledge bases are freely available and accessible in the Internet.

Rapid Prototyping. By using the basic functionalities provided by Wikipedia, WEEVIS allows rapid prototyping processes where the result of a change can immediately be seen by simply switching from the edit mode to the corresponding read mode. This approach allows an easy understanding of the WEEVIS tags and also of the semantics of the provided WEEVIS language.

The major contributions of this chapter are the following. We introduce a Wiki-based environment for the development and maintenance of configuration problems. In this context we provide an overview of the functionalities supported by the WEEVISenvironment. This serves as a basis for further application and exploitation.

The remainder of this chapter is organized as follows. On the basis of an example from the domain of personal computers (see Hotz et al., 20142) we introduce the WEEVIS knowledge representation concepts (Section 25.2). In Section 25.3 we give an overview of how WEEVIS is embedded in the Media Wiki environment. In Section 25.4 we disc uss the limitations of the WEEVIS approach and shed light on related work by comparing existing engineering practices with the WEEVIS functionalities. With Section 25.5 we conclude the chapter.

25.2 Modeling of the Working Example

For demonstration purposes we will now show how to define the configuration model introduced in Hotz et al. (2014) on the basis of the WEEVIS knowledge representation concepts. In this context we will see that not all the semantic properties defined in that configuration model can be represented directly within WEEVIS. Note that due to the supported knowledge representation concepts, WEEVIS can also be interpreted as a basic constraint-based recommendation environment (see Felfernig et al., 2006), however, in its current version specific personalization concepts such as solution ranking and personalized repair for inconsistent requirements (see Felfernig et al., 2009) are not supported. The expressivity of WEEVIS (which properties can be represented?) is very similar to those of feature models (see Hotz et al., 20143); that is the upper bound of the multiplicity of the relationship between different variables (features) is restricted to 1. However, variables in WEEVIS are not restricted to the values 1 (true) and 0 (false). WEEVIS relies on a CSP-based knowledge representation (see, e.g., Mackworth, 1977; Tsang, 1993). Constraints are currently restricted to types typically used for configuration knowledge representation (e.g., compatibilities, incompatibilities, and requirement relationships). Restricted to such basic knowledge types, WEEVIS has not been designed for the development of large-scale and complex component-oriented configurator applications (see, e.g., Hotz et al., 2014). Reasonable upper bounds regarding the complexity of knowledge bases that can be developed in WEEVIS have to be figured out in future work.

In the following we provide a short overview of the knowledge representation concepts currently available in WEEVIS.

Customer Properties. Customer properties describe the way in which users are enabled to specify their requirements with regard to the configurable product. Examples of customer properties are the primary usage (usage), the degree of energy efficiency (efficiency), the maximum price accepted by the user (maxprice), the resident country (country), the selected motherboard (mb), and the selected central processing unit (cpu). The list of customer properties used in this working example is shown in Table 25.1.

Table 25.1

Customer properties of working example. For example, maxprice allows the customer to specify his/her requirements regarding the upper bound of the price.

Image

Product Properties. In WEEVIS, product properties are representing the basic properties of items that can be part of a solution. Examples of product properties in the personal computer domain are the name of the product (pname), type of the cpu (pcpu), the type of the motherboard (pmb), the type of operating system (pos), the price of the computer (pprice). The list of product properties used in our working example is shown in Table 25.2.

Table 25.2

Product properties of working example. For example, each computer configuration has a specified cpu type pcpu (CPUS or CPUD).

Product Property

Domain

pname

Text

pcpu

CPUS, CPUD

pmb

MBSilver, MBDiamond

pos

OSAlpha, OSBeta

pprice

Integer

Incompatibility Constraints. These constraints describe exclusion relationships between different customer properties and/or product properties. For example, if the value of efficiency is A then the value of mb must not be MBSilver. Furthermore, if the value ofefficiency is C then the value of mb must not be MBDiamond. The complete list of incompatibility constraints in our working example is shown in Table 25.3.

Table 25.3

Incompatibility constraints of working example. For example, a motherboard MBSilver is incompatible with the energy efficiency class A.

Image

Filter Constraints. In WEEVIS, filter constraints are used for expressing the relationship between selected customer requirements (instantiations of customer properties) and the corresponding product properties. For example, the price of a solution must not exceed the maximum price defined by the user or the selected cpu should be contained in the configuration. The complete list of filter constraints used in this working example is shown in Table 25.4.

Table 25.4

Filter constraints of working example. For example, the cpu selected by the customer has to be included in the corresponding configuration.

Image

Includes. This is an additional constraint type that allows the definition of alternative inclusions that are not taken into account by incompatibility and filter constraints. An example of such an inclusion constraint is the following: if the user is interested in a highly energy-efficient computer, include the newest model named energystar (even if the maximum price accepted by the user is lower than the price of energystar); see Table 25.5.

Table 25.5

Includes constraint of working example. For example, if a user is interested in an energy class A configuration, then the item (product) energystar should be included.

Image

Excludes. In the line of includes constraints, WEEVIS also supports the definition of so-called excludes constraints. A solution could be excluded because the needed hardware is currently not available (e.g., pname = hw1) or a solution cannot be delivered due to the fact that certain personal computers cannot be delivered to all destination countries (e.g., country = Austria and pname = hw2). An overview of the excludes constraints is given in Table 25.6.

Table 25.6

Excludes constraint of working example. For example, if the destination country is Austria then the computer hw2 is not allowed to be contained in a configuration. Furthermore, hw1 is currently not available.

Image

Products. In WEEVIS, possible solution alternatives can be defined in a product table (see Table 25.7). Using such a product table makes sense if the set of alternatives is low. This way, search can be made more efficient. In the case of a large search space, the explicit representation of solution alternatives makes knowledge engineering and the underlying search processes inefficient. In such a situation, WEEVIS also allows for the definition of the solution space in an implicit (constraint-based) form.

Table 25.7

Supported solutions of working example.

Image

25.3 User Interface

The entry page of the WEEVIS Wiki environment is depicted in Figure 25.1. The idea of this entry page is similar to the entry page of Wikipedia to support the user in easily identifying the most relevant information units (in our context configuration-enhanced Wikipedia pages).

image
FIGURE 25.1 The WeeVis entry page (www.selectionarts.org/weevis).

After having selected (or created) a configurator application (this is done by simply inserting a link to a new Wiki page), the new configurator application can be defined where the MediaWiki Tag Extension System has been used to define a custom recommender tag. WEEVIS configuration knowledge bases can be defined on a textual level with a syntax that is similar to the syntax of standard Wiki pages. A screenshot that shows the definition of WEEVIS configurator applications is depicted in Figure 25.2.

image
FIGURE 25.2 WEEVIS: Example configurator knowledge base.

Finally, a configurator application can be activated by simply switching from the edit view to the corresponding read view. A screenshot of a corresponding WEEVIS configurator application is shown in Figure 25.3. The interface supports the definition of customer requirements on the left-hand side and corresponding solutions are displayed on the right-hand side. For each solution, a so-called support score is determined. If a solution fulfills all requirements, this score is 100%, otherwise it is lower and, when clicking on the score value, a corresponding repair action is displayed on the left-hand side (see Figure 25.3).

image
FIGURE 25.3 WeeVis: example personal computer configurator. Users specify their requirements in terms of providing answers to questions. WEEVIS determines solutions and – in the case of inconsistent requirements – presents a set of repair actions.

25.4 Related Work

Semantic Wikis. The integration of knowledge-based concepts into Wikipedia platforms has already been realized by different approaches to the development of so-called Semantic Wikis. For example, Baumeister et al. (2011) introduce a Semantic Wiki-based approach where domain ontologies can be specified as a basis of the corresponding Wiki-based application. Domain ontologies are defined in terms of an ontology representation language. Compared to WEEVIS, Baumeister et al. focus on the application of ontology representation languages, which are less accessible to users who are not experts in the knowledge engineering field. Furthermore, the WEEVIS constraint representation is focused on configuration domain specific knowledge representations, which makes it easier to define the corresponding domain knowledge.

Configuration Knowledge Representations. There is a long history of developing representation languages for configuration problems. One of the first approaches to a consistency-based characterization of a configuration problem has been proposed by Mittal and Frayman (1989). Thereafter different types of constraint-based representations have been developed, ranging from dynamic constraint satisfaction problems (see Mittal and Falkenhainer, 1990) to so-called generative constraint satisfaction problems (see Stumptner et al., 1998). An in-depth overview of different types of basic configuration knowledge representations can be found in Stumptner (1997). Felfernig (2007) introduced an approach to define configuration knowledge bases on the basis of the Unified Modeling Language (UML) and Felfernig et al. (2003) also show how to represent such models on the basis of description logics based concepts. Soininen et al. (1998) introduce a general ontology that includes relevant concepts needed for configuration knowledge representation.

Configuration Environments. Felfernig et al. (2006) introduce an environment for the graphical development of knowledge-based recommender applications. This environment has commonalities with the basic functionalities of WEEVIS: product alternatives are explicitly specified and then selected and ranked on the basis of a given set of user requirements. Tiihonen et al. (2003, 2013) introduce their answer-set programming based configuration environment WeCoTin, which is an environment dedicated to the graphical definition of large-scale configuration knowledge bases. Major configuration-related constraint types can be defined on a graphical level. More complex constraints have to be defined in a proprietary logic-based knowledge representation language. Other graphical development environments are presented in Haselböck and Schenner (2014),4 Krebs (2014),5 and Hotz and Günter (2014).6 The major difference between WEEVIS and other configuration knowledge base development environments is that we can expect that more users are able to deal with modeling configurators in Wikipedia compared to the alternative of defining knowledge bases with (provider-) specific environments. However, admittedly, the major drawback of WEEVIS is its limited expressiveness compared to more general knowledge representation formalisms (see Hotz et al., 20147). Furthermore, graphical constraint management facilities have to be integrated in order to achieve widespread use.

Anomaly Management. Most of the existing configuration environments include different types of anomaly detection (see Felfernig et al., 20148) or at least consistency management functionalities. In a similar fashion, WEEVIS includes a basic implementation of the FASTDIAG diagnosis algorithm (Felfernig et al., 2012), which supports users in situations where no solution can be found. Furthermore, WEEVIS allows the specification of test cases that can be exploited for the purposes of regression testing. The integration of further quality assurance mechanisms such as the automated debugging of WEEVIS knowledge bases, redundancy detection (Felfernig et al., 2011), and diagnosis discrimination (Shchekotykhin et al., 2012) is within the scope of future work.

25.5 Conclusion

In this chapter we have introduced the WEEVIS environment for the Wiki-based development and maintenance of simple configuration knowledge bases. WEEVIS is especially useful in scenarios where groups or communities of users are interested in commonly providing a configurator application to the whole public or to a specific group of users. From the technological point of view the major advantage of WEEVIS is the development and maintenance of configuration knowledge bases without the overhead of getting acquainted with a completely new technology. Major issues related to the further development of WEEVIS are the integration of personalization concepts (Ardissono et al., 2003; Tiihonen and Felfernig, 2010) that help to rank the set of determined solutions (configurations), the integration of additional quality assurance mechanisms (beside the basic versioning concept of Wikipedia), and the further development of the WEEVIS language itself in the sense of improving the understandability and reducing the cognitive complexity of the provided modeling concepts.

References

1. Ardissono L, Felfernig A, Friedrich G, et al. A framework for the development of personalized, distributed web-based configuration systems. AI Magazine. 2003;24(3):93–108.

2. Baumeister J, Reutelshoefer J, Puppe F. KnowWE: a semantic Wiki for knowledge engineering. Applied Intelligence. 2011;35(3):323–344.

3. Felfernig A. Standardized configuration knowledge representations as technological foundation for mass customization. IEEE Transactions on Engineering Management. 2007;54(1):41–56.

4. Felfernig A, Friedrich G, Jannach D, Stumptner M, Zanker M. Configuration knowledge representations for semantic web applications. Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM). 2003;17(1):31–50.

5. Felfernig A, Friedrich G, Jannach D, Zanker M. An integrated environment for the development of knowledge-based recommender applications. International Journal of Electronic Commerce (IJEC). 2006;11(2):11–34.

6. Felfernig A, Schubert M, Friedrich G, Mandl M, Mairitsch M, Teppan E. Plausible repairs for inconsistent requirements. In: 21st International Joint Conference on Artificial Intelligence (IJCAI’09), Pasadena, CA. 2009:791–796.

7. Felfernig A, Zehentner C, Blazek P. CoreDiag: eliminating redundancy in constraint sets. In: 22nd International Workshop on Principles of Diagnosis (DX’2011), Murnau, Germany. 2011;219–224.

8. Felfernig A, Schubert M, Zehentner C. An efficient diagnosis algorithm for inconsistent constraint sets. Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM). 2012;26(1):53–62.

9. Felfernig A, Reiterer S, Reinfrank F, Ninaus G, Jeran M. Conflict detection & diagnosis in configuration. In: Felfernig A, Hotz L, Bagley C, Tiihonen J, eds. Knowledge-based Configuration – From Research to Business Cases. Waltham, MA: Morgan Kaufmann Publishers; 2014:73–87. (Chapter 7).

10. Fleischanderl G, Friedrich GE, Haselböck A, Schreiner H, Stumptner M. Configuring large systems using generative constraint satisfaction. IEEE Intelligent Systems. 1998;13(4):59–68.

11. Haselböck A, Schenner G. S’UPREME. In: Felfernig A, Hotz L, Bagley C, Tiihonen J, eds. Knowledge-based Configuration – From Research to Business Cases. Waltham, MA: Morgan Kaufmann Publishers; 2014:263–269. (Chapter 22).

12. Hotz L, Günter A. KONWERK. In: Felfernig A, Hotz L, Bagley C, Tiihonen J, eds. Knowledge-based Configuration – From Research to Business Cases. Waltham, MA: Morgan Kaufmann Publishers; 2014:281–295. (Chapter 24).

13. Hotz L, Felfernig A, Stumptner M, Ryabokon A, Bagley C, Wolter K. Configuration knowledge representation & reasoning. In: Felfernig A, Hotz L, Bagley C, Tiihonen J, eds. Knowledge-based Configuration – From Research to Business Cases. Waltham, MA: Morgan Kaufmann Publishers; 2014:41–72. (Chapter 6).

14. Krebs T. encoway. In: Felfernig A, Hotz L, Bagley C, Tiihonen J, eds. Knowledge-based Configuration – From Research to Business Cases. Waltham, MA: Morgan Kaufmann Publishers; 2014:271–279. (Chapter 23).

15. Mackworth A. Consistency in networks of relations. Artificial Intelligence. 1977;8(1):99–118.

16. Mittal S, Falkenhainer B. Dynamic constraint satisfaction problems. In: Proceedings of the Eighth National Conference on Artificial Intelligence (AAAI-90), Boston. 1990:25–32.

17. Mittal S, Frayman F. Towards a generic model of configuration tasks. In: 1989:1395–1401. 11th International Joint Conference on Artificial Intelligence (IJCAI-89), Detroit, MI. vol. 2.

18. Shchekotykhin KM, Friedrich G, Fleiss P, Rodler P. Interactive ontology debugging: two query strategies for efficient fault localization. Web Semantics: Science, Services and Agents on the World Wide Web. 2012;12–13:88–103.

19. Soininen T, Tiihonen J, Männistö T, Sulonen R. Towards a general ontology of configuration. Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM). 1998;12(4):357–372.

20. Stumptner M. An overview of knowledge-based configuration. AI Communications. 1997;10(2):111–126.

21. Stumptner M, Friedrich G, Haselböck A. Generative constraint-based configuration of large technical systems. Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AI EDAM). 1998;12(4):307–320.

22. Tiihonen J, Felfernig A. Towards recommending configurable offerings. International Journal of Mass Customization. 2010;3(4):389–406.

23. Tiihonen J, Soininen T, Niemelä I, Sulonen R. A practical tool for mass-customising configurable products. In: Proceedings of the 14th International Conference on Engineering Design, Stockholm, Sweden, August 19–21, 2003, CDROM. 2003; p. 10 (Paper number: 1290).

24. Tiihonen J, Heiskala M, Anderson A, Soininen T. WeCoTin – a practical logic-based sales configurator. AI Communications. 2013;26(1):99–131.

25. Tsang E. Foundations of Constraint Satisfaction. London, San Diego, New York: Academic Press; 1993.


1www.weevis.org.

2Chapter 6.

3Chapter 6.

4Chapter 22.

5Chapter 23.

6Chapter 24.

7Chapter 6.

8Chapter 7.