Wikis are a great tool inside the Social Web, as they provide the chance of creating collaborative knowledge in a quick way. Semantic wikis are becoming popular as Web technologies evolve: ontologies and semantic markup on the Web allow the generation of machine-readable information. Semantic wikis are often seen as small semantic webs as they provide support for enhanced navigation and searching of their contents, just what the standards of the Semantic Web aim to o er. Moreover, the great amount of information normally present inside wikis, or any web page, creates the necessity of some kind of ltering or personalized recommendation in order to lighten the search of interesting items. We have developed TasTicWiki, a novel semantic wiki engine which takes advantage of semantic information in order, not only to enhance navigation and searching, but also to provide recommendation services.
A wiki is a web site with collaboratively edited pages. Users of the wiki perform
these editions through the browser, in a quick way and without restrictions. Each
page or article has an unique identi er, so they can be referenced from anywhere
inside or outside the wiki. The general features of wikis are the following [
We have developed a wiki engine, TasTicWiki, which seizes semantic technologies in order to o er sophisticated functionalities as well as semantic-enhanced recommendation services, in order to enlighten the tedious searching tasks derived from the potential existence of a vast amount of articles. In the next sections we will explain how this objectives are achieved as well as the architecture and features of TasTicWiki.
Semantic Wikis are traditional wikis extended with semantic technologies like OWL or RDF. The goal of this enrichment is to make the available information machine-readable, so presentation, navigation, searching and even edition can be improved in a sophisticated way. This is usually done by adding meaning to the strong linking present in every wiki: the links are not mere hypertext anymore, as they represent meaningful relations among articles, or between articles and data types.
Common features of all approaches to semantic wikis are the following [
In this section we brie y introduce how semantics can be taken advantage of in the context of recommender systems, and how it improves the results as they take into account the truly underlying reasons that determine the users satisfaction or dissatisfaction about the items.
Traditional Collaborative Filtering algorithms proceed by calculating
similarities between users or between items [
If semantic features are taken into account, then the similarities could be computed according to them. This is what we call Semantic Filtering Recommendation. Indeed, the semantic features are the underlying reasons owing to which the items are similar or not. As we will see in section 4.5, our item-based approach for developing for a semantic recommender systems is based on domain ontologies containing the semantic attributes for the items. We use OWL ontologies and a reasoner able to classify the described resources. 4
TasTicWiki is a wiki engine that supports the creation and management of semantic wikis with recommendation services. This engine is born from the mixture between the ideas of semantic wikis and semantic recommender systems. Both of them are utterly better o with the addition of semantic annotations, and we have developed an architecture where this extra information can be used in an homogeneous way, both for the semantic wiki and the recommendation system sake. In fact, we can see the recommendation services as an enhancement of wiki search, which is purely one of the leading leitmotivs of adding semantics to wikis. 4.1
In gure 1 we illustrate the architecture of TasTicWiki.
Admin interface Configuration module
Editor
Renderer
User interface
Semantic search Recommender
Admin module Keyword search
Wiki Database interface Article Database
Articles
Wiki Database
Knowledge
Base
Every article in TasTicWiki is stored inside the database and it also corresponds to an instance inside the knowledge base, i.e., the ontology. The semantic metadata is thus stored separately from the page content, but we have set up a cache inside the database that will serve basic semantic information at the time of rendering and making certain type of queries, for the sake of reducing time processing. We use the knowledge base only when an article is rstly classied and when the users request queries involving complex axioms. The modules over the database interface are the ones that implement the functionality of the wiki. The admin module is devoted to administrative tasks such login, logout, registration, management of user pro les, etcetera.
Knowledge Base. TasTicWiki relies on a background ontology preloaded in the knowledge base. This domain ontology depends on the speci c topic of the wiki. For example, we have developed a domain ontology in the eld of tourism, since we have implemented a wiki1 for a tourist information system. This background ontology has to ful ll some conditions in order to be used as a logic model in our knowledge base. It needs two main classes or concepts: one for storing the articles and another one for the di erent features the articles may have. We need 1 http://khaos.uma.es/wikitrip at least one role connecting the former with the latter, i.e., a hasFeature role -but nothing prevents the existence or others roles.
As an example, we brie y explain the skeleton of the tourism ontology we have developed. It has a Tourist Service class devoted to store the instances of the regular articles inside the wiki. These instances are related to the instances inside the class (or subclasses of) Tourist Service Feature, via some roles including hasFeature -we have three more roles as sub roles of the last one: hasTradeActivity, hasSportActivity and hasSpecialty. In addition, we count with some data roles establishing properties like the price, opening and closing times, etcetera.
In order to make the ontology expressive enough, we have de ned some sub classes of the article class (i.e., the Tourist Service one). They are in much cases de ned with complex axioms, e.g., there is a class called Department Stores which is de ned as a service with at least two di erent trade activities. Another example can be Inexpensive Accommodation, de ned as every Accommodation Service whose price is lower than thirty euros. The idea behind these de nitions is that the Knowledge Base will perform some reasoning over the annotations the users include inside the text of the articles. 4.2
When creating or editing an article, users in TasTicWiki may include two kinds of semantic annotations. This is done by special wikitext commands, and they consist in: a) annotations about features and b) annotations about categories the article belongs to. In a), the system needs the user to specify both some role and some feature value (or equivalently, some data role and some data value). In b), only the name of the category is needed. In 4.6 we will show an example of the wiki text used to add this semantic annotations. 4.3
When rendering an article, TasTicWiki provides a Semantic Box, which summarizes all the available semantic metadata. The kind of information present in the Semantic Box depends on the type of article that is being rendered. Indeed, inside TasTicWiki exists a clean classi cation of articles depending on their concrete roles, as we explain in the next section. In gure 2 we can see an article with its Semantic Box.
Types of articles. In this section we describe each type of article in TasTicWiki and some details about them.
{ Regular articles: they are the standard articles of the wiki, i.e., those whose purpose is just spreading knowledge about some particular topic. In our example, they would be the articles standing for Tourist Services. Users are allowed to insert semantic annotations in their wikitext. The information contained in their Semantic Boxes are: asserted features and categories (i.e., those explicitly speci ed by the users with semantic annotations) and inferred features and categories (those inferred by the reasoner). { Special articles: they represent ontology entities like categories, feature concepts (in which we can found lists with feature values), feature values themselves, roles and data roles. Users are not allowed to add semantic annotations on them, but they can edit the wikitext in a pure textual way. Their semantic boxes show structural information like sub and super classes, domains and ranges, etcetera.
Users may create regular articles and feature value ones, but not the articles corresponding to concepts or roles. In other words, they are not allowed by the moment to edit the architecture of the background ontology (only their instances). This is considered as future work on the TasTicWiki system. 4.4
Traditional wikis normally o er some kind of keyword, textual search. This sometimes is not powerful enough to retrieve the articles we need, as keywords do not really grasp the semantics underneath. In TasTicWiki we have developed a semantic search module, in which users, through a friendly, graphical interface, will be able to build and share complex queries based on complex ontological axioms.
It is not only about typical database search like tell me all the services with a
price lower than thirty. It goes beyond, as complex axioms aim to recover articles
following not only the explicitly provided information, but implicit knowledge
as well. As we are working with OWL ontologies, these axioms are the ones who
exist in OWL DL: cardinality restrictions, universal and existential quanti ers,
value axioms, negation axioms and membership axioms, with logical connectives
as glue. In gure 3 we can see the interface for building complex queries.
In Semantic Filtering Recommendation [
Analyzing users interactions. Inside a wiki we have several sources of information that can be taken into account at the time of computing the satisfaction of users. The direct one is collecting explicit ratings about the articles, asking for a numeric evaluation. But we also can take advantage of the previous behavior of the user inside the system: searchings, readings and editions. These last source is somewhat wiki-speci c and, though by the moment is only used as a numeric coe cient (i.e., we only focus on the quantity of editions), an immediate future work way is taking into account the quality of the editions, mostly the semantic ones. This source of information could be used not only for the recommendations sake (e.g., we could infer semantic categories or features of which the user is a connoisseur), but also for supporting the edition tasks, o ering suggestions of possible annotations that would go well with the current wiki text.
The con guration module allows the administrator of the system to decide a weighting coe cient of all these factors in order to compute the satisfaction degree that an article has for an user (e.g., we could consider that explicit ratings are more important than the rest of factors). We need this degrees in order to build the input for the recommendation algorithm described in the next section. Recommendation process. Providing we have a set of articles that satis ed a given user to some extent, computed from the study of the past interactions that the user has performed inside the wiki as we explained in the previous section, we are now able to compute the nal recommendations. Given a well-rated article, its neighborhood is the set of the n most similar articles in the system. The similarity between two articles is calculated as follows: simi;j =
jSIP (i) T SIP (j)j max(jSIP (i)j ; jSIP (j)j)
Where SIP (i) is the Semantic Item Pro le of the item (article) i, calculated by means of the Article Ontology -i.e, it is the set of semantic categories the item i belongs to. Note that similarities range from 0 to 1.
Once we have computed all the neighborhoods of the well-rated articles, we recommend those items in the union of all the neighborhoods that ful ll the next two conditions: the article has not been read by the selected user and the Recommendation Factor, which is a measure of how good the recommendation will be for an user, is bigger than a certain number, called Recommendation Threshold 2. The Recommendation Factor is calculated as follows:
RF (i) = r(f ather) simi;father
Where father is the article from which the neighborhood was calculated. If an article belongs to more than one neighborhood, then we take into account the biggest factor of all the possible recommendations. The Recommendation Threshold that we use to lter the items depends on the ratings domain and could be parametrized, as well as the size of the neighborhoods -in terms of percentage of the total number of articles in the system. 4.6
Let us imagine an user who is going to use the wiki for a while. We will see through a simple, brief example how this experience will be like. In http:// khaos.uma.es/wikitrip we can nd the concrete wiki used for this example, called Wikitrip, developed in the topic of tourism services inside Malaga, Spain. 2 This threshold can go from 0 to the upper limit of the ratings, e.g., from 0 to 5 Editing an article. The user wants to create an article about a hotel where he stayed during his last holidays. It was a three-star hotel with lift, private bathroom and a price of forty euros. Moreover, he consider that its category is medium. Among other textual information, the user wants to specify this four semantic annotations, task which will be performed by special wikitext commands: ...Astoria Hotel has [[feat:hasFeature:with lift/lift]], [[feat:hasFeature:private bathroom]] and a price per night of [[dfeat:hasPrice:30]] euros. Is is a [[cat:Medium Category]] service and...
As we can see, special, di erent commands are used depending on whether we are specifying features (feat ), categories (cat ) or data features (dfeat ). Navigation and presentation. Once the user has saved this article, it will be presented with links in the places where the semantic annotations were inserted. { For features (i.e., with lift and private bathroom) a link to the corresponding feature value article will be rendered. { For categories (i.e., Medium Category ) a link to the category article will be rendered. { In the case of data features, it makes nonsense to render a link to the value 30 euros. Instead, an special type of link is generated: a query of all the articles inside the wiki which have a price of 30 euros.
Inside the Semantic Box of the article the user will nd the most interesting pieces of information. Here, the system shows the implicit information extracted from the semantic annotations the user has inserted. Speci cally, we will nd that the article belongs to four categories: one explicitly inserted by the user (Medium Category) and three inferred by the reasoner, this is: Tourist Service, Accommodation Service and Inexpensive Service.
The information about the features will not be rendered in the semantic box as links to articles. Instead, these links lead to special queries which retrieve all the articles in the system related to the same value through the same role. In the case that implicit feature relations are inferred, they will be shown inside the Semantic Box as well.
Searching. The user can do some searching inside the wiki. It could be in a pure textual way, as in many traditional wikis, but also in a semantic way. Thanks to the underlying reasoner and a proper interface, the user will be able to make queries like: All the Catering Services with either a price lower than thirty or with at least three di erent specialties. Once the result list is computed, the user can read, edit and rate the given articles. Recommendations. Once the user has read, searched, edited or rated some articles inside the system, the recommendation module will be able to compute a list of recommended items as we explained in section 4.5. If the user does not have any experience inside the system, then this list will be made up of the most popular articles (measured by explicit ratings). 5
Fred Durao and Peter Dolog have proposed a tag-based recommendation [
TasTicWiki is currently in its beta version, providing the services we pointed out in previous sections. Some future work is actually needed: an internationalization module, some improvements in the edition interface -as well as taking advantage of semantics in the edition tasks-, OWL/RDF export, and of course, the possibility of editing the underlying ontology in a collaborative way.
Other issues like performance are also to be studied, since we are using rich,
expressive ontologies that do not go well with complexity. Complex queries are
hard to solve, and we need scalable reasoning able to respond within a tolerable
time. DBOWL [
Moreover, when complex queries are requested, we need the knowledge base to be prepared and adapted to every previous change in the annotations of articles. This means, in reasoning terms, that the underlying ontology needs to be classi ed regularly in order to show complete results, so more solutions in this eld are to be investigated. Furthermore, an evaluation of the recommender system inside the wiki needs to be done. TasTicWiki is a wiki engine that allows the creation and management of semantic wikis with recommendation services. Semantic metadata improves presentation and navigation inside the wiki. TasTicWiki relies on background, rich ontologies that make possible advanced reasoning tasks, improved searching and some sophisticated functionalities as content recommendation.
Acknowledgments. This work was supported by the ICARIA Project Grant, TIN2008-04844 (Spanish Ministry of Education and Science), the pilot project Formacion y desarrollo de tecnolog a aplicada a la biolog a de sistemas, P07-TIC02978 (Innovation, Science and Enterprise Ministry of the regional government of the Junta de Andaluc a) and the project Creacion de un soporte tecnologico para un sistema de informacion tur stica, FFI 055/2008 (Tourism, Sport and Commerce Ministry of the regional government of the Junta de Andaluc a).