=Paper=
{{Paper
|id=Vol-3773/paper5
|storemode=property
|title=KGSnap! in Practice: a Block-based Programming Environment for Enabling Knowledge Graph Literacy
|pdfUrl=https://ceur-ws.org/Vol-3773/paper6.pdf
|volume=Vol-3773
|authors=Alessia Antelmi,Vincenzo Offertucci,Maria Angela Pellegrino
|dblpUrl=https://dblp.org/rec/conf/voila/AntelmiOP24
}}
==KGSnap! in Practice: a Block-based Programming Environment for Enabling Knowledge Graph Literacy==
https://ceur-ws.org/Vol-3773/paper6.pdf
KGSnap! in Practice: a Block-based Programming
Environment for Enabling Knowledge Graph Literacy
Alessia Antelmi1,† , Vincenzo Offertucci2 and Maria Angela Pellegrino2,*,†
1
Università degli Studi di Torino, Via Giuseppe Verdi, 8, 10124 Torino (Torino), ITALY
2
Università degli Studi di Salerno, via Giovanni Paolo II, 132, 84084 Fisciano (Salerno), ITALY
Abstract
The growing availability of (linked) open data requires lay users to master how to deal with data
effectively, yet SPARQL presents a barrier to leveraging data represented as knowledge graphs. As the
block programming paradigm has been successfully used to teach programming skills, we demonstrate
how to use KGSnap!, an extension of the block-based programming environment Snap!, to foster
knowledge graph literacy among individuals lacking expertise in query languages. This work mainly
focuses on the visualization and interaction aspects of KGSnap!, a visual SPARQL query builder, when
experienced by users without expertise in the Semantic Web technologies. The reported experience is
discussed as a learning-by-doing protocol aimed at facilitating the reproducibility and transparency of
the performed evaluation. KGSnap! ease of use has been verified by 14 Snap! experts and 24 high-school
learners. The findings indicate that lay users perceived it as a promising approach to acquaint themselves
with knowledge graphs.
Keywords
SPARQL, Block-based programming paradigm, Snap!, Easy of use, Query-builder, Reproducibility
1. Introduction
Knowledge Graphs (KGs) have emerged as notable tools in enhancing educational processes and
outcomes [1]. Significant effort has been dedicated to adhering to Linked Data (LD) principles
in sharing educational data [2]. However, KGs remain largely underexplored as a learning
objective [3, 4, 5, 6, 7]. Enabling KG learning requires investigating approaches that make them
easily queryable by users lacking technical proficiency in Semantic Web technologies.
Towards this direction, block programming languages have emerged as a popular approach
to introducing coding to non-experts [8]. Block-based environments enhance learnability for
beginners by emphasizing recognition over recall, thus reducing cognitive load. This goal is
achieved by representing computational patterns as blocks, allowing users to manipulate these
blocks directly by dragging and connecting them like jigsaw puzzle pieces, thus preventing
VOILA 2024: The 9th International Workshop on the Visualization and Interaction for Ontologies, Linked Data and
Knowledge Graphs co-located with the 23rd International Semantic Web Conference (ISWC 2024), Baltimore, USA,
November 11-15, 2024.
*
Corresponding author.
†
These authors contributed equally to the authoring and refinement of the article.
$ alessia.antelmi@unito.it (A. Antelmi); v.offertucci@studenti.unisa.it (V. Offertucci); mapellegrino@unisa.it
(M. A. Pellegrino)
0000-0002-6366-0546 (A. Antelmi); 0000-0001-8927-5833 (M. A. Pellegrino)
© 2024 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
ceur-ws.org
Workshop ISSN 1613-0073
Proceedings
errors and enhancing understanding of program structure [8]. Block-based programming
environments aim to mask the complexity of querying KGs via SPARQL1 , recognized to be
demanding for lay users [9, 10, 11].
This article describes the platform KGSnap!, an extension of Snap!2 which follows the
trend of supporting lay users to build and run queries on a working and publicly available
SPARQL endpoint without previous knowledge of the syntax of SPARQL through a block-based
programming approach. This work extends a previous article outlining the KGSnap! interface
and interaction model [12] by answering to the following research question (RQ): Is KGSnap!
considered easy to use by lay users? We assessed it through two distinct groups: (i) 14 experts
proficient in Snap! programming to gauge their acceptance of integrating data literacy blocks,
and (ii) 24 high school learners participating in intensive data literacy workshops to evaluate
their proficiency in composing queries of increasing complexity. The results indicate that
KGSnap! facilitates an intuitive interaction, enabling non-experts to engage with KGs.
The article is structured as follows. Section 2 overviews related work. Section 3 details
KGSnap! interface and interaction aspects. Section 4 presents and discuss the ease of use results.
Section 5 concludes the article with final remarks and future directions.
2. Related work
This section reviews visual SPARQL query builders and block-based programming environments.
Table 1 provides a comparative analysis of visual SPARQL query builders developed within the
last decade and block-programming environments, replacing the column ‘Approach’ with the
intended objective of each tool.
Visual SPARQL query builders. Over the past years, different visual query builders have
been proposed to hide the complexity of SPARQL and facilitate query construction. A basic
distinction can be drawn between tools that require the usage of SPARQL syntax and those that
opt for more intuitive interaction, thereby lowering the learning curve. Focusing on interfaces
that mask SPARQL complexity, a plethora of different approaches have been proposed within
the last decade. Some examples follow: queries can be modeled as data flows, as in SPARQL
Filter Flow [13]; as graphs as implemented in QueryVOWL [14], RDF Explorer [9], Simplod [21];
queries can be formulated by requiring users interacting with forms as implemented in Spar-
natural [24] and Wikidata Query Service [18]; with mashup, as in OptiqueVQS [16]; with
conversational agents, as in Pellegrino et al. [19] and Forest QB [22]; or via a combination of
controlled natural language and facets, as supported by Sparklis [15] and QueDI [20]. As a
general trend, all the cited tools do not require users to explicitly deal with URIs.
Block programming environments. In the realm of block-based programming environments
for LD, we can name several notable examples that go from supporting lay users in defining
LD to query KGs. In the former category, Juma Uplift [27], extends Blockly to facilitate the
definition of LD mappings. In the same vein, Sanctorum et al. [29] and Öztürk and Özacar [28]
contributed to assisting non-expert users in ontology authoring and KG population. Toward
the second direction, Punya [30] offers a block-based programming environment specifically
1
SPARQL: https://www.w3.org/TR/sparql11-query
2
Snap!: https://snap.berkeley.edu
Table 1
Comparison of works similar to KGSnap!, considering their objective (i.e., SPARQL query builders) or
their approach (i.e., adoption of the jigsaw metaphor). Legend: OK stands for full support, ∼ for partial
support, - for not supported or not explicitly reported, blanks mean not applicable.
Tool [Ref] Approach / Masked Masked Material
Objective URIs SPARQL 4Edu
Visual SPARQL Query Builders
SPARQL Filter Flow [13] Data flow OK OK -
QueryVOWL [14] Graph OK OK -
Sparklis [15] Controlled NL & facets OK OK ∼
OptiqueVQS [16] UI mashup OK OK ∼
SPARQLVis [17] Graph OK OK -
Wikidata Query Service [18] Form-based OK OK ∼
RDF Explorer [9] Graph OK OK -
Pellegrino et al. [19] Conversational AI OK OK ∼
QueDI [20] Controlled NL & facets OK OK ∼
Simplod [21] Graph OK OK ∼
Forest QB [22] Conversational AI OK OK -
KGVQL [23] Query by example & Graph OK OK -
Sparnatural [24] Form-based OK OK ∼
Block-based Interfaces
SPARQL/CQELS [25] Query building - OK -
SparqlBlocks [26] Query building OK OK ∼
Juma Uplift [27] LD mappings definition -
Öztürk and Özacar [28] Ontology instantiating -
Sanctorum et al. [29] KG construction -
Punya [30] Query execution OK
KGSnap! [12, 31] Query building OK OK OK
tailored for SPARQL query execution and result handling. Similarly, SPARQL/CQELS Visual
Editor [25] and SparqlBlocks [26] empower end-users to author SPARQL queries.
While SPARQL/CQELS Visual Editor does not mask URIs, KGSnap! and SparqlBlocks hide
both URIs and the SPARQL language. One significant difference between those tools is that
KGSnap! extends Snap!, whereas SparqlBlocks extends Blockly. Beyond being a technical
distinction, Blockly enables developers to modify all category content. This approach results in
environments that may appear similar but may offer different functionalities, which must be
verified in any extension. Our proposed Snap! extension retains familiar blocks in their original
positions, while new blocks are confined to a specific category. This approach could benefit the
Snap! community that can extend their environment while maintaining traditional interaction
with existing blocks. Notably, only Punya among block-based interfaces shares the philosophy
we promote, i.e., supporting a structured learning experience with freely available material.
3. KGSnap!: querying Knowledge Graphs with Snap!
KGSnap!3 mirrors the structure of SPARQL queries, aligning with the philosophy of block
programming to guide learners in gradually experimenting with the underlying language.
The tool facilitates the formulation of SPARQL queries by specifying triples (subject, predicate,
object), and covers basic graph patterns, including traversals, filters, and sorting. Once a SPARQL
query is executed, users can visualize the results as data tables and store specific outcomes in
variables to iteratively refine queries. Query results can be downloaded as JSON or CSV files,
while the query itself can be saved as a TXT file.
KGSnap! implements SELECT queries on KGs using a functional SPARQL endpoint. By
default, the tool is configured to query Wikidata4 . However, users can effortlessly introduce
any SPARQL endpoint of interest using a dedicated block, i.e., define a new endpoint
which requires the name that will be accessible in the from clause in the select query and the
endpoint URL. The interface of KGSnap! is depicted in Figure 1. As an extension of Snap!, it
seamlessly integrates into the existing Snap! interface, providing users with a dedicated tab to
access all KG query functionalities. While blocks from Motion to Variables belong to the
Snap! platform, all blocks related to KGs are encapsulated within the KGQueries container.
Blocks within a container share the same color, facilitating easy identification of the category
to which a block belongs. Users can distinguish the container from which a block has been
extracted by examining its color in relation to the category name.
In a block-based programming environment, the shape of a block determines its compatibility
with other blocks and how they can be combined.
• Blocks with rounded corners are not naturally stackable due to their asynchronous nature,
as seen in the SELECT query or the entity resolution process, performed via search
blocks. To incorporate them into the code puzzle, they must be wrapped within a function
and made synchronous, potentially by introducing a short delay between the functionality
call and the return of the result(s). An example in this direction has been discussed with
experts in Snap! and is visible on the bottom of Figure 1, where functions wrap search
blocks and make them synchronous.
• Other blocks in KGSnap! feature a “mouth" that can enclose other blocks, enabling a
hierarchical structure. For instance, the subject block can wrap one or more instances of
the predicate-object block to model all predicate-object pairs sharing the same subject, as
illustrated in Figure 1. Blocks can be connected via jigsaw-like connectors, facilitating
their interoperability. For example, the subject block can be stacked with the filter block
since they possess a compatible interface.
• Most of the proposed blocks in KGSnap! have a round shape, which facilitates their
usage in completing filters. For example, the block ...@... allows users to look up the
label specified before the “@" symbol and the language specified after it (see the left
side of Figure 1). Similarly, the rdfs:label block models the widely used predicate for
3
KGSnap! source code: https://github.com/isislab-unisa/KnowledgeGraphsAndSnap
KGSnap! interface: https://isislab-unisa.github.io/Snap/snap.html
4
Wikidata: https://www.wikidata.org
Figure 1: The KGSnap! interface. As a step-by-step tutorial, first, we define two auxiliary functions
to make the search blocks synchronous. Functions are defined via the block editor and result in two
monitor blocks. Then, these new blocks can be combined with the set variable block, as shown in
the query to retrieve the boiling tempetarature of the water.
attaching labels to nodes. Additionally, the language of ... is block checks if
the language of a given textual field is set to English ().
• Blocks designed for authoring SPARQL SELECT queries can be enclosed within the
translate query block to explore the formulated query. Once the query is ready,
users can use the execute query block to run it over the configured SPARQL endpoint.
• In addition to blocks for querying a working SPARQL endpoint, KGSnap! is equipped
with blocks specifically designed for returning or manipulating results. These include
the show results block, which displays the query results, and the get column/row
... from blocks, which allow users to extract specific columns or rows from the result set.
4. Ease of Use Evaluation
This section documents the evaluation of the interface of KGSnap! with end-users who lack an
understanding of SPARQL. A similar evaluation protocol was repeated with two distinct groups
across two separate events. KGSnap! was introduced in a dedicated workshop at Snap!Con
2023, an annual conference centered around the Snap! platform. Subsequently, KGSnap! has
been tested by high-school learners during extra-curricular sessions focused on OD. While
results concerning the high-school experience are documented in [31], the following will focus
on the Snap!Con experience. We document participants and settings, the implemented protocol,
methods of data collection, and an overview of results to assess the ease of use of KGSnap!.
Participants and Settings. The workshop was conducted online in a remote setting. Its
proposal successfully passed an evaluation stage where a conference committee deemed it
aligned with the Snap!Con standards and expectations. Fourteen participants freely joined the
workshop without compensation. Most of them kept their cameras switched on for the entire
workshop duration.
Protocol. The workshop lasted one hour and took place as an individual activity due to the
remote setting. The protocol is detailed as follows:
• Familiarization. The moderator begins by introducing the concepts of LOD and KGs
through a traditional frontal lecture supported by slides publicly available in a GitHub
repository to ensure transparency and reproducibility. Then, emphasis is put on the
nature of LOD, which consists of (inter)linked data published with an open license and
structured in terms of nodes and edges. To illustrate these concepts, a small KG related to
cultural heritage is used as an example, simulating the interest in retrieving the author
of the Mona Lisa. Recognizing that SPARQL may pose challenges for learners due to its
technical nature, the moderator finally introduces KGSnap! with the intention of masking
these technical complexities. Once the terminology is clarified, the moderator welcomes
questions from the audience, encouraging further discussion and clarification.
• Step-by-step tutorial. This stage is moderated as an interactive frontal lecture, chal-
lenging participants to reflect on how to respond to specific questions by hypothesizing
the underlying structure of the KG. The moderator prompted participants to consider the
question, What is the boiling point of water?. Participants are encouraged to formulate
hypotheses about the underlying KG and answer questions posed by the moderator to
maintain engagement. Once all the participants reached a consensus on the underlying
structure, the moderator formulated the query within the KGSnap! interface, as in Fig. 1.
• Hands-on. After 15 minutes of presentations, participants had access to the web interface
of KGSnap! and could explore it autonomously. The moderator encouraged them to
respond to some questions via Wikidata to engage them, but they were mostly free to
interact with the interface as they preferred. The moderator was available throughout
the workshop to answer questions and provide support with the platform.
Data Collection Mechanism. Participants had the option to interact with the moderator
by speaking aloud or chatting with them. Additionally, the moderator provided access to their
email to facilitate follow-up feedback. The results discussed in the following verbatim report all
feedback spontaneously raised by participants and sent to the moderator via chat and email.
Results. Some participants autonomously executed queries and spontaneously shared their
results with the moderator. For example, one participant had fun retrieving UNICODE characters
via Wikidata and successfully obtained the Dutch flag. On multiple occasions, participants
expressed their enjoyment and interest, stating that “It is [an activity] really fun to do and
very interesting.". One participant mentioned that they attempted to query KGs directly using
SPARQL two years before but failed. However, they found it much easier to perform basic
queries via KGSnap! and considered it a promising access point for non-expert users due to its
masking and simplification of SPARQL syntax. Other participants echoed this sentiment, saying,
“It seems to me a powerful approach to use Snap! to learn about KGs.". Another participant
inquired about the possibility of querying other SPARQL endpoints, allowing the moderator to
introduce KGSnap! blocks for querying arbitrary working SPARQL endpoints.
Other participants primarily focused on investigating how KGSnap! blocks can be integrated
with the rest of the environment to make it easier to use for the community. For instance, since
KGSnap! blocks are not natively stackable as most of them perform asynchronous calls, one
participant created and shared a function to make those calls synchronous, thereby enabling
the possibility to fit blocks together seamlessly. Furthermore, the same participant proposed
wrapping SPARQL variables in Snap! variable blocks to avoid errors that might occur when
hand-writing variable names, as well as the risk of forgetting the question mark required in
SPARQL to identify variables. Subsequent discussions revolved around making blocks for
searching entities and properties compatible with variable blocks, as visible in Figure 1.
All participants successfully experienced KGSnap! by formulating simple but functional
queries without any support. However, one participant acknowledged that KGSnap! required
knowledge of entity and property names to query Wikidata, as the conceptualization stage is
not masked by the interface. Despite this, the participant expressed optimism that users can
easily become accustomed to it with practice. This observation can be partially confirmed by
the absence of negative comments raised during the workshop.
Discussion. Similar to SparqlBlocks [26], KGSnap! provide end-users with intuitive access
to commonly used structures while minimizing the need for text input. These design principles
guided the interface development, where SPARQL language elements are visually represented
through blocks, whose shape helps to prevent syntax errors. KGSnap! offers basic constructs
that can be combined to author complex queries, along with support for more advanced features
such as search class and predicate blocks, and offering commonly used classes and properties
directly, such as rdfs:label. Moreover, query results are directly reusable, as suggested by
Ceriani and Bottoni [26]. To achieve this, KGSnap! integrates results into the query view,
presenting them as data tables composed of reusable variables. Results are displayed in popup
windows and can be manipulated using dedicated blocks in the KGQueries module, such as
get columns/rows from, which supports learners in developing their data literacy skills for
both linked and tabular data. Besdies results, also queries can be exported and explored outside
of the block-programming environment, as in SparqlBlocks [26].
As demonstrated by the KGSnap! ease of use evaluation, participants successfully ran simple
yet functional queries on Wikidata within limited time frame, spanning from one to two hours.
Moreover, KGSnap! was generally perceived as sufficiently user-friendly. It replies to our RQ.
At its current stage, KGSnap! employs a visual, action-unaware query processing approach
by offering users distinct blocks for query authoring and execution, thereby precluding live
query execution. Although SparqlBlocks discouraged this practice [26], none of the participants
expressed concerns about this practice, likely due to their brief exposure to progressively
challenging exercises. This aspect should be carefully verified in the future.
All participants remained highly engaged throughout the entire learning experiences, ex-
pressing their interest in an innovative approach to querying data that is often perceived as
inaccessible by the target communities. These findings are confirmed by high-school learn-
ers [31] and echoied the strengths previously documented by the existing literature [26].
While many studies testing tools with end-users detail their protocol to enable reproducibility,
educational materials supporting inexperienced educators are often not freely available. For
this reason, we advocate for a broader release of educational materials as OD to promote
transparency and reproducibility and foster a culture of data literacy.
5. Conclusions and Future Directions
This article explores a block-based programming approach for executing SPARQL queries
without the need for technical expertise. It introduces KGSnap!, an extension of Snap! equipped
with blocks designed for executing SELECT queries through basic graph patterns.
While lay users expressed satisfaction with the support provided during the learning experi-
ence, enhancing in-line support could further facilitate query formulation and block distinction
within KGSnap!. Although this article evaluates the ease of use among non-experts in seman-
tic web technologies, assessing the platform’s usability with semantic web experts would be
valuable to gauge their agreement with the block shapes and the implemented mechanisms for
query formulation and execution. Currently, both KGSnap! and its competitors only query a
single data source at a time. To enhance functionality, future efforts could focus on supporting
federated queries. Encouraged by the positive feedback documented in this article, more quanti-
tative evidence are required to verify the benefits of the proposed tool, such as the complexity of
queries in terms of links followed, the time to build the queries, and a comparison with similar
tools in terms of expressiveness, accuracy, and ease of use.
References
[1] Y. Fettach, M. Ghogho, B. Benatallah, Knowledge Graphs in Education and Employability:
A Survey on Applications and Techniques, IEEE Access 10 (2022) 80174–80183. doi:10.
1109/ACCESS.2022.3194063.
[2] C. K. Pereira, S. W. M. Siqueira, B. P. Nunes, S. Dietze, Linked Data in Education: A Survey
and a Synthesis of Actual Research and Future Challenges, IEEE Transactions on Learning
Technologies 11 (2018) 400–412. doi:10.1109/TLT.2017.2787659.
[3] R. De Donato, M. Garofalo, D. Malandrino, M. A. Pellegrino, A. Petta, Education meets
knowledge graphs for the knowledge management, in: MIS4TEL, Workshops., Springer,
2021, pp. 272–280. doi:10.1007/978-3-030-52287-2_28.
[4] S. Evenstein Sigalov, R. Nachmias, Investigating the potential of the semantic web for
education: Exploring Wikidata as a learning platform, Education and Information Tech-
nologies 28 (2023) 12565–12614. doi:10.1007/s10639-023-11664-1.
[5] B. Inostroza, R. Cid, A. Hogan, RDF Playground: An Online Tool for Learning about the
Semantic Web, in: The Web Conference, ACM, 2023, pp. 111–114. doi:10.1145/3543873.
3587325.
[6] L. Pieschel, S. Welten, L. C. Gleim, S. Decker, Teaching Semantic Web Technologies
through Interactive Jupyter Notebooks, in: SEMANTiCS (Posters & Demos), 2021. URL:
https://ceur-ws.org/Vol-2941/paper6.pdf.
[7] M. A. Pellegrino, A. Antelmi, At school of Open Data: A literature review, in: CSEDU,
SCITEPRESS, 2023, pp. 172–183. doi:10.5220/0011747500003470.
[8] D. Bau, J. Gray, C. Kelleher, J. Sheldon, F. Turbak, Learnable programming: Blocks and
beyond, ACM Communication 60 (2017) 72–80. doi:10.1145/3015455.
[9] H. Vargas, C. B. Aranda, A. Hogan, C. López, RDF Explorer: A Visual SPARQL Query
Builder, in: ISWC, Springer, 2019, pp. 647–663. doi:10.1007/978-3-030-30793-6_37.
[10] P. Bellini, P. Nesi, A. Venturi, Linked open graph: Browsing multiple sparql entry points
to build your own lod views, Journal of Visual Languages & Computing 25 (2014) 703 –
716. doi:10.1016/j.jvlc.2014.10.003.
[11] D. Damljanovic, M. Agatonovic, H. Cunningham, Natural Language Interfaces to On-
tologies: Combining Syntactic Analysis and Ontology-based Lookup Through the User
Interaction, in: The Semantic Web: Research and Application, 2010, pp. 106–120.
doi:10.1007/978-3-642-13486-9_8.
[12] V. Offertucci, M. A. Pellegrino, V. Scarano, KGSnap!: query Knowledge Graphs by Snap!,
in: The Semantic Web: ESWC Satellite Events, Springer, 2024.
[13] F. Haag, S. Lohmann, S. Bold, T. Ertl, Visual SPARQL querying based on extended filter/flow
graphs, in: Advanced Visual Interfaces (AVI), 2014, pp. 305–312. doi:10.1145/2598153.
2598185.
[14] F. Haag, S. Lohmann, S. Siek, T. Ertl, QueryVOWL: A visual query notation for Linked
Data, in: The Semantic Web: ESWC Satellite Events, Springer, 2015, pp. 387–402. doi:10.
1007/978-3-319-25639-9_51.
[15] S. Ferré, Sparklis: An expressive query builder for SPARQL endpoints with guidance in
natural language, Semantic Web 8 (2017) 405–418. doi:10.3233/SW-150208.
[16] A. Soylu, E. Kharlamov, D. Zheleznyakov, E. Jiménez-Ruiz, M. Giese, M. G. Skjæveland,
D. Hovland, R. Schlatte, S. Brandt, H. Lie, I. Horrocks, OptiqueVQS: A visual query system
over ontologies for industry, Semantic Web 9 (2018) 627–660. doi:10.3233/SW-180293.
[17] C. Yang, X. Wang, Q. Xu, W. Li, Sparqlvis: An interactive visualization tool for knowledge
graphs, in: Web and Big Data: Second International Joint Conference, APWeb-WAIM,
Springer, 2018, pp. 471–474.
[18] S. Malyshev, M. Krötzsch, L. González, J. Gonsior, A. Bielefeldt, Getting the Most Out
of Wikidata: Semantic Technology Usage in Wikipedia’s Knowledge Graph, in: ISWC,
Springer, 2018, pp. 376–394. doi:10.1007/978-3-030-00668-6_23.
[19] M. A. Pellegrino, V. Scarano, C. Spagnuolo, Move cultural heritage knowledge graphs in
everyone’s pocket, Semantic Web 14 (2023) 323–359. doi:10.3233/SW-223117.
[20] R. De Donato, M. Garofalo, D. Malandrino, M. A. Pellegrino, A. Petta, V. Scarano, QueDI:
From Knowledge Graph Querying to Data Visualization, in: SEMANTiCS, Springer, 2020,
pp. 70––86. doi:10.1007/978-3-030-59833-4_5.
[21] A. Jares, J. Klimek, Simplod: Simple SPARQL Query Builder for Rapid Export of Linked
Open Data in the Form of CSV Files, in: Information Integration and Web Intelligence,
ACM, 2021, pp. 415–418. doi:10.1145/3487664.3487790.
[22] O. Mussa, O. F. Rana, B. Goossens, P. O. ter Wengel, C. Perera, ForestQB: An adaptive
query builder to support wildlife research, in: ISWC Posters, Demos and Industry Tracks,
volume 3254, CEUR-WS.org, 2022. URL: https://ceur-ws.org/Vol-3254/xpreface.pdf.
[23] P. Liu, X. Wang, Q. Fu, Y. Yang, Y.-F. Li, Q. Zhang, KGVQL: A knowledge graph visual
query language with bidirectional transformations, Knowledge-Based Systems 250 (2022)
108870.
[24] T. Francart, Sparnatural: A visual knowledge graph exploration tool, in: ESWC. Satellite
Events, Springer, 2023, pp. 11–15. doi:10.1007/978-3-031-43458-7_2.
[25] D. Le Phuoc, M. Dao-Tran, A. Le Tuan, M. N. Duc, M. Hauswirth, RDF stream processing
with CQELS framework for real-time analysis, in: International Conference on Distributed
Event-Based Systems, ACM, 2015, p. 285–292. doi:10.1145/2675743.2772586.
[26] M. Ceriani, P. Bottoni, SparqlBlocks: Using Blocks to Design Structured Linked Data
Queries, Language (XSD) 1 (2017). doi:10.18293/VLSS2017-006.
[27] A. C. Junior, C. Debruyne, D. O’Sullivan, Juma Uplift: Using a Block Metaphor for
Representing Uplift Mappings, in: International Conference on Semantic Computing
(ICSC), IEEE, 2018, pp. 211–218. doi:10.1109/ICSC.2018.00037.
[28] Ö. Öztürk, T. Özacar, A case study for block-based linked data generation: Recipes
as jigsaw puzzles, Journal of Information Science 46 (2020) 419–433. doi:0.1177/
0165551519849518.
[29] A. Sanctorum, J. Riggio, S. Sepehri, E. Arnesdotter, T. Vanhaecke, O. De Troyer, A Jigsaw-
Based End-User Tool for the Development of Ontology-Based Knowledge Bases, in:
International Symposium on End User Development, Springer, 2021, pp. 169–184. doi:10.
1007/978-3-030-79840-6_11.
[30] E. W. Patton, W. Van Woensel, O. Seneviratne, G. Loseto, F. Scioscia, L. Kagal, The Punya
Platform: Building Mobile Research Apps with Linked Data and Semantic Features, in:
ISWC, Springer, 2021, pp. 563–579. doi:10.1007/978-3-030-88361-4_33.
[31] A. Antelmi, P. Esposito, Empowering Data Literacy Among High School Learners, in:
MIS4TEL. Workshops, Springer, 2024.