The PSM Tab: Documentation

The PSM Librarian is a tab plugin to Protégé that allows you to browse, configure and activate libraries of Problem-Solving Methods.

Problem-Solving Methods (PSMs) are reusable algorithms that encode domain-independent strategies to realize common knowledge-intensive tasks by processing domain knowledge. Well-known PSMs are propose-and-revise and heuristic classification, that respectively have been used to tackle tasks such as constraint-satisfaction, classification and diagnosis in domains as varied as elevator configuration, ribosome-conformation prediction and diagnosis of arthritic conditions.

A PSM provides both a formal model of a generic reasoning process, and a piece of program code that implements it. As such, a PSM serves as a reasoning building block that can be assembled with a domain knowledge base to create a running knowledge system. PSMs are typically collected in libraries, that help indexing and retrieving PSMs for different purposes and contexts. In particular, PSM libraries formalize the properties, capabilities and requirements of the PSMs available, using a specification language. In this version of the PSM tab, PSM libraries are modeled with the Unified Problem-solving Method development Language (UPML). Pragmatically, PSM libraries hence are encoded as UPML-based Protégé projects--Protégé projects that include a base UPML ontology (also encoded as a Protégé project) and that contain instances of the UPML concepts. Note that a separate UPML editor supports providers of PSM libraries in modeling their PSMs with UPML.

The PSM Librarian is a tool that plugs into Protégé to support you (as a library user) in (1) browsing and selecting a PSM suitable for your task, and (2) configuring that PSM for your domain, by creating mapping relations between the concepts of your domain and the inputs-outputs required by the PSM. In other words, the PSM Librarian helps you to create and configure your knowledge-based application so that you can eventually run it with your domain case data without having to change anything to the PSM you have chosen. You typically enable the PSM Librarian tab on one of your domain Protégé projects, so that the PSM tab serves as a front-end interface to a set of UPML-specified PSM libraries. The PSM Librarian tab is itself organized as a set of subtabs, that each supports you in one of the activities involved in building a knowledge-based application out of available PSMs, currently: (1) PSM selection, and (2) PSM configuration (or domain-to-method mapping). Note that the current version of the PSM Librarian tab does not support the method-execution activity.

Overall, the process of selecting and configuring a PSM with help of the PSM Librarian can be depicted as follows:

Building a knowledge application with our PSM Librarian. Note that the current support provided by the tab is delineated by the blue doted line. The PSM Selection Manager (or PSM Selection subtab) enables the application developer to choose a PSM from available UPML libraries, and isolates that PSM's method ontology. The PSM-Domain Mapping Editor (or PSM Configuration subtab) allows the developer to create a knowledge base of domain--method mapping relations, according to our mapping ontology. The Mapping Interpreter processes the mapping relations to transform the domain-knowledge instances (including case data) into corresponding method instances---instances of the method ontology, which the PSM can operate on directly. The mapping interpreter also processes reverse mapping relations when translating the PSM's outputs into domain-compliant instances.

The PSM Selection subtab allows you to load several PSM libraries, browse the specification of each PSM available in those library, and select the PSM most suitable to meet your needs. PSMs are specified according to the UPML framework. PSM libraries are Protégé projects that include the UPML ontology project and contain specific PSM instance models. The PSM tab interfaces your domain project with a set of UPML-based PSM library projects.

In particular, you can browse a PSM's competence and operational specification: the input and output roles of the PSM, its subtask decomposition and its operational description (optionally with an associated control and role-flow diagram).

Main view of the PSM Selection subtab. The "Libraries" pane (upper left) allows you to load and select libraries of PSMs (here, the protege-psm-library). The "PSMs" pane (lower left) allows you to browse the PSMs that are available in the selected library. The "UPML Description" panel (right) displays the description of the highlighted PSM, as modeled in the UPML framework. From this area, you can browse all elements that are related to the model of the selected PSM (pragmatics, ontology, particular roles or subtasks, etc.)--in other words, this area provides a restricted view of the UPML-based library project. Note that the "Query PSMs" button below the "Libraries" pane invokes a dialog to search the entire UPML model of the selected library for particular PSMs that meet certain criteria. The "Commit PSM selection" button (bottom left) enables you to choose your selection of a PSM as the one you want to use in your knowledge-based application. All committed selections are summarized in the lower line.

The "method ontology" of a PSM. In particular, the "Signature Elements" hold all terms defined by the ontology.

A particular role in a PSM's method ontology. In this case, the role "parameters" is defined by a "stateVariable" Protege class, in turn defined externally to the UPML specification.

The pragmatics of a PSM's "method ontology". In particular, the "Format" and "Resource Identifier" fields hold information about the possible external ontology that completely defines all terms used by a PSM, in this case a Protégé project (the PnR.pprj project).

The UPML ontology represented in Protégé, here customized with additional elements to represent ontology components as Protégé projects (i.e., the upml-protege.pprj project). PSMs, Tasks and Domain Models are the main types of knowledge components that take part in a knowledge-based application. Each knowledge component relies on an Ontology that holds and defines the concepts used in the specifications of the component. Relationships between two different kinds of components assembled in a configuration are held in Bridge adapters.

Once you have committed your selection of a PSM, you need to configure that PSM to work with your domain. Because PSMs are generic, the way in which they specify their competence and their input-output requirements--using a method ontology--is independent of any domain knowledge. Conversely, your domain knowledge typically is not construed in a way directly compatible with the PSM's method ontology.

The PSM Configuration subtab provides you with a methodological framework to reconcile the conceptual and syntactic differences between your domain knowledge and the expectations of a method ontology. The components of our methodology are a mapping ontology and a mapping interpreter, involved in the PSM-configuration process as follows:

First, you need to declare a set of domain-to-PSM mapping relations--correspondence links and transformation rules between the concepts in your domain and the concepts in the PSM's method ontology. For this, you instantiate a mapping ontology--an ontology of prototypical domain-to-method mapping relations, both at the instance level and at the slot level. The result of this activity is a mapping knowledge base for your domain and the selected PSM.
Second, a mapping interpreter processes the mapping relations that you have declared and produces a set of instances for the PSM to run on--the method knowledge base.

The figure below pictures the intricate architecture of the PSM Librarian tab.

Synopsis of the PSM Librarian tab. Enabled on a domain project, the PSM tab extends Protégé by providing browsing and selection access to libraries of PSMs modeled in UPML. PSM libraries are projects that all include the base UPML ontology---possibly extended for a particular knowledge representation formalism, such as Protégé itself---and instantiate the UPML concepts with PSM models. Once a particular PSM has been selected for the user's target system, the PSM tab loads this PSM's method ontology---an external Protégé project in this case---and the generic mapping ontology. The PSM tab allows the user to configure the PSM by creating mapping relations---instances of the mapping ontology---between the domain ontology and the PSM's method ontology. The PSM tab finally invokes a mapping interpreter that computes a set of instances for the PSM's ontology, by processing the domain instances according to relations and transformations expressed in domain-PSM mapping instances. As a result, the PSM's ontology contains all domain knowledge needed for the executable PSM to operate, in a format that it can process.

The PSM Configuration subtab allows you to perform the non-trivial activity of mapping domain entities to method input and output roles. The subtab provides you with an integrated and synchronized support for browing and managing all three knowledge bases involved, i.e., domain, method and mappings (instead of having to switch manually between multiple Protégé applications). You can browse your domain classes and instances and the selected PSM's method classes together and create or visualize their relationships easily. You can populate, browse and edit the corresponding mappings knowledge base---a custom set of instances of the mapping ontology---that reflects your domain-specific configuration of the selected PSM. The PSM Configuration subtab automatically creates a new mappings knowledge base for your current domain and PSM, or loads an existing one if available. Concretely, you then first create a set of instance-level mapping relations between pairs of concepts of the two ontologies---relations that mean that for each instance of a domain concept, an instance of the method concept needs to be created. For each instance-level mapping relation between a domain class and a method class, you also create a set of slot-level mapping relations---relations that express the way to compute the values of each slot of that method class from values of slots of that domain class. You then can save the mappings knowledge base and invoke the mapping interpreter directly from the PSM Configuration subtab. After running the mapping interpreter, you can browse the computed instances in the newly populated PSM's method knowledge base.

Main view of the PSM Configuration subtab. The two left columns display, side-by-side, your domain knowledge base and the selected PSM's method ontology (classes in the upper panel, and slots or instances in the lower panel). Small icons next to a class or slot name mean that that frame is part of a mapping relation with the a class or slot in the other ontology. The button at the top of the ontologies allow you to synchronize all three panels according to the mappings defined for the selected class. At the right, the mapping panel displays the mappings knowledge base: At the top, the mapping ontology (left) and existing instances of mapping relations (right); below, the contents of the selected mapping relation instance, including the set of slot-level mappings. The "Mapping operations" menu at the very top of the mapping panel enables you to create mapping relations from classes or slots selected in the domain and method ontologies; to save the mapping knowledge base; and to run the mapping interpreter. For instance, this screenshot shows a mapping relation of the type "renaming mapping" between the "elvis-parameter" (source) class of the elevator-design domain ontology (i.e., elvis.pprj) and the "stateVariable" (target) class of the propose-and-revise PSM's method ontology (i.e., PnR.pprj), for which four slot-level mapping relations have been defined to compute the values of the "the-name," "input-variable," "output-variable" and "initial-value" slots (this example mappings knowledge base is elvis-pnr.pprj).

Two particular slot-mapping relations. (1) The upper one is a simple renaming slot mapping, defined in the scope of the above instance mapping, and that specifies that for each instance of the method (target) "stateVariable" class created from an instance of the domain (source) "elvis-parameter" class, the value of the method (target) slot "initial-value" should be filled-in with the value of the domain (source) slot "parameterdefault-value." (2) The lower one is a lexical slot mapping (defined in the scope of the instance mapping in the next screenshot) that specifies a lexical expression to calculate the value of the method (target) slot "variable" (here a concatenation of the values of the two domain (source) slots "upgrade-classname" and "upgrade-keyslot"). Both examples are from the mappings knowledge base elvis-pnr.pprj)

Side-by-side inspection of the domain instances and their corresponding method instances. As a result of running the mapping interpreter, the PSM's method ontology gets populated with instances that are filled according to the set of instance and slot mapping relations (i.e., in elvis-to-pnr.pprj). Note that instances of the selected method class can be the result of either instance mapping that has that class as a target class. Selected instances are shown below.

Mapped domain and method instances. Left is an instance of the domain class "elvis-fixes" which partial contents have been mapped to an instance of the method class "fix," according to the mapping relation shown above. In particular, the value of the method slot "variable" contains the lexical concatenation of the domain slots "upgrade-classname" and "upgrade-keyslot," as defined by the slot mapping shown earlier.

The mapping ontology (i.e., mappings.pprj). A mapping knowledge base consists of a set of instance mappings that relate a domain (source) class to a method (target) class. The actual data and knowledge transformation is expressed in an associated set of slot mappings that each defines the rules for computing values of method (target) slots from domain (source) slots. The slot mappings are of different types, allowing for different kinds of method slot-value computation, from simple slot-value renaming to lexical expressions, to functional transformations. Recursive slot mappings are used for calculating instance-valued method slots, through a dependent instance mapping only processed on-demand. Finally, an instance mapping can be conditional upon properties of instances being mapped (thus allowing for one-to-many instance-level mapping relations); can be defined for instances of subclasses of the domain (source) class; and can involve instances of auxiliary domain (source) classes.