## 5 Case Study  
### The Implementation of MPI-OKCS  
Based on the proposed approach, this sub-section implements a prototype management system _MPI-OKCS_ for open capturing systematic process innovation knowledge. It is integrated as a submodule into the pre-built general platform of CAPI system _pi_Pioneer, which contains the basic tools needed for the knowledge management system.  
The _MPI-OKCS_ has a 4-layer-architecture, as illustrated in Figure 5. The knowledge & data layer stores the basic data of the innovation system, knowledge-social information of the community, and captured process innovation knowledge. The service layer supports access to the knowledge and data layer, and provides various system background services of knowledge capturing process. The functional layer provides the functional components required for the system business logic of the three main modules, namely, knowledge capture, knowledge application, and system management. The interaction layer provides a visual man-machine interface for users from different departments and dispersed geographic locations, so that they can participate in the innovation knowledge processing activities of the corresponding roles in an open environment.  
To facilitate the implementation process, we have invited seven domain experts from the Institute of CAPP & Manufacturing Engineering Software at NWPU (Xi'an, China) and the Department of Mechanical Design at CHD (Xi'an, China) to participate in innovation knowledge refinement. All graduate students from the above two departments were allowed to contribute their innovation knowledge. Additionally, about 20 engineers from the R & D department of Sinomach Changlin Company Limited (Changzhou, China) have contributed their individual process knowledge to the system.  
\begin{table}
\begin{tabular}{p{142.3 pt} p{284.5 pt}} \hline \hline
**Rules** & **Descriptions** \\ \hline Rule 1 & The read locks are compatible with each other. More than one read locks can be placed on one knowledge object at the same time. Group members of knowledge refinement are allowed to hold read lock of the corresponding knowledge objects. \\ \hline Rule 2 & The write locks are mutually exclusive with each other for a locked region. This means that only one write lock can be placed on the same knowledge object at a certain moment, and for a knowledge element only one editor may hold the write lock. \\ \hline Rule 3 & After participants publish their comments and exchange views on the knowledge object to be refined, members who obtained a positive evaluation of more than a certain level can apply to be the refinement editor. \\ \hline Rule 4 & If a knowledge element has been locked, the write lock requests will be put forward. Meanwhile, notifications are sent to the owners of write locks whenever the latter form queues in front of certain knowledge objects. Specifically, a system timer process, which sends time-stamped notifications to the owners of write locks, can be employed to prevent the starvation of other editing operations whenever there are editing operations waiting for more than a certain time to access certain objects. \\ \hline Rule 5 & Group managers have the permission to grant write locks to a suitable group member at all times. \\ \hline \hline \end{tabular}
\end{table}
Table 1: Rules for lock-based knowledge collaborative editing and refinement (adapted from [25]).