This paper details the main concepts and the architecture of UfoWiki, a semantic wiki farm { i.e. a server of wikis { that uses form-based templates to produce ontology-based knowledge. Moreover, the system allows di erent wikis to share and interlink ontology instance between each other, so that knowledge can be produced by di erent and distinct communities in a distributed but collaborative way.
During the last few years, various Web 2.0 services and principles - such as
blogging, wikis, social tagging and social networking - gained interest in corporate
environments, leveraging tools that people are more and more used to in their
personal life to the enterprise [
While some consider Web 2.0 and Semantic Web as being opposite concepts
with di erent origins and goals, we believe as others [
In this paper we will describe a semantic wiki-farm system, i.e. a wiki server where communities can setup new wiki instances, called UfoWiki { Unifying Forms and Ontologies in a Wiki { that aims to achieve this goal, currently in use at EDF R&D3. The paper is organized as follows. First, we will brie y introduce the limits of classical wikis and various implementations of semantic wikis designed to enhance wiki features thanks to semantics. Then we will introduce the features and the architecture of our semantic wiki farm, as well as novelties compared to current semantic wikis systems, especially the way we combine data and meta-data to keep some information about the knowledge created from wiki pages. We will then describe how people can use one wiki to create ontology instances thanks to form-based templates and emphasize on how the system interlinks data from one wiki to another one but also allows to re-use external data. We will then show how created data can be reused to provide advanced features in a single wiki but also for the complete wiki farm. 2 2.1
Among the numerous practices and tools that became popular thanks to Web 2.0, wikis o er new and interesting possibilities regarding collaborative knowledge management. Pages versioning, open plus non-hierarchical editing, hyperlinks and back-links provide useful services to gather and build knowledge within communities and business environments or in open environments as the Web.
Nevertheless, traditional wikis su er from the di culty for computers to exploit and reuse the knowledge they contain. A reader could learn from a wiki that EDF is a company that produces nuclear energy in France but a software agent will not be able to easily answer queries like "Is EDF located in France ?" or "List all companies known in that wiki" without natural language processing algorithms. Indeed, wikis deal with documents and not with machineunderstandable representations of real-world concepts and objects, as a reader does when browsing or editing a page. So, a wiki will model that "There are some hyper-links between a page titled EDF, a page titled France and a page titled nuclear energy", but will not be able to deduce anything about the nature of those di erent objects and their relationships, since pages do not carry enough semantics about the knowledge they contain (Fig. 1). 2.2
To bridge this gap between documents and machine-readable knowledge about
real world objects, data must be described in a way software agents interpret
and understand uniformly in order to reuse it e ciently. Ontologies [
France Nuclear energy
hyperlink Documents (wiki level)
EDF hyperlink
Knowledge perception gap
EDF is A
Company
Real wold (human mind level) features and Semantic Web technologies. While tools use di erent ways to produce this machine-readable data thanks to e orts of their community of users, they all share the common goal of providing value-added services from advanced pages browsing to query answering or even reasoning upon the created dataset.
Systems such as Semantic MediaWiki [
In these tools, semantic annotations are mainly used to create and maintain
ontology instances and relationships between them, as well as properties, thus
providing a real-world and machine-readable representation of the content
described inside the pages. They can help to enhance browsing capabilities of the
wiki, by suggesting related pages sharing similar instances or listing all pages
featuring a certain property as does Semantic MediaWiki. Moreover, new ways
to browse the data are available, like in OntoWiki that features map and
calendar view of existing data, while some tools provide a back-end RDF store that
allows to query data from the whole wiki and embed query results in wiki pages.
Finally, some tools also feature inferencing capabilities in order to deduce new
knowledge from the current state of the wiki and thus enrich user experience
in discovering new knowledge. For example, IkeWIki and OntoWiki can list all
instances of a given type taking into account instances of various subclasses.
Eventually, it seems important to reference DBpedia [
Regarding various aspects of semantic wikis that have been mentioned before, we created UfoWiki, a new semantic wiki farm system - i.e. a wiki server designed to setup and host several wikis - based on the following features, that will be described in the rest of the paper: { Ontology-based knowledge representation. Data created from wiki pages is represented in RDF and is based on a set of ontologies de ned by administrators of the wiki in order to avoid semantic heterogeneity problems of data modeling; { Usability. In extent of the previous point and in order to let users easily produce that ontology-based data, we focused on a combination of plaintext and intuitive forms to edit wiki pages, so that users do neither confront to a new syntax or to Semantic Web modeling principles; { Interlinking data While each wiki of the farm acts independent (regarding users that can access it, topics, and modeled knowledge), the system allows di erent wikis to exchange and interlink their data even if they do not share hyperlinks between each other, thanks to a common knowledge base for the whole system; { Modeling both data and meta-data. While our approach mainly focuses on modeling knowledge contained within wiki pages, we also separately represent the complete wiki server meta-data (wikis, users, pages, tagging actions ...) in RDF, combined with links between those two distinct levels of representation. { Immediate reuse of formalized data. RDF data created among the wikis must be immediately reusable to enhance browsing and querying capabilities of the system, either for a single wiki or the complete farm. Our system uses inline macros, that can provide semantic back-links in the wiki. 3.2
To achieve these goals, our system involves di erent components. The rst part
of the architecture consists in a set of ontologies that are used to model RDF
data from the wikis, whether it is data about the pages or about their content.
For the latter, ontologies must be de ned in RDFS or OWL depending on the
needs of the knowledge eld of the wiki. Regarding the RDF description of
wiki pages and user actions, we are using the SIOC ontology [
Then, the system features its web interface to create wikis, manage wiki forms and browse and edit wiki pages. This interface uses Drupal and is mainly based on a fork of the exinode module5 to let wiki owners de ne their forms. Each form is related to a given class - e.g. people (related to foaf:Person) or software project (doap:Project) - and each part of the form (a eld or a set of elds) can be related to an ontology property and also to a given class, which is used for the autocompletion features of the system. Thus, the editing interface of each wiki combines plain-text and structured parts in order to easily manage the creation of RDF statements according to the ontologies it uses, as we will see on the next section.
The last component of the system is the knowledge base of the wiki farm,
storing all created RDF statements thanks to a triple-store, using the 3store6
API. By storing in real-time all RDF data as well as ontologies in a single place,
it o ers querying capabilities for the complete data and meta-data of all the
wikis, but nevertheless keeps a trace of each statement thanks to its named
graphs compliance, so that queries can involve the complete wiki farm data or
only data of a given wiki. This store also manages basic inference capabilities
(subclasses and subproperties) and supports SPARQL [
User 1 edit
WikiApage
HTML hyperlink
WikiBpage
As most semantic wikis, our system automatically creates one main ontology instance for each wiki page, based on the page title. While some wikis do not explicitly assign them a given type and other rely on the page category to de ne it, our system uses the class assigned to the page form to de ne it. Regarding de nition of properties and relationships of each instance, we use a mix of plaintext and forms in the wiki editing interface, thus separating plain-text content from content to be modeled in RDF, as the Semantic Forms extension8 for Semantic Wiki or Freebase9 can do. When creating the page, translation from wiki content to RDF data is then automatically done thanks to the mappings de ned by wiki administrators between the form and a set of ontologies. We think that this combination of plain-text and forms to ease the modeling of RDF data (Fig. 3) has numerous advantages: 8 http://www.mediawiki.org/wiki/Extension:Semantic_Forms 9 http://www.freebase.com { First, as elds are de ned by the wiki owner for each type of page and so for each class, users know what kind of knowledge is relevant for the wiki regarding a given page and can focus on essential aspects in this context; { Moreover, as we kept a simple WYSIWYG eld for each page, any other relevant information can be added there. It can also help to participate in evolution of the model itself when regular patterns appear, even if the model must be edited manually in this case; { Users can bene t from autocompletion features, suggesting possible related instances by querying the RDF store with on-the- y SPARQL queries, thanks to AJAX technologies; { At last, in our system, this approach allows to create complex relationships and ontology instances inside a single page. While most semantic wikis allow only to create relationships between existing objects, a form part can correspond to a dedicated class in our system, o ering better ways to manage complex ontologies population. Moreover, in the page meta-data representation, we distinguish the main instance and the embedded ones, using two subproperties of sioc:topic we especially created to achieve this distinction.
Inline macro
Simple autocomplete
field
Complex instance field
While each page corresponds to a given ontology instance, instances are also created for each lled relationship eld where a class has been assigned. Then, if one later decides to create a wiki page for these instances, properties will be added to the existing ones. Moreover, when instances are not used anymore in any wiki, i.e. do not have any property, they are automatically removed from the RDF store to avoid orphan instances. From these aspects, the wiki really acts as a collaborative ontology population tool, bene cing from Web 2.0 features to provide this task. An instance can be created by a user, modi ed by another, then linked to a third one by another one and even can disappear from the knowledge base if a fourth user edit the page that contains its only reference and removes it.
As we saw in the previous section, our system allows various pages of a given wiki to add information about a single ontology instance. For example, we can create an instance in a wiki page and add a relationship from another instance in a di erent page than the one that creates it. Yet, our system goes further by allowing two di erent and disconnected wikis to manage information about the same instance in a distributed way, but keeping the trace of which wiki and which page - helped to create the information. Thanks to the combination of named graphs and the embedsKnowledge property we introduced before, the wiki farm can consider either the whole RDF graph, or subgraphs of RDF statements related to a given wiki only (Fig. 4).
Such a scenario might be useful in some corporate environments, where people do not want to allow anyone to access their wiki, but agree on sharing some expertise and data with others. By exporting only some parts of the wiki page in RDF (i.e. the instances and properties created from some elds of the form page), our model allows the webpage itself to be hidden to not-authorized people while the RDF statements can be exported and become available to a larger community. Moreover, due to our technical architecture that uses SPARQL and SPARUL, the system allows wikis that are distributed on a network (and not from the same wiki farm) to exchange data and interlink it the same way, in case they share a single common RDF database. The system currently do not deal with inconsistency between data from di erent wikis. We think that this issue should be dedicated to some reasoning engine, that would check inconsistency between produced statements thanks to OWL axioms de ned in the ontologies.
Moreover, instead of querying the complete knowledge base, queries can be restricted to data created from a single wiki by using this kind of SPARQL query: select ?page ?title where { graph ?data {
:EDF ?predicate ?object } . ?page :embedsKnowledge ?data ; rdf:type sioct:WikiArticle ; dc:title ?title ; sioc:has_container <http://example.org/wiki/6> .
<http://example.org/wiki/6> a sioct:Wiki . }
This process of combining the two levels of representation can also be used in the autocompletion eld, by restricting the autocompletion SPARQL queries to data created from a single wiki, rather than to the whole RDF statements.
WikipageA rdf:type sioct:WikiArticle embedsKnowledge athena:EDF geonames:locatedIn
Our system also allows to connect our data to external, publicly available, RDF data. At the moment, a single plug-in is available, to reuse the GeoNames10 ontology and knowledge base. Each time a form eld corresponds to a place and is assigned to the geonames:Feature class, the system queries the GeoNames webservice11 to retrieve the URI of the given instance. Thus, the updated local instances can be linked to external resources, bene cing from a global connection between our data and e orts of communities that help to build such knowledge base. Moreover, we not only link to the URI but also crawl the related RDF le to put in in the wiki knowledge base. Thus, it allow the system to provide geo-location features to end users, without the need for them to type the exact location (i.e. latitude and longitude) of each instance (eg: a people or a company), as they would have done using systems like Semantic MediaWiki and its Semantic Layers extension12. 10 http://www.geonames.org 11 http://ws.geonames.org 12 http://s89238293.onlinehome.us/w/index.php?title=Main_Page
In the future, we plan to implement new wrappers and linkage systems for
other RDF data, especially ways to link to DBpedia extracted knowledge, which
can help to provide additional information about instances created within the
wikis, and also contribute to the expansion of the Linked Data Web [
The main feature to enhance wiki browsing capabilities in our system is the use of inline macros, similar to inline queries of Semantic Mediawiki. Those macros are de ned by wiki administrators themselves, using SPARQL and PHP to render the results and are then called by users in wiki pages with simple hooks. Since all data are based on a set of prede ned ontologies, queries can be written without having to deal with semantic heterogeneity problems, as people that would have use di erent property names for the same one, e.g. isLocatedIn versus has location. The system then runs the query over the RDF store when the page loads, so that query results are always up-to-date. While queries can be complex, users simply type function names, with some arguments if needed, to use it in wiki pages. For example, [onto|members] will be translated in a query that will retrieve all people that are member of the organization described in a wiki page (Fig. 3, Fig. 5). Such queries take inference capabilities of the system into account, so that, for example, if they must list all organizations instances described in the wiki, they will also lists companies or associations if they have been de ned as subclasses of the rst one in the ontology. Finally, the administrator can decide that the macro will render a link to add new page in the wiki to create an instance of a given type, thus facilitating the process of creating new data.
Inline macro result featuring new page creation link Inline macro result
Fig. 5. Browsing an enhanced wiki page
Moreover, macros can take into account the way we combine modeling of data and meta-data in RDF export of wiki pages, so that a wiki can display a list of pages from another wiki for a given query, as the previous SPARQL snippet showed. It allows one wiki to bene t from the e ort of another community done in another wiki.
More generally, such queries can be seen as a way to move from classical wiki back-links to semantic back-links, as we bridged the gap between documents and Semantic Web formalized data. While a typical wiki could list thanks to its backlink feature that an organization page has an incoming link from a people page, our system takes advantage of the data formalism to be more speci c about the nature of this link, mentioning that this company employs that person, going from the document to the data layer. 5.2
Finally, those macros can display results according other rendering inter-faces, such as Google Maps, in case the needed geo-location information is available in the RDF store thanks to the integration of the GeoNames lookup service. Thus, while the result is similar to what can be done with the map view of OntoWiki, users do not have to manually enter the coordinates of each instance (e.g. a company) but simply ll a "City, (State), Country" eld, that will be used to retrieve the appropriate RDF data - including coordinates - from GeoNames an add it in our knowledge base. Here, we clearly see the bene t of using the same model (i.e. the GeoNames ontology) than an existing RDF dataset to include data from external services at zero-cost. The Fig. 6 displays the output map of a macro that retrieves the location of a given association and all of its members from a single wiki interlinked with GeoNames data in a single SPARQL query.
Fig. 6. Map view of the wiki data 5.3
Another feature of the system is a dedicated semantic search engine, taking into account existing instances described within the wiki (or used in a semantic tagging process) rather than plain-text only when retrieving data. When a user search for a given term in the wiki farm, the system rst nds the list of all instances related to this label, using (1) rdfs:label that can have be de ned thanks to the wiki pages and dedicated forms and (2) the moat:Tag instances that contains this term within their label and that are linked to existing instances thanks to a related moat:Meaning. Thus, if a user type the search term "France", the system will ask the user if he requires information about"EDF" (since it has "Electricit de France" as a tag) but also, of course, the "France" concept.
Then, the system will list independently: { All wiki pages - for each wiki, identi ed by their name - that have this instance as a main topic; { All wiki pages where the instance is an "alternative" topic (i.e. an instance created within a page); { All wiki pages "tagged" (thanks to MOAT) with this instance. Thus, it o ers various meta-data representation of the wiki.
Moreover, while we do not currently provide user friendly interface to generate new queries or macros, advanced users can run SPARQL queries over the RDF data.
In this paper, we described a prototype of wiki that combine structure and Semantic Web modeling capabilities to produce ontology-based and machinereadable data in a collaborative way. We showed how various wikis could be used to model and interlink knowledge about ontology instances in an open and distributed way. We nally showed how such knowledge can be used to enrich functionalities of the wiki. While this system combines some features that already exist in various prototypes, it focuses on usability for end-users, as well as, from the technical side, a way to model and link both data and meta-data, o ering capabilities to view di erent levels of annotation, either from a single wiki or for the complete set of wikis.
The system is currently in use at EDF R&D, where users have created more than 200 instances from various lightweight ontologies. We extensively use the GeoNames integration, making the geo-location feature easy to integrate in order to provide new and interesting ways to browse the wiki content. Inline macros are also useful for end-users since they allow to easily nd instances and related wiki pages. For example, we included a macro that lists, in a page dedicated to some company, all other organizations working on the same topics.
Regarding our future works, we will concentrate on adding new value-added functionalities to the wiki for end-users to ease the discovery of relevant information from the set of RDF data, as faceted browsing, as well as interlinking with other existing datasets. We will also focus on how to formalize wiki pages versioning in RDF, in order to see how statements about a given resource can evolve during its lifetime and track more precisely each change of information on a given ontology instance.
We would like to thanks the ID-Net team from EDF R&D for their input on the current experiments about our wiki farm.