0) Deck Slide The aim of this presentation is to discuss our ontological modelling of TRIZ System Evolution Concepts based on the approaches in (Shpakovski 2010), Trends of Engineering System Evolution 2018, short (TESE), and further own considerations. It is common work with my student Tom Strempel. 1) A Short Overview The work fits into recent activities to model core TRIZ concepts using modern Semantic Web means. We provide two kinds of result – a formally described SKOS based body of notions and formal models of examples taken from the literature (available in our github repository), and this presentation and conference paper, in which the background and motivation of the modelling decisions are informally described in more detail. 2a) Evolution of Technical Systems The theory of Evolution of Technical Systems is one of the most prominent, but at the same time most obscure and controversial parts of TRIZ. Altshuller cites the S-curve mechanism, which is widely used in management literature, to justify his laws. The approach does not yet appear explicitly in (Altshuller 1969). No structural thought is yet given there to "controlling the task". Such an approach is only discussed in the last three chapters in (Altshuller 1979), but less as a theory in its own right than as a guide to the application of solution standards. 2b) Evolution of Technical Systems This is reflected in Altshuller's subheadings in chapter 7. The S-curve serves as a paradigm, the laws as guard rails, to ultimately formulate 10 standards as concrete methodological recommendations. In (Altshuller 1980) this is further strengthened in two consecutive chapters "Law is law" and "The family of standards", whereby here laws and lifelines have changed their places in the order of argumentation. The whole thing triggered a fulminate discussion among Altshuller's followers about the extent to which general laws of development, systemic approaches and the concrete evolution of technical systems intertwine here. (Goldovski 1983) can be seen as a certain synopsis of the discussed interrelations, although here too engineering experience rather than analytical-deductive reasoning has guided the author's hand. Thirty years later, these considerations have been taken up again in several works by Mikhail Rubin. 3) The Mainstream The mainstream, however, took a different path and tried to derive various hierarchies of development laws, trends, lines of development or even just patterns - the various authors certainly disagree on the quality of the arguments - from the interplay of market and technological development. This is also the case, for example, in the TESE book certified by MATRIZ as standard teaching material, where the classic approaches of a market pull and technology push, which play a role in economically based innovation theories, are contrasted with a technology pull. Unfortunately, these approaches and thus the entire debate with its lofty goals of technology forecasting are on the level of the innovation theories of the 1960s. The extensive illustrative material is of course a treasure. Nevertheless the question remains, how meaningful examples are about the greenness of a world viewed solely through green glasses. Another question is whether the narrow orientation of evolution concepts to the artefactual dimension of technical systems, as in the TESE book, is at all suitable for tracing technical evolution or only scratches its surface. Most influential technical breakthrough are essentially determined by new operational principles with a pervasive influence on artefactual technical systems from a variety of fields. This cannot be discussed here in detail, even if in Shpakovski’s approach such points play a prominent role. I refer to one of my earlier papers. 4) The Dilemma of Conceptualisation One of the fundamental questions is how to delimit classes of real-world technical systems when investigating laws of evolution. The approach itself suggests that it is not about the 20 years of evolution of the green, rusty car in front of Peter's house, but about an average line of average evolution of real-world artefacts in a certain time horizon. The S-curve approach somehow starts from questions of the marketability of new artefacts, but even here a multitude of questions of delimitation remain unanswered. What, for example, is a car? The average new single car that runs for about five years without serious repair, but then has to go to the garage more often? Do the operating conditions play a role – for example, as annual car in the vehicle fleet of a company, as a leased car that is disposed of after the mentioned five years by the leasing provider, or as a private vehicle acquired cheaply just after this time? Which infrastructure conditions influence the evolution of technical systems? Could the inadequate charging infrastructure and obscure charging concepts slow down the e-car evolution, as you cannot simply drive in to the filling station and refill the technical system's "energy source" in just a minute? Does the "car" focus make any sense at all here and is the "energy source" in fact an "energy store" that is regularly filled and emptied according to the TRIZ principle 19 of "Periodic Action"? You may object: "That is the upper system". Then what's about co-evolution scenarios? None of the theoretical approaches that I am aware of address such essential questions. 5) Evolution Trees Evolution trees as developed in (Shpakovski 2010) are an exciting alternative approach to these examplary fragments. This approach can also be criticised in all the dimensions just mentioned, but the examples are at least more systematically developed, in contrast to (TESE 2018). The connections in the conceptual system remain vague here as well. The aim of our modelling efforts was to get some clarity into this conceptual world. This picture shows the basic approach. An evolution tree is a directed graph whose arrows describe a transformation of the technical system, with the type of transformation indicated under the target node. In (Shpakovski 2010), all examples are trees, although evolutionary lines also converge in trimming, for example. The specificity of Shpakovski's trees is related to the constraints of the evolutionary contexts under consideration, which unfold from a certain root along a main line of development, in which a basic functional principle and its technical unfolding are encoded and fixed for the respective perspective of observation. 5a) The Modelling I can only cursorily discuss the modelling itself here. The evolution of technical systems is basically described by one of these ten BasicEvolutionPatterns. Shpakovsky extracts – largely from experience of the differences in the usefulness of TRIZ principles in practical inventive projects – these basic patterns. Each of these basic patterns is further refined into a sequence of modification subpatterns of graded intensity, and this conceptual toolkit (the basic evolution tree) is applied as a methodological basis to the systematisation of real-world technological development in the form of special evolution trees. Unlike in TESE a clear principle is proposed according to which technical systems are brought into an evolutionary context in such considerations: The basis for any such investigation is a sufficiently general elementary technical function. Only those – sufficiently generalised – technical systems are included in the investigation that realise this elementary technical function as an emergent function. I refer to this selection in the following as class of technical systems (CTS). Its elements are called objects. Each class of technical systems delimited on this basis is doubly contextualised by the choice of the elementary technical function and the degree of generality of the technical systems under consideration. The delimitation should fulfill the following conditions: 1 The objects span a tree-like structure which allows visual presentation of all basic known versions within the class of technical systems under examination. 2 The evolution tree is an organized set of objective evolution patterns based on the analysis of the evolution of many real technical systems. Hence the construction of evolution trees suggests that an objective classification criterion is used. 3 Every evolution pattern includes a set of generalized descriptions of transformations and transitions and may be illustrated by a transformation example of a specific technical object. Hence the requirement of generality and specificity is satisfied. 4 Information presentation in the form of a tree-like structure allows a designer to see all the basic transformation versions simultaneously and to distinctly trace their structure. 5 The availability of the basic tree allows foreseeing all significant transformation versions even if the information available on the versions of a system under consideration is scant or fragmentary. 5b) The Modelling Shpakovsky thus proposed a systematic-methodical approach to the study of the evolution of technical systems, which goes beyond previous approaches, and demonstrates the practical performance of this approach in a number of examples. The aim of our work is to prepare this methodological approach for a Semantic Web formalisation. With regard to general considerations of ontology modelling, we limit ourselves to a formalisation of the taxonomy (the basic tree as evolution tree ontology) and show how this can be used in the formalised representation of special evolution trees. Each basic pattern and modification subpattern is represented by a special URI. Such an URI is a globally unique textual representation, i.e. reference, to an individual artefact or concept. They can be recognised by a prefix separated by a colon, whereby the prefix tc: refers to an established term from the TRIZ context under consideration. Conceptual relations between these patterns and subpatterns are modeled using different WUMM-specific predicates with the od: prefix. E.g. the segmentation pattern is represented by the URI SegmentationPattern and has the code displayed on this slide. In the given example the SegmentationPattern is a subconcept of the BasicEvolutionPattern. Different modification patterns like Liquid are also formalised in that way. The BasicEvolutionPattern, SegmentationPattern and Liquid are in a clear general-special relation since every SegmentationPattern is a BasicEvolutionPattern and every Liquid pattern is a SegmentationPattern. This is not in all situations such easy. Different to Shpakovski certain subpatterns as FlatSurface and CylindricalSurface of the generic GeometricalEvolutionPattern are not put in a mutual subconcept relation in our modelling, even if transformations in both directions appear in specific examples: Some modern monitors use curved displays instead of flat ones, whereas older CRT displays have a cylindrical surface due to manufacturing constraints but using better glass newer CRT displays have a flat surface. 5c) The Modelling Our central task is to model the nodes and edges of a given evolution tree of a class of technical systems in RDF as textual representation. The full graphical representation of that evolution tree as an edge-marked graph can be reconstructed from that textual representation in the usual way (actually, the two representation forms as RDF and as graph are equivalent.). The interaction between a special class of technical systems modelling and the basic constructs of the evolution tree ontology is explained here using code from the class of technical systems DisplayDevelopment. An edge in the evolution graph of a class of technical systems has the typical shape of an RDF sentence as shown on this slide. It uses the prefix ex: since the URIs refer to the model of a special class of technical systems and not to notions of the ontology. This sentence addresses the development from TV with large pixels to TV with medium pixels that have a better performance in brightness and sharpness of images. The code of the two nodes is not presented here, we only note that the introduced URIs have nothing directly to do with the semantics of the represented technical system except that – following the modelling recommendations of the Semantic Web – “speaking names” are used. To the RDF predicate ex:decreasePixelSize further information is attached. It instantiates the tc:SegmentationPattern in a special way. SKOS label and definition describe the transformation in the class of technical systems in more detail, od:usesPattern refers to the pattern from the evolution tree ontology that was applied in this transformation. Shpakovsky emphasises that the construction of an evolution tree is mostly an iterative process in the course of which goal, elementary technical function, scope and degree of abstraction of modelling the class of technical systems are gradually refined. Our tools for formal descriptions support this iterative process, as new objects can easily be added as nodes and transformation steps can be added or modified as edge descriptions. With the description elements presented so far, some of Shpakovski’s more advanced concepts cannot yet be adequately represented. This is especially the case for the concepts trunk and branch of a tree of a class of technical systems, which, however, remain vague not only from a graph-theoretical perspective. The concepts trunk and root attempt to address the development in a class of technical systems from simpler to more complex forms, which is mainly oriented towards the unfolding of the elementary technical function and associated with the basic patterns 1–4. However, since the modification sequences for each basic pattern define branches in the tree, even in such a linear context it is unclear which of these branches is the trunk. In the evolution tree ontology, a language element can easily be added that identifies transformation edges as belonging to the trunk. However, it is not clear that this results in a linear rather than a branched structure. However, this is a general conceptual problem – the basic constructs only guarantee that the evolution is described by a directed graph. Even the property that the emerging graph is acyclic requires additional preconditions. An acyclic graph is characterised by the fact that its nodes can be placed in a linear order that coincides with the edge directions. This can be achieved, for example, assigning timestamps to the objects, but this poses restrictions on the abstraction principle applied in the constitution process of the objects of the class of technical systems. Hence our modelling is nothing more than a first approach to a complex conceptual challenge. Thank you for your attention.