Metadata about research data is increasingly represented using the Resource Description Framework (RDF) across diverse domains, as RDF ofers a structured yet flexible way to represent and query data. However, querying RDF data can be challenging, as users need to be proficient in the SPARQL query language to create syntactically correct queries. Furthermore, users must be familiar with the ontologies used for describing the desired data to choose appropriate classes and properties for their queries. As a result, the manual query construction process is both time-consuming and error-prone. To address this, we propose an approach that leverages schemas in the Shape Expressions Language (ShEx) as blueprints for constructing SPARQL queries. This approach is demonstrated using two case studies in the research data domain - one focusing on image data and one focusing on survey data - where each data type is described in a respective ShEx shape. We then use our ShEx2SPARQL tool to automatically translate a ShEx schema into a SPARQL query, thereby relieving users of the burden of manual query construction and enhancing the accessibility of RDF data.
Research data management encompasses the handling of a large diversity of data types, such as tabular
data, survey results, videos, or images [
Accessing RDF data is typically realized using the SPARQL query language [
Consider the scenario of Alice, a researcher who is looking for detailed information about survey data
stored in a research data repository. The repository provides an SPARQL endpoint to retrieve the data
Alice is searching for. However, Alice faces two major challenges hindering her from finding the data.
First, she must investigate which ontologies the repository uses, as she needs to identify all relevant
classes and properties for her query. Second, Alice is new to RDF and SPARQL, which makes the task
of manually constructing an efective query both time-consuming and labor-intensive. In this scenario,
predefined templates to query survey data would mitigate the challenges faced by Alice. Diferent data
types can be expressed in formal data shapes that describe the expected structure of RDF data. These
2nd International Workshop on Natural Scientific Language Processing and Research Knowledge Graphs (NSLP 2025), co-located
with ESWC 2025, June 01–02, 2025, Portorož, Slovenia
* Corresponding author.
$ christoph.goepfert@informatik.tu-chemnitz.de (C. Göpfert); sheeba.samuel@informatik.tu-chemnitz.de (S. Samuel);
martin.gaedke@informatik.tu-chemnitz.de (M. Gaedke)
0000-0001-6659-8947 (C. Göpfert); 0000-0002-7981-8504 (S. Samuel); 0000-0002-6729-2912 (M. Gaedke)
© 2025 Copyright © 2025 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
description can be realized by defining constraints on classes and their relationships, e.g. by using the
Shape Expressions Language (ShEx) [
In this paper, we leverage shape definitions to automatically construct SPARQL queries conforming
to the specified shape of a research data type. For this purpose, we use our ShEx2SPARQL tool to
demonstrate query construction for both image and survey data which are described using the
domainspecific ontologies: Lightweight Image Ontology [
The remainder of this paper is structured as follows: Section 2 ofers a review of related work. Section 3 contains technical information on the Shape Expressions Language and ShEx2SPARQL. In Section 4, we demonstrate in two case studies how shape definitions for survey and image data can be used to automatically construct SPARQL queries. Section 5 provides a discussion of the results for the two case studies. Finally, Section 6 ofers a conclusion.
There exists a multitude of approaches in the domain of SPARQL query construction. Mussa et al. [
Among form-based query building approaches, a prominent example is the Wikidata Query Service
(WDQS) [
Graph-based query builders ofer a more intuitive approach to query construction by enabling the
interaction with RDF data through visual representation as a graph. QueryVOWL [
Sparklis [18] ofers a visual query builder based on natural language and faceted views to simplify query construction. Sparklis guides users by suggesting available entities, classes, properties, filters and modifiers to refine their queries interactively. However, its reliance on predefined query patterns also restricts its flexibility. The authors state that Sparklis covers a "large subset of SPARQL 1.1", it does however not support CONSTRUCT queries. 1https://hay.toolforge.org/vizquery/ 2https://www.w3.org/TR/vocab-data-cube/
Cocco et al. [19] use a template-based approach for their QA system which links natural language questions to SPARQL queries. A tagger component is used to identify entities and relationships contained in a new question. The result returned from the tagger are then used to construct a SPARQL query by selecting the most suitable template based on similarity. The templates contain placeholders that are iflled with the identified entities and relationships. Chen et al. [ 20] also use a template-based approach for the Light-QAWizard approach. Their approach makes use of a recurrent neural network and multilabel classification, mapping questions to templates. The classifier is used to select the most suitable template and attempts to create only the SPARQL clauses that are required to answer the question to increase query performance by avoiding any redundant query patterns. Many recent approaches leverage Large Language Models (LLM) in QA systems. Tafa and Usbeck [ 21] use an LLM to generate SPARQL queries in the context of scholarly knowledge graphs. Their approach relies on a training set of test questions, from which the top-n most similar questions are retrieved for a new question. Similarity is calculated based on the question’s embedding score using a BERT-based sentence encoder. The SPARQL queries associated with the top-n most similar questions are used in the prompt to the LLM and serve as guidance for creating a SPARQL query. A disadvantage of the presented template-based approaches is that they require an initial phase in which the templates used as guidance or reference data must either be compiled or manually created.
The Shape Expressions Language (ShEx) [
Traditionally, the intended use for ShEx schemas has been data validation [22], ensuring that data conforms to specified shape structures and maintaining consistency within a graph. However, as shape expressions provide a precise description of expected graph structures, this information also ofers a blueprint for SPARQL query patterns. Our tool ShEx2SPARQL3 is able to leverage these blueprints to automatically construct SPARQL queries. ShEx2SPARQL processes a given ShEx schema and translates it into a corresponding SPARQL query that reflects the constraints of a designated start shape in the schema. The tool parses each element of the schema, including shape expressions, node constraints and triple constraints, and maps them onto SPARQL query patterns conforming to the defined constraints. Consequently, the data retrieved through the constructed query inherently conforms to the underlying ontologies, making use of the same classes and properties that were used in the shape definition. This automated construction procedure addresses the challenges faced by Alice in the initial scenario, who otherwise had to construct the query manually and also had to be familiar with SPARQL and the structure of the underlying ontologies in the knowledge graph.
Despite these benefits, the current implementation of the ShEx2SPARQL tool is subject to limitations. Due to the limited support for recursion provided in the query language, recursive shape references are not and can not be supported. Specifically, it is not possible to express constrained traversal with SPARQL; for instance, it is not possible to enforce for a resource nested at an arbitrary depth to match a specific shape. Currently, the tool ofers limited support for cardinality constraints (i.e., optionality and exclusivity) and does not support importing schemas.
With the technical foundations established, we now turn to the practical application of ShEx2SPARQL for specific types of research data. In the following section, we explain how ShEx schemas together with ShEx2SPARQL can be utilized to create SPARQL queries for survey and image data.
In this section, we use two case studies to show how ShEx2SPARQL can be used to construct SPARQL
queries from predefined ShEx schemas. The case studies focus on image and survey data. To this end, we
selected a domain-specific ontology relevant to each of the respective data types: the Lightweight Image
Ontology [
Images are a common type of research data used in various research domains. Efective research data
management aims for obtaining rich metadata to not only describe the image itself, but also contextual,
descriptive properties. A structured RDF-based representation of image metadata is ofered by the
Lightweight Image Ontology (LIO) [
We define an Image shape which is limited to classes and properties of the LIO ontology that are needed for describing the Image shape in ShEx. Specifically, this comprises the class Image which is described by several properties describing its contextual and visual elements. Figure 1 depicts the image class and associated properties. The hasDepictedBackground property specifies background elements in the depicted scene, while hasPictorialBackground refers to the surface background of the image itself. The hasSetting property provides contextual information about where or under what circumstances an image was created. The location property ofers more specific spatial metadata about where an image was taken. The shows property refers to entities that are visually represented in an image, while hasTag relates an image to a keyword. The properties materials, style and technique are used to relate to the physical material used to create an image, as well as the used artistic style and technique.
Next, we formalize the classes and properties from the illustrated excerpt of the LIO ontology in a shape named Image using the ShEx language. The schema defining the Image shape is shown in Fig. 2. First, the schema defines the shape Image to be the start shape of the schema. On lines 3–14, the shape definition specifies the expected properties for the Image shape. The shape consists of the four datatype properties hasTag, location, style, and technique. Node Constraints restrict the literal values for these properties to the datatype xsd:string. The shape describes further properties on lines 8–12 without any Node Constraints on objects of the triples. All properties described on lines 4–12 are optional which is indicated by the ’?’ quantifier. Finally, line 13 enforces that instances of this shape must be typed to the class :Image.
The above Image shape can be translated into a corresponding SPARQL query using the ShEx2SPARQL tool. Figure 3 depicts the generated SPARQL query in a condensed form. While for the illustrated example a CONSTRUCT query was chosen, the tool does also allow the generation of ASK and SELECT queries. 00 CONSTRUCT { 01 ?image a ?type. 02 ?image lio:hasTag ?tag. 03 ?image lio:hasDepictedBackground ?depictedBg. 04 (... shortened ...) 05 } WHERE { 06 ?image a ?type. 07 VALUES ?type { lio:Image } 08 OPTIONAL { 09 ?image lio:hasTag ?tag. 10 FILTER((DATATYPE(?tag)) = xsd:string) 11 12 13 14 } } OPTIONAL { ?image lio:hasDepictedBackground ?depictedBg. } (... shortened ...)
The CONSTRUCT graph template on lines 1–4 contains all unique graph patterns that occur within the WHERE clause. The graph pattern on line 6 with the VALUES restriction on the subsequent line express the enforced type constraint to the :Image class. The Image shape consists of Triple Constraints specified on lines 4–7 in Fig. 2, which describe the (optional) presence of datatype properties together with Node Constraints, which constrain the value ranges of literals to the xsd:string datatype. The corresponding segment in the SPARQL query can be found in Fig. 3 within the OPTIONAL fragment on lines 8–11, with a graph pattern described on line 9 and the datatype constraint expressed using a FILTER on line 10.
The schema contains further Triple Constraints on lines 8–12. These constraints are mapped to SPARQL structures as shown on line 12 in Fig. 3. As previously, the constraints are mapped to a corresponding graph pattern. However, an additional FILTER is not required as the schema does not specify any Node Constraints for these patterns. For the remaining properties, the complete SPARQL query contains analogous segments to those on lines 8–11 for datatype properties, as well as line 12 for the remaining properties without Node Constraints.
Surveys such as standardized questionnaires play an important role in several diferent areas of research.
Data gathered in surveys can be presented in a structured form that establishes the relationships
between the survey, the questions it consists of, answers to the questions, and participants that took the
survey. A way to represent survey data in RDF is presented by Scrocca et al. with The Survey Ontology
[
The relationships between these classes are shown in Fig. 4 and are described in the ontology as follows: One or multiple instances of a completed question (CompletedQuestion) are part of a survey dataset (SurveyDataset) and are related to an Answer (hasAnswer) and an answer text (hasAnswerText). Furthermore, a completed question has been answered (answeredIn) in the context of a SurveyCompletionTask which is associated (wasAssociatedWith) with a particular Participant. The Survey Ontology describes further subclass relationships that we have omitted from our example for reasons of clarity, as they were not relevant for the ShEx schema.
We follow the same procedure as in the first case study and formalize the aforementioned relationships in a ShEx schema by defining a CompletedQuestion shape, as shown in Fig. 5. This shape specifies the expected structure of survey-related RDF data based on properties and classes defined in The Survey Ontology. First, the schema defines the CompletedQuestion shape as its start shape. Lines 5–8 specify the } OPTIONAL { ?completedQuestion sur:hasAnswerText ?hasAnswerText.
FILTER((DATATYPE(?hasAnswerText)) = xsd:string) CompletedQuestion shape as comprising of the four object properties :answeredIn, :completesQuestion, cube:dataSet and :hasAnswer, whose objects are in turn described with the shapes SurveyCompletionTask, Question, SurveyDataSet and Answer. The shape includes also the datatype property :hasAnswerText and enforces the literal’s datatype for this property to be xsd:string on line 9. In addition, each shape holds an object property that specifies the type of the respective shape (lines 10, 12–17). With the exclusion of the type properties (’a’ alias rdf:type), all properties of the schema are specified to be optional.
Next, the CompletedQuestion shape is translated into a SPARQL CONSTRUCT query using the ShEx2SPARQL tool. The resulting SPARQL query is shown in Fig. 6. Lines 9–15 specify a graph pattern for the cube:dataSet property using the variable ?dataSet for the object of the triple. As objects for this relation must conform to a shape — in this particular example, the SurveyDataSet shape — a nested graph pattern follows on lines 11–14. This nested graph pattern describes the constraints associated with the SurveyDataSet shape, i.e. its type property as well as the VALUES expression enforcing its type to be sur:SurveyDataSet. In a similar manner, the type of the CompletedQuestion is constrained on lines 7–8. The segment on lines 16–19 reflects the mapping of the datatype property :hasAnswerText and constrains its value range to xsd:string using a FILTER expression. For all other properties not included in the excerpt, the full query contains segments that are structured in the same way as those on lines 16–19.
In the two case studies shown, we demonstrated how SPARQL queries can be constructed automatically from a ShEx schema for image and survey data respectively. In these examples, an ontology was assumed as the starting point, from which then a corresponding ShEx schema was derived. In practice, however, it is common for multiple ontologies to be used in combination with each other — as is also the case, for example, with the complete version of The Survey Ontology. Such scenarios can be realized with the shown procedure as well: properties and classes from diferent ontologies can be incorporated easily in the derived ShEx schema, the translation of the ShEx schema to a SPARQL query remains unafected.
Some Semantic Web applications (such as Wikidata4) facilitate data retrieval for their users by providing them with SPARQL query templates for reference. Using our approach, such templates can be generated directly from ShEx schemas. We believe that this approach can be particularly useful for instances where shape expressions are already employed for data validation, as this eliminates the efort of developing the ShEx schemas or, if needed at all, necessitates only minor adjustments to the schemas.
Although our case studies focused exclusively on research data management, the procedure can be applied to other domains as well. It should be noted, however, that the aforementioned limitations of the ShEx2SPARQL tool still apply.
In this paper, we demonstrate how the accessibility of RDF data can be enhanced, particularly in the context of research data, by leveraging the formal structure defined in a Shape Expressions (ShEx) schema. We demonstrate the necessary steps through two case studies, one on image data utilizing the Lightweight Image Ontology, and on survey data using The Survey Ontology. A ShEx schema is derived from each of the two ontologies, serving as a blueprint for generating a corresponding SPARQL query. The translation of ShEx schemas into SPARQL is realized using our ShEx2SPARQL tool, which facilitates the retrieval of instance data conforming to the schema. This approach is particularly beneficial for users who otherwise struggle with the manual formulation of complex queries or who are unfamiliar with the ontologies used in a knowledge graph. Overall, the approach represents a step toward more accessible RDF-based research data management, ultimately fostering the efective use of Linked Open Data in research. Future work includes extending ShEx2SPARQL to translate all types of cardinality constraints.
This work was funded by the Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) — Project-ID 514664767 — TRR 386.
During the preparation of this work, the authors used GPT-4 and DeepL in order to: Grammar and spelling check, Improve writing style. After using this tool/service, the authors reviewed and edited the content as needed and take full responsibility for the publication’s content. in: C. Ghidini, O. Hartig, M. Maleshkova, V. Svátek, I. Cruz, A. Hogan, J. Song, M. Lefrançois, F. Gandon (Eds.), The Semantic Web – ISWC 2019, Springer International Publishing, Cham, 2019, pp. 647–663. doi:10.1007/978-3-030-30793-6_37. [18] 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, publisher: IOS Press. [19] R. Cocco, M. Atzori, C. Zaniolo, Machine Learning of SPARQL Templates for Question Answering Over LinkedSpending, in: 2019 IEEE 28th International Conference on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE), 2019, pp. 156–161. doi:10.1109/WETICE. 2019.00041, iSSN: 2641-8169. [20] P. Chen, Y. Lu, V. W. Zheng, X. Chen, X. Li, An Automatic Knowledge Graph Construction System for K-12 Education, in: Proceedings of the Fifth Annual ACM Conference on Learning at Scale, L@S ’18, Association for Computing Machinery, New York, NY, USA, 2018, pp. 1–4. doi:10.1145/3231644.3231698. [21] T. A. Tafa, R. Usbeck, Leveraging LLMs in Scholarly Knowledge Graph Question Answering, 2023.
doi:10.48550/arXiv.2311.09841, arXiv:2311.09841 [cs]. [22] T. Baker, E. Prud’hommeaux, Shape Expressions (ShEx) 2.1 Primer, 2019. URL: https://shex.io/ shex-primer-20191009/.