This paper describes how we extended the SIOC ontology to take into account particular aspects of wikis in order to enable integration capabilities between various wiki systems. In particular, we will overview the proposed extensions and detail a webservice providing SIOC data from any MediaWiki instance, as well as related query examples that show how di erent wikis, designed as independant data silos, can be uniformally queried and interlinked.
The SIOC Ontology { Semantically-Interlinked Online Communities [
However, only a few work have been done so far regarding wikis, semantic wikis and the SIOC ontology. While the SIOC Types6 module already provides the Wiki and WikiArticle classes that can be used to represent the basic objects manipulated by wikis, some particular features of wikis such as pages versioning and backlinks are not taken into account, neither in the SIOC core nor in its modules. Yet, providing wikis information using SIOC would have several advantages in terms of integration with existing and constantly dynamically-created
SIOC data, as well as interlinking with other RDF data for advanced querying purposes. For instance, one will be able to run the same SPARQL query to nd latest created items on a MediaWiki instance or on a WordPress weblog. Hence, we recently worked on extending the SIOC ontology for this purposes, as well as providing a SIOC exporter for MediaWiki, potentially creating millions of SIOC-based RDF documents from various popular wiki services.
This paper is organized as follows. First, we will go through an overview of wiki features that are important to consider in such a modeling approach and explain how we took them in consideration in regards of the SIOC ontology and how we extended it based on this analysis. Second, since some wikis already expose their data in a machine-readable form thanks to Semantic Web technologies, we will focus on a state of the art of existing models that achieve the same goal. Then we will detail how we built a webservice that translates any MediaWiki wiki page to RDF using the newly-extended SIOC ontology. We will particularly focus on how this service produces RDF data compliant with the Linked Data principles and how it relates to initiatives such as DBpedia. Then we will show some relevant query examples, from advanced queries in a single wiki to cross-querying capabilities. Finally, we will conclude the paper with an overview of future works on the domain. 2
In this section we spot and explore what we consider being the typical and fundamental features of wikis in terms of structure and social interactions. Typically wikis allow editing of documents and, by de nition, allow multiple users to simultaneously contribute to the content; they track history of changes so that pages can be restored to previous modi ed versions; they include comments or discussion areas; they link to other external sources or within the wiki; they describe categories into hierarchical structures. For each identi ed feature, we give a brief overview of its goal, and detail how we extended, and generally use, the SIOC Core ontology7 and its Types module8 taking each feature into account in our modeling approach. 2.1
Multi-authoring. A fundamental feature of wikis is that multiple users are allowed to modify the same content, enabling some kind of collective intelligence process. In this regard the semantic infrastructure should provide a model to identify users and theirs modi cations, marking events with a corresponding timestamp.
This feature can be modeled using the class sioc:User as object of the property sioc:has_creator that describes a user account in an online community
site, and which is a subclass of foaf:OnlineAccount. In this way a foaf:Person could be linked to several sioc:User belonging to di erent wiki sites. Another way to model the relationships between pages and their authors is to reuse properties from the Dublin Core ontology, i.e. dc:contributor (or dc:creator) and dcterms:created. Yet, these properties do not link to a user URI but to a simple text string, which can be an issue when querying information, especially for cross-querying as we will detail in section 5.
Categories. Wiki pages are generally related to categories, that allow
readers to nd sets of articles on related topics. Categories can also be organized
in a tree-like structure and their semantic model should mantain the original
taxonomical structure. In this regard an appropriate solution is provided by
the SKOS9 vocabulary [
As regards the SIOC ontology, a sioct:Category class was already present into the SIOC Types module, allowing only the modeling of a at set of category names. Hence, we decided to declare this class as a subclass of a skos:Concept, giving it the ability to use the wide SKOS ontology capabilities to organize categories into advanced taxonomies. Moreover, thanks to the sioc:topic property, one can link any wiki page to such category.
Social tagging. While not all wiki engines support that feature, we believe this is particularly relevant, especially as it o ers an open and user-driven classi cation scheme for wiki pages. The use of tags lead to a non-organised but dynamic organisation process, known as a "folksonomy", rather than the more widely used hierarchical structures.
The properties sioc:topic and dc:subject can be used to represent tags
related to a particular wiki page, either using URIs for these tags (with sioc:topic)
or simple keywords (dc:subject). In addition, vocabularies such as the Tag
ontology [
Discussions. Several wikis associate a discussion page to every wiki page, so that each user is able to comment and argue his point-of-view on the topic. On a discussion page, people can discuss about the article subject, or about the way that subject is presented (see the Wikipedia's approach10). A rst modeling solution could be to simply keep the native wiki text format of the wiki and just semantically link the discussion page to the related article page.
The SIOC's main class responsible for the modeling of a discussion is the
sioc:Forum class, but there could be other speci c classes that are more suitable
9 http://www.w3.org/2004/02/skos/
10 http://en.wikipedia.org/wiki/Wikipedia:Talk_page_guidelines
for these discussion purposes, as de ned in the Types module. The appropriate
class to choose depends also on the type and style of the discussion page. So it has
been necessary to identify a proper attribute to link a wiki page to its discussion
page. In this regard we decided to add a sioc:has discussion property to
the SIOC Core ontology, with domain sioc:Item and open range. This choice
has been done in order to make this property reusable also in other contexts,
for instance linking a simple webpage to a discussion forum. The discussions
happening within the related sioc:Forum can then be modeled either as
wikistyle discussions or threaded ones, and that feature also allows us to re-use
advanced SIOC-based argumentative discussion modeling as de ned in [
We modeled this feature using the already existing sioc:links to property. This property identi es links extracted from hyperlinks within a SIOC concept and is a subproperty of dcterms:references. It is important to remember that this property has to be de ned into the RDF description of the original wiki article which links back to the wiki article. Hence, to model for instance that the Wikipedia page about "DERI" features a backlink from the page about "RDF", the following statement would be added into the RDF description of DERI's page.
< http :// en . wikipedia . org / wiki /
Resource_Description_Framework > sioc : links_to < http :// en . wikipedia . org / wiki /
Digital_Enterprise_Research_Institute > .
Listing 1.1. Representing backlinks Pages versioning. Usually all editable pages on wikis have an associated page history. This history consists of the old versions of the wikitext, as well as a record of the date and time of every edit, the username or IP address of the user who wrote it, and their edit summary. All this is usually accessible through a special "history" page which shows time-ordered links to all the revisions. Commonly the latest revision of a wiki page has always the same URL (alias name), meanwhile older versions have further parameters appended to the URL.
The versioning of pages could be modeled in several ways. Taking into account other semantic wikis, that we describe in Section 3, we took inspiration from other existing approaches. Then we de ned our own di erent model because we wanted to keep the pros of each model and we did not nd one capable to satisfy completely our needs. An important requirement we take into account is the fast and simple browsing capability that the model should have. For this reason we chose to use transitive properties to express the temporal relation between revisions of a wiki page. The model is displayed in Fig. 1 and all the used properties are now de ned in the SIOC Core ontology.
http://wikiexample.org/PageName next_version previous_version earlier_version latest_version http://wikiexample.org/PageName_Vers_X next_version
previous_version http://wikiexample.org/PageName_Vers_Y next_version
previous_version http://wikiexample.org/PageName_Vers_Z later_version
The next/previous version properties link only the next/previous revision of a generic sioc:Item. Meanwhile earlier/later version are de ned as transitive properties and as super-properties respectively of next/previous version. The main advantage of the de nition of transitivity and the declaration of superproperties, is that they can be inferred automatically by a reasoner. Hence, using an OWL level reasoning engine, when modeling a WikiArticle (or a sioc:Item in general), it is only necessary to describe its previous and next revision and the transitive super-properties will be automatically inferred by the system. This can also be convenient during the querying process (described in Section 5): if it is necessary to get all the earlier versions of a wiki page, with transitivity it is su cient to use the sioc:earlier version transitive property, while in the other case, it has to be implemented a query that recursively "jumps" on each sioc:previous version of the latest wiki article. Another introduced property is the sioc:latest version which points always to the newest revision. Usually it is used in combination with an alias name of the latest version so that it is not necessary to change the referred URI in all the earlier versions as soon as a modi cation happens. All the wikis we analyzed adopt this solution as it addresses scalability. 2.2
All the changes we made to the SIOC ontology are summarized as follows: { De ned the sioct:Category class as a subclass of skos:Concept. { Added a sioc:has discussion property, with domain sioc:Item and open range. { Added a sioc:latest version property, with sioc:Item as domain and range. { Added two transitive properties: sioc:earlier version and sioc:later version, with sioc:Item as domain and range. { De ned sioc:later version as inverse property of sioc:earlier version. { De ned sioc:next version as a subproperty of sioc:later version. { De ned sioc:previous version as a subproperty of sioc:earlier version. 3 3.1
While our aim is to model wiki features by extending SIOC, several vocabularies have been already proposed to achieve this goal. We will overview some of them in this section, by distinguishing models created with a general purpose and models created for a particular wiki engine but nevertheless available on the Web. In addition, it is worth noticing that we focus here on models and tools de ned to represent the structure of wikis and not on the ones that allow domain ontology modeling and population in RDF(S)/OWL from the wiki itself, while these two levels of semantics can be obviously combined.
As regards generic models WikiOnt11 [
In addition to the previous models we considered some particular wiki engines
that expose their data in RDF providing an RDF vocabulary for such export.
IkeWiki13 [
Semantic MediaWiki15 (SMW) [
Finally, regarding the use of SIOC for wikis, we can mention UfoWiki [
Based on the previous analysis, we produced a comparison matrix, to underline the pros and cons of each approach. We may conclude that multi-authoring is a feature supported by the ontologies of all the wiki models, and this is because it is an inescapable characteristic of a semantic wiki. On the other hand backlinks and versioning are not modeled by most of the considered wikis. These two features are addressed only by SweetWiki, with the exception of WIF developing a very simple versioning solution. Moreover, some features that are not modeled by these vocabularies could be added by external vocabularies, as for instance social tagging. Finally the most complete model to take into account is SweetWiki, being able to accomplish to every requirement but the discussions. 14 http://sweetwiki.inria.fr/sweetwiki 15 http://semantic-mediawiki.org Multi-authoring
Categories Social Tagging
Discussions Backlinks Versioning
IkeWiki SweetWiki SWIVT WikiOnt WIF SIOC p p p p p p p p p p p
p p p p p p p p p
In order to see implications of our extension, our aim was to build an exporter from a popular wiki platform, so that it can expose its data in RDF using our proposed model. Hence we decided to create a web-service application to export any MediaWiki instance. MediaWiki is one of the most popular wiki platforms, hosting all the Wikimedia Fundation wikis (i.e. Wikipedia, Wiktionary, etc.) and propulsing more that 25 millions of wiki articles from di erent wiki sites16. 4.1
In order to export SIOC data from MediaWiki's wikis we implemented a webservice, written in PHP, that exports a wiki article in RDF with the structure we explained in the previous sections. The webservice is publicly available at http://ws.sioc-project.org/mediawiki/. 16 http://s23.org/wikistats/largest_html.php
The MediaWiki exporter is relatively lightweight and built thanks to two PHP classes: the SIOC-Mediawiki exporter itself and the already existing SIOC API17. Our approach combines the use of the MediaWiki API as well as the SIOC PHP API { that has been extended based on the previously-detailed ontology changes { to create SIOC data. The exporter class is the part responsible for querying the MediaWiki API and parsing the results, and the SIOC API is responsible for exporting the content in RDF. The script indeed uses the MediaWiki API to get all the information about the article inserted in the form, with the following process (as represented in Fig. 3): { it automatically discovers the API location (if not detected it is possible to manually specify the API path in the proper text eld); { it connects to the API sending HTTP requests as queries; { it parses the results of the queries and lls in the proper variables; { it calls the SIOC API to export in RDF the fetched structural information and outputs the results in RDF/XML serialization.
User query RDF Output
SIOC MediaWiki webservice
MediaWiki
API
SIOC PHP
API
One of our goals with this exporter was not only to create RDF data from any
MediaWiki page, but also to easily allow interlinking between various wikis, as
well as between wiki data and other RDF data, whatever it is social data modeled
with FOAF or SIOC or any other kind of RDF data. Hence, we followed the
Linked Data best practices de ned in [
Particularly, to o er a better browsing experience and ease the process of crawling SIOC exports of MediaWiki instances, our webservice automatically 17 http://wiki.sioc-project.org/index.php/PHPExportAPI produces rdfs:seeAlso links between wiki pages. Actually, more than a simple link to the wiki page, the exporter provides a link to the related RDF document, as we can see in the following Listing 1.2 related to a particular sioc:User. As we can also notice in that example, we distinguish the concept itself (i.e. User:StefanDecker) and the related RDF page. These seeAlso links are very useful not only to provide link to other related RDF documents, that can be used for instance when browsing data with Tabulator, but also in a crawling perspective. A RDF crawler could easily follow all the seeAlso links found on every document and continue to crawl. In this regard, for example, we crawled and exported entire wiki sites just following these links.
< sioc : User rdf : about =" http :// en . wikipedia . org / wiki / User :
StefanDecker "> < rdfs : seeAlso rdf : resource =" http :// ws . sioc - project . org / mediawiki / mediawiki . php ? wiki = http :// en . wikipedia . org / wiki / User : StefanDecker "/ > </ sioc : User >
Listing 1.2. Modeling a user in the MediaWiki exporter
Another interesting feature is the linkage to the corresponding DBpedia18 resource, if the article belongs to the english Wikipedia. Since DBpedia semantically models the content of a Wikipedia page, this connection is very useful to link semantic data about the content and the structure of a wiki article. DBpedia resource URIs are used in rage of the foaf:primaryTopic property, this because it relates a document to the main thing that the document is about. 5
In order to evaluate our proposal, we exported and crawled di erent MediaWiki
instances. Four di erent wikis have been crawled { using for each crawl a single
entry point thanks to the use of the rdfs:seeAlso links { each one belonging to
the same area of interest in order to have a high probability of shared topics and
users: Semanticweb.org19, Protege Wiki 20, RDFa Wiki 21 and the ONTOLORE
Karlsruhe wiki22. In total, we collected about 1GB of RDF data and loaded it
in Sesame [
A rst example of advanced querying for a particular wiki is the ability to answer to the following question: "what are the collaborating users that worked alternatively on the same wiki article?". In Listing 1.3 we provide the SPARQL implementation of this query.
SELECT DISTINCT ? wikiArt ? Contrib_a ? Contrib_b WHERE { ?x sioc : latest_version ? wikiArt . ? wikiArt sioc : earlier_version ? VersA . ? VersA sioc : earlier_version ? VersB ;
dc : contributor ? Contrib_a . ? VersB sioc : earlier_version ? VersC ;
dc : contributor ? Contrib_b . ? VersC dc : contributor ? Contrib_a .
FILTER (? Contrib_a != ? Contrib_b ) . }
Listing 1.3. Identifying collaborating users
In Fig. 4 we display a diagram that summarizes the above query, meanwhile in Fig. 5 we show the results we got querying on our SESAME triplestore. As we can see, this query takes advantage of the transitivity of the newly created property sioc:earlier_version, since we identify users that worked on earlier versions, and not only immediately on the previous one.
?wikiArt
sioc:earlier_version sioc:earlier_version sioc:earlier_version ?VersA ?VersB ?VersC dc:contributor dc:contributor dc:contributor ?Contrib_a ?Contrib_b
The query results provide the article URI and the two usernames in case the rst user (?Contrib a) re-edited the article after a modi cation made by the second user (?Contrib b). It enables you to look for users sharing the same interests and knowledge areas. The query is important expecially in a social semantic context.
Another interesting feature of our approach is the ability to do cross-wikis querying, since they are based on the same model. Obviously, one can argue that since all the exported wikis are based on MediaWiki, the same approach could have been used simply with the MediaWiki API. Yet, our proposal has many advantages as it relies on SPARQL instead of a particular API and it provides advanced inference capabilities that the original API does not o er. The following query identi es users involved in di erent wikis, looking for the same usernames.
SELECT DISTINCT ? creator1 ? page1 ? page2 ? wiki1 ? wiki2 WHERE { ? page1 sioc : has_container ? wiki1 ;
dc : contributor ? creator1 . ? page2 sioc : has_container ? wiki2 ;
dc : contributor ? creator2 .
FILTER ( str (? creator1 ) == str (? creator2 )) .
FILTER ( str (? wiki1 ) != str (? wiki2 )) . } Listing 1.4. Identifying pages created by a single user in di erent wikis While this is a very simple query it requires high computation capabilities when ran through a large number of di erent wikis. Hence, in Fig. 6 we display a screenshot of the results we get after running the same query between the Semanticweb.org wiki and the Protege wiki. Instead of also displaying all the other details, such as the related wiki pages and the two wiki containers, we show only the distinct usernames of the found users.
Yet, as this query relies on a FILTER clause, it will identify common users only if they use the same account name on two di erent wikis. Moreover, we can imagine that some common account names will be used by di erent people on di erent wikis, e.g. JohnSmith. To that extend, we can bene t from the strong ties that exist between FOAF and SIOC and the fact we are modeling a wiki user using the sioc:User class. One person can indeed de ne in his FOAF pro le the various wiki accounts he owns, using simple foaf:holdsAccount properties. Then, the previous query can be adapted to deal not only with text strings to identify the user, but with their related accounts from the FOAF URI, so that a single query can be used to retrieve all the contributions of a user whatever the wiki used was. Moreover, since the wiki model is based on SIOC, the same query can be used to retrieve wiki pages, blog posts, etc. as follows.
SELECT DISTINCT ? content WHERE { < http :// example . org / js #me > foaf : holdsAccount ? account . ? account rdf : type sioc : User .
? content sioc : has_creator ? account . }
Listing 1.5. Cross-sites querying by combining FOAF and SIOC
In this paper we presented how the SIOC ontology and lightweight semantics can be used and extended to represent the structure of wikis in an uni ed way. We rst explained our motivations regarding some properties of wikis that we focused on in our modeling process, particularly focusing on a versioning process, and how we can bene t in this case of OWL reasoning capabilities. Then, we described how we designed a webservice to translate any MediaWiki page into SIOC data, following the Linked Data best principles to provide not only isolated RDF, but interlinked data. Finally, we gave some examples regarding how this data could be e ciently used for querying purposes.
While the work done here have been only applied to MediaWiki, further developments may include exporters and plug-in for other platforms to enable better cross-wikis integration. We also consider extending the versioning system de ned in SIOC regarding wiki pages to other user-generated content. Moreover the semantic modeling of a wiki article might be improved adding more details about the content of the article itself. One of our goals is also to run crossqueries between our Wikipedia export and DBpedia, for instance to identify which people where the most active on a particular wiki page or topic. Finally, we also believe that this article gives a complete and nice overview regarding how to extend an ontology such as SIOC for particular purposes. 7
The work presented in this paper has been funded in part by Science Foundation Ireland under Grant No. SFI/08/CE/I1380 (Lion-2).