Git4Voc: Git-Based Versioning for Collaborative Vocabulary Development

Abstract

Collaborative vocabulary development in the context of data integration is the process of finding consensus between the experts of the different systems and domains. The complexity of this process is increased with the number of involved people, the variety of the systems to be integrated and the dynamics of their domain. In this paper we advocate that the realization of a powerful version control system is the heart of the problem. Driven by this idea and the success of Git in the context of software development, we investigate the applicability of Git for collaborative vocabulary development. Even though vocabulary development and software development have much more similarities than differences there are still important differences. These need to be considered within the development of a successful versioning and collaboration system for vocabulary development. Therefore, this paper starts by presenting the challenges we were faced with during the creation of vocabularies collaboratively and discusses its distinction to software development. Based on these insights we propose Git4Voc which comprises guidelines how Git can be adopted to vocabulary development. Finally, we demonstrate how Git hooks can be implemented to go beyond the plain functionality of Git by realizing vocabulary-specific features like syntactic validation and semantic diffs

IoT-based Smart Parking System for Sporting Event Management

“…Such a topic is gaining traction both in the research and industrial sectors, let us cite e.g. (i) schema.org (W3C) that defines extensive collections of concepts like Thing, Person, Event or Organization; or still (ii) Mobivoc intiative [6] that participates in the development of the Open Mobility Vocabulary. Such vocabulary compliance will be addressed during the bIoTope project.…”

“…However, one may argue that the payload is only the 'useful' data for the application, which can be either the value itself or the semantic (O-DF) structure depending on whether the application needs to understand the surrounding context (i.e., part of the O-DF tree). As a consequence, we decided to study these two considerations that implies using, on the one hand, the reference implementation that conveys the whole or part of the O-DF tree depending on the request (associated performance results are given in Figure 7(a)) and, on the other hand, the REST interface whose payload consists only of the URL in the request 6 and the value in the response (associated performance results are given in Figure 7(b)). As can be observed in both figures, using the REST interface needs to send as many frames as InfoItems when reading more than one InfoItem; this is why the data load is continuously growing in Figure 7(b), and vice-versa, using an aggregation strategy as achieved with O-DF results in more efficient data load than sending one frame per infoItem.…”

Decentralized Collaborative Knowledge Management Using Git

“…(cf. Deltas among versions (R7) in [27]) REQ7 Support of RDF Data Sets and Modularization of Graphs. The system should be able to handle multiple RDF graphs (i.e.…”

“…The Git4Voc, as proposed by Halilaj et al [27] is a methodology and collection of best practices for collaboratively creating RDF vocabularies using Git repositories. To support vocabulary authors in the process of creating RDF and OWL vocabularies Git4Voc is implemented using pre-and post-commit hooks to validate the vocabulary and generate documentation.…”

Decentralized Evolution and Consolidation of RDF Graphs

“…Git4Voc, as proposed by Halilaj et al [17] is a collection of best practices and tools to support authors in the collaborative creation process of RDF and Approach storage quad support bnodes branches merge push/pull Meinhardt et al [21] hybrid no a yes no f no (yes) h Frommhold et al [14] delta yes yes no f no no Graube et al [15] delta no b,c (yes) d yes no no Vander Sande et al [26] delta no c (yes) e yes (yes) g no dat chunks n/a n/a no no yes a The granularity of versioning are repositories; b Only single graphs are put under version control; c The context is used to encode revisions; d Blank nodes are skolemized; e Blank nodes are addressed by internal identifiers; f Only linear change tracking is supported; g Naive merge implementation; h No pull requests but history replication via memento API Table 1. Comparison of the different (D)SCM systems for RDF data.…”