Version control systems provide ways to ease collaboratively working on a set of source les. Due to the nature of RDF models that represent ontologies, there is a clear bene t on using those kinds of systems, and many well-known datasets and vocabularies are already being worked on collaboratively. However, there are domain experts who could provide feedback and add new knowledge to the data, but do not know how to work with version control systems or with RDF les directly. Wikibase provides a human-friendly interface with an underlying Linked Data model, and can be used as a publication service for the data where those experts can easily browse and add their knowledge. In this paper, we propose a system that automatically synchronizes RDF les hosted in a version control system with a Wikibase instance. We describe the system from an architectural point of view, and explain the main components needed for the synchronization of data. Some of the challenges for an e ective synchronization of RDF les with Wikibase are also addressed. This system is currently being used as part of the Hercules project to synchronize a research ecosystem ontology with a Wikibase instance.
Version Control Systems (VCS) have been used by software developers to
facilitate the process of working collaboratively on a set of source les. Developers
can greatly bene t from the discussion of individual changes and the
establishment of an acceptance work ow. Due to the nature of RDF models representing
ontologies, they are dynamic entities which may change as a consequence of
di erent reasons[
Commons License Attribution 4.0 International (CC BY 4.0). { Appearance of new information about concepts. { Changes in the domain being described.
This makes RDF les a perfect t for use with version control systems. However, some domain experts may not know how to work with Version Control Systems or with RDF les directly, but could still contribute useful information to the ontology creation and conceptualization. These users can work on an easy-to-use RDF browsing and publication service like Wikidata, where they can make modi cations to the underlying content through a web interface. The contents of both the VCS and the publication service need to be synchronized, so both ontology engineers and domain experts can contribute to the growth and evolution of the ontology.
In this paper we propose a synchronization system between RDF les, which are hosted on GitHub, and a Wikibase instance. As part of the Hercules project3, we have implemented this system and it is being used to synchronize an ontology which represents the research ecosystem4 with a custom Wikibase instance. This instance is not publicly accessible but we have deployed a public copy at https: //herc-core.wiki.opencura.com.
We have structured this paper as follows: we will start by brie y de ning some of the technologies used by the synchronization system and related work. In section 4, we will give an overview of the synchronization system from an architectural point of view. After this, we will illustrate the ow and operations made on the data in section 5. In section 6, we will go over some of the functionality that we are planning to add as future work to the system. Finally, we will give our nal conclusions in section 7. 2 2.1
Wikibase is an open-source knowledge base software-suite which drives
Wikidata, and makes collaboration easy for humans and machines alike. Since it uses
MediaWiki as its front-end, it provides users with an intuitive and easy to use
interface to interact with the underlying data model, based on semantic web
concepts[
The underlying infrastructure of Wikibase contains a SPARQL engine, which makes use of a BlazeGraph triplestore and allows the exposure of the data within Wikibase as Linked Data. Content negotiation mechanisms are also set up, so a Wikibase entity can be either viewed through the default HTML format displayed by the browser, or in other multiple formats, such as .json, .rdf, .ttl or .nt.
Therefore, one of the main strengths of Wikibase is that users working directly with it may not know the details of the underlying data model and infras
tructure, but can still collaboratively work with the linked data and add new information to it. 2.2
Wikidata Integrator is a Python library that serves as a wrapper around the
Wikidata API, providing tools to programmatically modify its contents. It
consists of the common code modules from a series of computer programs that
uploaded biomedical knowledge to Wikidata, and attempts to simplify the process
of creating Wikidata bots [
WebHooks are POST requests that are sent to a given URL, which can be
congured by the user, in response to a certain event that has occurred [
There are several ontology editors like the popular Protege6, which also o ers a collaborative web environment called WebProtege7. WebProtege provides useful features for collaborative ontology development, like user permissions and change history. A di erence between that approach and the proposal presented in this paper is that we can rely on GitHub project management tools like issues, releases and pull requests. Furthermore, with the use of Wikibase as a publication platform for the ontology we can also have access to the additional functionality from the software suite de ned previously. With the use of both GitHub and Wikibase we aim to facilitate the collaboration of external contributors to the evolution of the ontology.
The problem of making an e ective and e cient di between two given RDF
graphs has been for a long time a eld of study in the Semantic Web community.
In [
The W3C Semantic Web wiki maintains a list with various tools that can be
used to compare RDF graphs8. In our system we are using one of those tools,
RDFLib [
Although the complete work ow involves the use of GitHub and WebHooks to synchronize the content to a Wikibase, it is important to note that this is not necessary, and the synchronization system can be invoked independently to synchronize any given RDF data to a Wikibase10. 5
In this section we are going to go through the ow of data and inner workings of the synchronization system, from the modi cation of an RDF le to its synchronization to a Wikibase.
DataAccess/proto-tests/tools/rdfdi .py 10 For instance, the UniTest Wikibase, available at https://unitest.wiki.opencura.com, has been populated using just the synchronization system and an RDF le.
The overall process begins with the modi cation of an RDF le. These changes in the le may be distributed amongst many commits in the VCS. In Fig. 2 we provide an example where a subset of an original le is changed multiple times. Some new triples are added to the graph, while others are removed or modi ed.
Original file :knows owl:inverseOf :isKnownBy ;
a owl:ObjectProperty :alice :knows :bob, :carol .
Commit A :knows owl:inverseOf :isKnownBy ; rdfs:range :Person ; a owl:ObjectProperty . :alice :knows :bob, :carol ; rdfs:label "Alice" .
Commit B :knows owl:inverseOf :isKnownBy ; rdfs:range :Person ; a owl:ObjectProperty . :alice :knows :bob, :carol ; rdfs:label "Alice" .
Final file :knows owl:inverseOf :isKnownBy; rdfs:range :Person ; a owl:ObjectProperty . :alice :knows :bob ;
rdfs:label "Alice" . After a number of commits have been performed and the administrators of the repository decide that the new data is ready to be synchronized and published, a new release in GitHub can be created11. After that, the WebHook will be triggered and will notify the synchronization system with information about this new event. 5.3
Once the synchronization system has received this noti cation from the WebHook, it will download the original and nal RDF les from the repository. These les will then be parsed as graphs using the RDFLib library, and compared to obtain the di between them. 5.4
After the di between the two graphs is known, the next step is the creation of the operations that need to be executed on Wikibase to synchronize the changes.
An important step when creating the synchronization operations is to infer the types of each resource that will be added to the Wikibase. First of all, when 11 https://help.github.com/en/enterprise/2.13/user/articles/creating-releases synchronizing an IRI node we need to know if that node represents a Wikibase property (Px ) or an item (Qx ) before executing any operations on the Wikibase. Sometimes it is trivial to know when a node corresponds to a given entity type: for example, all the IRIs that are used as a predicate in an RDF triple are properties. However, there are cases when some kind of type of inference needs to be performed (e.g. exploring rdfs:subPropertyOf predicates in the graph to identify the properties).
After we know which IRIs correspond to classes and properties, we also need to know which are the ranges of the properties. When creating a new property in Wikibase it is necessary to indicate its data type. Modifying it after its creation, although possible, is not an expected operation and should be done with care. When a property is used as a predicate in a triple, we rely on the type of the object to infer the datatype of the property. If the property is not used as a predicate in the whole graph, we also rely on the rdfs:range predicates available for the property. There may be times when the datatype of a property may not be inferred with the information available in the graph. For those cases, we expect its range to be 'wikibase-item' by default. 5.5
Once the operations have been created, the next step is to execute them on the target Wikibase. Since those operations provide general information to be executed on multiple triplestores, this step also includes some Wikibase-speci c tasks: { Handling labels, descriptions and aliases. An important aspect of the Wikibase data model to take into account for the synchronization is its internal entity representation12. The description of a node is composed of the following mappings to RDF:
Labels are de ned as rdfs:label, schema:name and skos:prefLabel predicates.
Aliases are de ned as skos:altLabel predicates.
Descriptions are de ned as schema:description predicates.
All of the predicates above have as objects language-tagged literals. When
we encounter any of those predicates in the synchronization process, they
are used as label, alias or description values for the given entity.
{ Mapping datatypes. Although in the creation of synchronization
operations we have already annotated the properties with their respective datatypes,
there still needs to be a mapping between those datatypes and the ones from
the Wikibase data model. For example, coordinates expressed in an RDF
le using the geo:wktLiteral datatype are mapped to the Wikibase globe
coordinate datatype, and the values from literals must be processed to t
with the format speci ed by Wikibase.
12 For more information, see https://bit.ly/2PBU6Fo
{ Blank nodes. Blank nodes can be de ned as existential variables,
representing the existence of some unnamed resource [
6.1
We have seen so far the point of view of ontology engineers making changes directly on the les in the GitHub repository and re ecting those changes on the Wikibase system. However, the inverse direction is also possible.
An initial approach to solve this type of synchronization is illustrated in Fig. 3. Tasks related to the inverse synchronization are marked in blue, while other tasks already present in the system are greyed out. After the initial modi cation from a domain expert has been saved, we could make use of the available Wikibase hooks13 and notify the synchronization system with the changes made to the item from Wikibase. After that, the system would create a new pull request in the original repository that administrators can review before synchronizing the new changes. Both quali ers and references are important parts of the Wikibase data model: the former allow the re nement of values from properties in a given statement, while the latter are used to state which are the sources of a claim. Although the synchronization of both elements is not implemented yet, we are currently working on de ning a model that can be used to synchronize them. 13 https://doc.wikimedia.org/Wikibase/master/php/md docs topics hooks-js.html
Although there is already a initial mapping of XML Schema datatypes to Wikibase ones, some of them are not yet mapped. To be speci c, there is still no support for external identi ers, mathematical expressions, musical notations and lexemes.
In this demo paper we have presented a synchronization system between RDF les and a Wikibase instance. The system allows to browse ontologies de ned as RDF data through the Wikibase user-friendly interface, and allows domain experts to add knowledge to them without knowing the underlying data model. The system is already being used as part of the Hercules project to synchronize a research management ontology with a Wikibase, and has also been used to populate several Wikibase instances hosted on WBStack.
However, there is still additional work that needs to be done to allow a complete synchronization between the Wikibase instance and the repository where the RDF les are stored. The complete documentation of the system from an architectural point of view can be accessed at http://www.weso.es/hercules-sync.
The HERCULES Semantic University Research Data Project is backed by the Ministry of Economy, Industry and Competitiveness with a budget of 5.462.600,00 euros with an 80% of co nancing from the 2014-2020 ERDF Program. This work has been partially funded by the Spanish Ministry of Economy and Competitiveness (Society challenges: TIN2017-88877-R).