Camlon H Asuncion
email: c.h.asuncion@utwente.nl

Marten Van Sinderen
email: m.j.vansinderen@utwente.nl

Towards Pragmatic Interoperability in the New Enterprise -A Survey of Approaches

Keywords: enterprise interoperability, pragmatic interoperability, survey of approaches

Pragmatic interoperability (PI) is the compatibility between the intended versus the actual effect of message exchange. This paper advances PI as a new research agenda within the gamut of enterprise interoperability research. PI is timely in today's new enterprises as it is increasingly important that organizations are able to collectively add value to their products and services through effective collaboration. When enterprise systems exchange information, PI goes beyond the compatibility between the structure and the meaning of shared information. It also considers the use of information in a given context as an equally important aspect. As PI is a relatively new domain, this paper attempts to elucidate its notion by identifying and relating its key concepts from proposed definitions, and by reviewing extant approaches to identify critical knowledge gaps in PI research.

Introduction

The International Organization for Standardization (ISO) defines an enterprise to be "one or more organizations sharing a definite mission, goals, and objectives to offer an output such as a product or service" [START_REF]Industrial Automation Systems -Requirements for Enterprise Reference Architectures and Methodologies[END_REF]. This definition implies that either one or a group of organizations is involved. However, today's organizations remain competitive if they collaborate with other organizations with the objective of adding more value to their products and services (e.g. supply chain networks [START_REF] Davis | The Extended Enterprise: Gaining Competitive Advantage through Collaborative Supply Chains[END_REF]). This cross-organizational nature of enterprises gave way to two types: a virtual enterprise (VE) and an extended enterprise (EE). While a VE temporarily exists between organizations to exploit an immediate market opportunity, an EE requires long-term trust and mutually dependent relationships [START_REF] Chen | Architectures for Enterprise Integration and Interoperability: Past, Present and Future[END_REF]. These new enterprises have given rise to innovative business models that drive today's global economy [START_REF] Chung | Networked Enterprise: A New Business Model for Global Sourcing[END_REF].

Although today's enterprises want to leverage the benefits of their collaboration, interoperability problems between enterprise systems prevents them from doing so to the full extent [START_REF] Van Sinderen | Challenges and Solutions in Enterprise Computing[END_REF]. Previous investments in equipment and software cause incompatibilities between data representation and application methods. New acquisitions can cause impracticable integration with third party applications [START_REF] Jardim-Goncalves | Challenging the Interoperability between Computers in Industry with MDA and SOA[END_REF].

Vernadat [START_REF] Vernadat | Interoperable Enterprise Systems: Principles, Concepts, and Methods[END_REF] argues that interoperability in the enterprise: "provides two or more business entities [...] with the ability of exchanging or sharing information (wherever it is and at any time) and of using functionality of one another in a distributed and heterogeneous environment." Since organizations are not only composed of software but of people as well, achieving enterprise interoperability is multi-faceted [START_REF] Doumeingts | Enterprise Interoperability: New Challenges and Approaches[END_REF]. Chen, et al. [START_REF] Chen | Architectures for Enterprise Integration and Interoperability: Past, Present and Future[END_REF] argue that enterprise interoperability is ensured if there is interaction at least in the following layers: data, services, process and business.

In recent years, a number of researchers are also looking into the role of pragmatic interoperability (PI) as another layer in the general research of enterprise interoperability. They argue that while there is a need to agree on the structure and the meaning of the shared information, use of information is important as well. To provide a working definition of PI, we borrow Pokraev's [START_REF] Pokraev | Model-Driven Semantic Integration of Service-Oriented Applications[END_REF] definition as being: Definition 1. The compatibility between the intended versus the actual effect of message exchange Various motivations from different domains have been put forward to advance PI as a new, timely and important research agenda. Among them, for example, is in the domain of collaborative enteprise computing where Kutvonen, et al. [START_REF] Kutvonen | Automating Decisions for Inter-enterprise Collaboration Management[END_REF] argue that cross-organizational collaboration not only involves technology but social aspects of integration as well (i.e., pragmatics). In the domain of Web service discovery, Lee [START_REF] Lee | HIS-KCWater: Context-Aware Geospatial Data and Service Integration[END_REF] argues that pragmatics can be used to select the most appropriate service from among a set of syntactically and semantically similar, yet competing, services. This view is shared by de Moor [START_REF] De Moor | Web Service Selection in Virtual Communities[END_REF] where stakeholders interpret the appropriateness, suitability and applicability of a set of Web services, a process they call pragmatic selection in the domain of virtual communities. Singh, among others, proposes the notion of the Pragmatic Web [START_REF] Singh | The Pragmatic Web[END_REF], which entails that the meaning of information should be interpreted in the context of its use.

We recently conducted a systematic literature review to elucidate important concepts that can be derived from published definitions of PI [START_REF] Asuncion | Pragmatic Interoperability: A Systematic Review of Published Definitions[END_REF] -essentially, we wanted to understand what PI currently means. The contribution of this paper, on the other hand, builds on previous work by investigating how current approaches propose to achieve PI. We do this by proposing a set of criteria whereby we can position the approaches accordingly.

The rest of this paper is structured as follows. Section 2 provides an elaboration on the notion of PI. Section 3 provides a framework to compare PI approaches. Section 4 compares extant approaches using the framework. Section 5 draws insights from the comparison. Finally, Section 6 presents conclusions and a brief research roadmap to further advance PI research.

Defining Pragmatic Interoperability

Our previous work focused on extracting dominant concepts from published definitions of PI as we have seen that there is a lack of canonical agreement as to how it is currently defined [START_REF] Asuncion | Pragmatic Interoperability: A Systematic Review of Published Definitions[END_REF]. The following concepts from the proposed definitions of PI can be derived: intention, exchange, use and context.

A sender sends a message with some intention (also known as goal, need, preference, or intended effect). To realize this intention, the message must be delivered to the receiver, and hence, message exchange is part and parcel. On the receiver's end, message use deals with how the receiver acts to realize the intention of the message. However, a message must not be used arbitrarily but in a given context as its actual meaning varies according to the context in which it is used. Apart from this, context also changes over time which can affect the meaning of the message as well. Therefore, there must be a shared context which is relevant for the purpose of interoperation. Based on these concepts, we now propose a refinement of Definition 1 by stating PI as: Definition 2. The compatibility between the intended versus the actual use of received message within a relevant shared context. This is still consistent with Definition 1 in the sense that we relate effect to both message use and context. The notion of message use can be furthermore refined in terms of the relevant subsequent use of information and the relevant subsequent actions using that information. Essentially, we argue that the intended effect is achieved through a mutually dependent relationship between information, action, and context; i.e., Actions on received information depend on context.

-Relevant subsequent use of information: This denotes which relevant information (or part of the message) are to be used in a given context from the set of all data received during message exchange. We borrow this concept from Zeigler's notion of pragmatic frame [START_REF] Zeigler | Modeling & Simulation-Based Data Engineering: Introducing Pragmatics into Ontologies for Net-Centric Information Exchange[END_REF]. -Relevant subsequent actions: This denotes which relevant subsequent actions the receiver can perform in a given context from the set of all possible actions. We borrow this from the Speech Act Theory (SAT) [START_REF] Searle | Speech Acts: An Essay in the Philosophy of Language[END_REF] and the Language/Action Perspective (LAP) [START_REF] Weigand | Two Decades of the Language-Action Perspective[END_REF], and from definitions given by such authors as Schade [START_REF] Schade | Towards the Edge and Beyond: The Role of Interoperability[END_REF], Hofmann [START_REF] Hofmann | Challenges of Model Interoperation in Military Simulations[END_REF], Bazijanec [START_REF] Bazijanec | Establishing Interoperability of Coordination Protocols in Ad Hoc Inter-Organizational Collaborations[END_REF], among others.

Criteria for Comparison

Seeing that the approaches are quite diverse in terms of their domain and implementation, a difficulty arises when they are compared with specific properties. Thus, we have resorted to devising a generalized set of criteria which is not too specific but still keeps the objective of this paper achievable. The approaches are compared in terms of the basic architecture it supports, the phase(s) of a development life cycle it contributes to, the role of context, the adaptiveness of its solution, how it realizes compatibility, and where the scope of the effect is achieved. We now briefly describe each criterion.

Architecture. This criterion positions an approach according to the support it has in terms of the types of relations participants have in the collaboration (e.g., one-to-one, one-to-many or many-to-many), the distributed computing model of the architecture (e.g., client-server, peer-to-peer, n-tier, or space-based), and how the intended effect can be achieved through message exchange (e.g., single request or dialogue).

Life cycle. This criterion positions the approach in terms of which phase of an information systems development life cycle it contributes or applies to. We use the phases of the Systems Development Life Cycle (SDLC) [START_REF] Haag | Management Information Systems for the Information Age[END_REF]: planning, analysis, design, development, testing, and implementation. Although more elaborate frameworks can be used (e.g. ISO/IEC 12207, ISO/IEC 15288), we deem it sufficient to make a simplified and generalized comparison of the approaches using SDLC. The planning phase defines a development plan (e.g., project definition, scope, documentation, etc.) of the proposed system. The analysis phase involves understanding and documenting system requirements. The design phase involves creating a "blueprint" of how the proposed system will work. The development phase involves building the actual system according to the design documents. The testing phase involves verifying if the actual system meets the requirements of the analysis phase. The implementation phase begins when the system becomes operational by the end users. Finally, the maintenance phase involves monitoring the actual system to ensure its compliance with business goals.

Context. Our previous work [START_REF] Asuncion | Pragmatic Interoperability: A Systematic Review of Published Definitions[END_REF] showed that a number of approaches consider context to be important in PI. This criterion asks if an approach is dependent on the notion of context to achieve PI. If so, we classify the role of context using the two refinements of message use described in Section 2; i.e, message use as the relevant subsequent use of information, or the relevant subsequent actions using that information as means to achieve the intended effect, in a given context.

Adaptiveness. A pressing requirement in today's new enterprises is to be adaptive to change. Adaptation compels an enterprise to respond to changes because of the conditions of its environment in an effort to survive [START_REF] Chakravarthy | Adaptation: A Promising Metaphor for Strategic Management[END_REF]. This imposes on the PI solution a high degree of flexibility. We use this criterion to position an approach as to whether it has some mechanisms that allow the solution to swiftly adapt to new situations and still remain interoperable.

Compatibility. Recalling Definition 2, the key relation between the intended versus the actual effect is compatibility, which can be achieved either absolutely or relatively. By relative, we mean that achieving the intended effect is approximate in that, for example, one sender may be satisfied at a different level from another sender. By absolute, we mean that the intended effect is either present entirely or not; i.e, either PI is there or isn't there.

Scope. This criterion positions the approach as to where the intended effect is ultimately realized. We propose in our previous work [START_REF] Asuncion | Pragmatic Interoperability: A Systematic Review of Published Definitions[END_REF] that message exchange can create a intended effect either at the application level or business level. For each approach we ask: Does the intended effect remain at the digital world only (e.g., the update of a data item in a database column) or does the intended effect propagate to the business level to achieve a business objective; i.e, outside the digital world and into the real world?

Approaches to Pragmatic Interoperability

We now describe briefly and position accordingly each approach using the criteria. Of the 44 papers that were identified from our previous work [START_REF] Asuncion | Pragmatic Interoperability: A Systematic Review of Published Definitions[END_REF], 9 are discussed here as they provide some level of detail as to how PI can be achieved; 24 papers, however, do not provide enough detail to warrant a comparison. The remaining 11 papers are in the domain of Multi-Agent Systems (MAS) which are deliberately excluded here.

Kutvonen et al. [START_REF] Kutvonen | Automating Decisions for Inter-enterprise Collaboration Management[END_REF] The approach supports the collaboration of VEs, or eCommunities as the authors call them, where organizations can dynamically participate (i.e., they can join, leave, or be removed for various reasons) in global business environments based on open markets to achieve a certain business opportunity. An eCommunity is a venue for participants to be pragmatically interoperable as they can negotiate and agree on the compatibility of their business rules and policies.

The approach uses the concept of an eContract which not only encapsulates the rules and policies, but functional and non-functional properties of the collaboration as well. An eContract is implemented under an automated environment, called the webPilarcos B2B middleware, where facilities for finding, selecting and contracting relevant services are provided. The middleware is designed to follow a federated form of interoperation where services are developed independently by organizations and no meta-information is assumed to be shared allowing the approach to be adaptive. The middleware supports a many-to-many collaboration any organization can dynamically participate in the eCommunity, an n-tier distributed model is supported by the middleware, and dialogue is necessary during negotiation to agree on the eContract. The approach provides contribution to the analysis, design, and development of the eContract, and thereafter, maintenance and compliance monitoring using the eContract. It is oriented towards providing a PI solution at the business level achieving scope at that level. The role of context, however, is not explicitly explained.

Lee et al. [START_REF] Lee | HIS-KCWater: Context-Aware Geospatial Data and Service Integration[END_REF] The approach proposes a solution for the automatic composition of Web services into a service workflow which combines simple services to form a complex one that meets user requirements. When a service requester is faced with a set of syntactically compatible, semantically equivalent, yet competing services, contextual knowledge can be used to select the most appropriate service. Pragmatic or contextual knowledge describes how and in what situations provided services can satisfy user requirements in a given context. Contextual knowledge is modelled using rule-annotated ontologies (e.g., RuleML and OWL).

An architecture uses a service composition agent to perform the necessary discovery and selection using pragmatic knowledge. We thus view interoperabil-ity in their approach to be one-to-many and n-tier; however, it appears that once the selection of the service is completed, achieving the intended effect occurs using a single service request only. The approach seems to focus more on the analysis, design, and development of the PI solution rather than with other phases. Context is used as the key component in selecting the most appropriate service; in particular, the composition agent uses contextual information of the service requester during the service selection process. The approach is adaptive in the sense that once the contextual information of the service requester changes, the most appropriate service can then be selected to compose a new service workflow. Compatibility seems to be absolute since if the composition agent cannot find an appropriate service based on the context of the service requester, the service workflow cannot be generated as well. Finally, the approach is largely oriented towards achieving PI at the application level.

Liu et al. [START_REF] Liu | Pragmatic Computing -A Semiotic Perspective to Web Services[END_REF] To design service-oriented applications, the approach leverages pragmatics (a component of the Theory of Semiotics [START_REF] Morris | Foundations of the Theory of Signs[END_REF]), which is concerned with the use of information in relation to its intended purpose in a given context. The approach proposes a Pragmatic Web Service Framework for service request decomposition and aggregation. Here, a service broker decomposes a request into finer sub-requests that specify requirements that a concrete Web service should satisfy. A sub-request is annotated with its own semantic and pragmatic (i.e., purpose and context, or a pragmatic frame) definitions which are then represented as Web service abstracts. A workflow is then designed using business process requirements and the Web service abstracts. To implement the workflow, the service broker uses pragmatic knowledge to find concrete Web services using the Web service abstract and the pragmatic frame. How a concrete Web service meets the requirements of an abstract Web service in terms of the pragmatic frame is measured as the pragmatic distance.

The interaction is one-to-many where one request can be satisfied by many providers, mediated by a service broker. Once an appropriate concrete Web service is selected, a single request seems to achieve the intended effect. The approach can be positioned in terms of the analysis, design, and development phases of the life cycle. Context is important, and the approach makes use of illocutionary acts from the SAT to achieve intended effect. The notion of pragmatic distance leads us to believe that compatibility can be achieved relatively; e.g., requesters may select concrete Web services with varying pragmatic distances. Since the approach is preliminary, we cannot sufficiently assess the adaptiveness of the solution. Finally, we view the scope of the approach to be at the application level.

de Moor et al. [START_REF] De Moor | Web Service Selection in Virtual Communities[END_REF] The approach proposes a solution to Web service selection in virtual communities (VC) for the communication of their members using collaborative tools. Particularly challenging in VCs is that tacit knowledge cannot be completely and explicitly represented. In this respect, the authors leverage pragmatic concepts to provide a context-dependent mechanism so that service selection can be tied to the context of its intended use. This is important as VCs use services in novel and unique depending on their context. Guided by a methodology called RENISYS [START_REF] De Moor | Making Workflow Change Acceptable[END_REF], relevant stakeholders of a VC interpret the usefulness of a set of syntactically and semantically compatible candidate Web services based on certain criteria. This is called as the process of pragmatic selection.

We cannot assess the architectural aspect of the solution as no architecture is used, but rather a methodology. RENISYS can be positioned mostly during the analysis stage when a VC selects the most pragmatically compatible set of Web services according to the VC's context of use. Context is critical as it will determine what sort of services a VC requires; however, it is not clear if context is described in terms of relevant information or relevant actions. Compatibility is relative as a virtual community may have different and unique requirements from another. Finally, the methodology is focused at achieving the intended effect ultimately at the business level.

Pokraev [START_REF] Pokraev | Model-Driven Semantic Integration of Service-Oriented Applications[END_REF] The approach uses service-oriented and model-driven principles to provide solutions in the domain of Enterprise Application Integration (EAI) where multiple, heterogenous, autonomous and complex distributed systems need a flexible interoperability solution to collaborate effectively. It implements a service mediator that resolves data and process mismatches between collaborating systems with fixed service descriptions. A data mismatch occurs when systems have different denotations of the same message element in the real world. A process mismatch occurs when systems have a different understanding of message interaction protocols (i.e., the order of message exchange). PI is achieved when the sender and receiver of the message have the same expectation of the effect of message exchange which can be realized by ensuring that the proper order and execution of message invocations are followed.

We view the compatibility of the approach to be rather absolute as the specific order of service invocation must be observed. The approach proposes a five-step methodology for designing integration solutions which covers analysis, design, development, and testing. However, it does not explicitly consider the role of context in PI. As the approach leverages model-driven techniques, a key benefit is abstraction; i.e., with the same abstract solution depicted as platform-independent models, new implementations can be automatically generated, allowing adaptiveness. Furthermore, there is also work that extends the approach whereby business rules are used to separate the dynamic aspects of the requirements making the approach even more flexible [START_REF] Asuncion | Towards a Flexible Service Integration through Separation of Business Rules[END_REF]. We position the approach as having a business level scope.

Rukanova [START_REF] Rukanova | Business Transactions and Standards: Towards a System of Concepts and a Method for Early Problem Identification in Standard Implementation Projects[END_REF] The use of a standard can help organizations be interoperable. However, the challenge lies in determining if whether or not a standard is sufficient to meet the communication requirements of an organization's digital business transaction (DBT), where a DBT is an electronic exchange of products and/or services for some remuneration. Thus, when organizations choose to adopt a standard to perform DBTs with others, the "fit" or the capabilities of a standard vis-a-vis the requirements of a DBT should first be evaluated. To do this, the approach proposes a meta-model that can be used as basis for the evaluation, with an accompanying methodology for doing such evaluation. The theoretical foundations of the meta-model are derived from theories related to the pragmatics of communication, where context plays an important role. The approach argues that when a standard fits a DBT, PI is satisfied.

The architectural aspect of the approach cannot be positioned as no architecture is used, but rather a methodology. The methodology can be positioned at the analysis phase of the life cycle where it helps assess the fit of a standard for a given DBT. In terms of context, the meta-model uses the communicative acts of the SAT and LAP to describe the pragmatic aspect of the communication. Compatibility is therefore absolute as a selected standard should be able to address all communicative patterns of LAP; otherwise, pragmatic interoperability problems may occur. On the other hand, it is not clear how the methodology would allow the solution to be adaptive to business changes. Finally, we position the scope at the business level as the ultimate effect is realized through an effective DBT.

Tamani et al. [START_REF] Tamani | A Pragmatic Methodology to Web Service Discovery[END_REF] Motivated by the argument that collaborating parties use Web services differently according to their own context, the approach proposes a solution levaraging principles of the Pragmatic Web [START_REF] Singh | The Pragmatic Web[END_REF] for automated Web service discovery, where context is used to select the most appropriate service above and beyond semantically equivalent services. The approach uses XML to capture and XPath to query the personal, functional, and contextual information of collaborating parties stored in profile repositories. These XML profiles specify each requester's and provider's identity and role (the "who" part), the purpose and goal (the "why" part that specifies the context of the collaborating parties), the input and output parameters annotated by some ontology structure (the "what" part). A matching architecture is used to semantically match the "what" part of the request/offer XML and pragmatically match the "why" part of the request/offer XML. The Web service of the offer XML that is semantically and pragmatically closest to the request XML, through string tokenization algorithms, is selected.

Architecturally, the approach uses a one-to-many interaction as one requester may need to discover from one among many offers from the profile repository. A matcher sits in between the requester and provider that resolves semantic and pragmatic differences between the two. A single request, however, seems to be sufficient to achieve the intended effect. The approach falls within the design and development stages of the life cycle. Context is important by treating only the similar contextual information specified as "why" part of the request/offer XMLs. On the other hand, it is difficult to assess the adaptiveness of the approach as this criterion is not well described. Compatibility is rather absolute in the sense that if a matcher cannot find similarities between the "why" part of the request/offer XMLs, PI cannot be achieved. Finally, the intended effect is only realized at the application level through the successful matching of contextual information.

Tolk et al. [START_REF] Tolk | A Layered Approach to Composition and Interoperation in Complex Systems[END_REF] The approach proposes a framework for measuring the degree of conceptual representation between interoperable systems, known as the Levels of Conceptual Interoperability Model (LCIM), which is highly influenced by the Modelling and Simulation community. LCIM has seven levels of interoperability: no interoperability, technical, syntactic, semantic, pragmatic, dynamic, and conceptual. Focusing on the PI level, PI is reached when "when the interoperating systems are aware of each others methods and procedures. In other words, the use of the data -or the context of its application -is understood by the participating systems; the context in which the information is exchanged is unambiguously defined". LCIM takes two roles: descriptive and prescriptive, Descriptively, LCIM can be used as a documentation which serves as a maturity model whereby properties of an interoperating system is measured against an LCIM level. Prescriptively, LCIM has a set of methods for achieving a target interoperability level.

As LCIM is largely an assessment framework, no architecture is proposed. Furthermore, as LCIM can be used descriptively and prescriptively, we position it in terms of the analysis, design and testing phases of the life cycle. Context relates to how information is used in a given state and specification of the system. LCIM does not clearly discuss if reaching the PI level entails adaptiveness of the solution. We view compatibility as absolute because the meaning of information depends on the state and specification of the system. Finally, we view the scope as that which is confined only to the interactions of the systems.

Zeigler et al. [31][24] In the Modelling and Simulation domain, the approaches positions PI in one of three levels: syntactic, semantic, and pragmatic. At the pragmatic level, focus is on the receivers' interpretation of messages in the context of its application relative to the senders intent. Thus, at the pragmatic level, there is a shared agreement between the sender and receiver of a message as to how information is to be used; i.e, the receiver reacts to the communicated message in a manner that the sender originally anticipated (with the assumption that there is non-hostility in the collaboration).

The approach introduces the notion of a pragmatic frame. Information exchange involves reporting or requesting changes in the state of the world between a sender and a receiver. When a sender produces information by capturing the state of the world (through some form of ontology, derived from his own perspective of the world), the pragmatic frame characterizes how a receiver would use that information (which maybe the full or part of that ontology). Thus, the pragmatics of use describes how data will be subsequently processed.

Architecturally, the approach supports a one-to-many type of interaction, n-tier, and single request. We position the approach in terms of the analysis, design, development phases of the life cycle. Context is an important concept that emphasizes on the subsequent use of information. The approach is not clear as to whether adaptiveness is reached when PI is achieved. Compatibility is relative in the sense that the subsequent use of relevant information may depend on the receiver and its context. We position the scope to be at the business level as the ultimate effect is realized by the receiver of the message when it uses the acquired relevant information. [START_REF] Lee | HIS-KCWater: Context-Aware Geospatial Data and Service Integration[END_REF] O2M/NT/S A, Des, Dev Yes, I Yes A A Liu et al. [START_REF] Liu | Pragmatic Computing -A Semiotic Perspective to Web Services[END_REF] O2M/NT/S A, Des, Dev Yes, A ? R A de Moor et al. [START_REF] De Moor | Web Service Selection in Virtual Communities[END_REF] none A Yes, ? ? R B Pokraev [START_REF] Pokraev | Model-Driven Semantic Integration of Service-Oriented Applications[END_REF] O2M/NT/D A, Des, Dev, T No Yes A B Rukanova [START_REF] Rukanova | Business Transactions and Standards: Towards a System of Concepts and a Method for Early Problem Identification in Standard Implementation Projects[END_REF] none A Yes, A ? A B Tamani et al. [START_REF] Tamani | A Pragmatic Methodology to Web Service Discovery[END_REF] O2M/NT/S Des, Dev Yes, I ? A A Tolk et al. [START_REF] Tolk | A Layered Approach to Composition and Interoperation in Complex Systems[END_REF] none A, Des, T Yes, I ? A A Zeigler et al. [START_REF] Zeigler | Modeling & Simulation-Based Data Engineering: Introducing Pragmatics into Ontologies for Net-Centric Information Exchange[END_REF] O2M/NT/S A, Des, Dev Yes, I ? R B

α O2O: one-to-one, O2M : one-to-many, M2M : many to many / P2P : peer-to-peer, NT : n-tier, CS : client-server / S : single request, D: dialogue φ P : planning, A: analysis, Des: design, Dev : development, T : testing, I : implementation, M : maintenance. ϕ I : relevant subsequent use of information, A: relevant subsequent actions ξ A: absolute, R: relative δ B : business level, A: application level

Discussion

A summary of the comparison among PI approaches with respect to the previously described criteria is given in Table 1. In this section, we first summarize and compare approaches per criterion to ascertain their differences and similarities. Thereafter, we attempt to identify critical knowledge gaps in PI research based on this comparison. Summarizing the approaches per criterion:

Architecture. Although there are more architectural approaches to PI, either a methodology or an assessment framework is also used. Among the architecturebased approaches, a one-to-many type of relation is mostly supported. It is often the case that an intermediary software is used to coordinate participants in the collaboration (i.e., a middleware, mediator, matcher, or a Web service broker). Particularly, among service-oriented approaches, a single request is often the type of message exchange used to achieve the intended effect. We also notice that the "one-to-many : single request" pair occurs more frequently.

Life cycle. Most of the approaches can be positioned in terms of the analysis, design and development phases of the life cycle. No approach adequately supports the planning phase. Furthermore, there are very few approaches that support the testing and maintenance phases. Furthermore, it is interesting to note that non-architectural approaches contribute more to the analysis phase where the focus is on requirements elicitation; e.g., pragmatics is seen as a technique during service selection where the most appropriate service is chosen based on contextual information.

Context. A large number of approaches value context as an integral part of achieving PI. This is due to the fact that these approaches leverage pragmatic theories such as Semiotics, SAT, and LAP as foundations for designing their solutions. The difference lies, however, in their interpretation of context: either the focus is more on the relevant subsequent information use or relevant subsequent actions performed; we observe, however, that neither approach supports these types simultaneously. Approaches that do not use pragmatic theories are not explicit about their support for context.

Adaptiveness. Most of the approaches are not clear as to how adaptive their solutions are, and hence we cannot position them accordingly. For approaches which we have positioned as adaptive, we cannot directly attribute their adaptiveness to their use of pragmatics. An exception, however, is the one of Lee [START_REF] Lee | HIS-KCWater: Context-Aware Geospatial Data and Service Integration[END_REF] where the change in context can be used to dynamically recreate a service workflow to meet the service requester's requirements by selecting the most appropriate service relative to the requester's context.

Compatibility. The approaches vary greatly in terms of achieving the intended effect either relatively or absolutely. There also seems to be a pattern: approaches whose scope is at the application level (i.e., that is the focus of the approach is rather technical, and, hence, the effect remains in the digital world) achieve PI absolutely. On the other hand, approaches whose scope is at the business level, achieving the intended effect is relative.

Scope. The approaches also vary in terms of scope. Some approaches, which are mostly technical (and, hence, the compatibility is absolute), achieve the intended effect at the application level; whereas, approaches with a relative compatibility achieve the intended effect at a business level scope. It is also interesting to note that single-request approaches have the scope of application level; whereas, dialogues are common in approaches whose scope is at the business level.

A number of critical knowledge gaps in PI research can be observed. We find that there is a need to bridge the gap among approaches that provide only architectural or methodological solutions to PI. We argue that to advance PI research, an architectural and methodological approach, which are both complementary, should be devised.

Currently, no approach seems available that supports the development of PI solutions in each phase of a software development life cycle (i.e., from planning to maintenance). Challenges are yet to be identified when pragmatic principles are considered in every phase of a system development life cycle specific to the goal of developing PI solutions. One promising approach is called MEASUR (Methods for Eliciting, Analysing and Specifying Users' Requirements) [START_REF] Liu | Semiotics in Information Systems Engineering[END_REF] that takes a semiotic approach to information systems development.

We still need to deepen our understanding in terms of which form of message exchange is necessary and sufficient to achieve the intended effect in PI: is it through a single request or through a dialogue? In human linguistics, pragmatic effects of communication are usually achieved through a dialogue that depends significantly on the prevailing context; how do we translate this when enterprise systems communicate pragmatically?

Our notion of context in PI needs further exploration as various approaches characterize context differently. This seems to be the most important aspect in PI, yet the most difficult to get to grips with. The two refinements of message use we described in Section 2 (i.e., relevant subsequent information use and relevant subsequent action in achieving PI) need consolidation as neither of the approaches treat both as important concerns together. Finally, it has been argued that not everything about context can be formalized [START_REF] De Moor | Web Service Selection in Virtual Communities[END_REF]. Questions thus remain: how much of context can or should we automate for the purpose of PI? How do we handle context that is difficult to automate but is nevertheless important for achieving PI?

As we have mentioned, adaptiveness and flexibility are critical in today's new enterprises. There is a need to create approaches that are adaptive to change. Already we find that this has been one of the goals of more recent PI approaches; however, evidence is yet to be had to ascertain whether the adaptiveness of the solution can be directed attributed to its being pragmatic. Demonstrating adaptiveness may allow PI research rapid adoption in the industry.

PI is a new and still less-developed research area as evidenced by the lack of implementation and validation in real life scenarios and the diversity of the terminologies used. Application of pragmatics-based solution remains to be seen in real life settings. Already we find that PI has been applied in various domains, is it possible to conceptualize PI so that it becomes applicable in various domains, similar to how semantic interoperability is understood in whatever domain it is applied?

Finally, no approach offers a mature way to measure the intended effect especially in both cases when the compatibility is either absolute or relative, or the scope is either at the business level or application level. Measuring PI especially becomes difficult when the business level is considered. One promising measure is proposed by Liu [START_REF] Liu | Pragmatic Computing -A Semiotic Perspective to Web Services[END_REF] called the pragmatic distance at the application level; however, implementation details remain to be seen.

Conclusion and Future Work

Pragmatic interoperability (PI) is the compatibility between the intended versus the actual use of message exchange within a relevant shared context. The interest in PI has been increasing recently as more and more researchers argue that agreeing on the syntax and semantics during message exchange is not enough, how information is used in a given context is important as well to reap the benefits of a truly effective interoperability solution. The application of pragmatics in information system research, in general, and PI research, in particular, still remains preliminary. This paper attempts to advance this field by harmonizing different concepts related to the notion of PI from among currently diverse interpretations of its concept. We also position PI approaches according to a set of criteria so that critical gaps in knowledge, related to PI research, can be elucidated.

In summary, some of these knowledge gaps include developing an approach where both architectural and methodological aspects are considered, studying the impact when pragmatic principles are considered in every phase of a system development life cycle, exploring the role of context in PI, and validating approaches in real life settings.

As we have described earlier, there are several other approaches to PI specific to the MAS domain. We have not considered them in this paper deliberately as we believe that they deserve a separate review. We intend to do this in the future, and perhaps perform a further comparison between MAS and non-MAS approaches to PI. Finally, it is our aim to envision a future solution where service-oriented principles will be used to achieve PI particularly in the healthcare domain.

Table 1 .

 1 A summary of the comparison among pragmatic interoperability approaches

	Architecture α	Life cycle φ	Context ϕ	Adaptiveness	Compatibility ξ	Scope δ
	Kutvonen et al. [13] M2M/NT/D A, Des, Dev, M	No	Yes R	B
	Lee et al.


Zahid Usman

Robert Ian Marr

Nitishal Chungoora

Claire Palmer

Keith Case

Jenny Harding
email: j.a.harding@lboro.ac.uk

{z Usman

R I Young

C Palmer3

A Manufacturing Core Concepts Ontology for Product Lifecycle Interoperability

Keywords: semantics, core concepts, interoperability, manufacturing ontology, knowledge sharing, product lifecycle, design and production

This paper proposes a manufacturing core concepts ontology (MCCO) aimed at providing support for product life cycle interoperability. The potential focus of the work is interoperability across the production and design domains of product lifecycle. A core set of manufacturing concepts and their key relationships are identified in MCCO. Semantics are captured formally through heavyweight logic using rigorous rules and axioms. Three different levels of specialization have been identified according to the degree of specialization required. Each level provides an immediate route to interoperability for the concepts specialized from that level. MCCO enable knowledge sharing across design and production domains through core concepts. A successful initial experimental implementation has been done to demonstrate the working of MCCO.

Introduction

Technology and knowledge have been recognized as the key factors for production [START_REF] Frankovič | The Role of Ontology in Building of Knowledge Systems for Industrial Applications[END_REF]. Information and Communication Technologies (ICT) have become an integral part of most organizations. Manufacturing organizations have moved from traditional manual drawings and design to Computer Aided Technologies (CAx). Software based approaches like Enterprise Resource Planning (ERP), Manufacturing and Materials Resource Planning (MRP), Product Lifecycle Management (PLM) etc are being employed rapidly. ICT are key to the manufacturing competence, competitiveness and jobs in Europe [START_REF]ICT for Manufacturing, Report of Meeting with Group of Representatives of Five Expert Panels[END_REF]. With machines replacing men, a mechanism of interoperability is required for machines to communicate across different domains.

Interoperability is "the ability to share technical and business data, information and knowledge seamlessly across two or more software tools or application systems in an error free manner with minimal manual interventions" [START_REF] Ray | Manufacturing interoperability[END_REF]. To highlight the importance of interoperability a study in 1999 at NIST showed that U.S.$ 1 billion are spent per year by the U.S. automotive sector alone for solving interoperability problems [START_REF] Brunnermeier | Interoperability Cost Analysis of the U[END_REF]. The multiples of this amount when other sectors like, services, health care, logistics, telecom, etc are considered from around the globe, the figures would definitely highlight this as a major problem. It has also highlighted the need to minimize the cost incurred in solving interoperability problems.

To make a system interoperable it is of extreme importance to formally capture & incorporate the semantics of concepts. A survey highlighted that almost 70% of total costs of interoperability projects is spent on solving issues of semantic mismatches [START_REF] Bussler | Context Mediation in the Semantic Web: Handling OWL Ontology and Data Disparity Through Context Interchange, in Semantic Web and Databases[END_REF]. Semantics can be captured formally by using ontologies based on rigorously formalized logical theories [START_REF] Uschold | Ontologies and Semantics for Seamless Connectivity[END_REF] i.e. heavyweight ontologies. Several definitions of ontology which is a borrowed term from philosophy are found in literature. The most quoted one being "An ontology is an explicit specification of a conceptualization" [START_REF] Gruber | Toward principles for the design of ontologies used for knowledge sharing[END_REF]. The one preferred for this work though is "a Lexicon of the specialized terminology along with some specifications of the meanings of the terms involved" [START_REF] Schlenoff | ISO-18629 The Process Specification Language (PSL): Overview and Version 1.0 Specification[END_REF]. This definition covers both the lightweight and heavyweight ontologies. The definition and use of concepts are captured by formalizing ontologies with rigorous logic based rules and this is what makes the ontologies formal or heavy weight.

To fulfill the requirements of manufacturing knowledge sharing core ontologies are generally developed from foundation ontologies [START_REF] Young | Manufacturing knowledge sharing in PLM: a progression towards the use of heavy weight ontologies[END_REF]. In the domains of design and production an extended heavyweight ontological foundation needs to be explored and developed further [START_REF] Chungoora | The configuration of design and manufacture knowledge models from a heavyweight ontological foundation[END_REF]. A novel method for developing a novel common semantic base in the form of a multilevel heavyweight MCCO to assist sharing knowledge across design and production domains of product lifecycle is proposed in this paper.

The Need for a Heavyweight Manufacturing Ontology

Lightweight Ontologies

Knowledge capturing and sharing has been done partially through database approaches like ERP, MRP, PLM, etc software tools. Limited success has been achieved in providing the information through databases [START_REF] Abramovici | Status and development trends of product lifecycle management systems[END_REF] because they have an underlying structure based on lightweight ontologies. Lightweight Ontologies in manufacturing have loosely formalized semantics making concepts open to multiple interpretations. These are also not understood well enough by computers for interoperability. There exists a lack of generally agreed terminology and underlying concepts not being defined explicitly in the manufacturing enterprise architectures area [START_REF] Chen | Architectures for enterprise integration and interoperability:Past, present and future[END_REF].

The current major route to interoperability is to use international standards. But, when it comes to knowledge sharing across different domains they have their own issues. ISO standards relevant to the manufacturing (mainly from ISO TC 184/ SC4) are very focused on their narrow domains of interest, e.g.:

• ISO 10303-STEP-Standard for The Exchange of Product date model AP239-Product Lifecycle Support (PRODUCT LIFECYCLES), AP224-Feature based manufacturing and mainly machining, AP1-Overview and fundamental principles, etc.,

• ISO 13584-Part Library (PLIB),

• ISO 15531-industrial MANufacturing management DATa (MANDATE),

• ISO13399-Cutting Tool Standard,

• Etc.

In a very specific and narrow domain of discourse the relevant standards are very useful. Definitions of terms in a narrow domain can be loose since their meanings are already understood by the concerned community. Across a broader domain like product lifecycle where more than one standard are required, interoperability through standards becomes an issue. To share knowledge across standard a common understanding among them is required. Most of the relevant ISO standards have non formalized text based semantics. Consistency lacks not only across standards but even within the same standards as well, e.g. the definition of 'component' in ISO standards:

• 'Component' definition in ISO-10303-1: "A product that is not subject to decomposition from the perspective of a specific application", • 'Component' definition in ISO-10303-AP224: "The component specifies either a Single_piece_part or another Manufactured_assembly used to define an assembly", • 'Component' definition in ISO 19439:2006 [general]: "Entity that is part of, or capable of becoming part of, a larger whole".

The semantics being text based and different within and across standards raise an issue for knowledge sharing through standards. The design and production domains of product lifecycle would require different set of concepts but they need to have a commonly understood formal semantic base for interoperability and knowledge sharing.

Heavyweight Ontologies Approach

Heavyweight ontologies can potentially overcome this problem of standards and lightweight ontologies. Heavyweight ontologies can formally define concepts, control their use, capture knowledge and provide a route to share across design and production. They offer better reasoning capability compared to the databases with fixed form and formats. Heavyweight ontologies have the potential to provide a rigorous common semantic base. Therefore, research potential is there to work on precisely and rigorously defined manufacturing ontology as a common semantic base. No common semantic base in the form of a heavyweight core manufacturing ontology is available for interoperability across design and production.

Foundation ontologies like DOLCE, SUMO, OCHRE, OpenCyc, BFO provide the first stage of a common understanding. They provide formally axiomatised domain independent set of concept e.g. AbstractEntity, ConcreteEntity, Endurant, Perdurant, spatial and temporal concepts, etc. But these are developed to cover everything therefore they are broadly based and generic [START_REF] Borgo | Foundations for a core ontology of manufacturing[END_REF]. Thus, the common semantic base provided by foundation ontologies will be too generic for interoperability across product lifecycle domains. Thus, concepts from foundation ontologies can serve as a basic backbone for the creation of the more specialized/viewpoint-dependent MCCO.

Heavyweight manufacturing ontologies available as of now are incomplete and do not cover the whole of product lifecycle and need to be completed and developed more [START_REF] Lee | Ontology-based Multi-layered Knowledge Framework for Product Lifecycle Management[END_REF]. Ontologies for the product lifecycle and manufacturing need to be developed further and tested [START_REF] Borgo | Foundations for a core ontology of manufacturing[END_REF][START_REF] Zhou | Manufacturing Ontology Analysis and Design: Towards Excellent Manufacturing[END_REF]. Also, the lack of core manufacturing ontologies to provide a common understanding for various strands of manufacturing [START_REF] Chen | Architectures for enterprise integration and interoperability:Past, present and future[END_REF][START_REF] Leimagnan | MASON: A proposal for an ontology for manufacturing domain[END_REF] needs to be overcome. Therefore, heavyweight product ontology capturing the semantics will help focus others on knowledge management issues [START_REF] Lee | Ontology-based Multi-layered Knowledge Framework for Product Lifecycle Management[END_REF].

Manufacturing Core Concepts Ontology

MCCO is formed by identifying a core set of concepts formalized in heavyweight logic. Three different levels with increasing degrees of specialization have identified for formalizing concepts.

Core Concepts & Relationships within MCCO

Capturing production knowledge requires different types of concepts. A detailed discussion on this is not possible in this paper. The UML diagram in fig 1 summarizes all the categories of concepts, key concepts in each category, and some of the key relationships identified between the concepts.

Features and Part Family category contains the most important one. Features and Part Family concepts and their specialized concepts at three different levels are key to capturing and sharing knowledge in product lifecycle [START_REF] Gunendran | An Information and Knowledge Framework to Support Multiple Viewpoints in the Design for Manufacture of Injection Moulded Products[END_REF][START_REF] Gunendran | Methods for the Capture of Manufacture Best Practice in Product Lifecycle Management[END_REF]. In this paper the feature concepts are used to show the implementation of the multi level ontology, to show implementation of core concepts, to prove their specialization and their ability to provide a route to sharing knowledge across design and production domains.

Levels of Specialization of Concepts

The domain specific concepts developed directly from the foundation ontology lack the required level of interoperability. The design and production concepts can be directly specialized from very generic foundation ontology concepts. Foundational concepts enable knowledge sharing only through a level having nothing to do directly with either design or production. Some intermediate concepts are required in addition which are more concerned with the product lifecycle and its sub domains. Design and production layers of concepts can have a common underlying layer which can provide the route to interoperability and knowledge sharing at a more specialized level. Since the layers above the foundation ontology contain concepts relatively more specialized they provide a common base for interoperability at a more specialized level. Each intermediate level of concepts has a higher degree of specialization with concepts closer to the specific domain. Each level acts as a semantic base for the concepts specialized from that. This gradual specialization of concepts is thus required for providing a route to share knowledge at more specialized levels. Various levels are required to specialize concepts from the foundation to the specific domains. As shown in fig. 2 the number of levels identified in this research work are three [20] based on the degree of specialization required.

Fig 2 summarizes the manufacturing core concepts ontology and its application. It shows two main layers. The bottom layer represents MCCO. While the top layer represents the implementation and evaluation. MCCO at the bottom layer with its three levels of specializations. Top Layer represents the interoperable specialized ontologies and knowledge bases (KB) developed from MCCO. This layer may contain some further specialized concepts according to requirement. The Interoperability across design and production has been tested by querying the relevant knowledge between the two domains. The exploration of core concepts and their relations in MCCO is vital for the successful implementation.

Generic Core Concept Level

This level is to provide a link of product lifecycle concepts to other domains like business domain etc if required. These concepts are more specific as compared to foundational concepts like entity, event, quality, quantity etc. Concepts like activity, activity occurrence, feature, dimension, tolerance, part, part family etc, are present in this level. These concepts are applicable to any domain.

Product Lifecycle Generic Core Concept Level

A set of concepts generic to the product lifecycle domains are also required to act as a common level for the specific product lifecycle domains like design and production. Product lifecycle generic concepts are specialized from generic concepts and are applicable to any of the specific product lifecycle domains like design and production but not outside product lifecycle. Concepts like ProductFeature, ProductPartFamily, GeometricDimensions, GeometricTolerance, are some of the product lifecycle generic concept level.

Product Lifecycle Domain Specific Core Concept Level

This contains concepts specific individually to each product lifecycle domains like design and production. Concepts like ProductionFeature and ProductionPartFamily' are production specialization of product lifecycle generic concepts. Similarly DesignFeature' and 'DesignPartFamily' are design specializations of product lifecycle generic concepts. The design and production concepts can either be used directly for capturing knowledge or can be further specialized to develop customized ontologies.

An Example of Concepts Specialization

Specialization of concepts is not a simple process. Most specializations of concepts require other concepts, relations, function and rigorous rules & axioms. The three specialization levels have been elaborated by taking the Feature concept and showing its journey through the levels. The formalization of definitions, knowledge capture and sharing are also demonstrated. It is appropriate to use Feature as this is one of the key concepts for interoperability and has simpler relations and axioms. Moreover, the ontology is developed more with respect to Feature.

Increasing level of specialization

Feature concepts start from the generic "Feature" concept. Feature as defined in oxford dictionary is "a distinctive attribute or aspect of something". So 'Feature' is defined as "anything having an attribute of interest". Feature is at the generic level of the ontology. Feature thus can be the dark hair of a person, or the ability of a person to run fast etc. The Feature in the product lifecycle domain will have some form or shape. This leads to the specialization of Feature as a FormFeature which should have a Form as its AttributeOfInterest. A FormFeature may be associated to a Product. The FormFeature thus gets specialized in to a product feature where it has an associated product. The domain specific concepts DesignFeature and ProductionFeature can be direct specializations of from form or product feature. So, Design Feature is a product/form feature having function as a compulsory attribute of interest and ProductionFeature is a ProductFeature / FormFeature having ManufacturingMethod as an AttributeOfInterest. The concept of StandardFeature is generic to both design and production which is a ProductFeature / FormFeature having both ManufacturingMethod and a Function as attributes of interest.

Formalization of Concepts

To formally define concepts, control their use, capture knowledge and populate facts, heavyweight logic is embedded in MCCO. Common logic (ISO/IEC 24707:200) based Knowledge Frame Language (KFL) provided by Highfleet is used for heavyweight formalization. Axioms and rules are there at all levels of MCCO. The more generic the concepts the lesser the number of constraints on them and the higher is the level of interoperability. The formalization of Feature concept and its specializations in KFL are elaborated.

First of all the concepts and relations are declared in the ontology e.g. the concepts 'feature' and 'AttributeOfInterest' and relation hasAttributeOfinterest which relates a feature to its attribute are declared in ontology for defining feature. Similarly specializations of feature i.e. FormFeature, ProductFeature, DesignFeature, ProductionFeature and their respective attributes of interest Form, Product, Function, ManufacturingMethod, along with their key relationships are declared in MCCO.

The declaration of concepts, relations and functions is followed by the most important part of formalization i.e. Axiomatization, which makes the ontology heavyweight. Rules and axioms have been divided in two parts i.e. 'Semantic Rules' and 'Knowledge Rules'. Semantic Axioms formally capture and control the meanings of terms. They are subdivided into 'Defining Axioms' and Controlling Axioms'. Defining Axioms formally capture the definition of concepts e.g. to capture the definition of Feature following axioms is embedded in ontology.

(=> (Feature ?f)(exists(?AOI) (and (AttributeOfInterest ?AOI) (hasAttributeOfInterest ?f ?AOI))))

:IC hard "Feature has an Attribute of Interest"

The above axiom means in simple English "if there is a feature ?f then there has to exits an attribute of interest ?AOI related to feature by the relation hasAttributeOfInterest". This captures formally the definition of feature and puts it as a hard integrity constraint (IC) in MCCO. This would prevent loading any feature without its attribute of interest. Similarly definitions of all specializations of feature i.e. FormFeature at generic level, ProductFeature at product lifecycle level and StandardFeature, ProductionFeature & DesignFeature at domain specific levels can be captured. Other type of semantic axioms and rules i.e. 'Controlling Axioms' are similar and they make the facts assertion fool proof in accordance with formal definitions e.g. a ProductionFeature cannot be asserted with function as its attributes of interest as it belongs to DesignFeature and similarly a DesignFeature cannot have a ManufacturingMethod as its AttributeOfInterest.

Knowledge rules are divided into two parts as well. The first type is 'knowledge capturing rules' which formally capture the actual domain specific knowledge e.g. the rule below captures the knowledge relating NeckWidth parameter of a feature and the CuttingTool available to machine that and places it as a soft IC. This IC fires and warns the designer whether the value of NeckWidth is out of range with respect to available CuttingTool. The facts are still populated because soft ICs are there to warn only.

(=>(and(Groove ?g) (NeckWidth ?n) (hasParameter ?g ?n) (hasValue ?n (mm ?r1))) (inInterval ?r1 (interval in 8 12 in)))

:IC soft "NeckWidth value is out of range (8mm to 12mm) for machining with standard tooling"

The second of the knowledge rules types i.e. 'Inference rules' make the inference of facts from the already loaded facts e.g. A StandardFeature has both function and ManufacturingMethod as its attribute of interest. Therefore, it has both DesignFeature and ProductionFeature in it, and they should be inferred whenever a StandardFeature is asserted in knowledge base. The rule below does exactly that when a StandardFeature is asserted in knowledge base. In simple English the above rule implies: if there is a StandardFeature ?sf, having Function ?f and Form ?fm as its attributes of interest then infer a design feature 'DesignFeaturefor' having same Function and Form as those of StandardFeature.

Experimental Validation of the MCCO

The experimental implementation of MCCO is focused on the critical concepts and their relationships, on the basis that if these can be rigorously defined the rest of MCCo will be straight forward to implement. MCCO is loaded in the Integrated Ontology Development Environment (IODE). The following aspects of ontology have been tested: 1. Capturing of semantics, 2. Controlling concepts, 3. Capturing Domain Knowledge 4. Inferring Knowledge 5. Route to knowledge sharing through MCCO.

Testing Definition and Specialization of Feature Concepts

This experiments test the assertion ProductionFeature. This verifies two things: 1. Definition of ProductionFeature has been captured, 2. ProductionFeature FormFeature is indeed a specialization of ProductFeature which is a specialization of FormFeature which is a specialization of Feature.

According to the definition, a ProductionFeature has a ManufacturingMethod as its AttributeOfInterest. First the ProductionFeature is asserted without ManufacturingMethod to test the definition. As shown in fig 5 the assertion has been cancelled. The IC cancels the assertion and notifies the user that a ManufacturingMethod may be defined for it. But this is not the only IC which has fired. ICs from generic concepts Feature and FormFeature as well of product lifecycle generic concept ProductFeature have also fired. This is due to the specialization.

A ProductionFeature inherits ICs from all three levels of specialization.

ProductionFeature is specialized from the product lifecycle generic concepts ProductFeature which is specialized from the generic concept FormFeature which in turn is specialized from the generic concept Feature. After that a production feature is asserted with ManufacturingMethod 'TurningA' as its AttributeOfInterest, 'ProductA' as its associated Product, and 'FormA' as its other AttributeOfInterest. The assertion is accepted as shown in fig 6. This is because all the ICs coming from all three levels have been taken care of and the assertion satisfies all of them. This shows that the definition of ProductionFeature has been successfully captured. Firing of ICs from all levels confirms the integrity driven specialization of concepts at different level.

Conclusion

The focus of the work is to provide an ontological foundation for sharing manufacturing knowledge across production design and production. However, the underlying technological base can provide an understanding of production quality, cost and timescales. This has a potential to provide further linkages to a business perspective. This approach does not ensure full interoperability but it does ensure the understanding of the extent to which interoperability is possible. A core set of concepts has been formally defined in MCCO and these concepts have been used to capture as well as share production knowledge. Three different levels of specialization i.e. generic, product lifecycle generic and domain specific level have been identified for MCCO. Feature concepts have been successfully specialized at the three levels and other concepts in MCCO are being specialized. The behaviors of concepts have been controlled. Knowledge has been captured and inferred successfully using core concepts and the expressive power of common logic. The ability of core concepts to provide a route to communicate, identify and share the knowledge across design and production domains has been demonstrated through the Feature concepts. Future research direction is aimed to explore a more detailed level of Interoperability between design and production features at parametric level. Manufacturing method for features and part families from knowledge sharing context is being explored using a meta-level underpinning. Actual industrial implementation remains to be explored. The formalization of concepts in MCCO which are borrowed from various ISO-standards and encoded in common logic based formal definitions. MCCO can be extended to explore interoperability across other product lifecycle domains like services, operation and disposal.

Fig. 1 .

 1 Fig. 1. Light weight representation of manufacturing core concepts ontology (MCCO): Key categories, concepts and their relationship.

Fig. 2 .

 2 Fig.2. MCCO, its specialization levels and its implementation scheme.

Fig. 3 .

 3 Fig. 3. Feature specializations, lightweight representation.

  Fig 3 shows the lightweight UML representation of feature specializations.

Fig. 4 .

 4 Fig. 4. A portion of MCCO ontology in IODE showing feature and its specializations.

Fig. 5 .

 5 Fig. 5. Asserting a production feature without manufacturing method.

Fig. 6 .

 6 Fig. 6. ProductionFeature asserted with all its AttributesOfInterest and associated Product.

Fig. 7 .

 7 Fig. 7. Route to knowledge sharing and inferred facts.

6 . 2

 62 Testing Inference of Knowledge and Route to Knowledge Sharing A sample of DesignFeature, ProductionFeature and StandardFeature facts have been asserted in the KB having a common form. A query is run find out the DesignFeature and ProductionFeature as well as StandardFeature having common form. As shown in fig 7 Form 'CirGroove' is the common form for all feature facts. Once a ProductionFeature with common a Form as that of a DesignFeature is identified, the knowledge about the ProductionFeature can be queried and fed back to the DesignFeature with the same form. Common form comes from FromFeature thus the concepts Form and FormFeature provided the route to interoperability between design and production features. The DesignFeature 'DesignFeaturefor StdGroove' and ProductionFeature 'ProductionFeaurefor StdGroove' are inferred from the StandardFeature StdGroove. So this also showed that knowledge can be inferred automatically using MCCO rules and axioms.

Acknowledgments. This research work is funded by the Innovative Manufacturing and Construction Research Centre (IMCRC) under the Interoperable Manufacturing Knowledge Systems (IMKS) project (IMCRC project 253). The authors would also like to thank the research team in IMKS project for their support and cooperation.