A semantic representation model for design rationale of products

Advanced Engineering Informatics 27 (2013) 13–26

Contents lists available at SciVerse ScienceDirect

Advanced Engineering Informatics journal homepage: www.elsevier.com/locate/aei

A semantic representation model for design rationale of products Yingzhong Zhang a,⇑, Xiaofang Luo a, Jian Li a, Jennifer J. Buis b a b

School of Mechanical Engineering, Dalian University of Technology, Dalian 116024, China Division of Environmental and Ecological Engineering, Purdue University, West Lafayette, IN 47907, United States

a r t i c l e

i n f o

Article history: Available online 10 November 2012 Keywords: Design rationale Design semantics Representation model Ontology

a b s t r a c t Design rationale (DR) is crucial information in product design decision support, design analysis and design reuse. In this paper, based on the Issue-based Information System (IBIS) model, a new ontology-based semantic representation model for DR information; the integrated issue, solution, artifact and argument (ISAA) model; is proposed. The ISAA model introduces the ontology-based semantic representation mode to the DR representation and expands the concept elements of IBIS. The class of concept elements and the semantic relationships among them are defined by Web Ontology Language (OWL). The axioms and rules which are used to reason and analyze DR are defined and encoded with Semantic Web Rule Language (SWRL), which enrich the semantic relations defined by OWL. The ISAA model represents the directed graph of IBIS to the Resource Description Framework (RDF) graph and serializes to an RDF/ XML document which lays the foundation for retrieving and reasoning semantic information of DR. A semantic annotator integrating with the visual product design model was developed, by which the discrete information of thinking is captured and abstracted to a conceptual representation of the ISAA model. Finally, an example of DR representation for the spring operating mechanism of a high-voltage circuit breaker product is given. Ó 2012 Elsevier Ltd. All rights reserved.

1. Introduction Design rationale (DR) is an explanation of why an artifact, or some part of an artifact, is designed the way it is [1,2]. An artifact is something made or given shape by humans, such as various types of manufactured products (e.g. machinery, electronics, software), various forms of structure, parameters and constraints. DR encompasses the documentation of the active processes of reasoning and decision making that lead to the artifact design, including the justification for design decisions, records of design alternatives considered and tradeoffs evaluated, and details of the argumentation and communication processes associated with design work [2]. DR includes background information on product design, the design process and product design knowledge, such as considerations and trade-offs in the design process, design decisions and reasoning behind the product design. The representation and application of DR information is very important for engineering design reuse, design reasoning, and design evaluation [3]. Design is an activity to create artifacts according to design requirements. The design process is considered as a series of decision-making processes to produce design schema [4]. The current design document generally includes only the results of the final de-

⇑ Corresponding author. Tel./fax: +86 0411 84708614. E-mail address: [email protected] (Y. Zhang). 1474-0346/$ - see front matter Ó 2012 Elsevier Ltd. All rights reserved. http://dx.doi.org/10.1016/j.aei.2012.10.005

sign of the product, such as the product’s geometric model, feature model and some technical documents. However, it does not include the description of why it is designed the way it is. DR is usually not well documented, most of it is hidden in the designer’s brain and a small part of is scattered in various design documents. In the design reuse or the collaborative design process, a lot of time is spent to communicate with the original designer in order to understand the original design. However, if designers leave their occupation or DR information is forgotten, the communication cannot be carried out and a loss in business may result. Therefore, the capture, representation and application of DR information lays the foundation for collaborative design discussions among designers, design reasoning and design reuse. DR information has wide applications in product design modification, maintenance and design of similar products. A lot of research on capture, representation and application of DR information has been carried out and much progress has been made on the development of DR approaches and tools since the early 1980s, but few design rationale systems have been practically implemented in industry [3]. The main reasons are as follows:  The representation of DR lacks the integration between the issue and the design structure of the product. Almost all DR models do not have the relationships with product structure models [3]. DR documentation is separated from the product model.

14

Y. Zhang et al. / Advanced Engineering Informatics 27 (2013) 13–26

 The representation of DR lacks semantic representation on issues, solutions, arguments, etc., and does not provide the ability to semantically reason and intelligently retrieve. As a result, it is difficult for DR information to be understood and exchanged by information processing systems.  DR information capturing is still the bottleneck for construction of DR. DR is actually the representation of design knowledge during the design process. The key problem that must be solved is how the DR information can be captured in the design process while at the same time not affecting the designer’s design thinking.  So far, there has been little research on the application of DR information, such as the research on how to intelligently retrieve the DR information during the collaborative design and the design reuse, and on how to verify and guide the design based on DR. In general, the representation model determines how DR can be captured and used in design reuse and design analysis. Argumentation-based models have been widely used to represent DR. The most famous classic argumentation-based model is the Issuebased Information System (IBIS) model. With this in mind, in this paper, based on the IBIS model a new ontology-based semantic representation model; an integrated issue, solution, artifact and argument (ISAA) model; is proposed. In the ISAA model, the mode of semantic representation based on ontology is introduced, and the directed graph of the IBIS model is replaced by a Resource Description Framework (RDF) graph. In addition, there are more conceptual elements to represent DR than in the IBIS model. Furthermore, the RDF(S) graph of the ISAA model can be serialized to an RDF/XML document, which is the foundation for semantic reasoning and retrieval of DR information. The rest of this paper is organized as follows. Section 2 introduces the related works. Section 3 presents the semantic representation model for DR, which includes the requirements for the DR representation model and ISAA Ontology. Section 4 develops a DR capturing and constructing approach based on the ISAA model. Section 5 gives an example of DR representation. Section 6 concludes this paper.

2. Related work 2.1. DR representation model A DR representation explicitly documents the reasoning and argumentation occurring in design [5]. Therefore, a good DR representation model is vital. Research on DR representation has been reported since the 1970s. Most of the DR representation approaches are argumentation-based. Through the arguments, the designer can easily organize design decisions and reasons, maintain consistency of design decisions and track the related decision-making information. The typical argumentation-based model is IBIS [3,6]. IBIS uses the issues, positions, and arguments as conceptual node elements, the relationships between node elements as directed edges, which form a directed graph, to represent DR. Issues represent design questions that need to be discussed, deliberated or disputed during the design process. Positions denote the ways or answers to resolve the issues. Arguments describe the statements supporting or objecting to the positions [6]. IBIS can achieve a better formalized structure to represent the DR information based on argumentation. The relationships of issue, position and argument in the IBIS model are shown in Fig. 1. Based on the IBIS model, a series of DR software tools have been developed, such as graphical IBIS (gIBIS) [7] and Design Rationale editor (DRed) [8]. These tools allow engineering designers to re-

Issue responds to Position 1 supports Argument 1

supports Argument 2

responds to

responds to Position 2

Position 3

objects to Argument 3

objects to Argument 4

Fig. 1. The relationship of issue, position and argument in the IBIS model.

cord rationales along with the design process. Meanwhile, based on the IBIS model, a large number of improved DR representation models have been produced. McCall [9] proposed the Procedural Hierarchy of Issues (PHI) model, which expands the range of issues in the IBIS model and improves their relationships. De Medeiros and Schwabe expanded IBIS and added the semantic relations by Kuaba approach, which provides an ontological vocabulary and a set of rules described in F-logic [10] in order to support software design reuse. However, The Kuaba approach lacks definitions and classifications of DR concepts for electromechanical products. Liu et al. [11] proposed an issue, solution and artifact layer (ISAL) model for DR representation and an approach for DR discovery from design archival patent documents. From the literature [11], the ISAL model did not employ the Semantic Web technology and has limited abilities for DR semantic representation and reasoning. In addition, the design space analysis approach places an artifact in the space of possibilities and seeks to explain why the particular artifact was chosen from these possibilities. The Question, Option and Criteria model (QOC) is a semi-formal model of design space analysis, which is different from the IBIS-derived systems [12]. QOC represents the design space using three components: questions to identify key issues for structuring the space of alternatives, options to provide possible answers to the questions and criteria to evaluate and choose from among the options. Another representation approach is functional representation. In the functional representation scheme, DR is used as an account of how the designed artifact serves or satisfies expected functionality [13]. The Structure, Behavior and Function (SBF) model is a typical functional representation model in which function can be defined as what (an object) does, behavior as how (it) does what (it) does, and structure as what (an object) is [14]. 2.2. DR capture From the designer’s point of view, DR capture approaches can be divided into the following three categories: (1) The reconstruction DR approach: The reconstruction operation is usually performed after design, hence outside the design process. The advantage of this approach is that it is nonintrusive, and the disadvantage is that it may not accurately or completely capture the rationale [2]. (2) Based on the user interaction DR capture approach: This approach requires that the designer must manually record the design information, including the history of design activities, decision-making and so on. Under the IBIS framework, the University of Cambridge developed a DR software tool which is called the Design Rationale editor (DRed) that assists designers to structure their design thinking, captures their rationale as they gain an understanding of and solve design problems, and reduces the need for written reports [8,15].

Y. Zhang et al. / Advanced Engineering Informatics 27 (2013) 13–26

(3) Automatic DR capture approach: This approach can be implemented two ways: One is that DR is automatically captured based on agents during the design process of decisionmaking and communication with the design team, and the other is that DR is captured by excavating the design documents and patent documents [11,16].

2.3. Semantic representation based on ontology As mentioned above, DR needs an argumentation-based semantic representation model and documentation. Modeling semantic information means to construct conceptual models that represent concepts and relationships between them in engineering applications. The conceptual model is a well known technique of data modeling, together with logical modeling and physical modeling, the aim of which is to express the meaning of terms and concepts, to find the correct relationships between different concepts, and to be used for communication. During the past 30 years, many conceptual modeling methods have been proposed for different objectives, such as the E-R Model [17], the Unified Modeling Language (UML) [18], Semantic Web technology [19], the Recursive Object Model (ROM) [20]. Semantic Web technology provides a solution to enable automated information access and use based on machine-processable semantics of data. The foundation of Semantic Web technology is ontology and representation of metadata. Ontologies are specific vocabularies of concepts and their relationships among these concepts. As defined by Gruber [21], an ontology is a formal explicit specification of a shared conceptualization. Ontologies permit computers to better categorize, retrieve, query and deduce information than other current technology. Ontologies are able to provide a shared and common understanding of a domain so that people and various application systems can communicate across the wide-spread heterogeneous sources. In this respect, ontologies are useful to organize and share semantic information. The W3C has made significant progress toward standardizing the specification necessary for the Semantic Web. For example, W3C finalized Resource Description Framework (RDF) [22] to provide a data-modeling framework for semantic representation, and also finalized the Web Ontology Language (OWL) as a modeling language [23]. Ontology has been widely used in various scientific fields. A lot of the research works on representation and processing of semantic information are based on ontology technology. Kim et al. [24] presented a new paradigm of ontology-based assembly design. Li et al. [25] proposed a new computational framework that includes ontological basis and algorithms to retrieve unstructured engineering documents while handling complex queries. Rossitza et al. [26] proposed a semantic-based image retrieval approach to supporting concept design. Hai et al. [27] presented an ontology based approach for operational process modeling. Zhang and Luo [28] proposed an ontology-based framework to represent the design meta-intent. Fernandes et al. [29] presented a semantic knowledge representation based on ontology to support engineering design innovation.

3. Semantic representation based on ontology for design rationale 3.1. Requirements for DR representation In fact, DR information is a kind of description about design thinking, selection, and reasoning processes [30]. The DR representation model is required to at least meet the following requirements:

15

The DR representation model should be able to abstract and organize the DR information and to give a formal explicit description. The IBIS model is concise, in which the complex DR information is described with issue, position and argument conceptual elements as well as relationships among the conceptual elements. The DR representation model should be able to track and document DR information [31]. The IBIS model links the issue, position and argument elements, and forms a DR network graph by the relationships between the element nodes. Hence, the IBIS model has the ability to track and document DR information. In addition to the above two basic requirements, DR representation model should also meet the following requirements: (1) The DR representation model should be able to support designers to interactively query any artifact’s DR information from a visual product model. Because the product design model is generally regarded as the final design outcome, visual inquiry can promote the application of DR. However, with current technology, few DR systems are able to provide the functionality which requires the ability to associate issue query with detailed artifact elements of a product. Although the inquiry may be ‘‘what-if’’ or ‘‘what does?’’ or similar problems, the system needs to explicitly locate the issue to detailed artifact elements, such as the specific sub-assembly, parts, features or dimensions. (2) The DR representation model should have the ability to semantically query and reason DR information. It is very difficult for a designer who is unfamiliar with the product to accurately input query keywords. When semantically similar terms or keywords are input, the system should give the correct queried results according to semantic reasoning [25,26]. (3) The DR representation model should have a certain semantic reasoning ability in order to ensure the consistency and completeness of the DR information. 3.2. The ISAA ontology Based on the represented contents and the above analyzed requirements for DR representation, this paper proposes an ontology-based semantic representation model, the ISAA model, which is based on the IBIS model. The foundation of the ISAA model is the ISAA ontology, which is used to formally and explicitly represent DR information with the knowledge model during the design process. The ISAA ontology uses a set of shared concepts, relations and rule sets to describe the DR; and lays the foundation for subsequent semantic query and reasoning in design reuse and analysis. Definition 1. The ISAA ontology is a kind of conceptual description of DR information, which is composed of a set of concepts, relations and axiom rules about DR. The ISAA ontology can be defined as follows:

OISAA ¼ fC dr ; Rdr ; Adr g where Cdr is the set of ontology concepts for ISAA. This paper defines seven concept elements of DR with OWL language: Design requirement class, Design intent class, Issue class, Solution class, Artifact class, Argument class, and Evidence class. The Solution class is defined as a subclass of the Design intent class. Rdr denotes the set of relations of the ISAA ontology. The relationships of the ISAA ontology include two aspects: One is the semantic relations between the conceptual levels defined by ontology modeling primitives, such as OWL inheritance relation (‘‘is_a’’), instance relation (‘‘instance_of’’) [23]. Another is the semantic rela-

16

Y. Zhang et al. / Advanced Engineering Informatics 27 (2013) 13–26

tions among the DR concepts defined by the ISAA ontology. For example, a design intent arises from a design requirement, which can be defined as an ‘‘arises’’ relation; a design intent suggests a design issue, which can be defined as a ‘‘suggests’’ relation; a design issue is addressed by one or more design solutions, which can be defined as an ‘‘isAddressedBy’’ relation; a solution results in at least one artifact, which can be defined as a ‘‘results_in’’ relation; an argument supports a solution, which can be defined as a ‘‘supports’’ relation. Adr denotes the set of axiom rules of the ISAA ontology. The ISAA ontology axiom rules also include two aspects: One is a kind of axiom rule defined by the ontology modeling primitive language, such as ‘‘disjointWith’’ or ‘‘equivalentClass’’ in OWL [23]. Another is a kind of axiom rule explicitly defined by the ISAA ontology to limit or constrain some relationships. The concept elements and relationships of the ISAA ontology are shown in Fig. 2. Due to paper’s space limitations, this paper discusses only main concept elements, relationships and axiom rules in the ISAA ontology. 3.2.1. Issue class In IBIS, as mentioned above, issues represent design questions that need to be discussed, deliberated or disputed during the design process. Issues are the foundation for argument-based DR representation. Generally, issues have the following characteristics:

I11 I12

I 22 I13

Fig. 3. Hierarchical relations between issues.

structure, an issue on material selection, etc. The issue of shape design also suggests a new issue on maximum cooling area, strength, stiffness and manufacturing. The issue can be iterated hierarchically until the boundaries of issue domain.

IS ¼ fI11 ; I12 ; . . . I1n ; . . . Ip1 ; Ip2 ; . . . Ipm g where the superscript j of an issue set Iji stands for a different issue level, and the subscript i indicates ith issue under same hierarchy. The hierarchical issue characteristic relations are shown in Fig. 3. For example, as an engine nozzle overheats during the use stage, it will propose an issue on the shape design of the nozzle

Design Intent

(3) Issues are specific to particular situations, and their contexts depend on the specific domain. An issue describes the motivational reason and objective of designing an artifact. Generally, an original issue arises from design requirements and follow-up issues are produced along with addressing previous issues. Therefore, an issue mainly answers or addresses the following aspects:  Design requirements: Design requirements usually come from design tasks and product markets, which include product function requirements, product performance requirements and sustainability requirements. For example, an issue like ‘‘How to store energy’’ comes from functional requirements.  Design constraints: Engineering design is constraint oriented, and much of the design process involves the recognition, formulation, and satisfaction of constraints [32]. Most issues are used to solve various constraint problems, so constraints themselves form a rationale associated with the design decisions taken by designers. For example, a typical issue is of the form: ‘‘How to satisfy constraint X’’. Design constraints mainly include physical constraints and geometrical constraints.  Manufacturing: If a design becomes a useful product it must go through manufacturing processes. Thus, a lot of issues are related to manufacturing. For example, many issues on the geometrical shape of the artifact are associated with the cutting method and the shape of cutting tools.

arises

Design Requirement

suggests address

I 23 I np

I1p I 2p

(1) Issues have the form of questions. With regard to content, the following types of issues can be distinguished [6]:  Factual issues: ‘‘Is X the case?’’  Inquiring issues: ‘‘How can X be realized?’’  Explanatory issues: ‘‘What is X used for?’’  Instrumental issues: ‘‘Is X the appropriate means to accomplish Y in this situation?’’ (2) Issues are associated with the design thinking process and evolve gradually, that is, an issue may be a parent issue or sub-issue of another issue. For example, during the design process in order to address issue I1, issue I2 may be presented. The issue I2 is a direct successor, or sub-issue of issue I1. All issues in DR representation can be formally defined as follows:

Issue Class

I 32

Solution Class

isAddressedBy

supports Argument Class objects _to

hasRationale Artifact Class

results _in

bases_on

Evidence Class

Fig. 2. The concept elements and relationships in ISAA ontology.

17

Y. Zhang et al. / Advanced Engineering Informatics 27 (2013) 13–26

 Environment: With more attention to environmental impact of the product life cycle, a lot of issues related to environmental problems arise in product design processes. These issues are associated with the material, energy, recycling, reuse, etc. Therefore, in order to represent issues in DR, this paper proposes issue concepts (IC) and an Issue class. Definition 2. Issue concepts are kinds of abstract element entities that are used to represent or describe the motivational reasons and objectives for designing an artifact. The Issue class is defined as a collection of various issue concepts. The issue concept is the foundation of product design rationale and the key element of DR representation. Therefore, how to abstract and describe the issue in the DR model is critical. Based above analysis, the issue concepts can be formally represented as follows:

IC ¼ fRequirement; Constraint; Manufacturing; Env ironmentg Then, the Issue class is defined based on the issue concepts with OWL. The Issue class produces the following subclasses: Requirement issue, Constraint issue, Manufacturing issue and Environment issue. Each subclass issue can continue to be classified into new subclasses, for example, the Requirement issue can be classified as the Function issue and the Performance issue, thus, forming a hierarchical classification structure of the Issue class shown in Fig. 4. 3.2.2. Solution class

usage solutions, Sr denotes the recycling or remanufacturing solutions, Rs denotes the relationships between the solution concepts, and As denotes the axiomatic rules to restrict relations. Ss, Sm, Se, Sh, Sp, Su, and Sr are defined as subclasses of the Solution class and continue to be classified further within their subclass, to form a hierarchical classification structure of the Solution class shown in Fig. 5. A solution can be further represented in detail by text or graphics. To represent a complex solution, a ‘‘refAddress’’ relation is provided, which directs a Uniform Resource Identifier (URI) to where further interpretation documents are stored at. Solutions are used to address issues, and at the same time are embodiments of design intents. Therefore, the Solution class is defined as a subclass of the Design Intent class, and inherits the ‘‘suggests’’ property which is a property of the Design Intent class. The properties of the Solution class are shown in Table 1. 3.2.3. Argument class In general, an argument is a statement to support or object to a solution which addresses an issue. Arguments reflect a designer’s viewpoints on chosen solutions, which are based on a designer’s experience, knowledge, and the collected evidence of facts to support an argument, such as successful cases, standards and regulations. Definition 4. The Argument class is an aggregate of a variety of argument concepts which are used to support or object to a solution during the design process. The argument concept (AC) consists of a set of argument statements and relationships with solutions and evidence of facts, which can be defined as below:

AC ¼ fstatements;Ra g Definition 3. The solution concepts (SC) are kinds of abstract element entities that are used to represent the methods or means to answer or address various issues in DR. The Solution class is an aggregate of solution concepts. The solution concepts include thinking and ideas, possible methods, mechanisms, causality, etc., which may be related to all aspects of the product life cycle. The solution concept is usually represented by domain terms and graphics. In the domain of the full life-cycle of electromechanical products, the solution concept can be formally represented as follows:

SC ¼ fSs ; Sm ; Se ; Sh ; Sp ; Su ; Sr ; Rs ; As g where Ss denotes the structure solutions, Sm denotes the material solutions, Se denotes the electric solutions, Sh denotes the structure solutions, Sp denotes the manufacturing solutions, Su denotes the

Ra ¼ fsupports; objects to; bases ong where statements denotes a set of literals to support or object to a proposed solution. The formalization of statements is helpful for implementing the justifying argument. The properties of Argument class are shown in Table 2. 3.2.4. Artifact class Artifact’s meaning is very broad. An artifact is something made or given shape by humans, such as a variety of manufactured products (machinery, electronics, software, etc.), various forms of structure (assembly, parts, features, etc.), materials, dimension, parameters and various constraints. An artifact corresponds to a final design solution. Therefore, in the DR representation, every artifact must be associated with at least one solution that must be supported by at least one argument statement. The relations be-

Constraint

rdfs:subClassOf

Motion transforming Function Energy transforming

Requirement Reliability owl::Thing

Issue

Performance Environment

Efficiency Cutting Tool

Manufacturing Machine Tool Fig. 4. Partial Issue class hierarchy.

Process Planning

18

Y. Zhang et al. / Advanced Engineering Informatics 27 (2013) 13–26 Table 2 The properties of Argument class.

Structure

Material

Property

Type

Description

Domain

Range

statements

Data

supports objects_to bases_on

Object Object Object

Statement description of argument Supports a solution Objects to a solution Bases on some evidences

Argument Argument Argument

Solution Solution Evidence

rdfs:subClassOf Electric

owl::Thing

Solution

Hydraulic

ity to work, the environmental impact, etc. Fig. 6 shows partial Artifact class semantic hierarchical relationships. In addition to the above mentioned hierarchy relationship of artifact, there are also other semantic relationships among the artifact concepts, such as ‘‘hasPart’’ and ‘‘hasFeature’’. These semantic relationships are usually defined as the properties of the Artifact class, by means of which retrieval and tracing from an artifact to another artifact become possible. Fig. 7 shows partial semantic relationships among artifacts (assemblies, parts, features, parameters and constraints, etc.).

Manufacturing

Usage

Recycling Fig. 5. Partial Solution class hierarchy.

Table 1 The properties of Solution class.

3.3. Relation rules and logic in ISAA model

Property

Type

Description

Domain

Range

description refAddress

Data Data

suggests address results_in

Object Object Object

Text description for solution URI for storing solution document Suggests a new issue Address an issue Results in an artifact

Solution Solution Solution

Issue Issue Artifact

tween the Artifact class and the Solution class integrate the artifact with DR representation so that the DR information can be used to assess and reuse in feature product design. Definition 5. The Artifact class is an aggregate of a variety of artifact concepts (AFC) which are used to describe the objects generated or selected by designers about the structure of products, materials, parameters and constraints, etc. The Artifact class includes the subclasses of structure, material, parameter and constraint and their mutual relationships, which can be defined as follows:

AFC ¼ fC s ; C m ; C p ; C c ; Rg where Cs denotes the Structure class which is an aggregate of concepts describing the geometry and feature of physical structure artificially generated by designers, such as assembly, sub-assembly, parts and feature. Cm denotes the Material class which is an aggregate of material concepts selected for setting the material properties for the physical structure of product. The Material class forms a hierarchical semantic structure according to their physical, chemical and mechanical properties. The choice of materials is an important consideration in the design. Cp denotes the Parameter class in which the parameters are divided into structural parameters and performance parameters. The structural parameter is used to control the size of the structure of the product, and the performance parameter is used to meet the various requirements for the product or components, such as dynamic performance, thermal performance, life, and fatigue, according to solutions. Cc denotes the Constraint class in which the constraint concept refers to a variety of product design constraints set by designers and is classified into structural constraints and performance constraints. The structural constraint is also classified into geometric constraints and topological constraints, and the performance constraint includes cost, abil-

The ISAA ontology defined above establishes the concept knowledge model of DR, which explicitly gives the semantic hierarchical relationships and mutual semantic relationships. However, in the reasoning process, there are many semantic relations that cannot be defined by the OWL ontology explicitly. The Semantic Web Rule Language (SWRL) is an expressive OWL-based rule language. SWRL allows users to write rules that can be expressed in terms of OWL concepts to provide more powerful deductive reasoning capabilities than OWL alone [33]. Therefore, SWRL is chosen to define new rules that can be added to the inference engine of Jena [34] in order to assist ISAA ontology to complete the reasoning and retrieval of DR information. The relationships in ontology can be represented by description Logic based on predicate, which gives the relations precise semantics. In description Logic, concepts are mapped to unary, relations to binary predicates. The meaning of an element in a relation expression is determined by the domain and range defined in ontology. Some rules are defined as follows: 3.3.1. Rules for relation semantics The relations between concepts of DR are represented by properties that are defined in the OWL class. However, in addition to part of the built-in OWL properties, the semantics of the user-defined properties needs to be explicitly defined by axiom rules. Partial rules for explicitly representing semantic relations of properties are defined below: (1) Inverse relation  ‘‘isAddresedBy’’ and ‘‘address’’ The above two properties represent the semantic relations that an issue is addressed by a solution and a solution addresses an issue respectively. Their semantic relations are mutually inverse and can be defined as follows:

isAddressedByðx; yÞ ¼ addressðy; xÞ  ‘‘results_in’’ and ‘‘hasRationale’’ The above properties represent the semantic relationships that a solution results in an artifact and an artifact has design rationale.

19

Y. Zhang et al. / Advanced Engineering Informatics 27 (2013) 13–26

performance _ Parameter subClassOf

structure _ Parameter

revolving _ Part

Assembly

box-type_ Part

Parameter

Structure Parts owl::Thing

blend_ Feature

Artifact Constraint

Feature Hole_Feature

Material

performance _ Constraint

based_Sketch _ Feature

structure _ Constraint metal_ Material

slot_Feature

nonmetal_ Material

Fig. 6. Partial Artifact class hierarchy.

structure_ Constraint

Assembly hasFit hasPart

Material Part

assembly_ Constraints

makeFrom sketch-based_ Feature

hasFeature

subClassOf

geometric_ Constraints

hasConst

structure_ Parameter

Feature

hasSketch hasSize

size_ Parameter

Sketch hasDimension

sketch_ Dimension

Fig. 7. Partial semantic relationships among artifacts.

The relations between these two properties are mutually inverse and can be defined as follows:

results inðx; yÞ ¼ hasRationaleðy; xÞ (2) Mutually exclusive relation The ‘‘supports’’ and ‘‘objects_to’’ properties are used to represent the semantic relations between the Argument class and the Solution class, which are mutually exclusive and can be defined as follows:

 address(x, y): The instance x of Solution class addresses the instance y of Issue class. An issue usually has a number of corresponding optional solutions, some of which are discarded after being demonstrated ineffective and some become the final solutions. In this paper, the Final_option relation is employed to represent or test whether a solution option becomes the final chosen option. The process of solution evolution is shown in Fig. 8, in which the instance ‘‘Solution 1’’ and ‘‘Solution 1-1’’ are instances of Final_option, while the ‘‘Solution 1-2’’ and ‘‘Solution 2-1’’ are not. From Fig. 8 we can see that to become the final solution, one of the following two conditions must be met: (1) A solution instance is a terminal node in the solution evolution graph and there exists an instance of argument to support it. (2) A solution instance is not a terminal node in the solution evolution graph, but there exists a final solution along the solution’s evolution path. In addition, the final solution must result in at least one artifact. Therefore, the Final_option(x) can be defined as following logical forms: Rule 1: If x is an instance of the Solution class and there exists y which is an instance of the Argument class and supports x, moreover x is a terminal node instance (namely a new instance of the Issue class will no longer be suggested from x), then x is a final solution, namely an instance of the Final_option:

supportsðx; yÞ ^ objects toðx; yÞ ¼ / 3.3.2. Rules for constructing Final_option relation Apart from the relations defined in the ISAA ontology class, many new relations can be derived based on existing relations by a set of rules. When certain conditions are met, a new relation can be automatically exported in order to implement DR information retrieval and verification by automatic reasoning. Some of the existing relations are as follows:  Supports(x,y): The instance x of Argument class supports the instance y of Solution class.  Results in(x, y): The instance x of Solution class results in the instance y of Artifact class.

Issue 1

Argument 1

address

Argument 1-2

supports

Solution 1

supports

Solution 1-2

suggests Issue 1-1

address address

Argument 1-1

suggests

Issue 2-1

address Argument 2-1

supports

Solution 1-1

Solution 2-1 objects_to

Fig. 8. The process of solution evolution.

20

Y. Zhang et al. / Advanced Engineering Informatics 27 (2013) 13–26

9xðFinal optonðxÞ

9yðsupportsðy; xÞ ^ :9zðsuggestsðx; zÞÞ ^ 9uðresults inðx; uÞÞÞÞ

Rule 2: If x is an instance of the Solution class and there exists y which is an instance of the Argument class and supports x moreover x suggests y which is an instance of the Issue class and there exists z which is an instance of the final solution and addresses y, then x is final solution:

9xðFinal optionðxÞ

9y; zðsupportsðy; xÞ ^ suggestsðx; zÞ ^ 9uðisAddressedByðz; uÞ ^ Final optionðuÞÞ ^ 9v ðresults inðx; v ÞÞÞÞ

Seen in the above logical rule, the Final_option relation is in the body of the rule. Therefore, the reasoning process must be implemented according following steps: Step1: According to rule 1 all instances of the terminal node are tested to determine whether the tested instance is the final solution. Step2: According to rule 2 each solution instance node is tested iteratively by a bottom-up approach. All instance of Final_option can be acquired. Rule 3: Only the instance of Final_option is able to result in an artifact.

ArtifactðxÞ

8x; yðFinal optionðyÞ ^ results inðy; xÞÞ

3.3.3. Rule library based on SWRL Although ontology supports inference, it does not provide the reasoning rules such as ‘‘IF. . . THEN. . .’’, so its reasoning ability is very limited. SWRL is a Semantic Web Rule Language combining OWL-DL and RuleML. A SWRL rule contains an antecedent part, which is referred to as the body, and a consequent part, which is referred to as the head. Both the body and head consist of positive conjunctions of atoms:

atom ^ atom    ! atom ^ atom    Informally, a SWRL rule may be read as meaning that if all the atoms in the antecedent are true, then the consequent must also be true. SWRL does not support negated atoms or disjunction. An atom is an expression of the form:

pðarg1; arg2; . . . ; argnÞ where p is a predicate symbol and arg1, arg2, . . . , argn are the terms or arguments of the expression. In SWRL, the predicate symbols can include OWL classes, properties or data types. Arguments can be OWL individuals or data values, or variables referring to them. All variables in SWRL are treated as universally quantified, with their scope limited to a given rule. SWRL provides seven types of atoms as follows:

Atom

CðiÞjDðv ÞjRði; jÞjUði; v ÞjbuiltInðp; v 1 ; . . . ; v n Þji ¼ jji – j

where C: class, D: data type, R: object property, U: data type property, i, j: object variable names or object individual names and v1, v2, . . . , vn: data type variable names or data type value names. In order to implement subsequent semantic reasoning, in the ISAA model, the ISAA rule library is constructed, in which more than 50 production rules are formalized with SWRL. These rules are defined in DR_Onto.rule file, which will be added to the inference engine of Jena when subsequent reasoning is implemented. These rules mainly relate the following three aspects to complement OWL semantic relations. Table 3 gives partial SWRL rules.

 Enriching the semantic relationships among Artifacts and between Artifacts and Solutions in order to realize the queries from the structure and parameter to Issues.  Complementing the semantic relationships from Argument to Solution, and to Evidence, from Issues to Solution or from Solution to Issue.  Checking the consistency and completeness of DR elements. 3.4. DR representation based on ISAA ontology The ISAA ontology gives a semantic conceptual model for DR information representation. For the specific representation of a product, only conceptual model instantiation is conducted under the ISAA ontology and the instance data is organized according to a certain data structure mode. Resource Description Frame (RDF) is a widely used network resource data meta-model and is able to support semantic query processing and reasoning as well as documentation files of RDF/XML [22]. This paper organizes the tagged instance of the ISAA ontology class according to the RDF schema and serializes documentation in the RDF/XML format. Fig. 9 shows the framework of the DR information representation based on the ISAA ontology and the RDF schema. The framework consists of the following three layers: (1) The ISAA ontology layer, which gives a conceptual knowledge representation for DR. In the ISAA ontology layer all of the above analyzed concepts, relationships and rules for DR are encoded by protégé 4.1 editor (http://protege.stanford.edu). The following two files are output:  DR_Onto.owl: This file defines all of the classes and properties of the ISAA ontology model.  DR_Onto.rules: This file defines all of the rules of the ISAA model using SWRL rules language. (2) DR representation layer, which is a description of instance of DR concepts and is represented according to the RDF graph schema. In the RDF graph schema the node is an instance of a concept class in ISAA ontology and each node mutually relates by the DR property relations. The creation of instance nodes and relations is completed by the DR semantic annotator that will be introduced in Section 4. (3) External document layer: The external document layer includes three aspects: First is the product’s artifact model generated by the solutions of DR, embodied in structures, materials, parameters and constraints of the product CAD model; second is the external storage URI address for document evidence; third is the serialized document of DR in the RDF/XML format. 4. DR Capturing and constructing based on ISAA model DR information capturing approaches are mainly categorized into reconstruction approaches based on user interaction and automatic capturing approaches [3]. During the design process, DR information is discrete, easy to change, and depends on design thinking. It is difficult to automatically capture, and even if the information is automatically captured, it also needs to be manually and interactively annotated and classified. Based on the Visual C++ development platform we developed a DR semantic annotator, in which designers realize the conceptualization of DR information and semantic annotation by interactively tagging DR instance and relation after the visual product model has been completed. The framework of DR semantic annotation is shown in Fig. 10. The interface of the ISAA semantic annotator is shown in Fig. 11, which consists of two parts. The left side contains the DR constructive tree, constructive buttons, and information input area; the

21

Y. Zhang et al. / Advanced Engineering Informatics 27 (2013) 13–26 Table 3 Partial SWRL rules defined in ISAA. Rule

Explanation

Assemblyð?xÞ ^ hasPartð?x; ?uÞ ^ hasPartð?x; ?v Þ ! isBrotherð?u; ?v Þ

u, v are same level part or sub-assembly in an assembly structure hierarchical tree

size Parameterð?xÞ ^ hasFeatureð?p; ?f Þ ^ hasSizeð?f ; ?xÞ ! BelongToð?x; ?pÞ

x is a size parameter belonging to part p x is a dimensional parameter belonging to part p

sketch Parameterð?xÞ ^ hasFeatureð?p; ?f Þ ^ hasSketchð?f ; ?sÞ ^ hasDimensionð?s; ?xÞ ! BelongToð?x; ?pÞ

Solutionð?xÞ ^ Argumentð?yÞ ^ supportsð?y; ?xÞ ! LegalSolutionð?xÞ Solutionð?xÞ ^ Argumentð?yÞ ^ supportsð?y; ?xÞ ^ Artifactð?zÞ ^ results inð?x; ?zÞ ! FinalSolutionð?xÞ

Tests whether solution x is an available solution Tests whether solution x is a final chosen solution

Issueð?xÞ ^ Solutionð?yÞ ^ isAddressedByð?x; ?yÞ ^ Solutionð?zÞ ^ isAddressedByð?x; ?zÞ ^ differentFromð?y; ?zÞ ! AcceptMultiSolutionð?xÞ

Issue x can accept all different solutions that address it

Issueð?xÞ ^ Solutionð?yÞ ^ isAddressedByð?x; ?yÞ ^ Solutionð?zÞ ^ isAddressedByð?x; ?zÞ ^ sameAsð?y; ?zÞ ! RejectMultiSolutionð?xÞ

Issue x can accept only one solution that address it Tests whether solution x is a debatable solution

Solutionð?xÞ ^ Argumentð?yÞ ^ supportsð?y; ?xÞ ^ Argumentð?zÞ ^ objects toð?z; ?xÞ ! Debatable Solutionð?xÞ

Argumentð?xÞ ^ Solutionð?yÞ ^ supportsð?x; ?yÞ ^ Argumentð?zÞ ^ objects toð?z; ?yÞ ! Plausible Argumentð?xÞ

Tests whether argument x is a plausible argument

Argumentð?xÞ ^ Solutionð?yÞ ^ supportsð?x; ?yÞ ^ ðnot Plausible ArgumentÞð?xÞ ! Justifying Argumentð?xÞ

Tests whether argument x is a justifying argument

Fig. 9. The representation framework based on ISAA ontology.

22

Y. Zhang et al. / Advanced Engineering Informatics 27 (2013) 13–26

RDF/XML RDF Serialization Document of DR Graph Model of DR

Product Model Annotating

DR Semantic Annotator Parsing

Instance relation

http://www.w3.org/1999/02/22-rdf-syntax-ns http://www.w3.org/2001/XMLSchema http://www.w3.org/2000/01/rdf-schema http://www.w3.org/2002/07/owl http://www.jhcad.com/owl/DR_Onto.owl http://www.jhcad.com/owl/DR_Onto.rules

Fig. 10. The framework of DR semantic annotating.

Fig. 11. The interface of ISAA semantic annotator.

right side contains the display area, including the visual product model and design element information query area. Each node of the DR constructive tree corresponds to a node in the RDF graph, and the relationships between nodes are identified by different colored icons. The ISAA semantic annotator mainly completes the following functions:

4.1. Issue generation Issue is the beginning of DR information representation. As introduced above, the issue only comes from the design requirements and solutions in ISAA representation. Therefore, to create a new instance of the Issue class, a design requirement node or a solution node must first be selected from the DR constructive tree, and then the ‘‘Add’’ button is clicked to start creating an instance of the Issue class. In order to create an instance of the Issue class, the text description on the issue must first be input, and then the Issue class concept is selected from the ontology library tree in order to tag their

instance relations. Once the associated label is completed, the instance node of the Issue class can be established.

4.2. Solution options and arguments For each created instance of the Issue class, a solution needs to be given. The given solution will become an instance of the Solution class. At the same time the solution instance needs to be argued and given an instance of the Argument class which supports the solution or objects to the solution. First, from the DR constructive tree on the left side of the interface shown in Fig. 11, select the instance node to be addressed, and then select the ‘‘Add’’ operation from the right-click menu. A solution option dialog will pop-up as shown in Fig. 12. A solution can be chosen from the existing solution list or can be newly created. A solution is usually described by a sentence or a paragraph of text which is able to fully and briefly express the characteristics of the solution. If a more detailed description is needed, an URI address where related documents or engineering drawings are stored at is required.

Y. Zhang et al. / Advanced Engineering Informatics 27 (2013) 13–26

23

Fig. 12. Dialog box to create an instance of Solution class.

For each created instance of the Solution class, a viable argument should be given, including either an argument supporting the solution or an argument objecting to the solution. Meanwhile, an instance of the Argument class is created. The Argument is usually directly described with a paragraph of text statements, and also can link to an address storing the standard, document, or drawing. Each argument’s property of relation to solution is chosen by clicking the ‘‘supports’’ or ‘‘objects to’’ button in the dialog box. During the annotating process, the designer does not only create a viable instance of the Solution class, but also is required to enumerate as many unfeasible solution options as possible and to provide the arguments to them in order to serve future design reuse. 4.3. Associating with the feature model of products Each feasible solution will result in an instance of the Artifact class. An instance of the Artifact class corresponds to a specific object in the feature model of a product, such as an assembly unit, part, feature, dimension or constraint. In the ISAA ontology, a property of ‘‘locates’’ relation is set in the Artifact class, whose domain is the Artifact class and range is xsd:string which is a string in the xml space and gives the associated code to the specific object in the feature model of a product. The code is represented in the following form according to the top-down structure of a product: Assembly name–Part name–Feature name–Parameter name or Constraint name

For example, if the ‘‘Hole-D1’’ is an instance of the size_Parameter class which is a subclass of the Artifact class and corresponds High voltage circuit breaker -Cam for storing energy -Center Hole-Diameter Assembly name

Part name

Feature name

Fig. 13. An example of correlative code.

Parameter name

to the diameter of a center hole feature in a cam part which is a part of high voltage circuit breaker assembly, the property relation ‘‘locates’’ of ‘‘Hole-D1’’ has the following range code as shown in Fig. 13. Partial OWL codes for the above example are defined as follows: . . .. . .

This paper has developed a smart tag associating tool. With the product feature model browser, a user can browse from assembly to part, from sketch to dimensional parameters and constraints. The system will automatically construct a correlative code from the chosen element in the model browser and compare the code with the text string which is directed by the relation of ‘‘locates’’ in an instance of the Artifact class to determine which instance of the Artifact class is related. The associated tool makes it possible for the user to inquire DR information from a visual feature model or to locate specific objects in the feature model from the DR representation model. 5. An example of DR representation This paper takes the DR representation of the spring operating mechanism of a high-voltage circuit breaker product shown in Fig. 11 as an example. The spring operating mechanism provides

24

Y. Zhang et al. / Advanced Engineering Informatics 27 (2013) 13–26

(1) Top-down semantic query starting from an issue. The ISAA model has made conceptual knowledge-based ontology definitions for every issue, including Requirement, Manufacturing, Constraint and Environment concepts on the first level. First, query terms are mapped to concepts. For example, in the above example, the query term ‘‘How to get the opening force when an opening operation is needed’’ is analyzed and the semantics are extracted. The ‘‘opening force’’ is matched with the Energy conversion concept of Issue, so it is easy to retrieve the instance ‘‘How to store energy’’ which is an instance of the Energy conversion concept in Issue. The solution and argument for the issue can be retrieved according to the semantic relations between issue and solution, and between solution and argument. By using the encoded string in the instance of the Artifact class the related part, feature and dimension can be retrieved directly. (2) Bottom-up semantic query starting from an artifact. There are usually similar forms of query as follows: Query 1: Why is a ratchet structure designed? Query 2: Why is the ring groove feature designed in a push rod structure? Query 3: Can this size parameter be modified?

both a closing and an opening operation for the circuit breaker. When the closing operation is being carried out, the storage spring stores energy, and when the opening operation is carried out, the storage spring will provide energy. Taking the issue on how to store energy as the beginning of the ISAA representation, a series of DR instances and relationships about solutions, arguments and new issues will be constructed. The thinking processes and design reasons of the spring operating mechanism are formally represented according to the ISAA representation framework.

5.1. Semantic DR representation Sections 4.1–4.3 have given the concrete semantic annotation steps. Fig. 14 gives a partial semantic DR representation of the spring operating mechanism in the RDF schema based on the ISAA model. In the RDF graph each node is an instance of the ISAA ontology class, which can be serialized to the RDF/XML format document. Partial contents of the serialized document are illustrated in Fig. 15.

5.2. Semantic retrieval for DR information One of the DR applications is DR information retrieval. Semantic retrieval is a retrieval of knowledge by matching concepts and reasoning to the semantic relationships, and has more advantages than the traditional keyword-based retrieval. The ISAA provides the following two methods for semantic query:

The design objects can be selected from the visual product model to inquire, because an encoded string to locate specific objects in the visual product model is defined in the Artifact class in the ISAA model. For example, after a ratchet part is selected interactively from the circuit breaker model, a query like

How for spring to store energy address

address

address

Compression spring

Tension spring

Torsion spring

supports objects to The structure is not suitable for this device

Space compact and easy to implement

A storing energy part

Legend Issue Solution Argument Artifact address

Compression spring mechanism Compression spring results How to produce compression displacement ?

objects to The structure is complex and store energy slowly

If the spring is compressed in Interval the cam is the most convenient supports

The structure of eccentric cam is simple and easy to manufacture

What kind of cam forms is used ?

supports Profile cam

Eccentric cam

How to achieve one-way motion ? Ratchet wheel part

objects to results

The structure is complex, and provided energy is small

Using cam mechanism

Using leadscrew nut mechanism

suggests supports

objects to

How to implement ?

Ratchet push rod

results results

Ratchet wheel mechanism

supports

results

A eccentric cam part

Ratchet can convert the continuous rotating motion into stepper interval motion

Fig. 14. Partial semantic DR representation for spring energy storage.

25

Y. Zhang et al. / Advanced Engineering Informatics 27 (2013) 13–26

< drbase:Solution rdf:ID="Tension spring"/> < drbase:Solution rdf:ID="Compression spring"/ > < drbase:Solution rdf:ID="Torsion spring"/ > < rdf:Description rdf:about="Tension spring"> < drbase:address rdf:resource ="How for spring to store energy? "/> < /rdf:Description> < rdf:Description rdf:about="Compression spring"> < drbase:address rdf:resource ="How for spring to store energy? "/> < /rdf:Description> < rdf:Description rdf:about="Torsion spring"> < drbase:address rdf:resource ="How for spring to store energy? "/> < /rdf:Description> < rdf:Description rdf:about="Argu1"> < drbase:states rdf:resource="The structure is not suitable for this device"/> < /rdf:Description> < rdf:Description rdf:about="Argu1"> < drbase:objects to rdf:resource="Tension spring"/> < /rdf:Description> < rdf:Description rdf:about="Argu2"> < drbase:states rdf:resource="Space is compact and easy to implement"/ > < /rdf:Description> < rdf:Description rdf:about="Argu2"> < drbase:supports rdf:resource="Compression spring"/> < /rdf:Description> < rdf:Description rdf:about="Argu3"> < drbase:states rdf:resource="The structure is complex, and provided energy is small"/> < /rdf:Description> < drbase:objects to rdf:resource="Torsion spring"/> < /rdf:Description>

Fig. 15. Partial representation of DR in RDF/XML format.

Table 4 Comparisons between ISAA and IBIS. Item

ISAA

IBIS

DR conceptualization

Issues, solutions, arguments, artifacts and evidences

Issues, positions and arguments

Knowledge and semantic

The domain knowledge can be integrated into the definition of the concept, and the semantic of DR concept can be explicitly specified Shared definitions of DR concept, explicit semantic specification, and RDF/XML format of documents can make DR machine-readable RDF/XML document format can be supported by popular Semantic Web

Implicit

Retrieving and reasoning

Supports semantic retrieval and query, with a degree of reasoning ability

Key words search, no reasoning ability

Relations between DR and artifacts

Associates with the feature model of the product directly

Implicit

Communication and exchange Documentation and archiving

‘‘Why is the ratchet structure designed?’’ can be proposed. The retrieval system can encode a string for the ratchet part according to encoded rules. This encoded string can be used to match

Difficulty Depending on the specific system

the encoded string in the instance of the Artifact in the RDF graph. According to the ‘‘results_in’’ relation the Solution instance and the Issue instance can be queried, which is the rea-

26

Y. Zhang et al. / Advanced Engineering Informatics 27 (2013) 13–26

son for the design. The Argument instance supporting the Solution instance can also be queried. 5.3. Comparison between ISAA mode and IBIS model DR essentially is a kind of knowledge about the product’s design. A DR representation explicitly structures and documents the reasoning and argumentation information occurring in design. How to give the information a formal representation schema by abstract concepts is very important. An ontology is a formal explicit specification of a shared conceptualization. Based on ontologies the DR concepts can be better integrated with the domain knowledge. Table 4 gives a comparison of ISAA model and IBIS models from six aspects, i.e., the DR conceptualization, knowledge and semantics, communication and exchange, retrieval and reasoning. With respect of six aspects listed above in Table 4, this paper has discussed in-depth in previous sections, and the characteristics of the ontology and Semantic Web technology have been verified in a lot of research. Obviously, the ISAA model has more advantages than the IBIS model. 6. Conclusions DR information plays a very important role in the design reuse and design analysis. The DR representation model is one of the key techniques for the DR application. This paper analyzes the DR representation and completes the following contributed works: (1) Extends the traditional IBIS model, introduces the Semantic Web technology into the DR representation, and proposes a new DR semantic representation model, the ISAA model, by combining the traditional concept model with formal semantics. (2) Gives a formal definition of rules for concepts, relationships and relation constraints, which expands the semantic representation abilities provided by OWL ontology language and lays the foundation for reasoning and testing DR information. (3) An approach for capturing and constructing DR information based on semantic annotation has been developed. DR information semantic representation is the foundation for DR applications. However, the capturing of DR information with an efficient method is still the key to the DR application. We will carry out in-depth research on how DR information is automatically captured during the design process. In addition, the applications based on the ISAA representation model are also further focused research. We will consider two applications as follows:  Based on the ISAA represented documentation, the research on DR information semantic retrieval will be carried out.  Few research works on design analysis and evaluation based on DR reasoning have been reported so far. Further research is needed towards in this direction.

Acknowledgements This work is supported by the National Science Foundation of China under Grants 60773214. The authors thank anonymous reviewers for their helpful suggestions in this study.

References [1] J. Lee, K. Lai, What’s in design rationale, Hum.–Comput. Interact. 6 (1991) 251– 280. [2] J. Lee, Design rationale systems: understanding the issues, IEEE Expert 12 (1997) 78–85. [3] W.C. Regli, X. Hu, M. Atwood, W. Sun, A survey of design rationale systems: approaches, representation, capture and retrieval, Eng. Comput. 16 (2000) 209–235. [4] J.A. Rockwell, I. R Grosse, S. Krishnamurty, J.C. Wileden, A semantic information model for capturing and communicating design decisions, J. Comput. Inform. Sci. Eng. 10 (2010) 031008-1–031008-8. [5] S. Gonnet, G. Henning, H. Leone, A model for capturing and representing the engineering design process, Expert Syst. Appl. 33 (2007) 881–902. [6] W. Kunz, H. Rittel, Issues as Elements of Information Systems, Working Paper 131, Center for Planning and Development Research, University of California at Berkeley, Berkeley, 1970. [7] J. Conklin, M. Begeman, GIBIS: a hypertext tool for exploratory policy discussion, ACM Trans. Off. Inform. Syst. 6 (1988) 303–331. [8] R. Bracewell, K. Wallace, M. Moss, D. Knott, Capturing design rationale, Comput. Aid. Des. 41 (2009) 173–186. [9] R.J. McCall, PHI: a conceptual foundation for design hypermedia, Des. Stud. 12 (1991) 30–41. [10] A.P. De Medeiros, D. Schwabe, Kuaba approach: integrating formal semantics and design rationale representation to support design reuse, Artif. Intell. Eng. Des. Anal. Manuf. 22 (2008) 399–419. [11] Y. Liu, Y. Liang, C.K. Kwong, W.B. Lee, A new design rationale representation model for rationale mining, J. Comput. Inform. Sci. Eng. 10 (2010) 031009-1– 031009-10. [12] A. MacLean, R. Young, V. Belloti, T. Moran, Questions, options, and criteria: elements of design space analysis, Hum.–Comput. Interact. 6 (1991) 201–250. [13] B. Chandrasekaran, A.K. Goel, Y. Iwasaki, Functional representation as design rationale, IEEE Comput. 26 (1993) 48–56. [14] B. Chandrasekaran, A.K. Goel, Y. Iwasaki, Functional representation as design rationale, Computer 26 (1993) 48–56. [15] K.J. Mix, C.G. Jensen, J. Ryskamp, Automated design rationale capture within the CAx environment, Comput.-Aid. Des. Appl. 7 (2010) (2010) 361–375. [16] Z. Wang, Q. Qiu, P. Feng, S. Xie, Information extraction method of technical solution from mechanical product patent, Chin. J. Mech. Eng. 45 (2009) 198– 206 (in Chinese). [17] P.P. Chen, The entity-relationship model: toward a unified view of data, ACM Trans. Database Syst. 1 (1976) 9–37. [18] Object Management Group (OMG), Unified Modeling Language, 2011. . [19] G. Antonio, F. van Harmelen, A Semantic Web Primer, The MIT Press, Massachusetts, 2004. [20] Y. Zeng, Recursive object model (ROM)—modeling of linguistic information in engineering design, Comput. Ind. 59 (2008) 612–625. [21] T.R. Gruber, A translation approach to portable ontology specifications, J. Knowl. Acquis. 5 (1993) 199–220. [22] W3C, Resource Description Framework (RDF): Concepts and Abstract Syntax, 2004. . [23] W3C, OWL Web Ontology Language Guide, 2004. . [24] K. Kim, D.G. Manley, H. Yang, Ontology-based assembly design and information sharing for collaborative product development, Comput. Aid. Des. 38 (2006) 1233–1250. [25] Z. Li, V. Raskin, K. Ramani, Developing engineering ontology for information retrieval, J. Comput. Inform. Sci. Eng. 8 (2008) 011003-1–011003-13. [26] S. Rossitza, Q. Tang, I. Stankov, Semantic-based information retrieval in support of concept design, Adv. Eng. Inform. 25 (2011) 131–146. [27] R. Hai, M. Theißen, W. Marquardt, An ontology based approach for operational process modeling, Adv. Eng. Inform. 25 (2011) 748–759. [28] Y. Zhang, X. Luo, Design meta-intent representation, Comput. Integr. Manuf. Syst. 16 (2010) 1345–1353 (in Chinese). [29] R.P. Fernandes, I.R. Grosse, S. Krishnamurty, P. Witherell, J.C. Wileden, Semantic methods supporting engineering design innovation, Adv. Eng. Inform. 25 (2011) 185–192. [30] L. Ball, N. Lambell, T. Ormerod, S. Slavin, J. Mariani, Representing design rationale to support innovative design reuse: a minimalist approach, Autom. Constr. 10 (2001) 663–674. [31] U. Kannengiesser, J.S. Gero, A Framework for Constructive Design Rationale, in: Design Computing and Cognition DCC’10, Springer, 2010. [32] S. Ajit, D. Sleeman, D.W. Fowler, D. Knott, Constraint capture and maintenance in engineering design, Artif. Intell. Eng. Des. Anal. Manuf. 22 (2008) 325–343. [33] W3C, A Semantic Web Rule Language Combining OWL and RuleML, 2004. . [34] The HP Semantic Web Team, Jena Semantic Web Framework, 2008. .