EP1305746A2 - Systeme d'information base sur l'ontologie - Google Patents

Systeme d'information base sur l'ontologie

Info

Publication number
EP1305746A2
EP1305746A2 EP00957598A EP00957598A EP1305746A2 EP 1305746 A2 EP1305746 A2 EP 1305746A2 EP 00957598 A EP00957598 A EP 00957598A EP 00957598 A EP00957598 A EP 00957598A EP 1305746 A2 EP1305746 A2 EP 1305746A2
Authority
EP
European Patent Office
Prior art keywords
engine
model
recited
information system
interaction flow
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP00957598A
Other languages
German (de)
English (en)
Inventor
Lisa C. Hammitt
Jörg BECKERT
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
6100198 Canada Inc
Original Assignee
Black Pearl Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Black Pearl Inc filed Critical Black Pearl Inc
Publication of EP1305746A2 publication Critical patent/EP1305746A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions

Definitions

  • the present invention relates generally to computers and, more particularly, to an ontology-driven information system.
  • the web Since the development of the Internet's World Wide Web (“the web”), the number of companies engaged in electronic commerce (“e-commerce”) has steadily increased. Indeed, companies now offer a multitude of products and services online. By conducting business on the web, companies can decrease operational costs and expedite business activities.
  • the web is also an effective medium for presenting information to and gathering information from customers.
  • an e-commerce system should provide the following functionality.
  • the system must access data that is distributed across numerous sources and react to events coming from numerous sources.
  • the data may reside in relational database management systems (RDBMSs), flat files, and large-scale packaged applications.
  • the events may come from Internet feeds, news services, and e-commerce systems (exchanges).
  • the events may come from event-based Internet middleware.
  • the system must analyze the distributed data and transform such data into an intelligent, personalized recommendation in real time. If the analysis is not conducted in real time, then the customer will have to wait for the intelligent, personalized recommendation. Any significant delay, e.g., a few minutes, decreases the likelihood that the customer will act on the recommendation.
  • the system must accommodate frequent changes in business conditions. In particular, it must be easy to change the business rules and business processes used to transform the data into the intelligent, personalized recommendation. If the business rules and business processes cannot be easily changed, then the system will not be able to keep up with the way the company is doing business.
  • existing e-commerce systems do not provide the above-described functionality.
  • One known e-commerce system generates personalized recommendations by matching business rules against customer attributes, e.g., age group, geographic region, and buying history. In this e-commerce system, however, it is difficult to change the business rules to adapt to changing business conditions. To illustrate this point, examples of the business rules used in this system are shown below:
  • Rule Nos. 1 and 2 must be changed to reflect the new business conditions. For example, consider a situation in which market analysis shows that the age group breakdowns in Rule Nos. 1 and 2 should be changed from 18-30 years old and 31-50 years old to 18-34 years old and 35-50 years old, respectively. To implement this change, it would be necessary to change each occurrence of "18-30 years old” to "18-34 years old” and to change each occurrence of "31-50 years old" to "35-50 years old.” As there are only two business rules in this simplified example, making the required changes is not a major undertaking.
  • Another example of changing business rules is the occurrence of additional context that requires that a different result be implemented when a given rule is satisfied.
  • the system may be required to incorporate a customer's purchase history to formulate an intelligent recommendation.
  • a customer's purchase history By way of example, if a customer has recently purchased a tent, then a recommendation suggesting that the customer purchase a tent would normally not be considered to be an intelligent recommendation.
  • an e-commerce system that analyzes distributed data and transforms such data into intelligent, personalized recommendations in real time using flexible business rules that can be easily adapted to ever-changing situations.
  • the present invention fills this need by providing an information system that transforms raw data from disparate sources into intelligent, personalized recommendations that may be used to drive business transactions.
  • an ontology-driven information system includes a plurality of models, each of which expresses an aspect of a business domain using concepts and relationships between concepts.
  • An ontology which is in communication with each of the plurality of models, provides uniform definitions for the concepts and relationships between concepts used in the plurality of models.
  • the use of the uniform definitions in the plurality of models avoids redundancy in the models, provides consistency between the models, and enables the plurality of models to provide an overall model of the business domain that is more expressive than an overall model based on a plurality of models that does not use uniform definitions.
  • the uniform definitions in the ontology can be changed on the fly by a business manager.
  • a method for executing an interaction flow model includes receiving a plurality of events and categorizing the received event events. Once the events are categorized, a situation that matches the categorized received events is identified. One or more tasks are then executed for the situation. The execution of the one or more tasks can include either an interpretation of a model (e.g., a rule base) or the execution of a method of an object.
  • a model e.g., a rule base
  • an information system is provided.
  • the information system includes a user and application interface and a reasoning engine that is in communication with the user and application interface.
  • the system further includes a knowledge manager that is in communication with the user and application interface and is interfaced with the reasoning engine.
  • a distributed information service also is in communication with the reasoning engine, the knowledge manager, and the user and application interface.
  • the reasoning engine may be configured to work in conjunction with the knowledge manager to enable the reasoning engine to handle events by executing one or more specific tasks prescribed by the knowledge manager to handle the events most appropriately.
  • the knowledge manager includes an interaction flow model that is a repository for abstract situations to handle the events received by the reasoning engine, with the situations defining the one or more tasks that are to be executed by the reasoning engine.
  • the information system includes a reasoning engine and a knowledge manager.
  • the reasoning engine may be configured to derive a set of conclusions using a set of premises and to execute actions that are attached to the set of conclusions.
  • the set of premises may be encoded using a plurality of models.
  • the knowledge manager serves as a repository of the plurality of models. Each of the plurality of models is configured to define situations that occur in decision making to achieve a goal state.
  • the knowledge manager includes an ontology, which is a collection of concepts and contexts used to provide a common vocabulary for defining rules, querying disparate data sources, and making actionable recommendations. As such, the ontology provides consistency between the plurality of models.
  • a computer readable media having program instructions for executing an interaction flow model.
  • the computer readable media includes program instructions for receiving an event (or a plurality of events), program instructions for categorizing the received events, program instructions for identifying a situation that matches the categorized received events, and program instructions for executing one or more tasks for the situation.
  • the execution of the one or more tasks includes one of an interpretation of a model and execution of a method of an object.
  • the information system of the invention enables e-market participants to apply business rules to data captured from disparate sources, e.g., existing enterprise databases and the Internet, to match buyers' interests with sellers' expertise taking into account goals, preferences, behaviors, and market context.
  • the information system provides more accurate and timely recommendations that increase the likelihood that a transaction will occur at the moment of contact.
  • Such accurate and timely recommendations also increase customer satisfaction and thereby reduce customer attrition.
  • Another advantage of the information system is that it uses business rules that are constructed using ordinary terms that can be changed on the fly by a non- technical business user. This helps reduce maintenance costs and increase responsiveness.
  • Figure 1A is a schematic diagram illustrating the functionality of an ontology- driven information system in accordance with one embodiment of the invention.
  • Figure IB is a block diagram showing the data exchange architecture of an ontology-driven information system in accordance with one embodiment of the invention.
  • Figure 2 is a block diagram showing the major submodules of an information system in accordance with one embodiment of the invention.
  • Figure 3 is a block diagram showing the submodules of a user and application interface in accordance with one embodiment of the invention.
  • Figure 4A is a block diagram showing the submodules of a reasoning engine in accordance with one embodiment of the invention.
  • Figure 4B is a block diagram showing the submodules of a knowledge manager in accordance with one embodiment of the invention.
  • Figure 5 is a block diagram illustrating the interaction flow between the knowledge manager and the reasoning engine in accordance with one embodiment of the invention.
  • Figure 6 is a block diagram showing the submodules of a distributed information service in accordance with one embodiment of the invention.
  • FIG 7 is a block diagram showing additional details of storage system 16c shown in Figure 6 in accordance with one embodiment of the invention.
  • Figure 8 is a detailed flowchart diagram illustrating the method operations performed in generating a recommendation for a user in accordance with one embodiment of the invention.
  • Figure 9 is a graph illustrating a method for obtaining particular meanings for generalized concepts in accordance with one embodiment of the invention.
  • Figure 10 is a directed acyclic graph illustrating a method for obtaining particular meanings for generalized concepts in accordance with another embodiment of the invention.
  • FIG. 1A is a schematic diagram 2 illustrating the functionality of an ontology- driven information system in accordance with one embodiment of the invention.
  • Knowledge BrokerTM ontology-driven information system 10 receives data from disparate sources including, by way of example, the World Wide Web ("the web") 3, mainframe computer 4, relational database management system (RDBMS) 5, and live wire feeds 6.
  • Information system 10 combines the disparate data with business rules 7, which may be formulated by business managers 8, and intelligence to produce personalized product and service recommendations 9 for an end user, e.g., a customer, at the moment of interaction, i.e., in real time.
  • Personalized product and service recommendations 9 may be transmitted to the end user via computing device 28, which is connected to a network.
  • computing device 28 may be a personal computer (desktop or laptop), a personal digital assistant (PDA), a handheld device, e.g., a wireless phone or other suitable wireless device having a processor and a memory.
  • the network connection may be to the Internet, an intranet, a WAN, a LAN, or a wireless network.
  • Figure IB is a block diagram showing the data exchange architecture of information system 10 in accordance with one embodiment of the invention. As shown therein, information system 10 includes reasoning engine 12, knowledge manager 14, distributed information service (DIS) 16, user interface (UI) and application programming interface (API) 18 (also referred to herein as the user and application interface), and Java 2 Platform Enterprise Edition (J2EE) 20.
  • DIS distributed information service
  • UI user interface
  • API application programming interface
  • J2EE Java 2 Platform Enterprise Edition
  • User and application interface 18 is configured to enable information system 10 to perform the functions of transforming raw data into information, transforming information into knowledge, and delivering the knowledge to the end user or taking appropriate action or actions based on the knowledge.
  • user and application interface 18 provides the functionality by which external actors cooperate with information system 10.
  • the external actors may be either users or applications, e.g., client application 22.
  • the user interface is primarily targeted at interaction with users of information system 10.
  • the application programming interface deals with numerous inbound and outbound content channels 24, which communicate with computing devices 28.
  • Such computing devices 28 can implement any number of communication protocols such as, for example, Internet browsers, e.g., HTTP and HTML, wireless application protocol (WAP), wireless markup language (WML), e-commerce systems (exchanges), voice interaction systems, e.g., IVR, and third party applications, e.g., J2EETM Enterprise Java Beans (EJB) and web applications. Additional details of user and application interface 18 are set forth below with reference to Figure 2.
  • communication protocols such as, for example, Internet browsers, e.g., HTTP and HTML, wireless application protocol (WAP), wireless markup language (WML), e-commerce systems (exchanges), voice interaction systems, e.g., IVR, and third party applications, e.g., J2EETM Enterprise Java Beans (EJB) and web applications. Additional details of user and application interface 18 are set forth below with reference to Figure 2.
  • Distributed information service 16 interacts with database 24, enterprise information systems (EIS) 26, and other resource managers (not shown).
  • EIS enterprise information systems
  • distributed information service 16 uses J2EE specified contracts to interact with these components.
  • database 24 includes one or more relational database management systems (RDBMS). Additional details of distributed information service 16 are set forth below with reference to Figure 6.
  • RDBMS relational database management systems
  • Figure 2 is a block diagram showing the major submodules of information system 10 in accordance with one embodiment of the invention. These submodules include reasoning engine 12, knowledge manager 14, distributed information service 16, and user and application interface 18, which is described in detail below with reference to Figure 3.
  • Reasoning engine 12 provides the functionality that is required to process business rules, process constraints, and execute processes. To this end, reasoning engine 12 derives a set of conclusions that are entailed by a given set of premises (and facts) and executes actions that are attached to the conclusions, which may be either partial or complete. A variety of models are used to encode the premises.
  • An ontology which is described in more detail later, forms a common thread between the models used to encode the business rules, constraints and processes by expressing concepts that are used in various models, such as, for example, a rule base.
  • Reasoning engine 12 communicates with distributed information service 16 and user and application interface 18 through architected contracts.
  • An architected contract is a special form of interface that provides a much richer form of coupling between modules or submodules with defined roles.
  • reasoning engine 12 uses the interfaces of knowledge manager 14. Additional details of reasoning engine 12 are set forth below with reference to Figures 4 A and 5.
  • Knowledge manager 14 provides the functionality that is required to store and manipulate ontologies and other models of a domain.
  • knowledge manager 14 maintains concepts and relationships to construct business rules, constraints, and processes.
  • Business models use these rules, constraints, and processes to capture knowledge about a specific business domain. This knowledge may be used to reason about the domain and to derive actions to achieve stated goals.
  • the use of concepts and relationships provides a higher abstraction on which business models can be built. This is advantageous because it enables the business models to be built more efficiently and to be managed more easily.
  • Knowledge manager 14 communicates with distributed information system 16 and user and application interface through architected contracts. Additional details of knowledge manager 14 are set forth below with reference to Figures 4B and 5.
  • Distributed information service 16 provides the functionality that is required to access heterogeneous, distributed data sources.
  • distributed information service 16 is a collection of services that shield other modules of information system 10, as well as external applications, from the details of accessing disparate information resources.
  • distributed information service 16 provides a uniform and simple way to access these information resources.
  • Each information resource may be accessed via a Uniform Resource Identifier (URI), which is a logical name that hides the location and the access protocol from the resource consumer.
  • URI Uniform Resource Identifier
  • Distributed information service 16 manages a repository of information about the resource and uses that information to locate the external resource manager, to establish a connection with the resource manager, and to interact with the resource manager to, e.g., store and retrieve data.
  • Distributed information service 16 communicates with reasoning engine 12, knowledge manager 14, and user and application interface 18 through architected contracts. Additional details of distributed information service 16 are set forth below with reference to Figure 6.
  • FIG. 3 is a block diagram showing the submodules of user and application interface 18 in accordance with one embodiment of the invention.
  • user and application interface 18 includes system administration interface 18a, application deployment interface 18b, business modeling interface 18c, application object system 18d, and delivery channel interface 18e.
  • the first three submodules, i.e., submodules 18a-18c, are used primarily during design, deployment, and setup of a solution, whereas the latter two submodules, i.e., submodules 18d and 18e, are used primarily at runtime.
  • the architecture of user and application interface 18 is based on three technologies: Java Components, XML-based access protocols, and Business Model Languages.
  • Java Components are Java objects that offer an interface to call methods, which implement or make accessible the functionality provided by information system 10. These components may be implemented using EJB, which is the standard component model for Java. Suitable XML-based access protocols include, but are not limited to, 1) HTTP with HTML or a specific XML content format, and 2) JMS with specific XML content format.
  • the Business Model Languages deal with the capturing of knowledge that is entered into the system by a business user. This component of user and application interface 18 is concerned with representing the business rules, processes, and constraints that form a model of the business.
  • User and application interface 18 provides components to access services that are implemented in other modules, e.g., the distributed information service.
  • the intrinsic functionality of user and application interface 18 also may be accessed via components.
  • the term "component” refers to an object that provides access to data or logic or assembles data or logic. Thus, the data or logic need not be implemented by the component.
  • this remote client may be a browser or another application.
  • the interface components may be implemented as EJB components. These components, which provide access for multiple remote clients where each client is isolated from the activity of other clients, encapsulate the state of a client session.
  • system administration interface 18a contains commands to configure the resource environment and to monitor running services. As such, system administration interface 18a provides the functionality that is required to let a user enter resource naming and location information. Each information collection that can be retrieved from information system 10 can be specified using a Uniform Resource Identifier (URI), which is mapped and located by distributed information system 16, as described in more detail below.
  • URI Uniform Resource Identifier
  • Table 1 illustrates exemplary commands contained in system administration interface 18a.
  • Add (add a connector, e.g., Oracle JDBC driver)
  • Application deployment interface 18b is the process that configures a specific application for its runtime environment.
  • Table 2 illustrates exemplary commands contained in application deployment interface 18b in accordance with one embodiment of the invention.
  • Verify (test if a connection can be established)
  • Extract import the schema from a given external data source
  • Create create a schema in a given external data source
  • Verify test whether a given schema is equal to the schema of a given data source
  • Show retrieve the objects that are part of the schema (type definitions, elements, attributes)
  • Business modeling interface 18c is concerned with the creation and management of business models.
  • business models include rule bases and business process flows.
  • Business modeling interface 18c serves as the entry point into information system 10 for business personnel, e.g., business line or marketing campaign managers, and provides the functionality that is required to enable these users to enter business rules, constraints, and processes.
  • business modeling interface 18c implements the abstract commands shown in Table 3. Table 3
  • Application object system 18d allows an application to interface with information system 10 using Java objects of the modeled domain.
  • Information system 10 uses the application schema to construct these objects.
  • Application object system also is used to integrate information system 10 with tools that support or automate the process of building a graphical representation, e.g., a user interface.
  • the objects that are constructed represent a model of the domain. This model can be used in Model- View-Controller type user interfaces.
  • the model includes objects that are defined in an application schema, e.g., objects such as Customer, Product, or Offer.
  • the objects of the domain model preferably comply with the Java Beans specification. This allows information system 10 to use standard tools to build views and controllers corresponding to the object model.
  • application object system 18d transforms the generic representation of information items into a typed object system.
  • Delivery channel interface 18e provides access to the services provided by information system 10 via communication protocols. This submodule also is concerned with the preparation of the content for display or further processing by a remote client. Delivery channel interface 18e serves as the entry point into information system 10 for end users and provides the functionality that is required to deliver the personalized product and service recommendations.
  • One function of delivery channel interface 18e is to provide mechanisms to extract information from information system 10 in a generic form. These mechanisms stand in contrast with application object system 18d, which represents domain objects as strictly typed Java Beans.
  • Delivery channel interface 18e also enables the exchange of XML data with the information system environment.
  • any software system e.g., middleware, that is able to process XML-structured data and supports one of the channel protocols can communicate with information system 10.
  • Every information set that can be retrieved from information system 10 can be specified using a Uniform Resource Identifier (URI).
  • URI Uniform Resource Identifier
  • URLs Uniform Resource Locators
  • Information system 10 maintains a repository of resource references and locates the resources based on the URI. As will be described in more detail below, a URI is mapped and located by distributed information service 16.
  • information system 10 supports a number of communication protocols.
  • Delivery channel interface 18e allows further protocols to be added.
  • the HTTP/HTTPS protocol family with the following content formats is supported initially: SOAP (Simple Object Access Protocol); WML (Wireless Markup Language); and HTML (the World Wide Web protocol). All of these protocols use some specific form of XML as the data content format.
  • Delivery channel interface 18e also provides components that encapsulate particular services of information system 10. These components, which belong to a special system domain, are used to access information and recommendations from generic applications. They do not implement the functionality but rather delegate the requests to the specific modules. Examples of such components include the interaction flow engine and the distributed information service, both of which are described in detail below.
  • Figure 4A is a block diagram showing the submodules of reasoning engine 12 in accordance with one embodiment of the invention.
  • reasoning engine 12 includes interaction flow engine 12a, categorization engine 12b, inference engine 12c, constraint satisfaction engine 12d, optimization engine 12e, and data mining engine 12f.
  • reasoning engine 12 provides the functionality that is required to process business rules, constraints, and processes.
  • "processes" refers to business interactions with external users and systems.
  • reasoning engine 12 is the processing core of information system 10.
  • Interaction flow engine 12a drives the reasoning process and uses specialized engines, which may be called from the interaction flow engine, to extend its capability to interpret models.
  • Each of specialized engines 12b- 12f interprets a partial model of the overall model.
  • Interaction flow engine 12a also provides hooks to call out to engines other than those shown in Figure 4A.
  • the number and type of engines that may be used in information system 10 is not limited to the engines shown in Figure 4A.
  • each engine that is part of reasoning engine 12 acts upon its own model.
  • a "model” is a representation of an aspect of the business domain. The engine and the models are tuned to one another, thereby providing an efficient way to describe a part of the business domain and to perform efficient reasoning on the model.
  • “reasoning” refers to the process of reaching conclusions based on a formal representation of the domain, e.g., a model, and an inference procedure.
  • Reasoning engine 12 reacts to changes in the information system environment by use of user and application interface 18 and the distributed information service 16. These modules act as the sensors and actors to the outside world.
  • Interaction flow engine 12a provides the functionality that is required to coordinate the usage of external data, ontologies, business rules, business constraints, and optimization parameters. As indicated above, interaction flow engine 12a invokes specialized engines that are able to interpret specialized models. In a given business context, interaction flow engine 12a generates a set of candidate recommendations, e.g., goods, services, or information, based on a customer profile and a set of business rules and constraints. The customer profile may reflect the customer's interests and the business rules and constraints may reflect the business' expertise and goals. Interaction flow engine 12a then prescribes the collection of feedback at the time when the interaction happens. Interaction flow engine 12a may further specify that the recommendations be optimized based on the feedback and other contextual information, the optimization models, and further business rules. It will be apparent to those skilled in the art that, because the process flow is model driven, other business interactions may be specified easily.
  • Interaction flow engine 12a uses an interaction model to drive the recommendation process. This interaction model is described in more detail below (see the description of interaction flow model 14a set forth below with reference to Figure 4B). Interaction flow engine 12a communicates with distributed information service 16 through an architected contract. In particular, interaction flow engine 12a invokes methods of arbitrary Java objects. These Java objects are located using the services of distributed information service 16. Furthermore, interaction flow engine 12a uses the interfaces of inference engine 12c, constraint satisfaction engine 12d, and optimization engine 12e.
  • Interaction flow engine 12a is responsible for initiating actions based on the precepts of the environment.
  • the general execution principle is as follows:
  • interaction flow engine 12a invokes categorization engine 12b, which, as described in more detail below, classifies events and other available and relevant information (e.g., user input and information stored in a database).
  • Categorization engine 12b determines a set of categories for events that have occurred. A preceding situation that has been dealt with is an event. Further, the categorization engine 12b determines a set of categories for information entities that are stored in a database and that are relevant for classifying a situation.
  • a situation action is selected and the associated actions are executed.
  • the actions may be the interpretation of a model (one of the built-in actions) or the execution of a method of an object.
  • Model- related actions include, for example, infer, search with constraints, interact, optimize, decide, etc.
  • a situation can describe multiple alternatives and loops.
  • the "decide" action describes a branch in the flow.
  • Step 1) is similar to identifying the state in a classic workflow engine.
  • the process of situation identification is, however, more powerful than simple state-transition models because it takes into consideration that the flow is interrupted after a situation is dealt with. Even if the situation prescribes the transition into a follow-up situation, as states do when the transition into a new state is made, the new situation does not occur unconditionally. It also is not deterministic when the following situation occurs. Often it depends on when and what feedback the user provides.
  • Interaction flow model 14a may specify the usage of another model, e.g., a rule base, to evaluate what situation most appropriately reflects the real world situation.
  • Interaction flow engine 12a uses distributed information service 16 (see Figure 2) to locate a Java object that is an information resource. Interaction flow engine 12a need only provide a Uniform Resource Identifier (URI) to distributed information service 16 to locate the Java object. Distributed information service 16 manages the additional information that is needed to look up the desired object and does the lookup for interaction flow engine 12a.
  • Categorization engine 12b provides the functionality that is required to categorize objects, which can be information entities or events.
  • An information entity may be stored in an external system or sent to information system 10 using one of the interfaces. Events may be created in storage systems or an application, or may be delivered via one of the channel interfaces.
  • Categorization engine 12b uses the properties and relationships of a concept to test the membership. The properties and relationships of a concept are defined in conceptual model 14c, which is described in more detail below with reference to Figure 4B.
  • Categorization engine 12b may use a number of techniques to perform classification, which include, but are not limited to, property value testing, exemplar approximation, and probabilistic techniques.
  • Categorization engine 12b may receive requests for categorizations from interaction flow engine 12a and inference engine 12c. In addition, categorization engine 12b uses the interfaces of conceptual model 14c (see Figure 4B).
  • Inference engine 12c which also may be referred to as a rule engine, provides the functionality that is required to perform logical inference.
  • “Logical inference,” which is sometimes referred to as deduction, is the process of deriving conclusions that are entailed in a set of rules and a set of facts known to be true.
  • a "rule” is a pair of premise or antecedent and conclusion or consequent.
  • a set of rules, e.g., a rule base is compiled into an efficient form for execution by inference engine 12c.
  • the entailment relation over a set of rules and a set of facts is computed. The inferred knowledge is useful only if it helps to take actions.
  • Constraint satisfaction engine 12d provides the functionality that is required to search for states in the state space that satisfy a number of constraints and the goal test. Thus, constraint satisfaction is a modified search problem and constraint satisfaction engine 12d is a special kind of search engine.
  • states are instances of concepts. Constraints can be either absolute or preferences. Violation of an absolute constraint rules out a potential solution. In the case of preferences, one solution is preferred over another.
  • Constraints may be dynamically inferred by inference engine 12c or taken from a profile or constraint base, which is managed in constraint model 14e (see the description of constraint model 14e set forth below with reference to Figure 4B).
  • a set of constraints e.g., a constraint base
  • constraint satisfaction engine 12d uses the interfaces of inference engine 12c, constraint model 14e (see Figure 4B), and query service 16e (see Figure 6).
  • An example of a constraint satisfaction problem is the search for products that match certain criteria.
  • the inference engine is invoked first and the inferred concepts and constraints are taken and passed to the constraint satisfaction engine.
  • the inference engine does not search for instances of the concepts. Rather, the inference results are interpreted as constraints by the constraint satisfaction engine.
  • the constraint satisfaction engine now combines the constraints with a search strategy to come up with appropriate instances.
  • the instances may be particular objects such as goods, services, and information.
  • the constraint satisfaction engine may reformulate the constraints into a query that is passed on to the query service in the distributed information service.
  • Optimization engine 12e provides the functionality that is required to find an optimal solution among a number of candidate solutions. Optimization engine 12e is used when a problem may be solved by selecting a solution that is optimal with respect to an optimization criterion. This typically requires that a metric exist. Finding a solution, e.g., a set of products to recommend, by optimization usually leads to more accurate results than simple constraint-bound searching. Optimization engine 12e communicates with distributed information service 16 through an architected contract. The model may be stored in a persistent storage and may be read and modified using distributed information service 16. Furthermore, optimization engine 12e uses the interfaces of ontology 14b, which is described in more detail below with reference to Figure 4B.
  • Data mining engine 12f provides the functionality that is required to analyze the correlation in data and to build a predictive model from that correlation. Stated differently, data mining engine 12f implements the functionality to build predictive models.
  • a "predictive model" takes the properties of an instance or a set of instances and produces the value of another property or relationship that is not stored in the external storage systems. By way of example, representative predictions include a person's tax bracket based on income, marital status, and number of children and a person's behavioral cluster based on previous purchases.
  • Data mining engine 12f communicates with distributed information service 16 through an architected contract.
  • Figure 4B is a block diagram showing the submodules of knowledge manager 14 in accordance with one embodiment of the invention.
  • knowledge manager 14 includes interaction flow model 14a, ontology 14b, conceptual model 14c, rule base 14d, constraint model 14e, optimization model 14f, and predictive model 14g.
  • Knowledge manager 14 is the repository for business models, which altogether model situations that occur in complex, real-world, commercial processes and involve decision making to achieve a goal state.
  • One important aspect of the business models is that a software program can derive reasonable actions from such models. Deriving reasonable actions is a special form of reasoning that results in the selection and execution of one or more actions. Many aspects contribute to the business models.
  • each model is a conceptual representation of certain things as they exist or are true in a given domain (propositions).
  • Such a conceptual model is referred to herein as an ontology.
  • the use of an ontology advantageously ensures consistency between different models. To this end, different models that describe aspects of a particular domain may share a common ontology.
  • An ontology managed by information system 10 typically contains multiple concepts and relationships between concepts.
  • the complexity of a business domain is captured mainly in the relationships between concepts because a concept alone is usually too simplistic to be helpful. In contrast, relationships between concepts are potentially very rich.
  • a few fundamental relationships between concepts are found in many ontologies. These fundamental relationships are meronymy, hypernomy, and synonymy.
  • Meronymy is defined between a whole concept and its partial concepts and is called the HAS_A relationship.
  • Hypernomy is defined between a concept and its subconcepts and is called the IS_A relationship. Synonymy exists within a number of terms referring to a concept if one can be used for the other and the meaning would be the same relative to a specified context.
  • Interaction flow model 14a manages multiple interaction flow models, that is it performs operations such as creation, reading, modification, and deletion with these models.
  • An interaction flow includes a number of situations. Each situation has a context description that contains the event concepts that a situation requires in order to occur.
  • An interaction flow is compiled into an efficient form for execution by interaction flow engine 12a (see Figure 4A).
  • Interaction flow model 14a communicates with distributed information service 16 through an architected contract. The model may be stored in a persistent storage and may be read and modified using distributed information service 16.
  • interaction flow model uses the interfaces of ontology 14b. In particular, the meaning of the terms that are used in interaction flow model 14a is defined via ontology 14b. This knowledge may be used in interpreting the model.
  • Ontology 14b of information system 10 serves as the common thread between all other models. For this reason, information system 10 is therefore an ontology-driven information system.
  • an ontology helps to formulate and relate various other knowledge representation models, which usually are based on first order logic or interaction flow. Concrete models typically use a vocabulary.
  • the vocabulary may be made up of words and word phrases of the particular domain. To relate different models, a commitment to the meaning of the vocabulary is needed. If, for instance, one model makes propositions about a "conservative investor," then another model can refer to the same concept and assume the same intention for the concept.
  • Ontology 14b is linked to all of the other models by terms that are used in those models and that are defined in the ontology. Ontology 14b communicates with distributed information service 16 through an architected contract. Each knowledge representation model refers to a conceptualization of the domain.
  • a “conceptualization” is a model that represents the domain as concepts.
  • a “concept” is an abstraction for a set of things. The set also may be called a category or class. The process of assigning a thing to a category is called categorization or classification.
  • a conceptualization gathers relationships between concepts, especially the relationships between concepts and their properties, which also can be concepts.
  • concepts exist independently of the words that are used to denote the concepts. For instance, the concept to which the English noun “bench” refers exists independently of the existence of the English language. Indeed, in the German language the noun “bank” is used to refer to this concept. However, the English noun “bank” refers to a different concept.
  • the relation is indirect because the ontology specifies the intended meaning of a vocabulary in the modeling language. If the vocabulary is used in these models, then the models commit themselves to that meaning. This commitment restricts the models that can be expressed using that modeling language. It also means that different models enter a mutual commitment via the ontology.
  • the various models agree with the meaning of the terms that they use and will not contradict the meaning that is formulated in the conceptualization. The models can and will add more knowledge around the concepts but they do not redefine the terms. For those models, the terms have an inner structure that is solely defined outside of the model. The model would otherwise treat the terms as atoms.
  • An ontology is very closely related to, but not the same as, a conceptualization. Two different ontologies can be linked to the same conceptualization.
  • Conceptual model 14c manages the creation, modification, and deletion of concepts, which form the basis of a conceptual model.
  • a "concept" is represented by a set of properties and relationships. The concept may be named using the ontology. In fact, a concept may have different names in different ontologies.
  • Conceptual model 14c communicates with distributed information service 16 through an architected contract. The model may be stored in a persistent storage and may be read and modified using distributed information service 16.
  • Rule base 14d manages multiple rule bases.
  • a "rule base” is a set of rules that are used together during inference. As described above, a set of rules is compiled into an efficient form for execution by inference engine 12c (see Figure 4A).
  • Rule base 14d is invoked by inference engine 12c, which executes the search inference process.
  • Inference engine 12c is invoked by interaction flow engine 12a, which drives the entire reasoning process.
  • Rule base 14d communicates with distributed information service 16 through an architected contract.
  • the rule base may be stored in a persistent storage and may be read and modified using distributed information service 16.
  • rule base 14d uses the interfaces of ontology 14b. The meaning of the terms that are used in the rule base may be defined via the ontology. This knowledge may be used in interpreting the rules during the inference process.
  • Constraint model 14e manages multiple models that define constraints for search problems. Constraint model 14e contains the preference manager (not shown). As described above, a set of constraints, e.g., a constraint base, is compiled into an efficient form for execution by constraint satisfaction engine 12d (see Figure 4A). Constraint model 14e is invoked by constraint satisfaction engine 12d, which executes the search process. Constraint satisfaction engine 12d is invoked by interaction flow engine 12a, which drives the entire reasoning process. A typical interaction flow involves a search for an object in external storage systems. The search criteria may be formulated during the reasoning process. Often an inference process will produce search criteria. To ensure consistency throughout the reasoning process, constraints can be formulated and stored in a constraint model. Constraints also can be preferences, in which case an implicit ordering over the search results can be expressed.
  • Constraints are an important factor for the outcome of recommendations. In particular, constraints are used to prevent business policies from being violated when recommendations are given. Constraints also can be used to prevent the recommendation of products, e.g., goods, services, and information, that have been rejected during a previous interaction. Constraint model 14e communicates with distributed information service 16 through an architected contract. The model may be stored in a persistent storage and may be read and modified using distributed information system 16. Furthermore, constraint model 14e uses the interfaces of ontology 14b. The meaning of the terms that are used in a constraint model may be defined via the ontology. This knowledge may be used in interpreting the model.
  • Optimization model 14f manages multiple models that define metrics for optimization problems. Suitable metrics include formulas and simple properties of concepts. As described above, an optimization model is compiled into an efficient form for execution by optimization engine 12e (see Figure 4A). Optimization model 14f communicates with distributed information service 16 through an architected contract. The model may be stored in a persistent storage and may be read and modified using distributed information system 16. Furthermore, optimization model 14f uses the interfaces of ontology 14b. The meaning of the terms that are used in an optimization model may be defined via the ontology. This knowledge may be used in interpreting the model.
  • Predictive model 14g manages multiple models that define formulas or values found by data mining engine 12f (see Figure 4A).
  • a "predictive model” describes a functional dependency between one or more properties of one or more instances and a property that is not externally stored.
  • Predictive model 14g communicates with distributed information service 16 through an architected contract.
  • the model may be stored in a persistent storage and may be read and modified using distributed information system 16.
  • predictive model 14g uses the interfaces of ontology 14b. The meaning of the terms that are used in a predictive model may be defined via the ontology. This knowledge may be used in interpreting the model.
  • Figure 5 is a block diagram illustrating the interaction flow between knowledge manager 14 and reasoning engine 12 in accordance with one embodiment of the invention.
  • interaction flow engine 12a is in communication with interaction flow model 14a
  • optimization engine 12e is in communication with optimization model 14f
  • inference engine 12c is in communication with rule base model 14d
  • constraint satisfaction engine 12d is in communication with constraint model 14e.
  • interaction flow engine 12a can communicate with other external applications 13 to execute other tasks.
  • Ontology 14b is in communication with rule base model 14d, optimization model 14f, and constraint model 14e. In this manner, the ontology defines a common thread between the different models.
  • interaction flow engine 12a In response to an event or set of events received from the real world, interaction flow engine 12a initially triggers categorization engine 12b to determine a set of categories for the events that have occurred. In one embodiment, a preceding situation that has been dealt with also is considered an event. Based on the categorized events, a situation action is selected by searching interaction flow model 14a. In one embodiment, the selected situation action obtained from interaction flow model 14a is in the form of a task list. Thus, the task list, which may include one or more tasks, is read by interaction flow engine 12a.
  • the task list includes instructions to interact with each of optimization engine 12e, inference engine 12c, and constraint satisfaction engine 12d. It should be appreciated, however, that there are many scenarios in which only one of optimization engine 12e, inference engine 12c, and constraint satisfaction engine 12d is needed to execute the instructions from the task list.
  • interaction flow engine 12a can communicate with one or more external applications 13 (or external models) to execute the instructions from the task list.
  • the task list may require that inference engine 12c execute an inference for the situation provided by interaction flow engine 12a. Accordingly, inference engine 12c will execute an inference using rule base model 14d.
  • the inference engine provides the functionality that is required to perform logical inference.
  • logical inference is the process of deriving conclusions that are entailed in a set of rules and a set of facts known to be true.
  • a rule is a pair of premise or antecedent and conclusion or consequent.
  • the set of rules may be compiled into an efficient form by rule base model 14d for execution by inference engine 12c.
  • Inference engine 12c passes the result, which is in the form of a number of constraints, to interaction flow engine 12c, which then executes the next task in the task list.
  • the next task in the task list requires that constraint satisfaction be performed.
  • interaction flow engine 12a will pass the number of constraints to constraint satisfaction engine 12d, which also receives compiled constraint model data from constraint model 14e.
  • Constraint satisfaction engine 12d will then perform a search (i.e., execute) to identify a set of objects or solutions (e.g., a set of products or services to be recommended). The set of objects or solutions may then be communicated back to interaction flow engine 12a. In other instances, only one object or solution may be provided. If further refinement within a set of objects or solutions is set forth in the task list, then interaction flow engine 12a passes the objects or solutions to optimization engine 12e.
  • optimization engine 12e will also obtain compiled information from optimization model 14f to execute an optimization model, e.g., an optimization algorithm.
  • the optimal solution may be recorded as an "event" and communicated back to interaction flow engine 12a.
  • optimization engine 12e functions to determine a solution that is optimal with respect to the optimization model. In one embodiment, this requires that a metric exist. Finding a solution, e.g, a set of products, to recommend by optimization leads to more accurate results than simple constraint-bound searching.
  • interaction flow engine 12a may communicate the result to the appropriate receiving module or interface, such as distributed information service (DIS) 16.
  • DIS distributed information service
  • the receiving module may be a message system, the user, a display, a database, or any other type of data receiving, data storing, or data processing object.
  • the number and type of engines contained in reasoning engine 12 may be varied from that shown in Figure 5.
  • interaction flow engine 12 can interact with other business models, applications, or objects.
  • FIG. 6 is a block diagram showing the submodules of distributed information service 16 in accordance with one embodiment of the invention.
  • distributed information service 16 includes naming service 16a, mapping service 16b, storage system 16c, schema manager 16d, query service 16e, and data model 16f.
  • Naming service 16a provides the functionality that is needed to look up information resources.
  • Each information resource has a Uniform Resource Identifier (URI) and naming service 16a manages a name space. Objects that are bound to the name space typically hold additional information that is required to access the represented object. The application is not concerned with providing this information and the information can be changed outside the application, even after the application is completed.
  • URI Uniform Resource Identifier
  • Information resources may be ordinary data entities, i.e., data sets that are stored in external systems, meta data information items, e.g., schema objects, and other suitable management objects, e.g., connectors or data source objects.
  • the implementation of the naming service is provided by the J2EE platform.
  • the J2EE platform requires an implementation of the Java Naming and Directory Interface (JNDI), which is a standard extension of the Java platform.
  • Mapping service 16b provides the functionality that is required to implement aggregated objects whose attributes and relationships come from multiple physical data sources. Mapping service uses the interfaces of naming service 16a, storage system 16c, schema manager 16d (a schema may be stored in an external storage system), and data model 16f.
  • Storage System 16c defines the abstractions that all resource adapters 102a,
  • connection management specifies how connections to external enterprise information systems are created and pooled.
  • Interaction management specifies how operations/statements that retrieve, create, update, and delete data in the specific storage systems are expressed and invoked.
  • Schema management specifies how the schema information that is employed by a storage system is retrieved and manipulated.
  • Data structure representation specifies how data structures, which have been returned from a retrieval operation, are examined and how they are provided for creation and update operations.
  • Transaction management specifies how an application server uses a transaction manager to manage transactions across multiple resource managers. This contract also supports transactions that are managed internal to an EIS resource manager without the necessity of involving an external transaction manager.
  • Security management enables secure access to an information resource, e.g., an RDBMS, a messaging system, or a packaged application. Additional details of storage system 16c are set forth below with reference to Figure 7.
  • Schema manager 16d provides the functionality that is required to create, read, update, and delete schemas. The main purpose of the schema manager is to create application schemas. These schemas are used to communicate the guaranteed structure of information items to other modules and applications, which can programmatically explore, display, and map the structure.
  • Schema manager 16d uses the interfaces of naming service 16a, storage system 16c, and data model 16f.
  • Query service 16e provides the functionality that is required to execute queries that involve multiple physical data sources and schemas.
  • Distributed information service 16 provides a uniform view on aggregated data coming from multiple heterogeneous data sources and, therefore, it is desirable to query that view as if it were a single data source.
  • the query language should be compliant with URI notation.
  • distribution information service 16 makes an information resource available under a URI. To find that information resource, an extended URI syntax, e.g., XPath, which allows selection of specific items along a path, may be used.
  • Query service 16e uses the interfaces of naming service 16a, schema manager 16d, and data model 16f.
  • Data model 16f provides a way to communicate the structure of a data item to its users, e.g., other modules, services, and applications. Thus, the data model is a foundation that is used by many other modules. Data model 16f also makes the values of the data structure accessible via a single API. In one embodiment, the data model uses an interface approach to access the data structures. Interfaces are desirable because they carry only minimal runtime overhead and do not add unnecessary development effort, provided they are small and concise.
  • Data model 16f provides an abstraction for all data structures that are stored in external storage systems.
  • the data model lends itself to the abstract data model that is behind XML documents.
  • the basic entity is an item. Items can have attributes, which have an atomic data type (no visible internal structure). Items also can have relationships with other items. These relationships may be represented as parent-child relationships. This means that each item has at most one parent. Using this relationship, aggregation can be expressed. General associations may be modeled using reference attributes. A "reference attribute" is similar to a Java object reference. Items have names that indicate the type of an item. However, data items do not have to be strictly typed. Although an item may be an instance of a class, it nevertheless can have additional attributes and relationships.
  • FIG 7 is a block diagram showing additional details of storage system 16c shown in Figure 6 in accordance with one embodiment of the invention.
  • the interactions shown in this embodiment illustrate the integration of the ontology-driven information system with the J2EETM Connector Architecture.
  • storage system 16c includes RDBMS connector 104a, XML document connector 104b, WWW connector 104c, MQSeries connector 104d, EJB connector 104e, and 3rd party connector 104f.
  • Storage system 16c communicates with J2EE application server 106 through an architected contract, e.g., the contracts that may be implemented by the application server in accordance with standard J2EE connector architecture, which is available from Sun Microsystems (http://java.sun.com/j2ee/connector).
  • Storage system 16c also communicates with application component 108, which is provided by application object system 18d of user and application interface 18 (see Figure 3), through an architected contract.
  • Application component 108 also communicates with J2EE application server 106 in accordance with an architected contract, e.g., a container/component contract.
  • storage system 16c communicates with an administration component (not shown) provided by system administration interface 18a (see Figure 3).
  • storage system 16c uses the interfaces of naming service 16a, mapping service 16b, schema manager 16d, and data model 16f (see Figure 6).
  • Figure 8 is a detailed flowchart diagram 300 illustrating the method operations performed in generating a recommendation for a user in accordance with one embodiment of the invention.
  • the method begins in operation 302 in which the user's profile is analyzed to ascertain rules to process for the profile.
  • operation 302 may be implemented by classifying the user upon logging in to an ontology-driven information system and displaying an interface that prompts the user as to whether a recommendation is desired.
  • the user may be a customer or a corporate user, e.g., a stockbroker.
  • operation 302 ascertains the rules to process by first determining the concepts associated with the user profile, and then determining the rules associated with those concepts.
  • the method proceeds to operation 304 in which data that meets the criteria of the rules being processed for the profile is found and retrieved.
  • the rules are expressed in terms of generalized concepts, which may have different meanings in different contexts.
  • the data that is found and retrieved in operation 304 includes the specific instances of the generalized concepts that apply to the context of the user.
  • found data that conflicts with the user's preferences is removed.
  • the method then proceeds to operation 308 in which the remaining found data is optimized in order of preference against the context of the user.
  • This optimization operation may be implemented using an appropriate optimization algorithm. In one exemplary embodiment of the invention in which investment recommendations are generated, the Markowitz optimization algorithm may be used.
  • the optimization algorithm generates a set of products or services that optimizes the remaining found data relative to a goal test, which may be defined by the user.
  • the method proceeds to operation 310 in which the optimized data, e.g., a product recommendation, is displayed to the user. If desired, the optimized data may be displayed to the user together with the reason for the selection and the ranking.
  • Operations 302-310 collectively comprise a product recommendation (PR) situation.
  • PR product recommendation
  • the product recommendation situation has reached its terminated state and the method waits for an event to occur before any further action is taken. If the user fails to respond within a predetermined period of time, then an "exit" event is deemed to occur and this exit event is recorded. If the user responds, then a "response” event is deemed to occur and the method proceeds to operations 312-318, which collectively comprise a response situation.
  • the feedback from the response is added to the user's profile.
  • decision operation 314 it is determined whether the product recommendation is selected. If the recommendation is selected, then the method proceeds to operation 316 in which the response situation has reached its terminated state and the method transits to a purchase flow situation. On the other hand, if the product recommendation is not selected, then the method proceeds to operation 318 in which a constraint is added to the user's profile. This constraint is added to the user's profile to avoid providing the user with the same recommendation that was just rejected. Once the constraint is added to the user's profile, the method may cycle back up and wait for another product recommendation situation to arise.
  • situation X may occur when external events indicate that the product recommendation made to the user is no longer valid.
  • external events indicate that the product recommendation made to the user is no longer valid.
  • news that Company A will experience a significant earnings shortfall may render the recommendation no good and thereby give rise to situation X.
  • Figure 9 is a graph 400 illustrating a method for obtaining particular meanings for generalized concepts in accordance with one embodiment of the invention.
  • Graph 400 illustrates an exemplary scenario in which a business has classified its customers into concepts A, B, C, and D, where A is a general customer, B is a customer with high net worth, C is a customer with high risk tolerance, and D is a customer with high net worth and high risk tolerance.
  • the business has two product lines X and Y, with X being recommended stocks and Y being recommended bonds. Within product lines X and Y, additional concepts XI, X2, X3, Yl, Y2, and Y3 are defined.
  • the business implements its selling policy using the following business rules: Rule No. 1 : If A, then recommend X.
  • Universal node 402 is coupled to nodes 412, 412a, 412b, and 412c by arrows 411, 411a, 411b, and 411c, respectively, and to nodes 414, 414a, 414b, and 414c by arrows 413,
  • Nodes 412, 412a, 412b, and 412c indicate concepts X, XI, X2, and X3, respectively.
  • Nodes 414, 414a, 414b, and 414c indicate concepts Y, Yl, Y2, and Y3, respectively.
  • FIG. 10 is a directed acyclic graph 450 illustrating a method for obtaining particular meanings for generalized concepts in accordance with another embodiment of the invention. Directed acyclic graph 450 illustrates the exemplary scenario described above with reference to Figure 9.
  • nodes 402, 404, 406, 408, 410, 412, and 414 shown in Figure 10 is the same as that shown in Figure 9, except that a first class object is disposed between each of the nodes, as indicated by the symbol "O" on each of arrows 403, 405a, 405b, 407, 409, 411, and 413.
  • classification node 406, which indicates concept B is coupled to node 412, which indicates concept X, by contextual arc 452.
  • Classification node 406 is coupled to node 414, which indicates concept Y, by contextual arc 454.
  • Classification node 408, which indicates concept C is coupled to nodes 412 and 414 by contextual arcs 456 and 458, respectively.
  • Classification node 410 which indicates concept C, is coupled to nodes 412 and 414 by contextual arcs 460 and 462, respectively.
  • a first class object is disposed between each of classification nodes 406, 408, and 410 and each of nodes 412 and 414, as indicated by the symbol "O" on each of contextual arcs 452, 454, 456, 458, 460, and 462.
  • the intermediate first class objects disposed between two nodes maintain the relationship between the two nodes.
  • the information regarding the relationship between the nodes would have to be stored in one of the nodes themselves. This is undesirable, however, because it presents complex memory management and programming issues as the system grows and the amount of relationship information stored in the nodes increases.
  • the use of intermediate objects is a powerful solution for at least two reasons. First, the use of intermediate objects avoids the need to store relationship information in the nodes. As a result, the information stored in the nodes may be limited to strings, which the ontology treats as terms. Second, the use of intermediate objects increases the flexibility of the system by enabling additional relationships, e.g., time and precedence, to be defined in the contextual arcs, which the ontology uses to define the relationships between the terms stored in the nodes.
  • nodes 412 and 414 which indicate concepts X and Y, respectively, are overloaded for concepts B, C, and D using the contextual arcs.
  • Rule No. 1 Recommend X.
  • contextual arcs minimizes the number of business rules required to implement a given business policy. By minimizing the number of business rules required, a significant maintenance advantage is obtained because it is easier to manage fewer business rules, as illustrated below.
  • the use of contextual arcs also provides a significant performance advantage.
  • Rule No. 1 If A, then recommend Y.
  • Rule No. 2 If B, then recommend Yl.
  • Rule No. 3 If C, then recommend Y2.
  • Rule No. 4 If D, then recommend Y3.
  • contextual arcs also makes it easier to change the recommended products or services. For example, in the exemplary scenario described above, consider the steps a business manager would have to take to change the list of recommended stocks LI. Without contextual arcs, the business manager would have to change the expression for the concept XL With contextual arcs, the business manager would only have to change the expression for contextual arc 452, which extends from node 406, which indicates concept B, to node 412, which indicates concept X (see Figure 10).
  • the present invention provides an information system that captures data from disparate sources and provides intelligent, personalized recommendations.
  • the invention has been described herein in terms of several preferred embodiments. Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention.
  • the embodiments and preferred features described above should be considered exemplary, with the invention being defined by the appended claims. What is claimed is:

Abstract

Un système d'information basé sur l'ontologie comprend une pluralité de modèles, dont chacun exprime un aspect d'un domaine commercial à l'aide de concepts et de relations entre des concepts. Une ontologie, laquelle constitue une communication avec chacun de la pluralité des modèles, fournit des définitions uniformes pour les concepts et les relations entre les concepts utilisés dans la pluralité de modèles. Un procédé d'exécution d'un modèle de flux d'interactions consiste à recevoir un événement et à catégoriser l'événement reçu. Une fois l'événement catégorisé, une situation correspondant à l'événement catégorisé reçu est identifiée. Une ou plusieurs tâches sont alors exécutées en fonction de la situation. L'exécution d'une ou de plusieurs tâches peut consister soit en une interprétation d'un modèle soit en l'exécution d'un procédé d'un objet. Le système d'information comprend également une interface utilisateur et d'application ainsi qu'un moteur de raisonnement en communication avec l'interface utilisateur et d'application. Un gestionnaire de connaissances est en communication avec l'interface utilisateur et d'application et est relié au moteur de raisonnement. Un service d'information réparti se trouve également en communication avec le moteur de raisonnement, le gestionnaire de connaissances et l'interface utilisateur et d'application.
EP00957598A 1999-08-20 2000-08-18 Systeme d'information base sur l'ontologie Withdrawn EP1305746A2 (fr)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US15020499P 1999-08-20 1999-08-20
US150204P 1999-08-20
US16514799P 1999-11-12 1999-11-12
US165147P 1999-11-12
PCT/US2000/022804 WO2001015042A2 (fr) 1999-08-20 2000-08-18 Systeme d'information base sur l'ontologie

Publications (1)

Publication Number Publication Date
EP1305746A2 true EP1305746A2 (fr) 2003-05-02

Family

ID=26847415

Family Applications (1)

Application Number Title Priority Date Filing Date
EP00957598A Withdrawn EP1305746A2 (fr) 1999-08-20 2000-08-18 Systeme d'information base sur l'ontologie

Country Status (3)

Country Link
EP (1) EP1305746A2 (fr)
AU (1) AU6919400A (fr)
WO (1) WO2001015042A2 (fr)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6847974B2 (en) * 2001-03-26 2005-01-25 Us Search.Com Inc Method and apparatus for intelligent data assimilation
JP2004533047A (ja) * 2001-04-16 2004-10-28 ビーイーエイ　システムズ，　インコーポレイテッド ウェブに基づいた個性化とｅコマース管理システム及びその方法
WO2002084441A2 (fr) * 2001-04-16 2002-10-24 Bea Systems, Inc. Systeme et procede de marketing base sur internet et gestion de campagne
US20030101170A1 (en) 2001-05-25 2003-05-29 Joseph Edelstein Data query and location through a central ontology model
US20060064666A1 (en) 2001-05-25 2006-03-23 Amaru Ruth M Business rules for configurable metamodels and enterprise impact analysis
US8412746B2 (en) 2001-05-25 2013-04-02 International Business Machines Corporation Method and system for federated querying of data sources
US7877421B2 (en) 2001-05-25 2011-01-25 International Business Machines Corporation Method and system for mapping enterprise data assets to a semantic information model
US7099885B2 (en) * 2001-05-25 2006-08-29 Unicorn Solutions Method and system for collaborative ontology modeling
US7146399B2 (en) 2001-05-25 2006-12-05 2006 Trident Company Run-time architecture for enterprise integration with transformation generation
CA2357165A1 (fr) 2001-09-10 2003-03-10 Ibm Canada Limited-Ibm Canada Limitee Connecteur configurable
US7225183B2 (en) * 2002-01-28 2007-05-29 Ipxl, Inc. Ontology-based information management system and method
US9418204B2 (en) 2002-01-28 2016-08-16 Samsung Electronics Co., Ltd Bioinformatics system architecture with data and process integration
US7383302B2 (en) 2003-09-15 2008-06-03 International Business Machines Corporation Method and system for providing a common collaboration framework accessible from within multiple applications
GB0322871D0 (en) * 2003-09-30 2003-10-29 British Telecomm A method of operating a computer network
KR100505970B1 (ko) * 2003-11-28 2005-08-30 한국전자통신연구원 온톨로지 기반의 지식 모델링 방법 및 그 시스템
US8799003B2 (en) 2004-05-18 2014-08-05 International Business Machines Corporation Dynamic binding of principal services in a cross-enterprise business process management system
US7254589B2 (en) * 2004-05-21 2007-08-07 International Business Machines Corporation Apparatus and method for managing and inferencing contextural relationships accessed by the context engine to answer queries received from the application program interface, wherein ontology manager is operationally coupled with a working memory
US8015135B2 (en) 2007-10-24 2011-09-06 Motorola Solutions, Inc. System and method for knowledge storage in an autonomic network
US8793208B2 (en) 2009-12-17 2014-07-29 International Business Machines Corporation Identifying common data objects representing solutions to a problem in different disciplines
US8478766B1 (en) * 2011-02-02 2013-07-02 Comindware Ltd. Unified data architecture for business process management
US8747115B2 (en) 2012-03-28 2014-06-10 International Business Machines Corporation Building an ontology by transforming complex triples
US8539001B1 (en) 2012-08-20 2013-09-17 International Business Machines Corporation Determining the value of an association between ontologies

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5794050A (en) * 1995-01-04 1998-08-11 Intelligent Text Processing, Inc. Natural language understanding system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0115042A3 *

Also Published As

Publication number Publication date
WO2001015042A3 (fr) 2003-02-20
WO2001015042A8 (fr) 2001-06-07
AU6919400A (en) 2001-03-19
WO2001015042A2 (fr) 2001-03-01

Similar Documents

Publication Publication Date Title
US7567915B2 (en) Ontology-driven information system
EP1305746A2 (fr) Systeme d'information base sur l'ontologie
US8489474B2 (en) Systems and/or methods for managing transformations in enterprise application integration and/or business processing management environments
Medjahed et al. A multilevel composability model for semantic web services
US8972872B2 (en) Building computing applications based upon metadata
Medjahed et al. Context-based matching for web service composition
US7543232B2 (en) Intelligent web based help system
US8296655B2 (en) Context sensitive information management system and method
US8214351B2 (en) Selecting rules engines for processing abstract rules based on functionality and cost
Devedzic Knowledge modeling–state of the art
US9009135B2 (en) Method and apparatus for satisfying a search request using multiple search engines
US7707040B2 (en) Method of generating business intelligence incorporated business process activity forms
US8495510B2 (en) System and method for managing browser extensions
US20040230667A1 (en) Loosely coupled intellectual capital processing engine
Zisman et al. Proactive and reactive runtime service discovery: A framework and its evaluation
US20120143879A1 (en) System and Method of Presenting Relevant Application Components to a User
JP2005528706A (ja) カスタマのアクティビティを統合、管理、および調整するためのシステムおよび方法
US8863153B2 (en) Situational recommendations in heterogenous system environment
US20210256396A1 (en) System and method of providing and updating rules for classifying actions and transactions in a computer system
CN114372807A (zh) 内部销售团队或专家支持团队的动态形成
Dai et al. Dynamic on-demand solution delivery based on a context-aware services management framework
Ouzzani Efficient delivery of web services
Medjahed et al. WebBIS: An infrastructure for agile integration of web services
Brezany et al. Ontology-based construction of grid data mining workflows
US20110282886A1 (en) Tools discovery in cloud computing

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20020312

AK Designated contracting states

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ACL INTERNATIONAL, INC.

17Q First examination report despatched

Effective date: 20090218

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: 6100198 CANADA INC.

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20090630