The content and structure of a wiki evolve as a result of the collaborative eort of the wiki users. In semantic wikis, this also results in the evolution of the ontology that is implicitly expressed through the semantic annotations. Without proper guidance, the semantic wiki can evolve in a chaotic manner resulting in quality problems in the underlying ontology, e.g. inconsistencies. As the wiki grows in size, the detection and solution of quality problems become more dicult. We propose an approach to detect quality problems in semantic wikis and assist users in the process of solving them. Our approach is inspired by the key principles of software refactoring, namely the cataloging and automated detection of quality problems (bad smells), and the application of quality improvement transformations (refactorings). In this paper we discuss the problem of evolving semantic wikis, present the core model of our approach, and introduce an extensible catalog of semantic wiki bad smells and an extensible toolkit of semantic wiki refactorings.
Semantic Wikis [
Wikis evolve as a result of the collaborative eort of its users [
In software engineering, refactoring techniques are applied to improve
programs quality. The term refactoring [
A strategy for refactoring consists in the following components: a toolbox of refactorings, a catalog of bad smells, and detailed instructions on how to apply refactorings to remove each smell. Additionally, automated tools for the detection of bad smells and refactoring editors reduce the eort of refactoring and the chance of introducing errors. Environments in which refactoring is a mature practice (a culture), such as Smalltalk, usually oer these powerful tools.
Inspired by the principles of refactoring, this paper explores the use of such strategies to assist the evolution of semantic wikis and incrementally improve their quality. In this order, we give denitions for Semantic Wiki Bad Smell and Semantic Wiki Refactoring . Then, we adapt each of the components of a refactoring strategy to the context of semantic wikis. This includes a toolbox of semantic wiki bad smells, and a catalog of semantic wiki refactorings with their instructions on how to remove bad smells. Additionally, we discuss how tools can be used to automate the detection of bad smells and refactoring operations.
The structure of this paper is the following. We discuss in detail the problem of achieving quality in evolving semantic wikis in Section 2. Afterwards, in Section 3, we describe the state of the art in works to assist the evolution of semantic wikis. In Section 4, we present our approach that applies the ideas of software engineering refactoring in the context of semantic wikis. Finally, in section 5 we present the conclusions and future work. 2
The structure of a wiki, as well as its content, evolves as a result of the
collaborative eort of the wiki users. Usually, wikis are created with very few or
no structure in advance, so that users adjust it as a necessity to express
knowledge, ideas, opinions, etc. Mader [
When the wiki is semantic, the wiki evolution also aects the formal
representation of the wiki content, i.e. the underlying ontology. Thus, the ontology
emerges with the wiki, as users add semantic annotations to the wiki content.
Kousetti et. al. [
The problem of evolving wikis consists in assuring a good wiki quality through all the stages of the wiki evolution. If the evolution is not controlled, it is very possible that the wiki evolves in a chaotic manner. Many problems can arise as the result of multiple users collaboratively and incrementally editing a wiki. In traditional wikis, these problems are usually related to the following quality metrics: readability, structure, navegability, completeness, consistency.
Semantic wikis aim to improve the quality of traditional wikis by allowing
to add semantic knowledge to the wiki content. However, they cannot assure
that the wiki evolves in a correct manner and that a good ontology convergence
is achieved. Kousetti et. al. [
Completeness: anything that needs to be in the ontology is explicitly dened or it can be inferred from other dened denitions and axioms.
Conciseness: does not contain unnecessary denitions or redundancies. Expandability: you can easily add more knowledge without requiring to make major changes to the existing structure.
Sensitiveness: the ontology is more sensitive if small changes can alter easily how well-dened a denition is.
Let’s take a motivating example of a semantic wiki being employed to describe geographical places. In an early stage of evolution, a user creates a category "City". Later, another user creates a category "Capital city", attempting to form a more specic group for cities that are also capitals. However, this user does not realize that this category denes a subset of the resources of category "City" and, consequently, should be a subcategory of it. The lack of this semantic relation between the two categories results in many problems. First of all, it aects the conciseness of the semantic wiki. Every time a user creates a page for a city that is also a capital city, he will have to categorize it with both categories, so that no semantic knowledge is lost. Secondly, it aects the semantic wiki completeness. A user asking the wiki for a list of cities will not get as result the resources categorized with category "Capital City" but not with category "City".
The example above exposes that problems can arise while the evolution of semantic wikis takes place. Such problems are nally perceived as a lack of quality in the product, thus jeopardizing the success of the wiki. This results in the necessity of an extra work, that consists in periodically checking for problems in the wiki quality, and making the corresponding modications. This work is commonly called "wiki gardening" 1. However, as the wiki becomes longer, with many pages and semantic annotations, it becomes more dicult to detect quality problems and solve them appropiately.
In this context, where shared ownership and evolution of structure and content are a plus, assistance needs to be provided to check that quality criteria are met and to minimize the eort of improvement. 3
Wikis are groupware. Peter and Trudy Johnson-Lenz [
In the eld of ontologies, the problem of ontology evolution is one of the
current topics of the research agenda. Djedidi et. al. [
An approach to assist the evolution of semantic wikis is MOCA [
Although these two works assist the evolution of semantic wikis by helping users in the creation of content, they do not aim to neither nd quality problems nor solve them. SMW+3 is actually an approach to accomplish part of this. SMW+ is a semantic wiki built on top of SMW, aimed at the enterprise market. In addition to assisting users in authoring using the Halo Extension, SMW+ oers gardening functionality. It comprises a set of programmable tasks (called bots) to automate or assist users in the process of improving the quality of the wiki content. For example, there are bots to nd pages without annotations, or to nd artifacts on schema or annotation level which indicate a bad modeling.
Although the contribution of the gardening functionality of SMW+ should be recognized, it is strongly biased towards the identication of quality problems. It does not provide support for the implementation of the changes required to remove them and, thus, to improve the quality of the semantic wiki. 4
In this section we will see how each of the components of a refactoring strategy, that were described in section 1, are applied to the context of semantic wikis. But rst of all, in section 4.1, we will need to dene the model of the artifact that will serve as the base to dene each of them.
4.1
The core model is a conceptual model of a semantic wiki and is inspired on the knowledge base of SMW. However, it can be customized and extended to support new features, so that new refactorings and smells could be dened in terms of them.
A Resource is anything that can be described in a wiki: Concept, that represents individuals in the wiki; Category, which allows to group resources; Property, that describes the semantic of relationships between resources; and Type, that is used to specify the object type of properties. Each of the resources can have a wiki Page or Article that describes it. Pages can be also directly related to other pages using untyped links.
Semantic Annotation is subclassied in Categorization and Property Annotation. A Categorization describes a relation of membership of a resource in a category. A subcategory relationship between categories is dened when the subject resource of a categorization is a category. In this case, the subject category is a subcategory of the object category.
A Property Annotation is composed by three elements: a subject, that can be any resource; a property, which is an individual of Property; and an object. Relationship Annotations are those property annotations whose object is another resource, while the object of Attribute Annotations are end values of a data type. Categorizations could be restated as relationship annotations in which the property describes the belongs to semantic, and the object is allways a category.
We assume the existence of a set of built-in properties with special meanings. One of them is the Subproperty of Property. When used as the property of a relationship annotation between two properties, it describes a subproperty relationship between the subject property and the object property. Another built-in property is the Has type Property that indicates the object Type of a Property. 4.2
Semantic wiki refactorings are transformations in the semantic structure of a semantic wiki knowledge base, that allow to improve the implicit ontology quality. Refactorings describe an ordered way of appropiately performing such transformations, so that new inconsistencies, redundancies and other quality problems are avoided. Each refactoring is dened by: a name ; a description, which summarizes the refactoring in informal language; and the mechanics, which are a series of mechanical transformations in the model of the wiki.
In the following we describe in detail the refactoring called Create subcategory relationship as an example. As it is not the objective of this paper to dene a complete catalog of refactorings, we will later list other refactorings for which we will only mention their name and description.
Create subcategory relationship refactoring describes a transformation in which an existent category turns to be a subcategory of another one. Dening such relationship helps improve the quality of search results, the conciseness and completeness of the semantic wiki.
Following the example described in section 2, applying this refactoring would mean to make "Capital City" a subcategory of "City". The rst step to appropiately accomplish this, must consist in actually making "Capital City" subcategory of "City". This is the basic step to create the subcategory relationship. Secondly, the categorizations of category "City" in each resource that also belongs to category "Capital City" have to be removed. This is because it is now implicit that every resource that belongs to "Capital City" also belongs to "City". Applying this step avoids redundant categorizations. The last step consists in eliminating redundancies in the categorization chain. Supose the existence of a category "Geographical place", that is supercategory of both categories. Then, the subcategory relationship that states that "Capital City" is subcategory of "Geographical place" is now redundant and, thus, has to be eliminated.
The following is the formalization of this refactoring. Applied to the example, the category "City" plays the role of supercategory, "Capital City" is the subcategory, and "Geographical place" is the super-supercategory :
Description Make an existent category subcategory subcategory of another existent category supercategory.
Mechanics 1. Make supercategory supercategory of subcategory. 2. For each resource that belongs to subcategory remove its categorization of supercategory. 3. For each category super-supercategory that is supercategory of subcategory : if it is also a supercategory of supercategory, remove it as supercategory of subcategory.
Note that the steps dened in the mechanics of the refactoring are not bound to any semantic wiki implementation. The concrete actions that has to be done to actually perform the steps, depend on the way each semantic wiki implementation implements each of the semantic wiki features. In this way, refactorings are able to be reused in any semantic wiki implementation.
Table 1 presents a list of other possible semantic wiki refactorings. This list can be extended and customized. Furthermore, if the implementation of the semantic wiki supported new features, it could be extended to make use of them.
Refactorings describe how to appropiatelly perform transformations in the wiki.
However, they say nothing about when they should be applied. Fowler [
Dening bad smells may help determine when to apply each refactoring. A semantic wiki bad smell is a symptom in the semantic structure of a semantic wiki that possibly indicates a deeper problem, and suggests that a refactoring should be applied. It must be said that the detection of a bad smell does not necessarily implies a real problem. It must be analyzed in the current context and decide whether it should be applied or not a refactoring.
Each bad smell is dened with: a name ; a description, which describes the bad smell in informal language; the related refactorings that should be applied to remove the smell; and a detection mechanism . The detection mechanism may simply involve the execution of a query to the wiki knowledge base, or may apply more sophisticated methods such as data minning techniques.
As with refactorings, it is not the objective of this paper to dene a complete catalog of bad smells. We will rst describe as an example the Twin categories bad smell and then present a preliminar list of other possible ones.
The Twin categories bad smell describes the case when two categories appear together in categorizations very frequently. The rst reason why this bad smell can be detected, is if two categories have the same semantic but dierent names. This case is intrinsic to the collaborative way of semantic wikis. This situation can arise because a user does not know a category already exists, or because of users belonging to dierent professional stu or speaking dierent languages. The consequence of this problem is that a category is duplicated.
The second possible cause is that the twin categories dene a subcategory relationship. The example presented in section 2 describes this situation. Because of the lack of the subcategory relationship between the categories "Capital City" and "City", every time a resource is categorized with category "Capital City", it should be also categorized with category "City". To remove the bad smell in this case, the "Create subcategory relationship" refactoring should be applied.
The following is the full denition of this bad smell:
Description Categorizations of two categories categoryA and categoryB appear together very frequently.
Related Refactorings 1. Unify categories
Cause: The two categories describe the same category.
Example: categoryA = "LIFIA", categoryB = "LIFIA Lab" 2. Create subcategory relationship
Cause: The two categories describe a subcategory relationship.
Example: categoryA = "Capital city", categoryB = "City" Detection Mechanism In this case, we decided to use a semantic query as the detection mechanism. The semantic query is expressed in SPARQL query language, and is based on "SPARQL 1.1 Query" 4 specication.
SELECT DISTINCT ? categoryA ? categoryB WHERE { ? categorizationA has_subject ? subjectA ? categorizationB has_subject ? subjectA ? categorizationA has_object ? categoryA ? categorizationB has_object ? categoryB .
FILTER ((? categorizationA != ? categorizationB )
&& (? categoryA != ? categoryB )) } GROUP BY ? categoryA ? categoryB
HAVING ( count (*) > PARAM )
Table 2 presents a list of other possible semantic wiki bad smells. 4 http://www.w3.org/TR/2009/WD-sparql11-query-20091022/ Name Description Concept too catego- A concept belongs to too many categories. This symptom may exrized pose the fact that the concept describes more than one real concept. Divergent property Instances of a property diverge in range and domain. A property is used with many semantics.
Twin properties Annotations of two properties appear together in the same resources very frequently.
Resource with no se- A resource is not subject of any semantic annotation. mantic annotations Large category
A category is object of too many categorizations.
Table 2: List of semantic wiki bad smells 4.4
operations Automating the detection of smells is a necessity as the wiki grows in size and semantic knowledge. Dening a detection mechanism such as a semantic query for each smell, makes it possible to nd all the occurrences of a bad smell automatically. Integrating a tool for the detection of bad smells in the semantic wiki would allow users to look for quality problems with less eort.
The mechanics of the refactorings describe an ordered way of applying transformations, consisting in a series of simple actions. However, it could become tedious and time-consuming to execute those actions by hand. Moreover, the chances of making mistakes and introducing new errors are increased. For wiki refactoring to be a productive strategy to assist semantic wiki evolution, eort and risk must be minimized.
Fortunately, many times it is possible to have a refactoring automation tool. Take for example the Create subcategory relationship refactoring. You have several changes to make and check for correctness if you do it by hand. With a refactoring automation tool, one simply selects both categories (subcategory and supercategory) and launches the refactoring. The refactoring tool applies all the steps of the mechanics as part of the same single transaction. The whole process takes seconds instead of several minutes. Moreover, the refactoring operation ensures that no action is lost and no bugs are introduced. 5
Semantic wiki refactoring is an approach to detect quality problems in semantic wikis and assist users in the process of solving them. It is inspired by the key principles of software refactoring. We have discussed the problem of evolving semantic wikis, presented the core model of our approach, and introduced extensible catalogs of semantic wiki bad smells and refactorings.
As future work to complete and extend this investigation, it remains to complete the catalogs of semantic wiki bad smells and refactorings. A categorization should be dened to achieve a better understanding. In other respects, the tools to automate the semantic wiki refactoring operations and semantic wiki detection of smells should be developed. It will allow to carry out experimental evaluations to check the eect of a refactoring strategy in the evolution of semantic wikis.
In other sense, as wikis have a strong social component, it can be investigated the social factor in a semantic wiki refactoring strategy. In this order, collaborative detection of smells and collaborative testing of refactorings should be studied. The rst one arises as a necessity because some bad smells are difcult to be detected by automated detection mechanisms, e.g. a bad smell to detect inappropiate names for categories. We propose a social detection mechanism in which users could collaboratively agree the presence of a bad smell. The second takes the idea from software engineering agile methods. They advocate the use of automated unit testing to ensure that no bugs were introduced and the success of a refactoring. Adapting this idea, we propose a social testing in which wiki users could collaboratively state if a refactoring was successful or not.
Finally, future work will deal with refactoring of wiki’s tacit knowledge. Tacit knowledge should be considered in the refactoring operations, and could also be the source of bad smells.