KG construction often involves mapping data from various sources to RDF, which can be achieved with declarative languages such as RML. RML, while powerful, presents authoring dificulties due to its RDF graph-based structure and Turtle serialization. Tools and languages have been proposed to help the creation of mappings by creating (UI) abstraction of RML concepts or more accessible languages. However, existing tools often struggle to balance guidance and flexibility. While representing RML in RDF allows enriching mappings with other vocabularies, it also presents a steep learning curve for users unfamiliar with Turtle and RML. This paper introduces GRAPE, an open-source projectional editor designed to facilitate RML mapping creation while preserving the flexibility of RDF schemas used to extend RML. GRAPE uses a language-oriented approach, treating each RML module as a domain-specific language. This allows users to write RML and/or Turtle in one artifact. Implemented using JetBrains MPS, GRAPE provides a text-like projection for manipulating the abstract syntax tree. GRAPE ensures syntactic correctness, prevents errors and guides with auto-completion and intentions. This lowers the barrier for new users while preserving the flexibility required for complex mappings. This paper aims to demonstrate the feasibility of this approach. It also describes the steps we have conducted to create an editor for Turtle, which is then extended for RML and its modules. The approach is extensible and allows the community to develop languages for other vocabularies. Git: https://gitlab.uliege.be/JakubDuchateau/GRAPE Tutorial and videos: https://jakubduchateau.gitlabpages.uliege.be/grape/ Proceedings
Constructing RDF Knowledge Graphs is challenging, as one needs to map various non-RDF sources to
RDF, often according to a vocabulary or ontology for which the correspondence is not trivial. Declarative
approaches, which allow one to describe how data sources should be mapped onto RDF using a special
language, have emerged to address this problem. A special processor then processes these mappings,
and the processor is responsible for “executing” the mapping. The RDF Mapping Language (RML) [
RML is stored as an RDF graph. Moreover, at the time of writing, the current RML specification states that RML mappings are stored in the Turtle serialization format. Nevertheless, authoring RML (in Turtle) is dificult. The community has looked at various approaches to guide and facilitate mapping authoring to address this dificulty. The problem is that many of these approaches do not provide the freedom that RDF graphs ofer, as we will describe in Section 2. We suspect that more technical profiles, such as developers accustomed to technologies other than RDF or RML, will find existing RML editing techniques either too constrained or with a steep learning curve, requiring a deep understanding of the specifications before they can be efectively used.
This work aims to develop a tool that balances guiding users in creating well-formed RDF documents
and RML mappings and retaining the flexibility of authoring RDF in a text-like editor. Such a tool would
achieve what is called a low threshold and high ceiling [
CEUR
ceur-ws.org such as syntax error prevention, auto-completion, and suggestions, thereby lowering the threshold for users. Simultaneously, it should maintain flexibility by allowing the interlacing of free-form RDF 1 and RML. Suppose one wants to obtain the flexibility of authoring RDF and RML in a text editor. In that case, a tool should be able to switch context, i.e., handle diferent contexts such as RML or free-form RDF in one document. If this is possible, then the runtime composition of new custom concepts ensures that the ceiling is not limited. Additionally, it attempts to ofer a keyboard-driven experience that is not too dissimilar to textual programming, improving familiarity for developer users.
The problem of parsing diferent languages in one text can be avoided with projectional editing, and
this is the solution that we will adopt and explore in this study. Projectional editing is an alternative to
traditional parsing approaches, where the user interacts directly with the Abstract Syntax Tree (AST)
structures.2 This approach eliminates the need for parsing and ensures syntactic correctness, making it
particularly advantageous for composing languages and concrete syntaxes. Projectional editing is a
well-established paradigm for Domain-Specific Languages (DSLs) [
In short, we want to explore whether it is feasible to propose mapping authors who are more technically savvy with a tool that approaches a text-based editing approach, providing all the support for writing well-formed RML (e.g., autocompletion) whilst providing them the liberty of turtle-based editing. The contributions of this paper are an approach and prototype implementation for creating and authoring RML mappings in such a manner. Our study demonstrates the feasibility of language-oriented programming through a projectional editor for RML, treating each part of RML as a domain-specific language while keeping the extensibility of the turtle notation or your custom-specific notation.
The editor, GRAPE, is made available as an open-source prototype implementation. GRAPE can process existing RML mappings, i.e., one does not have to create mappings in GRAPE from scratch, and the RML generated by GRAPE can be given to any RML-core compliant RML processor.
Various tools and methodologies have been proposed for RML authoring and related declarative
languages for data integration and data integration mappings. We refer to Van Assche et al. [
There are editors with a strong visual component, e.g., based on graphs and trees. For example,
RML Editor [
Then, there are text-based approaches. YARRRML uses YAML as a serialization format, providing
a textual abstraction of RML concepts. Yatter [
Other approaches include guided workflows (also called “wizards”) with RMLx [
From the observed editors, we identify a trade-of between guidance and flexibility. Visual editors ofer strong guidance but often at the expense of liberty, making complex mappings dificult or even impossible. For example, in JUMA, one must start with puzzles that resemble triple maps, where one needs to provide the pieces for logical sources, subject maps, predicate object maps, etc., in a set order and create tree-like mappings. One cannot reuse predicate object maps across mappings or declare those outside a triples map. The tools ensure the production of well-formed (R2)RML but do not allow the flexibility ofered by RDF. Furthermore, it cannot include additional metadata with other vocabulary.
In contrast, authoring RML mappings with textual editors provides greater liberty. RDF is a graphbased data model, but it is often serialized and manipulated in textual formats such as Turtle. This textual nature of these serialization formats naturally lends itself to text-based editing, but this comes with a steep learning curve and makes them less accessible to those not proficient in Semantic Web technologies.
This contrast highlights a gap in existing tools: an editor that combines supporting the users through features like autocompletion, which relies on recognition rather than recall while maintaining the lfexibility required for complex RML mappings in a text editor or a text-editor-like environment.
In the next section, we present our approach, which introduces adapted notations and a balance between guidance and freedom to improve the RML authoring experience.
RML can be considered a Domain-Specific Language (DSL) for KG Generation. A DSL is “a programming language or executable specification language that ofers, through appropriate notations and abstractions, expressive power focused on, and usually restricted to, a particular problem domain.” [15] As such, we could approach RML as a DSL by adopting DSL design techniques. However, RML is often authored in RDF serializations. RDF is special as it is a flexible model that allows us to use diferent vocabularies. Its graph structure also allows us to represent and combine information arbitrarily. One could thus consider that RDF allows us to mix languages if each vocabulary is considered to be a “DSL”. As diferent languages need to be supported, we must find a way to ensure that the document being authored can still be parsed.
The RML specification ofers ontologies and shapes formalizing well-formed and valid mappings. We will follow a Language-Oriented Programming paradigm to create a DSL informed by the RML specification and the Turtle serialization format. The reason is that a DSL for Turtle will allow us to extend it with DSLs for other vocabularies such as RML. Our approach will consider each RML module a domain-specific language with a specialized concrete syntax that can be mixed within an RDF document.
Suppose one wants to obtain the flexibility of authoring RML and RDF in a text editor. In that case, a tool should be able to switch context, i.e., handle diferent contexts such as RML or free-form RDF. Switching contexts is hard, and addressing this problem while parsing is complex. One can address this problem by avoiding the parsing process with a technique called projectional editing. Projectional editing, or structural editing, ofers an alternative to traditional approaches that rely on parsing. Instead of parsing user-written text in a concrete syntax to derive an Abstract Syntax Tree (AST), projectional editors allow users to directly interact with the AST structures. User actions are immediately reflected in the structure of the AST, bypassing the need for a parsing step.
To achieve this, we must support two perspectives. First, the editor must be able to represent any additional RDF Node within the mappings. Second, by approaching each vocabulary as a language, the editor should be able to mix languages within a single “document”5 to form an RDF graph. Support of the former will allow us to write arbitrary RDF and thus use any vocabulary. Still, when patterns (concerning a vocabulary or even a combination of vocabularies) emerge, one should consider creating a DSL. This approach can also be adopted for vocabularies consisting of modules, such as RML, and we should enable and facilitate the composition of these modules.
Projectional editing inherently supports unparseable code since it does not rely on grammar or parsing. This eliminates grammar ambiguities, making it particularly advantageous for composing languages and syntaxes [16], which fits the language-oriented approach we want to adopt.
While this paper focuses on a textual view with a keyboard-driven editing experience to study the familiarity of source code editing for developers, other visual forms of editing are also possible. However, projectional editors behave diferently to textual notations from what developers know from traditional editors for parser-based languages [17], which may need some adaptations of users. For example, authors must indicate, in some way, the DSL they want to use in a particular part of the document.
To help in the process of building an editor for a language, Language Workbenches (LW) [18] are a class of tools that facilitate the implementation of DSLs. Using a language workbench for RML has already been used successfully with XRM. We emphasize the compositional feature here and adhere closely to the RML specifications so that existing knowledge is transferable and additional abstractions can be added.
We use JetBrains Meta Programming System (MPS)6 to formalize the Turtle and RML language structures and to facilitate the creation of editor interfaces with an IDE infrastructure.
Briefly, MPS is a Language Workbench [ 18], where Structures define the concepts of a language, representing the Abstract Syntax Tree (AST). These structures, similar to classes in object-oriented languages like Java, implement inheritance, composition and allowing us to declare properties, children and references. These allow us, for example, to declare a concept “Triples Map” having zero or more “Predicate Object Maps” as children. Other modules, also called aspects of a concept, provide functionality for editor interaction, type systems, scoping, and (text) generation.
Constraints are dynamic rules that indicate what concept to use when a new node is created, limiting the AST that can be formulated. These dynamic constraints guide users in writing statements, complementing the static constraints encoded within the language’s structure. For example, such aspects ensure that term maps refer to the correct term type.
Editors in MPS are described with a cell system that forms a textual view with cells that are modifiable define how the AST is viewed and edited. These cells can be arranged horizontally, vertically, or indented to mimic blocks of text, but the editors can also be adapted for mathematical notation, graphs, diagrams, and tables.
Generators in MPS facilitate model-to-model transformations, generally converting higher-level language models to lower-level ones. In our case, this involves transforming RML concepts into Turtle concepts. A special kind of generator, textGen, specialises in generating textual representations from models, specifically it will convert Turtle concepts into their textual syntax. MPS also integrates various IDE features such as running and debugging code, version control, code completion, and type systems, which can be leveraged to enhance the development and editing experience.
The abstract ideas introduced in this section will be illustrated with concrete examples for the projectional editing of Turtle and RML in the next section. 5We use quotes as the authors will engage with something that looks and behaves like text, but the artifact contains a representation of the various ASTs. We will use “textual view” and “document” interchangeably when talking about the projectional text editor. 6https://www.jetbrains.com/mps/
GRAPE is an open-source projectional editor prototype for RML (and Turtle), developed with JetBrains MPS. It formalizes Turtle and RML specifications as concepts in composable domain-specific languages guided by a language-oriented paradigm. It provides fundamental IDE functionalities such as version control, running code integration, and viewing standard data files. The choice of MPS is also motivated by the benefits of projectional editing, which ofers guidance, prevents syntactic errors and enables composition, while having reasonable text-like projection.
Given the necessity of an RDF-compatible language, both as a generation target for exporting and to be able to mix any RDF nodes to extend non-standard mapping, we follow RML specifications by adopting Turtle as a base language. This section details our approach to designing and implementing the Turtle language within the MPS environment and enabling integration with other DSL in GRAPE.
Turtle concepts in GRAPE are based on the Turtle 1.1 grammar [19]. All Turtle 1.1 constructs are supported, and some Turtle 1.2 [20] features, such as the annotation block, are also included. We implemented these constructs by translating the grammar rules bottom-up into corresponding AST concepts within MPS. While strictly based on the grammar structure, we introduced additional concepts in our Turtle language to facilitate extensions and composition for elements from other DSLs.
To illustrate this process of translating Turtle grammar constructs into composable MPS concepts, we use the SubjectTriples concept as a representative example. This core Turtle construct, grouping triples by subject, was implemented as an MPS concept within our Turtle language. Figure 1 shows how the SubjectTriples concept, including its structure, editor representation, and text generation aspect, is declared using MPS DSLs. (a) The structure of concept
SubjectTriples. It associates a subject and a predicate object list.
(b) The editor aspect declaration for
SubjectTriples, showing the subject (c) The textGen aspect implefollowed by indented predicate objects. menting the conversion of a The folded view displays the subject SubjectTriples node to textual and the count of predicate objects. Turtle.
The editors of the Turtle language “simulates” the Turtle syntax by showing the concepts as in their textual representation. Due to the projectional nature of the editor, new lines and alignments follow what is decided in the editor aspect. Alternatives could be implemented, but never as entirely free as in text editor. In other words, the approach allows the arbitrary placement of Triples, but the precise representation (new lines, indentations, ...) is somewhat restricted. By editing data structures represented as text instead of text, we can provide advantages over textual editors, such as changing the IRI of a resource in all views of that resource in a document.7 7One can argue that renaming references is possible with traditional textual IDEs, but in such approaches, the text is first parsed to an AST to find the scope of references, while we only have the AST that we immediately manipulate.
MPS provides completion of concepts thanks to the metamodel defined in the language structure 8. These completion capabilities are extended with specific IRI completion features. In PrefixId, IRI completion is achieved through integration with prefix.cc, as illustrated in Figure 2b. For PrefixedName, once the prefix is known, completion for the name, as shown in Figure 2a, is provided by downloading the prefix namespace, assuming it contains a vocabulary or ontology, and processing it locally. (b) PrefixId completion with prefix.cc suggestion
for foaf.
(a) PrefixName completion for foaf prefix.
When importing a textual Turtle file, traditional Turtle parsers ignore empty lines and comments as their goal is to construct an RDF Graph. However, our parser retains them when at the top position to maintain visual resemblance with the original imported file. Comments in other positions are lost, it is beyond the scope of our prototype to support comments at all places in the projectional editor, as we need to reserve special slots for them in the AST and editor.
Converting the Turtle AST into text is straightforward as the DSL was built bottom-up from the grammar. An RDF Graph can also be constructed out of the Turtle AST, in which case during the conversion, the triples are annotated with the AST node responsible for their generation. One usage of this RDF Graph is validating the document against SHACL shapes, highlighting the invalid constructs thanks to the origin information. Another use case is to use the RDF Graph of the Turtle document to construct RML concepts out of it.
RML is implemented as an extension of the previously introduced Turtle language. The RML structures are modelled as an interpretation of the specifications and shapes, leading to bottom-up DSLs that stay at the same level of abstraction as the specifications.
As a formal interpretation of the specifications, modifications have been made to fit the object-oriented model of MPS structures and also to favor the simplicity of the AST. For AST simplicity, support for constant and references shortcut property has been removed. Instead, the editor assists in entering commonly used constructions by prefilling them. Also, it makes it easier for users to switch between a constant and other types of expression. Turtle concepts can be again used inside RML concepts to extend them, for example, in the TriplesMap concept Figure 3.
The notation used in the RML editor difers significantly from its Turtle counterpart. This design choice was primarily motivated by the goal to provide a shorter, focused syntax for RML, drawing inspiration from concise notations developed for other vocabularies like OWL and SHACL. The resulting notation adopts a structure resembling block-based programming languages and uses more explicit keywords to improve readability without needing to type the full keywords thanks to the structured editor’s support.
A notable example is the rml: PredicateObjectMap, which allows multiple predicates to be associated with multiple objects. In GRAPE, this structure is represented using braces { }, clarifying the relationships by grouping predicates and objects side by side in a mathematical notation. 8Code completion in MPS is implemented within the editor aspect of concepts, through side transforms and node substitutions. While MPS provides default completions based on language structure and constraints, developers can extend these with custom implementations. An alternative approach involves grammarcells [21], which parse small text fragments into AST nodes.
provide a view organized with indentation and braces.
erator (b) TriplesMap editor takes dis
tance with the Turtle syntax to (c) TriplesMap RML-to-Turtle gen(a) TriplesMap structure. The other
child contains Turtle nodes. subject map, and a list of predicate object maps, but can also contain turtle predicate objects that will be attached to the subject of the triples map. It also inherits from the Turtle TriplesStatment and therefore can be used, for example, instead of standard SubjectTriples introduced previously with the Turtle language.
Given the challenges encountered when authoring function executions in RML, an alternative notation has been proposed for FunctionExecution: function functionName (paramName = paramValue ). This notation resembles function calls in programming languages, functionName(paramName: paramValue), and is similar to YARRRML one-line function syntax.
GRAPE permits editing existing RML mappings by importing exiting turtle files with RML mappings.
The file is first imported to a Turtle AST, then the RDF Graph is constructed out of it. This graph is
then used to construct high-level RML structures while leveraging origin information to retain relevant
Turtle elements where appropriate. The steps of this transformation process are detailed in Figure 4.
This approach of creating higher level abstraction is analogous to Yatter [
Turtle
RML RDF Graph → ‧‧➡ + converts to lossy converts to ‧‧➡ and combined lossy convert to
To complete the IDE integration, GRAPE has a basic integration of a RML engine, BURP [22], to be able to run the mappings from within the tool. Launching the mapping can be done visually, and the user can choose the working directory, optional base IRI and output file. The console output of the tools is visible in the IDE.
To validate the feasibility of our approach, we provide an illustrative demonstration, a method for initial evaluation of early-stage ideas and prototypes [23].
We reuse the examples provided in the Matey publication [
The execution of a mapping file, facilitated by the BURP integration, is presented in Figure 5, which displays the full application screen. To demonstrate our notation for function execution, Figure 7 illustrates the extraction of a substring, specifically excluding the first three characters. The successful import of a mapping from the editor is shown in Figure 8. Furthermore, we have demonstrated the extensibility of our RML notations through the implementation of the RML-IO and RML-FNML, that can be enabled at runtime.
(4a) (2) (3) (1) (a) The Turtle document imported from a textual Turtle (b) The same mapping represented using dedicated ifle, keeps the node ordering and blank node names RML concepts, after Promoting RML Constructs. Creand top comments. ated from the RDF Graph represented by the Turtle ifle.
The authoring of KG construction mappings is challenging, and various approaches (languages, editors,…) have been proposed. We observed that approaches that provide lots of guidance tend to not provide much freedom to author (arbitrary RDF, or rigid editing order). We aimed to address this problem by proposing an editor that simulates a text editor but has built-in guidance to author well-formed Turtle and RML. In this work, we proposed GRAPE, an IDE for RML built with a language-oriented programming approach. GRAPE provides guidance to the users while maintaining higher freedom than existing visual RML, thereby reducing the limitations users might experience with other tools.
GRAPE retains the flexibility of RDF vocabulary combination by enabling the representation of any RDF Node mixed with RML abstractions. Following the RML modularisation, we developed DSLs for RML-core, RML-IO sources, and RML-FNML function execution, closely following the specifications, ensuring users work with familiar abstractions. These abstractions, each with their own notations, integrate seamlessly into a single document, generating compliant RML mapping documents in textual Turtle, which can be then processed by RML engines. The modularity of this approach facilitates the integration of further abstractions, their semantics defined through model-to-model transformations.
The editor leverages projectional editing, implemented with JetBrains MPS, to unambiguously mix textual representation and integrated IDE features, such as run capabilities. Projectional editing of the document provides syntax error avoidance and guides the users with completions along the way to increase recognition instead of having to recall the specifications. The tools support importing existing Turtle files and reconstructing the GRAPE’s RML abstractions from the turtle document.
The contributions of this work include the development of a flexible and extensible editor that ensures syntactic correctness, supports multiple notations, and integrates features such as autocompletion and mapping execution. By leveraging a framework for creating Domain-Specific Languages, we introduce a novel approach for RML that allows the embedding of abstractions within a single document, enabling RML to be seamlessly integrated within Turtle and vice versa. Through examples and demonstrations, we present an alternative method for authoring RML documents, which may be more accessible and intuitive for users.
While this work primarily demonstrates the capabilities of GRAPE through examples, a user evaluation is planned to investigate the tension field between guidance and freedom ofered by projectional editing, and how it is perceived by the users.
We are waiting for the RML specifications to stabilise before proceeding with the implementation of the remaining RML features. While implementing further RML modules, we will probably need to improve extensibility or RML-Core. Furthermore, we aim to enhance GRAPE’s integration of referenceFormulation, used in reference and templates query.
This work was supported by the Fonds de la Recherche Scientifique – FNRS under Grant n° MIS F.4016.24.
During the preparation of this work, the author(s) used GPT-4o and Grammarly to improve grammar and spelling check, paraphrase and reword, and translate words between French and English. After using these tool(s)/service(s), the author(s) reviewed and edited the content as needed and take(s) full responsibility for the publication’s content. perl, P. Cimiano, A. Polleres, O. Corcho, V. Presutti (Eds.), The Semantic Web: Research and Applications, volume 7295, Springer Berlin Heidelberg, Berlin, Heidelberg, 2012, pp. 375–390. doi:10.1007/978-3-642-30284-8_32. [14] A. Iglesias-Molina, L. Pozo-Gilo, D. Dona, E. Ruckhaus, D. Chaves-Fraga, O. Corcho, Mapeathor: Simplifying the Specification of Declarative Rules for Knowledge Graph Construction, in: ISWC 2020 (Demos/Industry), volume 2721, CEUR, 2020. URL: https://ceur-ws.org/Vol-2721/paper488. pdf. [15] A. Van Deursen, P. Klint, J. Visser, Domain-specific languages: an annotated bibliography, ACM
SIGPLAN Notices 35 (2006) 26–36. doi:10.1145/352029.352035. [16] M. Voelter, Language and IDE modularization and composition with MPS, in: R. Lämmel, J. Saraiva, J. Visser (Eds.), Generative and Transformational Techniques in Software Engineering IV: International Summer School, GTTSE 2011, Braga, Portugal, July 3-9, 2011. Revised Papers, Springer, 2013, pp. 383–430. doi:10.1007/978-3-642-35992-7_11. [17] M. Voelter, J. Siegmund, T. Berger, B. Kolb, Towards User-Friendly Projectional Editors, in: B. Combemale, D. J. Pearce, O. Barais, J. J. Vinju (Eds.), Software Language Engineering, Springer International Publishing, Cham, 2014, pp. 41–61. doi:10.1007/978-3-319-11245-9_3. [18] M. Fowler, Language Workbenches: The Killer-App for Domain Specific Languages?, 2005. URL: https://martinfowler.com/articles/languageWorkbench.html. [19] D. Beckett, T. Berners-Lee, E. Prud’hommeaux, G. Carothers, Rdf 1.1 turtle: Terse rdf triple language, W3C Recommendation, 2014. URL: https://www.w3.org/TR/2014/REC-turtle-20140225/, latest published version: https://www.w3.org/TR/rdf12-turtle/. [20] D. Beckett, T. Berners-Lee, E. Prud’hommeaux, G. Carothers, G. Kellogg, D. Tomaszuk, Rdf 1.2 turtle: Terse rdf triple language, W3C Working Draft, 2025. URL: https://www.w3.org/TR/2025/ WD-rdf12-turtle-20250109/, latest published version: https://www.w3.org/TR/rdf12-turtle/. [21] M. Voelter, T. Szabó, S. Lisson, B. Kolb, S. Erdweg, T. Berger, Eficient development of consistent projectional editors using grammar cells, in: Proceedings of the 2016 ACM SIGPLAN International Conference on Software Language Engineering, SLE 2016, Association for Computing Machinery, New York, NY, USA, 2016, pp. 28–40. doi:10.1145/2997364.2997365. [22] D. Van Assche, C. Debruyne, BURPing through RML test cases, in: KGCW 2024 : Knowledge Graph Construction 2024 : Proceedings of the 5th International Workshop on Knowledge Graph Construction Co-Located with 21th Extended Semantic Web Conference (ESWC 2024), volume 3718, CEUR, 2024. URL: https://ceur-ws.org/Vol-3718/paper4.pdf. [23] K. Pefers, T. Tuunanen, M. A. Rothenberger, S. Chatterjee, A Design Science Research Methodology for Information Systems Research, Journal of Management Information Systems 24 (2007) 45–77. doi:10.2753/MIS0742-1222240302.