Computers in Industry 59 (2008) 580–589
Contents lists available at ScienceDirect
Computers in Industry journal homepage: www.elsevier.com/locate/compind
OWL/SWRL representation methodology for EXPRESS-driven product information model Part I. Implementation methodology W. Zhao, J.K. Liu * Department of Mechanics, Zhongshan University, Guangzhou 510275, China
A R T I C L E I N F O
A B S T R A C T
Article history: Received 19 September 2006 Received in revised form 25 February 2008 Accepted 26 February 2008 Available online 8 April 2008
This paper presents an ontology-based approach to enable semantic interoperability and reasoning over the product information model. The web ontology language (OWL) and the semantic web rule language (SWRL) in the Semantic Web are employed to construct the product information model. The traditional modeling language called EXPRESS is discussed. The representation methodology for EXPRESS-driven product information model is then proposed. The key of the representation methodology is mapping from EXPRESS to OWL/SWRL. Some illustrated examples are presented. ß 2008 Elsevier B.V. All rights reserved.
Keywords: Product information model OWL SWRL EXPRESS Ontology representation
1. Introduction Nowadays, there is a trend toward forming a collaborative alliance for product development between industry companies in order to maintain international competitiveness or gain collective competitive advantage. The partners in the alliance usually come from a wide variety of domains; more often, they are located in different regions. Under this alliance, computer aided technologies and networking technology are widely used during all the product development phases so as to manage the product throughout its entire lifetime ranging from design, manufacturing, operation and destruction in these companies, which results in various product data types and formats, as well as different software tools. Thus it is fundamentally critical to fill the gap due to these differences, namely required to share and integrate information and knowledge between the partners. An effective way of this sharing and integration is to build a meaningful unified and comprehensive presentation for product data semantics. When we talk about ‘‘presentation’’, that often means structured data for the product; the structured schema of the presentation containing semantics is called product information model or product model. Actually, product modeling is the indispensable key ingredient of most implementations of advanced manufac* Corresponding author. Fax: +86 20 84039914. E-mail address:
[email protected] (J.K. Liu). 0166-3615/$ – see front matter ß 2008 Elsevier B.V. All rights reserved. doi:10.1016/j.compind.2008.02.002
turing technologies, and many research efforts have been devoted in this area [1–4,6]. Particularly, since 1983, work has been in progress under the auspices of the International Standard Organization to develop a standardized product data model associated with a relevant standard called the standard for the exchange of product model data (STEP). The product information models in STEP are specified in EXPRESS (ISO10303-11), a modeling language that combines ideas from the entity– attribute-relationship family of modeling languages with object modeling concepts [7,8]. EXPRESS is a powerful modeling language covering data types, structural aspects and complex constraints, widely used to construct a family of robust and timetested standard application protocols, which had been implemented in most CAX and PDM systems. But the lack of a formal semantic model for EXPRESS schema and the complexity of EXPRESS itself impose challenges on the serialization of product instance and data exchange. STEP 21 [10], STEP 25 [12] and STEP 28 [11] are the solutions of product instance serialization. STEP 21 defines a character-based file format for the exchange of data corresponding to an EXPRESS information model; it is sufficient for traditional data exchange. However, it lacks extensibility, it is hard for humans to read and perhaps greatly limited through computer interpreting by software only supporting STEP. Afterwards STEP 25 and STEP 28 use extensible markup language (XML) [17] fragments to encode product data. As XML is extensible and flexible supported by inexpensive and widely used software tools,
W. Zhao, J.K. Liu / Computers in Industry 59 (2008) 580–589
these XML-based presentation schemas move a step ahead. Unfortunately its biggest advantage is at the same time its biggest obstacle to consistently express semantic information of product data in different application areas [9]. For instance, it may confuse human understanding to express semantic information of product data in different application domains with XML tags derived from different defined vocabularies, that is, the tags representing the same concept defined by different users. An emerging solution to this problem is through the ‘‘Semantic Web’’, an ambitious extension to the existing WWW environment proposed by the World Wide Web consortium (W3C). In the Semantic Web, words appearing in web resources are linked to corresponding entries in ontologies, where terms are defined and their mutual relationships are clarified. An ontology can be seen as an explicit representation of a shared conceptualization that is formal, and that can be used to encode the semantic knowledge and enable sophisticated information services [5]. In [9], an ontology-based method for encoding STEP in XML is proposed to take advantage of XML’s extensibility and flexibility and be compatible with STEP’s rigorous description of product. Nevertheless, the ontology capability of knowledge representation and reasoning has not been further explored yet, only the structure knowledge (including data types, entities, etc.) in STEP is processed, the constraints defined by rules and the procedural knowledge (including functions, procedures, etc.) are not considered. In other words, ontologies are not only to be used to represent the content of the product information as web resources in the context of the Semantic Web to facilitate concept-based information retrieval, ontology-based services to the end-users must be able to use ontologies in an operational way in order to provide reasoning capabilities. Whereas reasoning on the Web requires the representation of axiomatic knowledge, not only terminological knowledge, but all the semantics of a knowledge domain [13], that is, the entire product data semantics need to be represented when encoding STEP in ontology. The current Semantic Web technology makes this possible. One of the missions of the Semantic Web is to put more knowledge on the Web in an organized fashion and link it to other information and data sources. Three successively more capable languages are provided for this: the resource description framework (RDF) [15], the web ontology language (OWL) [14], and the Semantic Web rules language (SWRL) [16]. OWL is good at describing concepts such as meetings, agendas and persons and the relationships between them, but it lacks the reasoning capabilities, i.e. the comparison operators, to reason about time, it is not suitable for reason on rules. Whereas these operators are included as built-in operators in SWRL; SWRL is an extension to OWL and, in addition to defining rules, provides the ability to reason over them. SWRL includes a high-level abstract syntax for Horn-like rules in both the OWL DL and OWL Lite sublanguages of OWL, it is considered as a possibly useful extension to OWL, not only to reason on the context information itself, but also to define and reason on the consequences of changes in context information and how this affects the behavior of services. In this paper, we focus on the problems of the entire representation of STEP semantics and the operational use of product information model, that is, how information expressed in ontologies can be further used to reason. We present an ontologybased methodology for encoding STEP in OWL and SWRL. Our research unites ideas from traditional product information modeling with recent work from the Semantic Web and knowledge engineering community. In our method, we construct the ontologies extracted from STEP in the similar way as [9] and map EXPRESS to OWL and SWRL, but make further extensions.
581
The remainder of this paper is structured as follows: Section 2 is concerned with the issue of content and structure of STEP and EXPRESS. Section 3 gives an overview of the Semantic Web standards. The detailed description of ontology-based method for encoding STEP in OWL and SWRL, some examples and discussions are given in Section 4. The paper is ended with some concluding remarks in Section 5. 2. STEP standard and EXPRESS The Standard for the Exchange of Product Data (STEP) [7,8,10– 12] has been developed by the International Organization for Standardization (ISO) in order to define a uniform representation of product information and to provide mechanisms that enable the exchange of product data between different computer systems over the complete product life cycle. It consists of many parts that can be divided into four major categories, namely, description methods (using EXPRESS), implementation methods, conformance testing methodology, information models and application protocols [8]. The data models of STEP are defined with the EXPRESS language, which captures the rich semantics of engineering data. EXPRESS is a lexical object-oriented information modeling language and is defined in ISO 10303-11. EXPRESS-G is an iconic language that provides a subset of the lexical modeling capabilities. EXPRESS is not a programming language, but (1) it provides for the modeling of data and data relationships with a very general and powerful inheritance mechanism (much more than is provided in object-oriented programming languages), and (2) it includes a full procedural programming language which is used to specify constraints on data instances. EXPRESS is structured in schemas, which represent the model of the product. A schema consists of entities, which are the main objects and data types that support the definitions of these entities. Within the entities are encapsulated attributes and constraints, which restrict the value of the attributes. A schema consists of operations, executable statements, functions, procedures and rules besides data types and entities. Additional details about them are introduced below [7,20]. Schemas provide containers for a coherent set of the following type and entity declarations, thereby enabling entities and data types from one schema to be invoked by another. Data types include simple type (Number, Real, Integer, Logical, Boolean, String, Binary), aggregation type (Array, List, Bag, Set), constructed type (Enumeration and Select), entity data type and defined data type. Entity definitions include type hierarchy declarations (defined by subtype or supertype), attributes (include three kinds: explicit, derived and inverse) and local rules (defined by UNIQUE clauses or WHERE clauses). Local rules specify the constraints which apply to each instance of the entity type. Operators are used to manipulate data types or entity types, which can be classified into arithmetic, relational, binary, logical, string, and aggregate operations. Executable statements are elements like program languages C or Java, etc., such as assignment, case, if-then, return. These are used for expressing general algorithms of procedures or functions. Except that users can define their own functions, various built-in functions such as Abs, Acos, Asin, etc. are defined. Global rules are defined by RULEs, which specify the constraints among a set of instances of an entity type or a set of instances of multiple entity types. A RULE consists of executable statements and a WHERE clause that decides the validity by the results of executables.
W. Zhao, J.K. Liu / Computers in Industry 59 (2008) 580–589
582
3. Semantic web The Semantic Web is the next step of evolution for the Web, which promises to transform the Web by providing machineprocessable and meaningful descriptions of Web resources. This can improve discovery, integration and use/reuse of Web resources. Ontologies can be considered as a primary key towards this goal since they provide a controlled vocabulary of concepts, each with an explicitly defined and machine processable semantics. The World Wide Web and eXtensible Markup Language (XML) [17] will provide the ontologies with interoperability, and these interoperable ontologies will, in return, facilitate a Web that can ‘‘know’’ something. Furthermore, a lot of effort is undertaken to define a rule language for the Semantic Web on top of ontologies in order to combine already existing information and deduce new knowledge. The Semantic Web architecture is a functional, non-fixed architecture. Berners–Lee defines three distinct levels that incrementally introduce expressive primitives: metadata layer, schema layer and logic/rule layer [18]. Languages that support this architecture and the place of OWL/SWRL are shown in Fig. 1. Common data interoperability in present applications is best achieved by using XML. As shown in Fig. 1, XML supports syntax, while semantics is provided by RDF, RDF Schema and mainly by OWL. Compared to RDF Schema, OWL adds more features for describing properties and classes such as relations between classes (e.g., disjointness), richer types of properties, cardinality of properties, and characteristics of properties (e.g., symmetry, transitivity). As a revision of the DAML + OIL ontology language, OWL is built upon the lessons learned from the design and application of DAML + OIL [19]. In order to provide capabilities for unconstrained representation of the Web knowledge and, at the same time, to support calculations and reasoning in finite time with tools that can be built on existing or soon available technologies, OWL introduces three increasingly expressive sublanguages for various purposes: OWL Full (maximal expressiveness but sacrifices decidability), OWL DL (guaranties computational completeness and decidability) and OWL Lite (has expressiveness similar to RDF Schema). OWL DL semantics enables automatic deduction processes, in particular powerful automatic reasoning, such as ontology checking, classification, and instances retrieval, which are based on basic reasoning tasks including satisfiability, subsumption, and instantiation. Powerful reasoning systems have been developed for ontologies constrained by the restrictions required for OWL DL, such as RACER [22]. Thus OWL is well suited for the ‘‘terminological’’ part of knowledge, and for representing ‘‘structured’’ knowledge by classes and properties, organized in taxonomies. The Semantic Web rule language (SWRL) extends OWL DL with the ability to write rules using a subset of RuleML [21]. It permits Horn logic rules to be added to OWL descriptions. This allows one to build up more complex predicates which can be used for more precise definitions of concepts. It also has built-ins for basic arithmetic (e.g., x + y) and comparisons (e.g., x < y). Thus SWRL are useful to represent the ‘‘deductive’’ part of the knowledge.
OWL relies on description logic (DL), and both DL and rules are required for the Semantic Web. Although both of them could overcome expressiveness limitations through extensions to represent various knowledge, each paradigm better fits some particular type of knowledge and supports specific reasoning services, and some applications furthermore need a close integration of both of them. 4. Encoding STEP in OWL and SWRL In our application, OWL and SWRL are used together to represent the semantic knowledge. The first step to encode STEP in OWL and SWRL is to extract ontologies from STEP description language EXPESS, and the complexity of the EXPRESS language is the biggest obstacle. As Section 2 presents, the EXPRESS language includes various constituent elements, not only uses data types and entities to describe the structural knowledge but also uses the operators, executable statements, functions and rules to describe procedure knowledge. The former represents the primitive concepts and their structural relationships; the latter makes some operations or specifies some constraints on the primitives. Here we take different measures to map them. The structural knowledge, involving concepts and the relationships between them, are represented in ontologies. In contrast with the other OWL sublanguages, OWL DL could guarantee computational completeness and decidability, so it is the suitable choice for the intention. The elementary modeling primitives in ontology include atomic classes, basic classes, complex classes, attributes, relationships, and some basic axioms for the domain, i.e., class equivalent, class including, class relationship inverse, and class disjointing, where classes represent the core concepts in a specific domain. Thus concepts in EXPRESS schemas and their instances, that is, the structural knowledge described in STEP files could be easily mapped into the opposites in OWL namely classes and their instances. The procedure knowledge is a procedural paradigm for representing knowledge like that of more conventional languages, such as Java and C, different from them is that the procedure knowledge such as a rule usually has a WHERE clause that decides the validity by the results of executables within it. Obviously the procedure knowledge is also indispensable to retain the integrality of product information. The WHERE clause rules of the procedure knowledge, as the constraints on the instances of the predefined entities or data types, have the similar intention as SWRL rules to OWL ontologies. So the mapping between WHERE clause rules and SWRL is feasible. As for the executable statements of the procedure knowledge, there are no counterparts that can be mapped directly in OWL/SWRL. Considering the compatibility with OWL/SWRL, we regard them as an executable unit and represent it as a special OWL concept/class, and their context can be mapped and stored as the instance of a property of the class. Ref. [9] presents some regulations to encode the structural knowledge of STEP in XML. On the basis of it, we make an attempt to map the EXPRESS language to OWL and SWRL without lose of semantics as far as possible. The following are five aspects of the EXPRESS language and the corresponding mapping rules. The ultimate goal is to build the class taxonomic hierarchy of the ontology associated with SWRL rules, so they are presented from the bottom up (from basic types to compound ones), from simple to complex (from simple types to complex ones) and from whole to part (from the global schema to its entities, rules, etc., or from the entity to its properties). 4.1. Schema and interface specification
Fig. 1. OWL/SWRL in the Semantic Web architecture.
An EXPRESS Schema is the outermost frame of EXPRESS language and is used to describe the product models. A product
W. Zhao, J.K. Liu / Computers in Industry 59 (2008) 580–589
model describes a self-governed and integrated concept pattern, that is, a data model of a product in the real world. Interface specifications provide the mechanism of sharing or referencing from resources between different Schemas. Thus each resource only needs to be defined once, and the use of them can be found in different schemas. Related to the schema and interface specification, the following rules are established. Rule 1: An EXPRESS Schema corresponds to an ontology. Both of them share the same name. Rule 2: Due to the distributed character of the Web, the interface specifications can be implemented through importing other ontologies to add or complement the defined ontology stemming from the other EXPRESS Schemas. 4.2. Data types As described in Section 2, abundant data types guarantee the powerful capability of EXPRESS language. However, OWL only supports simple data types inherited from XML Schema, and does not support aggregation types or other data types. Simple data types are often used when defining other aggregation types, constructed types, entity data types and defined data types, so different strategies must be designed to deal with them. The mapping rules for the data types, except the entity data type, are as follows. Rule 3: Simple data types, which are inherited in EXPRESS language, are extracted as atomic classes in an ontology. An atomic class is a class that cannot be further divided into more elementary components, and can be used to compose the other data types, including INTEGER, REAL, etc. A data type name in OWL consists of the original name in EXPRESS language concatenated with a predefined postfix (the default is ‘‘_XX’’ and here ‘‘XX’’ uses ‘‘TYPE’’, for example, INTEGER_TYPE). In addition, the defined class has an ‘‘XX_value’’ data type property, here ‘‘XX’’ uses the data type name such as INTEGER, and its data type range is the corresponding data type in OWL. Rule 4: Aggregate data types are basic classes in an ontology; a basic class is the class that has more than one elementary component and is not composed through the inheritance mechanism. The naming method of this data type and the resulting data types are the similar to Rule 3. The aggregate data types often have a size constraint, that is, the data types have a lower bound and an upper bound. To depict this feature, we define another two RDF:XMLLiteral data type properties ‘‘UpperBound’’ and ‘‘LowerBound’’. The context of the properties is expressed similar to MathML [23]; it can be parsed, calculated by some other applications and get a value when the document is parsed, which can be set as the bound of the aggregate data types. In particular, if the value of an ‘‘UpperBound’’ or ‘‘LowerBound’’ is ‘‘’’ and set to the bound properties, that means the bound of data type is unbounded. In addition, the class has another object property ‘‘has_XX_value’’ whose object range is any available data type or entity, ‘‘all_initial_XX_value’’ (‘‘XX’’ is the data type name) is for the convenience of assigning a uniform initial value to the array members, and an integer data type property ‘‘index’’ convenient for referencing the elements of the aggregate data type. The ‘‘minimum 1 cardinality’’ restriction also is given to the class to show the class has minimal 1 element. The following Table 1 is an example for the integer data type and ‘‘x: ARRAY [3:?] OF INTEGER’’ with two initial integer values 0 and 2. When the user wants to use the element of the array, he or she can use XML, RDF or OWL these parsing tools such as Jena APIs or Prote´ge´ APIs to access it via the ‘‘index’’ property. Rule 5: Among defined data types, those whose member types are simple data types are atomic classes, which also have a ‘‘value_XX’’ data type property analogical to Rule 3; those whose member types are entity types are complex classes, a complex class is composed through the inheritance mechanism.
583
Rule 6: Among constructed data types, ENUMERATION types are atomic classes; for SELECT type, those whose composing member types are entity types are treated as complex classes in an ontology, and defined as a class including the subsumption relation axiom to describe that it is the super class of the member entities. The class names of these types are added with a prefix or postfix such as ‘‘ENUM_’’ and ‘‘SELE_’’ or something else. Rule 7: All the above-mentioned complex classes have an object property ‘‘has_XX_value’’ as Rule 4. 4.3. Entity definition Entity supports a wide set of elements to be defined within it, so it belongs to a higher level type. It has more complicated structure than the above data types and defined on those types. Its attributes can be any data types discussed above, and sometimes there are restrictions or constraints on them (such as explicit, inverse, derived property). As a whole, the attributes are mapped as the properties of the class corresponding to the entity. The simple data type attributes are commonly mapped as its data type properties otherwise object properties. Rule 8: For every entity declaration in EXPRESS schema, there exists a corresponding class mapping to it, which shares the same name as the corresponding entity. The class further is classified as basic class or complex class according to their property declarations. Rule 9: Among explicit property declarations, those whose value types are atomic classes are attributes in the ontology and defined as data type properties in OWL. And to avoid confusions, the attribute names are composed with their owner entity name concatenated with an underline and their attribute name (all the property definitions including local rules within the entity are like this); those whose value types are basic classes are relationships in ontology, that is, they are defined as object properties. Rule 10: Inverse properties can be directly represented by an axiom of InverseFunctional relationships in OWL, and the quantity relationship between them can be represented thru the cardinality property. Rule 11: A derived property declarations are divided into two parts: an explicit data type declaration and an explicit property declaration. Both declarations can be processed with the same method as the above rules. The explicit property, that is, the assigning-value sentence of the derived property is treated as an expression and mapped as an XMLLiteral data type property of the class that corresponds to the data type. And its name in OWL is composed with a prefix ‘‘DER_’’ (or something else) concatenated with its name defined in EXPRESS. Rule 12: A unique and optional property declarations are mapped as a string array type property declaration. The names of the attributes that have the unique property are considered as the component of a string array to be mapped, the mapped names of these attributes are the same as the same attributes of the owner entities mapped. The mapped string array names in OWL are composed with a prefix ‘‘UNIQ_’’ and ‘‘OPT_’’ (or something else), respectively concatenated with its name defined in EXPRESS. For example, a point defined as follows. The ‘‘UNIQUE index’’ is treated as a string array ‘‘UNIQ_point_url: ARRAY OF STRING: = [‘‘point_index’’];’’ to be mapped. ENTITY point x: REAL; y:REAL; index: INTEGER; UNIQUE url: index; END_ENTITY;
584 Table 1 The representation of an integer array in OWL
W. Zhao, J.K. Liu / Computers in Industry 59 (2008) 580–589
W. Zhao, J.K. Liu / Computers in Industry 59 (2008) 580–589 Table 2 The scale function in EXPRESS and its representation in OWL
585
586
W. Zhao, J.K. Liu / Computers in Industry 59 (2008) 580–589
Table 2 (Continued )
4.4. Expression, function, procedure and rule definition Expression, function and procedure definitions are the indispensable elements of most current programming languages, but the powerful capability of EXPRESS provides more abundant functions, since the EXPRESS language has both features of traditional programming languages and the object-oriented programming languages. The biggest difference between the rule and procedure definition is that the former usually has a where clause declaration. Obviously, there are no counterparts to the expressions in these definitions in OWL and SWRL. Considering OWL and SWRL are the subclasses of XML, the expressions can be mapped as XML fragments. The restrictions has the corresponding implementation logic in SWRL, it can be directly mapped as SWRL fragments. Rule 13: To represent them in OWL, we use the similar syntax as MathML to define their context, which is stored as an XMLLiteral data type property of the class that represents the expression, function or procedure definition. Whereas MathML standard does not define corresponding functions specially used in EXPRESS and Table 3 A global rule in EXPRESS
when this is not enough to satisfy the need of the application, some modifications and extensions are made to MathML to make up the deficiency. The following is an example for a function definition to scale a number data type array which borrows from the EXPRESS language reference manual and has been simplified, the output result is something like Table 2. The overall function is defined as a class with an XMLLiteral data type property ‘‘statement’’, and the ‘‘statement’’ property is further divided into three parts, the input argument definitions, the local variable definitions and the executable statement definition in XML fragments form. The input arguments are defined with the XML tag ‘‘args_val’’, which has two attributes ‘‘type’’ and ‘‘label’’ to denote the variable’s data type and data type mark. The local variables have the same attributes as the input arguments but can be only used in the local body of the function. The executable statements are mapped from EXPRESS language to XML analogous to MathML definition. And ‘‘expression’’ acts as a group mechanism for other executable statements, function call definitions are given between the open tag and the close tag in which the ‘‘function’’ tag is nested; succeeding to it
W. Zhao, J.K. Liu / Computers in Industry 59 (2008) 580–589
587
Fig. 2. The mapping ontology diagram for the point set data type of Table 3.
is the input arguments of the called function. As we define the array as a class in OWL, the operators such as the index operator ‘‘[]’’ must be defined in another way, here, we define elsewhere another function ‘‘function_get_array_value’’ to achieve the same function. The ‘‘repeat’’ part means a for-loop like C language, ‘‘constraint’’ restricts the value of the loop variable ‘‘index’’. Due to the limited pages, the complexity of EXPRESS language and as an experiment, we do not present here the defined markup language including all the tags on the basis of XML used to represent the corresponding elements of expressions and statements in EXPRESS language. Rule 14: The WHERE clause declarations or local rules are treated as the constraints, as we indicate in Section 3, SWRL provides complex predicates and suitable for representing deductive knowledge, so the WHERE clauses can be mapped as rules in SWRL. Rule 15: The rule declarations not including local rules are treated as special entities, the regular entity and the rule can be distinguished by means of naming. An item of rule is divided into three parts: the local variables, executable statements and local rules. In particular, the local variables are treated as its attributes, the constrained entity type or a set of multiple entity types are as the input arguments of the executable statements, but the global rules have no output arguments. All these three parts can be mapped according to the above corresponding rules. Considering the following RULE (Table 3) from the EXPRESS Language Reference Manual [7], this simple RULE has two local variables, two query executable statements and a where-clause local rule. The mapping performs from the bottom up, and first is the data types as it should be. Similar to the definition of the integer array in Table 1, the point set data type is first mapped as the class ‘‘SET_point_TYPE’’, whose ontology diagram accompanied by its related class ‘‘point’’ is shown in Fig. 2. Then the ‘‘expression’’ and ‘‘function’’, the global rule and the where clause declaration are mapped as their corresponding classes shown in Figs. 3–5, respectively. The classes ‘‘expression’’ and ‘‘function’’ have the same DataTypeProperty ‘‘statement’’ in the XMLLiteral format, which will be used to store their context. The global rule mapping result, that is, the class ‘‘RULE_point-match’’, is shown in Fig. 4. Its ObjectProperty ‘‘point-match-statement’’ has a range of an
enumeration class made up of an ‘‘expression01’’ instance of Class ‘‘expression’’, which also stores the executable statements of the rule in the XMLLiteral format, and the local variables ‘‘first-oct’’ and ‘‘seventh-oct’’ are mapped as the ObjectProperty of the global rule class. The mapping result of the where-clause local rule is shown in Fig. 5, which defines an instance of the implication class (swrl:imp), and an implication consists of an antecedent
Fig. 3. The mapping ontology and relationship diagram for the expression and function of Table 3.
Fig. 4. The mapping ontology diagram for the global rule of Table 3.
W. Zhao, J.K. Liu / Computers in Industry 59 (2008) 580–589
588
In addition, in order to ensure a high quality of these ontologies, at design time the formal foundation of OWL on Description Logics can be exploited to find inconsistencies, maintain complex subclass relationships along multiple axes and reveal hidden relationships. 5. Conclusions
Fig. 5. The mapping SWRL instance for the where clause of Table 3.
(swrl:body) and a consequent (swrl:head). Two instances of the class ‘‘function’’, ‘‘sizeof’’ and ‘‘QUERY’’, are defined and used in the ‘‘expression’’ instances, ‘‘expression02’’ and ‘‘expression03’’, which store the expression of where-clause expressions, and in the consequent part of the definition, ‘‘swrlb:equal’’ represents the operator ‘‘ = ’’ in SWRL. Rule 16: All the properties that have concrete values such as constant, expression strings can be expressed as instances of the corresponding type using the related rules. And to distinguish them, some prefixes or postfixes can be added to their instance names (i.e. rdf:IDs in OWL), for example, a constant definition can use ‘‘CONST_’’ prefix concatenated with the original name in EXPRESS. 4.5. Inheritance mechanism in EXPRESS EXPRESS language provides the natural inheritance mechanism to describe more complex relations between objects. Compared with those of other object-oriented languages, inheritance in EXPRESS can take one of the following forms: ‘‘ONEOF’’, an instantiation of a supertype is exactly one of the subtypes; ‘‘AND’’, an instantiation of a supertype is the union of all subtypes; or ‘‘ANDOR’’, an instantiation of a supertype is a variable subset of the union of all subtypes. These inheritance mechanisms have the similar logic to the class axioms defined in OWL declarations, so some transformations between them can make them be easily mapped to OWL. The transformation or substitution rule of the above inheritance mechanisms is presented as follows. Rule 17: For ONEOF operator, paradigms as ‘‘C SUPERTYPE OF ONEOF: (C1, C2, . . ., Cn)’’ can be represented as: C i C; Ci \ : C j , where n j > i 1, CBBC1 [ C2, . . . [ Cn, where i, j 2 {1, 2, . . ., n}. Rule 18: For ANDOR operator, paradigms as ‘‘C SUPERTYPE OF ANDOR: (C1, C2, . . ., Cn)’’ can be represented as: C1 C, where i 2 {1, 2, . . ., n}. Rule 19: For AND operator, paradigms as ‘‘C SUPERTYPE OF C1 AND C2’’ can be represented as: to CBBC1 [ C2. Rule 20: For AND operator, paradigms as ‘‘C SUPERTYPE OF: (ONE OF (C1, C2, . . ., Cn) AND ONEOF (C 01 ; C 02 ; . . . ; C 0n ))’’ is equal to ‘‘C SUPERTYPE OF ONEOF (C1, C2, . . ., Cn)’’ and ‘‘C SUPERTYPE OF ONEOF (C 01 ; C 02 ; . . . C 0n )’’. All the presentation of the above 17–20th Rule forms can be described with the complement, intersection, union or other subsumption relation axioms in OWL. 4.6. Discussions We use the special naming method to distinguish the ontologies deriving from data types, entities, rules, etc., another feasible way is to define namespaces for different purposes and specify them as the prefixes of the names with a colon between them. For the sake of simplicity, we have not done like this. Since the namespace provides a simple method to avoid element name conflicts and does not disturb the local name, this method will bring more flexibility.
Our main objective is to provide product information in the Semantic Web not only presented in ontology but including its entire constraints on them that can be further used in reasoning. On the basis of the presentation of product information model in EXPRESS language, this paper has proposed the methodology to construct the product information model encoded in OWL/SWRL, which enable it more convenient, more flexible and more open to access and apply the product model information. Acknowledgements This work is supported by the NSFC (10772202), Doctoral Program Foundation of MOE of China (20050558032), GDSF (07003680, 05003295). References [1] R. Sudarsan, S.J. Fenves, R.D. Sriram, F. Wang, A product information modeling framework for product lifecycle management, Computer Aided Design 37 (13) (2005) 1399–1411. [2] A.M. Shaharoun, J.A. Razak, M.R. Alam, STEP-based geometrical representation as part of product data model of a plastics part, Journal of Materials Processing Technology 76 (1–3) (1998) 115–119. [3] S. Mostefai, A. Bouras, M. Batouche, Effective collaboration in product development via a common sharable ontology, International Journal of Computational Intelligence 2 (4) (2005) 206–212. [4] G. Lee, C.M. Eastman, R. Sacks, S.B. Navathe, Grammatical rules for specifying information for automated product data modeling, Advanced Engineering Informatics 20 (2) (2006) 155–170. [5] N. Guarino, Formal ontology, conceptual analysis and knowledge representation, International Journal of Human-Computer Studies 43 (1995) 625–640. [6] J. Jiao, M.M. Tseng, A methodology of developing product family architectures for mass customization, Journal of Intelligent Manufacturing 10 (1999) 3–20. [7] Philip Spidy, STEP Part 11: The EXPRESS Language Reference Manual, ISO TC184/ SC4 N65, 1994. [8] M. Pratt, Introduction to ISO 10303—The STEP standard for product data exchange, ASME Journal of Computing and Information Science in Engineering (Novemeber 2000). [9] X. Fu, N. Channa, Methodology for semantic representing of product data in XML,, in: Proceedings of Advanced Workshop on Content Computing, AWCC 2004, 2004. [10] Industrial automation systems and integration. Product data representation and exchange. Part 21. Clear text encoding of the exchange structure, ISO 10303-21, 1994. [11] Industrial automation systems and integration. Product data representation and exchange. Part 28. Implementation methods: XML representations of EXPRESS schemas and data, ISO 10303-28, 1998. [12] Industrial automation systems and integration. Product data representation and exchange. Part 25. Implementation methods: EXPRESS to XMI Binding, ISO 10303-25, 2002. [13] F. Fu¨rst, F. Trichet, Reasoning on the semantic web needs to reason both on ontology based assertions and on ontologies themselves, in: Proceedings of Reasoning on the Web Conference, 2006. [14] World Wide Web Consortium, OWL Web Ontology Language Overview, February 2004, available at http://www.w3.org/TR/2004/REC-owl-features-20040210/. [15] World Wide Web Consortium, RDF Primer, February 2004, available at http:// www.w3.org/TR/2004/REC-rdf-primer-20040210/. [16] World Wide Web Consortium, SWRL: A semantic web rule language combining OWL and RuleML, May 2004, available at http://www.w3.org/Submission/2004/ SUBM-SWRL-20040521/. [17] World Wide Web Consortium, Extensible Markup Language (XML) 1.0, second ed., 2000, available at http://www.w3.org/TR/2000/REC-xml-20001006. [18] D. Djuric, D. Gasevc, V. Devedzic, A MDA-based approach to the ontology definition metamodel, in: Proceedings of the 4th International Workshop on Computational Intelligence and Information Technologies, 2003, pp. 51–54. [19] D. Connolly, F. van Harmelen, I. Horrocks, D.L. McGuinness, P.F. Patel-Schneider, L. Andrea Stein, DAML + OIL Reference Description. W3C Note 18 December 2001, available at http://www.w3.org/TR/2001/NOTE-daml+oil-reference-20011218. [20] S.B. Yoo, S.K. Cha, Integrity maintenance in a heterogeneous engineering database environment, Data & Knowledge Engineering 21 (3) (1997) 347–363.
W. Zhao, J.K. Liu / Computers in Industry 59 (2008) 580–589 [21] The RuleML Initiative, http://www.ruleml.org/. [22] V. Haarslev, R. Mo¨ller, Racer: an OWL reasoning agent for the Semantic Web, in: Proceedings of the International Workshop on Applications, Products and Services of Web-based Support Systems, in conjunction with 2003 IEEE/WIC International Conference on Web Intelligence, Halifax Canada, October 13, (2003), pp. 91–95. [23] World Wide Web Consortium, Mathematical Markup Language, February 2001, available at http://www.w3.org/Math/. Wei Zhao received his engineering degree in Mechanical Engineering in 2001 and his postgraduate certificate in 2004 from Wuhan University of Hydraulic and Electric Engineering and Three Gorges University, China, respectively. He is currently a Ph.D. student in Engineering Mechanics in the Department of Mechanics of Sun Yatsen (Zhongshan) University. His main research interests include structural reliability analysis in mechanical engineering, knowledge-based system, collaboration
589
and information sharing between CAD, CAM and CAE, computer aided systems for reliability analysis in engineering, etc. Ji-Ke Liu is a professor in the Department of Mechanics of Sun Yat-sen (Zhongshan) University, PR China. He graduated in 1988, and received his Master’s degree in 1991 and Ph.D. degree in 1993 from Northwestern Polytechnical University. He worked as a Postdoctoral Research Fellow in the Institute of Dynamics, Noise and Control from 1993 to 1995. He was invited to The University of Hong Kong 12 times as a Research Associate. His research interests are oriented on vibration theory and its applications of complex structural systems, theory and applications of structural reliability analysis, computers and structures in engineering, etc. He has published more than 100 journal and conference papers.
