This section describes in detail the goal and functionalities of the Localiza- tion Management Module which is the key module for localization managers to monitor, manage and control the localization activity. The Workflow Lo- calization Manager (WLM) is the core component of this module. The main goals of the WLM are:
• To manage the timely flow of the localization activity from initiation
to delivery,
• To detect changes in the ontology model and propagate those changes
to the linguistic model, and
• To manage the individual localization task performed in the Ontology
Translator module.
In order to support the first goal the WLM includes a collaborative work-
flow, which implements the necessary mechanisms to allow the ontology
stake-holders to perform the activities of the ontology localization life-cycle. Thus, the collaborative workflow is responsible for the coordination of who (depending on the user’s role) can do what (i.e. what kind of actions) and when (depending on the status of the ontology elements).
From a technical point of view, the collaborative workflow is associated with a set of initialization parameters (e.g., user roles, assigned tasks, etc), source and target languages, and a partially ordered set of activities or states. The WLM individually stores the initialization parameters of each ontology. However, the information about user, roles and skills are stored in a shared database, which have two benefits:
1. Improved Project Staffing. The Localization Managers can see all the information related with a participant (e.g., language skills). This saves time and allows for better decisions when staffing a new ontology localization project.
2. Shared Information Across Ontology Projects. The shared information provides a particular benefit to ontology projects that need to localize several ontologies. Maintaining a single user database allows to share users in different ontology projects.
Coming back to the description of the workflow, the activities supported are: selecting the ontology elements to be translated, translating the selected elements, reviewing the translations, and updating the ontology with the linguistic information obtained. These activities summarize the localization tasks commonly followed by different organizations (see section 6.2.1 for more details). In the following we summarize the main steps in the workflow process to localize an ontology (see Figure 6.4):
Figure 6.4: Workflow process used to localize an ontology.
• An ontology is passed to the Localization Manager for localization. • The Localization Manager manually selects the ontology labels to be
localized and sends the selected labels for translation.
• A translator downloads the selected labels to be localized and (s)he
performs the translations using an automated localization tool (as pro- posed in this thesis) or an intensive manual process.
• Once translation activities have been accomplished, the translators
upload the translated ontology labels and send them for review.
• The reviewers download the translated labels and check for possible
errors.
• Finally, the Localization System updates all linguistic information of
each localized label.
In the next sections we explain the rest of the associated components.
6.5.1 Synchronization Component
The Synchronization component supports the second goal of the workflow localization manager which is detecting the changes in the ontology manage- ment module. This component listens the changes in the ontology model and then automatically propagates those changes to the linguistic model using synchronization techniques. Remember that our system follows the cur- rent trend in the integration of multilinguality in ontologies, which suggests the suitability of keeping ontology knowledge and linguistic (multilingual)
knowledge separated and independent [Montiel-Ponsoda et al., 2008, Buite- laar et al., 2009]
In order to keep both models, the ontology model (OM) and lexical model (LM), synchronized we first need to find out exactly what has been changed in the ontology model, then find the equivalent places in the linguistic model and only then start the updating. In a previous work [Espinoza et al., 2009a] we introduced the module for managing the conceptual knowledge and the linguistic knowledge by means of synchronization techniques. Hence, we briefly highlight the main features.
Addition of new terms in the ontology, or deletion of an existing term can be controlled by some mechanism of change tracking. Change tracking in our approach enables the system to obtain only changes that have been made to the ontology terms, along with the information about those changes. By adopting this feature, our system can accurately identify the minimum set of changes needed to adjust the structure of the linguistic model, a critical first step to ensure that a change is made in the localized ontology. To correctly update the linguistic model, the system needs to identify:
1. all ontology terms in the original ontology whose labels have changed in the updated ontology,
2. any ontology term that has been added to the updated ontology, 3. any ontology term which has been removed from the original ontology,
and
4. any ontology term whose position in the updated ontology differs from that in the original ontology.
Finding where a translation is required is only part of the problem. We also need to ensure that changes in the ontology structure are accurately propagated to the linguistic information. This requires that elements whose structure need to be updated are clearly flagged in the linguistic model, and that the relevant structural changes are indicated in a form that turns the updating of the translation into a simple process, thus involving minimum work on the part of the linguist user or domain expert. Figure 6.5 illustrates the process used in our system to synchronize the conceptual and linguis- tic information. In the following we analyze the process in more detail, describing the actions performed by each actor of our scenario.
• Ontology expert. (S)he is responsible for editing the changes in the
ontology model. All the changes executed in each user session are stored in a repository as a new version. The types of changes that our system can manage are the following: changes of the label content (e.g., ontology label rename) and ontology structure changes (e.g.,
delete or add operations). For each case, the system stores the type of operation executed and its additional information (e.g., the name of the renamed label). This information is used in our system to synchronize the conceptual and linguistic information.
• Linguist expert(s). The linguist expert in a specific target language is
responsible for performing the localization process. Notice that this process always uses the last version of an ontology. When the linguist needs to update the linguistic model (LM), our system tries to syn- chronize both models, performing the following actions: (1) obtaining the current version of the LM to be updated, (2) extracting the last version of the changes in the ontology model (OM) from which the last localization was taken (normally the one with the same number as the LM), (3) performing all the actions of the file of changes in the LM, and (4) updating the LM version in the repository.
Figure 6.5: Synchronization of ontology and linguistic model.
6.5.2 Localization Component
The last goal of the workflow localization manager is supported by the Local-
ization component. This component controls and manages the tasks that the
ontology stakeholders are allowed to perform depending on their roles and the status of the ontology elements to be localized. The possible tasks in the collaborative workflow (described previously) apply to different abstraction levels. In our solution we consider two levels: ontology element level and translation level. Although the workflows can be used independently of the underlying ontology model, the specific set of ontology terms depends on the ontology model. In our approach, we are mainly considering the OWL
ontology model, in which an OWL ontology consists of a set of axioms and facts. Concepts, properties, instances and ontology term comments are the set of ontology elements we are taking into account.
The possible states that can be assigned to ontology elements are:
• In Use: This is the status assigned to any element when it first passes
into the collaborative workflow, or when it was localized and then updated in the Ontology Repository.
• New: If the ontology element was added to the ontology after the
ontology has been localized, the ontology element is passed to the “New status, and remains there until the element is localized.
• Changed: If the original label of the ontology element has changed,
then the element is passed to the “Changed” status, and remains there until the element is checked to be localized again.
• Unused: If the ontology element has been deleted, then this element is
passed to the “Unused” status, and remains there until the ontology is synchronized (see synchronization component in the previous section). The localization component controls also the status of the translations. Figure 6.6 shows the workflow to translation level. States are denoted by rectangles and actions by arrows. The actors in the figure specify the actions that an ontology stakeholder can perform depending on its role. In the following we provide a detailed explanation:
Figure 6.6: Workflow to the Translation level.
• Not translated: This is the status assigned to any translation when it
first passes into the collaborative workflow or when any change has been performed in the element of the ontology under consideration.
• To be Translated: Once the Localization Manager selects the transla-
tions with the “Not translated” status, these translations are passed to the “To be Translated” status, and remain there until a “Translator” translates them.
• Auto translated: If a “Translator” uses the automatic translation al-
gorithm provided by the system, then the translation is passed to the “Auto-translated” status, and remains there until the own “Transla- tor” sends the translations to the “To Be Reviewed (auto)” status.
• Translated: If a “Translator” manually makes a translation, then the
translation is passed to the “Translated” status, and remains there until the own “Translator” sends the translations to the “To be Re- viewed” status.
• To be Reviewed: If a “Reviewer” approves the translations send by the
translator, it passes to the “Complete” status. The reviewer knows in advance if translations have been made automatically or manually. For example, the word “automatic” in the message “To Be Reviewed (au- tomatic)” indicates to the reviewer that these translations have been obtained automatically. Additionally, when the translations reach the “Complete” status, they are automatically updated in the Ontology Repository.
Note that during the collaborative workflow, actions are performed either implicitly or explicitly. For instance, when a user updates (i.e. modifies) an ontology label, he does not explicitly perform an update action. In this case the action has to be captured from the user interface and recorded when the ontology is saved. In contrast, when Reviewers for example explicitly approve/reject proposed translations, the action is immediately recorded when performed.