Abstract
There are a few applications available for educational purposes in the forestry domain. These applications have significant limitations, including not exploiting existing biodiversity datasets, lacking flexible and consistent use of domain concepts, and generating annotations that are not easily shareable or reusable by other applications. In this paper, we introduce EducaWood, a novel Semantic Web application designed for forestry education that overcomes these limitations by leveraging Linked Open Data (LOD). Users can easily create tree annotations through a web form that hides the complexity of Semantic Web technologies. These annotations adhere to the Simple Tree Annotation ontology and are saved in a triplestore, facilitating seamless sharing with other users and applications. Moreover, EducaWood offers scalable and efficient visualization of semantic tree data across various zoom levels on a map interface. Access to LOD is handled through a REST API that allows read and writes operations over multiple data sources. An implementation of EducaWood has been successfully tested by more than 650 users, including real students and teachers in a pilot educational experience.
Keywords
Introduction
Environmental education emerges as an effective approach to bring the forestry world closer to society, encompassing both urban and rural communities. Multiple researchers argue that a better understanding of environmental sciences is achieved through active learning experiences grounded in real-life settings (Cheng et al., 2019; Derevenskaia, 2014). Therefore, contextualized environmental education activities hold significant promise to better understand Earth’s ecosystems and promote more responsible attitudes toward the conservation and sustainable use of our planet. Such contextualized environmental education activities might address a wide variety of forestry-related learning objectives such as: (i) learning to differentiate forest species, pests, or diseases through digital inventories; (ii) increasing interest in nature by discovering the diversity of trees in the environment and the biodiversity associated with them; (iii) integrating other subjects, such as mathematics, through the calculation of variables from inventory data (e.g., structural diversity indices, carbon sequestration, etc.); and (iv) fostering teamwork and outdoor learning. These activities can be adapted for different educational levels, from primary school (e.g., finding a specific tree species in the local environment) to secondary school (e.g., identifying tree species, measuring diameter and height, and recognizing microhabitats) and high school (e.g., calculating the carbon sequestered by a forest). All these examples of learning activities shared a common element, which is the need for the learners to locate and describe forestry-related physical entities (trees, leaves, timber, etc.) in situ, a process also known as
Some applications, such as Integrate Tree Microhabitat (German Federal Ministry of Food and Agriculture, 2014), Observation.org (Observation International, 2025), and iNaturalist (iNaturalist, 2026) support the annotation of forestry-related physical entities. However, they have important limitations for environmental education that can be addressed with Semantic Web technologies. First, they do not exploit existing biodiversity datasets such as tree inventories, land cover maps, or taxonomic classifications—Linked Open Data (LOD) and knowledge graphs are especially suitable for data integration. Second, they tend to make an inconsistent use of domain concepts (tree species, dead materials, decay stages, etc.), a difficulty that can be alleviated by employing ontologies. Third, they make intensive use of environmental annotations that cannot be shared or reused by other applications. In this regard, the publication of environmental annotations as LOD enables their sharing and reuse, facilitating follow-up educational activities using the same or a different environmental education application.
Despite the aforementioned potential benefits of Semantic Web technologies for the support of environmental annotations, their application to educational activities brings a new set of challenges: Human–computer interaction with the Semantic Web is quite demanding (Charalampidis & Keramopoulos, 2018; Dadzie & Rowe, 2011; Heath et al., 2006). Target users, particularly forestry teachers and students, do not usually know RDF or SPARQL and should be able to easily visualize and author environmental annotations while carrying out educational tasks. Access to LOD is complex (Dadzie & Pietriga, 2017; Verborgh et al., 2016), especially when dealing with read and write operations across multiple sources. This is the expected situation when different forestry datasets need to be exploited. Forestry data tends to be very large and is geospatial by nature (Brink et al., 2019), requiring efficient approaches for visualizing semantic geospatial data.
In response to these challenges, we introduce EducaWood, a Semantic Web application designed for forestry education that showcases: (a) good practices in the design of web applications aimed at hiding the complexity of Semantic Web technologies to end users; (b) an easier approach to dealing with read and write access over multiple LOD endpoints; and (c) efficient visualization of large geospatial environmental semantic datasets. More concretely, EducaWood features: (1) a web architecture aimed at supporting the description of physical entities (e.g., trees) by means of user-friendly web forms for authoring various types of annotations (e.g., location, tree status, and taxon) while concealing the complexity of RDF, OWL, and SPARQL; (2) access to LOD through a Configurable REST APIs For Triple Stores (CRAFTS) API.
CRAFTS (Vega-Gorgojo, 2022) is an API generator for LOD that supports read and write operations across multiple endpoints, largely reducing the development effort when interacting with multiple datasets. Thanks to the CRAFTS API, EducaWood publishes environmental annotations in a triplestore, while consuming data from the Spanish National Forest Inventory (Inventario Forestal Nacional [IFN]; Ministerio para la Transición Ecológica y el Reto Demográfico, Gobierno de España, 2026), Wikidata (Wikidata, 2023), and DBpedia (DBpedia Association, 2025); and (3) an interactive map for seamless tree browsing and filtering by taxon. Since the application integrates more than one million trees from IFN, smart data management is critical to ensure performance across varying map resolutions and to minimize unnecessary data downloads.
Thanks to this use of Semantic Web technologies, EducaWood makes feasible the collaborative building of digital inventories of forestry-related physical entities. This way, EducaWood enables the design and enactment of complex, but also innovative learning scenarios in vocational and higher education, such as the creation of a forest herbarium for botany courses or the compilation of a collection of pests and diseases for forestry pathology classes. Similarly, at the university level, EducaWood might support a challenging learning scenario, which is explored in greater detail in this work: urban tree management.
Beyond the educational benefits for the forestry domain brought by EducaWood, the paper presents a set of contributions of special interest for the Semantic Web research community: (a) the Simple Tree Annotation (STA) ontology for structuring environmental annotations (mostly focused on trees); (b) a demonstrator of a web application architecture that hides the complexity of Semantic Web technologies from users, and that streamlines the read and write access to multiple LOD sources; and (c) a novel mechanism for the scalable and efficient visualization of semantic tree data on a map.
The rest of the paper is organized as follows. Section 2 reviews interactive annotation applications in forestry education, as well as semantic approaches for the aforementioned challenges. Section 3 provides a technical description of EducaWood, including its requirements, its ontology, its architecture, its data sources, its main functionalities, and implementation details. Section 4 illustrates the functionality of the application and describes a forestry education scenario. Section 5 reports on the impact of EducaWood so far and includes a pilot study with forestry students. The paper ends with a discussion in Section 6 and the main conclusions and future research lines in Section 7.
Section 2.1 examines interactive annotation applications relevant to forestry education, identifying their main limitations—the lack of biodiversity dataset integration, inconsistent use of domain concepts, and siloed content. While Semantic Web technologies offer a promising solution to these issues, they also introduce their own challenges. Therefore, we review existing approaches in three key areas: (1) human–computer interaction with the Semantic Web (Section 2.2), (2) simplifying access to LOD, particularly for read and write operations across multiple sources (Section 2.3), and (3) visualizing semantic geospatial data (Section 2.4)—corresponding to the challenges identified in the introduction.
Interactive Annotation Applications in Forestry Education
Currently, there are few applications available that could potentially be used for forestry education. One of them is the Integrate Tree Microhabitat application (German Federal Ministry of Food and Agriculture, 2014), developed by the European Forest Institute (2025) to support training exercises for forest managers, inventory personnel, and other groups in identifying and describing tree microhabitats. However, its utility is limited to a series of training and demonstration plots known as “marteloscopes” where all trees are measured and geopositioned, and where foresters can conduct virtual tree marking for training. This network of marteloscopes includes 224 sites across 25 European countries and four additional sites in Vietnam. Marteloscopes serve multifaceted purposes, including training for both students and professionals, public outreach, and research endeavors such as human behavior concerning forests (Bravo-Oviedo et al., 2020) or thinning effects on biodiversity conservation and socio-economic co-benefits (Segalina et al., 2020). However, a limitation of the Integrate Tree Microhabitat application is its inability to incorporate new data, a restriction imposed to uphold data integrity and facilitate consistent comparisons across different time frames and analyses.
Observation.org (Observation International, 2025) is another application that may be used for forestry education. Nowadays, it serves as a global hub for citizen science where naturalists, citizen scientists, and biologists collaborate to gather, verify, and exchange biodiversity data. Users can create their own projects, located anywhere in the world, allowing them to generate biodiversity annotations through the website or the mobile application. Observation.org is more intensively used for animal projects (especially birds and insects) since it only includes a very general section for plants. More specifically, users can only annotate tree species, photos, and locations, but no further information, such as dendrometric measures or tree status. iNaturalist (iNaturalist, 2026) is very similar to Observation.org, allowing users to gather, verify, and collaboratively exchange biodiversity data. iNaturalist has been used as a blended learning framework for biodiversity monitoring (Herodotou et al., 2023) and to engage the community in the organism identification in outdoor activities (Unger et al., 2021). Again, iNaturalist annotations are limited to tree species, photos, and locations.
Human–Computer Interaction With the Semantic Web
As noted in Section 1, there are several challenges with the use of Semantic Web technologies in interactive applications spanning multiple domains, including forestry education. The first challenge entails facilitating human–computer interaction for stakeholders unfamiliar with Semantic Web technologies. Addressing this issue involves offering appropriate user interfaces with familiar conventions, thereby facilitating a transparent utilization of Semantic Web technologies while enabling seamless data analysis (Ivanova et al., 2019). Several examples in the literature adopt this approach, although they are typically limited to LOD consumption without support for write operations. For example, the suite of Sampo portals (Hyvönen, 2023) allows users to query and filter semantic Cultural Heritage data using form interfaces comprising textboxes and selectors, dynamically presenting data in tables, graphs, and maps. LOD4Culture (Vega-Gorgojo, 2024) is another Semantic Web application from our previous work that follows this approach; it offers an interactive map and a table-based browser of Cultural Heritage entities sourced from Wikidata and DBpedia. Additionally, Linked Data browsers such as Berners-Lee et al. (2006) aid users unfamiliar with Semantic technologies in visualizing semantic data.
Expanding upon this challenge, enabling end users to add or modify semantic data poses a significant hurdle. Andrews et al. (2012) review the different annotation types employed in interactive annotation applications. Interestingly, the type of data to be recorded should influence the user interface design to introduce user input. For example, a clickable map interface may prove effective for capturing the coordinates of a place. In our previous work, we have successfully employed web forms to gather user data; this is the case of CHEST (García-Zarza et al., 2025), where teachers can easily create spatial objects and learning tasks, which are then transparently saved as LOD. Notably, Wikidata is acknowledged as the leading open knowledge base in the world (Koutsiana et al., 2023), also leveraging web forms for user inputs.
Access to LOD
While the availability of LOD and knowledge graphs has grown across all domains, access to LOD is quite demanding even for knowledge engineers (refer to CHALLENGE #2 in the introduction). Beyond expertise with RDF, OWL, and SPARQL, access to LOD requires familiarity with the ontologies used and domain knowledge. To address this challenge, the Semantic Web community has proposed different approaches. Some define an HTTP interface over Linked Data, such as Linked Data Fragments (Verborgh et al., 2016), which offers a limited API for efficient consumption of Linked Data, although write access is not supported. Other approaches define new serializations of Linked Data and SPARQL results to JSON such as JSON-LD (Kellogg et al., 2020) and SPARQL transformer (Lisena et al., 2019); unfortunately, they do not support SPARQL query formulation, a much more demanding task for web developers than output transformations.
Since web developers typically employ REST APIs and JSON as an interchange format, it is therefore desirable to follow these conventions when accessing LOD. As a result, there is a number of proposals that support the creation of REST APIs on top of triplestores: RAMOSE (Daquino et al., 2022), R4R (Badenes-Olmedo et al., 2021), OBA (Garijo & Osorio, 2020), grlc (Meroño-Peñuela & Hoekstra, 2016), BASIL (Daga et al., 2015), and CRAFTS (Vega-Gorgojo, 2022). RAMOSE, grlc, and BASIL essentially allow the provision of APIs that encapsulate parametrized SPARQL queries. R4R, OBA, and CRAFTS also allow the exposition of RDF resources over an API. Only OBA and CRAFTS support write operations, although partial updates through HTTP PATCH (Dusseault et al., 2010) are only available in CRAFTS. All of these API generators provide one-to-one mappings between API calls and SPARQL queries. CRAFTS, on the other hand, uses one-to-many mappings, offering greater control over data exposure. Lastly, CRAFTS is the only API generator that can work with multiple endpoints from a single API. Vega-Gorgojo (2022) includes a thorough comparison of API generators over Linked Data.
Visualizing Semantic Geospatial Data
Lastly, some application domains such as forestry heavily rely on geospatial data, which brings their own set of challenges (Brink et al., 2019). Here, we particularly focus on the visualization of semantic geospatial data (CHALLENGE #3), requiring effective interfaces that ease access and analysis. We can find several proposals for visualizing geospatial Linked Data that are targeted to Semantic Web experts. This is the case of GeoYASGUI (Beek et al., 2017), a GeoSPARQL editor that provides a map visualizer of result sets. Sextant (Nikolaou et al., 2015) is an advanced visualization application that can combine spatial data from several endpoints, although it still requires knowledge of SPARQL in order to use it.
Visualization of semantic spatial data should not be limited to Semantic Web experts. Given the ubiquitous use of map applications, map-based interfaces seem a suitable approach for lay users. However, spatial data is inherently complex and tends to be quite large, needing thoughtful design decisions when presenting data directly on the map. In this regard, Gaigg (2023) proposes techniques for dealing with large amounts of spatial data, including data filtering, layering, and clustering. Following these principles, our previous work introduced Forest Explorer (Vega-Gorgojo et al., 2022), a visualization application for official forestry data, including national forest inventories and land cover maps from Spain and Portugal. The application is read-only, meaning users cannot modify the underlying dataset. It handles various feature types—administrative regions, land cover patches, inventory plots, and sampled trees—which are displayed on the map depending on the zoom level. At lower zoom levels, the application provides aggregated forest information within administrative regions, gradually revealing more detailed data such as land cover maps, national inventory plots, and sampled trees with their measurements as the zoom level increases. Forest Explorer leverages a semantic dataset that integrates multiple forestry data sources, as described in Giménez-García et al. (2024). The application relies on SPARQL query templates for data retrieval, as explained in Vega-Gorgojo et al. (2022). Forest Explorer is designed for forestry experts, data journalists, and the general public, offering an accessible yet powerful way to explore forest-related data.
There exist other seldom visualizers of geospatial LOD designed for non-Semantic Web experts, such as LinkedGeoData (Stadler et al., 2012) and Map4rdf (de León et al., 2012). LinkedGeoData is a dedicated visualization tool for OpenStreetMap data (transformed to adhere to Linked Data principles), while Map4rdf is a browsing tool of geospatial RDF datasets that uses a faceted interface to control the information to display. However, the current status of these tools appears uncertain.
In summary, several interactive annotation applications can be applied to forestry education. However, they present important limitations, such as the lack of integration with biodiversity datasets, the inconsistent use of domain concepts, and the confinement of content in data silos. Semantic Web technologies are particularly well-suited to address these issues, although they also introduce specific challenges. The first concerns human–computer interaction with Semantic Web data. Proposed solutions include innovative user interfaces, which are typically restricted to LOD consumption; notable exceptions, such as Wikidata and CHEST, enable end users to perform write operations on semantic data through web forms. The second challenge relates to accessing LOD and knowledge graphs. Many approaches support the creation of REST APIs over triplestores, with OBA and CRAFTS being among the most versatile. The third challenge involves the visualization of semantic geospatial data. While some solutions require proficiency in SPARQL, map-based interfaces appear to be a suitable alternative for nonexperts. In all cases, particular attention must be paid to the volume and complexity of spatial data.
Design of EducaWood
In this paper, we propose EducaWood, a new Semantic Web application designed for forestry education, addressing the limitations of existing interactive annotation tools. Given the challenges of human–computer interaction with the Semantic Web, we employ map interfaces and web forms to enable content authoring without requiring users to interact directly with RDF, OWL, or SPARQL. Since our approach involves both reading and writing across multiple LOD sources, we leverage a CRAFTS API to streamline data access. For effective visualization of semantic geospatial data, we implement efficient strategies for retrieving and rendering tree data at different zoom levels.
The primary objective of EducaWood is to support learning activities based on the social annotation of trees, while also allowing the exploration of forestry information within specific regions of interest. Tree annotations can be of different types and are published as LOD. The application exploits existing semantic datasets from Spain that we have released as LOD in our previous work (Giménez-García et al., 2024; Vega-Gorgojo et al., 2022), specifically the Spanish National Forest Inventory (IFN¿Inventario Forestal Nacional). Moreover, EducaWood also consumes third-party semantic data, such as tree species taxonomic data from Wikidata and DBpedia. Throughout this paper, we use the prefixes and namespaces listed in Table 1. The domain educawood.gsic.uva.es is consistently used for both the ontology and the dataset, ensuring that all URIs remain under the authoritative source of EducaWood. This design choice follows common practice in the Semantic Web community, as illustrated by well-known examples such as Wikidata and DBpedia.
Prefixes and Namespaces Employed in this Paper.
Prefixes and Namespaces Employed in this Paper.
We have carried out a requirement analysis for EducaWood using as sources our own experience in the field, the gaps found in the literature (see Section 2), and the feedback collected from users when testing early prototypes of the application. Table 2 summarizes the main requirements, organized as functional (FRx) and nonfunctional (NFRx). The forestry experts in our team first identified the core functionalities: (i) collaborative authoring of tree annotations of different types, (ii) visualization of these annotations, and (iii) interactive exploration of trees through a map. These functionalities are captured by requirements FR0–4 in Table 2 and represent the minimal set needed for a viable prototype. Subsequently, the full team refined the requirements by adding desirable, though not critical, features related to map visualization and geospatial data (FR5–8 in Table 2).
Requirements for EducaWood: Functional (FRx) and Nonfunctional (NFRx), and Connection to the Identified Semantic Web Challenges.
Requirements for EducaWood: Functional (FRx) and Nonfunctional (NFRx), and Connection to the Identified Semantic Web Challenges.
The first group of functional requirements (FR0–3) addresses CHALLENGE #1: Supporting semantic annotations by non-Semantic Web experts. EducaWood should provide comprehensive visualizations of the tree annotations available (FR0); tree annotations can be created by registered users in the application (FR1), using an appropriate web form; trees can be described by annotations of different types (FR2), a location is always required, while the rest of annotation types (image, dendrometric measures, tree status, etc.) are optional; annotations can be made incrementally by different users, so the application has to handle multiauthor tree annotations and deletions (FR3).
The second group of functional requirements (FR4–8) corresponds to CHALLENGE #3: Visualizing and managing large geospatial datasets. FR4 refers to one of the main functionalities, the exploration of trees through an interactive map; the scope should be worldwide, while the map view has to be adaptable to different zoom levels (FR5), so as to facilitate the exploration of small areas—showing markers for trees—but also large ones, providing appropriate aggregation mechanisms to avoid cluttering the view with too many markers; as species information is quite relevant in forest education, the application should provide a taxon filtering mechanism (FR6); the map view should also display trees from forest inventories available as LOD (FR7), specifically, EducaWood will integrate IFN data as this source contains reliable and relevant information of native trees (although limited to Spain); tree data should also be downloadable at least in CSV format (FR8) to allow the realization of different types of analysis for forestry education such as allometric equations fitting, tree mingling analysis, or environmental effect on species distributions. The remaining CHALLENGE #2, Access to LOD, is addressed by the architecture of the application and is not, per se, perceived by the EducaWood users directly.
In addition to functional requirements, we defined key nonfunctional requirements. Portability (NFR0) is critical for ensuring that EducaWood can be used by students and teachers, with mobile devices as the primary target, and tablets and desktop computers as secondary. Low latency (NFR1) is also necessary for maintaining a responsive and usable application. At minimum, the application has to support English and Spanish (NFR2), with the possibility of adding further languages in the future. The following subsections describe in detail how the above requirements have been addressed in the design and implementation of EducaWood.
The STA ontology 1 is the basis for the main functionalities of EducaWood. It has been conceived for describing trees (FR0) and supporting different types of annotations (FR2); it also allows multiauthor annotations (FR3), as well as a mechanism for conflict resolution. The ontology is relatively small, consisting of 412 axioms, 36 classes, 16 object properties, 10 data properties, and 8 annotation properties. Its logical expressivity is RRESTRH(D), which reflects the use of existential restrictions, role hierarchies, property chains, transitive properties, and datatypes, while avoiding constructs such as nominals or qualified cardinalities.
STA reuses terms from Basic Geo (Brickley, 2006), FOAF (Brickley & Miller, 2014), IFN (Giménez-García et al., 2024), and Dublin Core (DCMI Usage Board, 2020). Basic Geo is employed to represent spatially located things (such as trees) with latitude and longitude in World Geodetic System 1984 (WGS84). FOAF provides concepts for Person (the annotators in STA) and Image (a type of annotation). For tree species, STA relies on the taxonomy defined in IFN. Dublin Core is used to specify metadata such as the creator and date of annotations. Figure 1 depicts STA graphically, while Table 3 organizes the ontology elements by category and type, indicating the requirements they address.
Visualization of the Simple Tree Annotation ontology with VOWL (Lohmann et al., 2016). Classes and properties from external ontologies are displayed in dark blue.
Elements of the Simple Tree Ontology, Organized by Category (With Mapping to Requirements) and Type.
The main classes of STA are
A
We have created additional terms in STA to support the different types of annotations: we reuse
EducaWood is designed as a web application with an architecture aimed at facilitating its users to visualize and carry out semantic annotations without needing technical expertise on Semantic Web technologies (refer to CHALLENGE #1 in the introduction). The web architecture of EducaWood can be described by the routes shown in Table 4.
Routes Exposed in EducaWood.
Routes Exposed in EducaWood.
Query parameters marked with
R0 is a landing page that presents the application and includes a link to route R1, corresponding to the interactive map functionality. R1 includes a required query parameter, loc, that defines a specific position and zoom level with the format LAT, LONG, ZOOMz 5 ; taxon can be set to filter the trees shown in the map (FR6), for example, ifntx:Species23 is the International Roughness Index (IRI) of Pinus pinea in the IFN dataset; esri is a Boolean query parameter for using the satellite base map provided by Esri (2025); and ifn can be activated to show the trees from the IFN dataset (FR7). In this way, R1 can be used to specify the location of any place in the world, with a specific zoom level, and with optional taxon filter, satellite base map, and display of IFN data, such as the route /map?loc=41.751849,-4.585419,10z&ifn=true&esri=true&taxon=ifntx:Species23. 6
New trees are created with a web form available at route R2 (FR1); query parameter loc has the same format as in route R1. Route R3 is used to provide functionalities FR0 and FR2, allowing the visualization of the annotations of a tree treeId and providing controls for creating and removing annotations. The management of trees and their annotations involves write operations that are restricted to registered users (FR3). Route R4 is used to display the last created trees in EducaWood; the optional query parameters are employed to switch from tree creations to annotations (showann), while pe and pae are used for pagination. Route R5 defines user pages employing the path parameter userId for identifying the user; tree creations and annotations are also displayed in user pages, and for this purpose, we use the same query parameters as in route R4.
In order to satisfy the nonfunctional requirements of portability (NFR0) and low latency (NFR1), EducaWood has been designed as a single-page application (SPA). SPAs are web applications that initially load a single web document and then update their body content with data from the server, thus avoiding full-page reloads. SPAs tend to provide performance gains and a more dynamic experience (Scott, 2015).
The architecture of EducaWood is graphically depicted in Figure 2. The Router component is in charge of performing client-side routing; if the browser URL changes, the Router detects it and checks its validity. A valid URL has to follow one of the routes in Table 4. The Router dispatches R1-compliant URLs to the Map handler, R2-compliant URLs to the Tree handler, R3-compliant URLs to the Tree creation handler, R4-compliant URLs to the Last trees handler, and R5-compliant URLs to the User handler. A Handler updates the view according to the incoming request, that is, the refreshed URL, and provides appropriate controls for user interaction. The Handlers will make requests to the Data manager to carry out their tasks. This latter component centralizes data access by making calls to the EducaWood API. Responses from the API are locally stored in the Data cache to minimize future exchanges; indeed, the Data manager first checks the Data cache and, in case of a miss, will make a call to the API.
Architecture of EducaWood.
In order to address the CHALLENGE #2 described in the introduction (dealing with complexity associated with the access to multiple LOD sources), the EducaWood API is built with CRAFTS (Vega-Gorgojo, 2022). The case of EducaWood is quite suitable for using CRAFTS, given the need for highly flexible data access with read and write operations over four different endpoints. CRAFTS provides a simple REST API exposing RDF resources and parametrized SPARQL queries, using JSON as an interchange format, and caching SPARQL queries from the source endpoints. In other words, the use of a CRAFTS-based API serves to reduce the complexity of creating an LOD-based application such as EducaWood. This complexity is transferred to the creation of a configuration file that is used in a CRAFTS site to translate REST calls into SPARQL queries. Vega-Gorgojo (Vega-Gorgojo, 2022) describes the elements of a CRAFTS configuration file, while the OpenAPI specification of CRAFTS is browsable (and actionable) at https://crafts.gsic.uva.es/docs/.
Appendix A depicts the configuration file of the EducaWood API—essentially a JSON object with a collection of keys and values. apiId contains the identifier of the API, educawood. endpoints includes the information for accessing the four endpoints in EducaWood, 7 model contains an array of the different RDF resources exposed by the API; each one defines mappings of RDF data to JSON by referring to datatype properties (dprops), object properties (oprops), and class membership (types). queryTemplates list a number of parametrized SPARQL queries. Table 5 includes a sample of the API calls used in EducaWood.
Sample Calls to the EducaWood API.
As shown in Figure 2, EducaWood integrates data from four distinct sources (EducaWood, CrossForest, Wikidata, and DBpedia). We have established a dedicated triplestore, referred to as EducaWood, 8 to store all tree annotations generated within the application. This dataset is continuously updated with user contributions, which requires write access via SPARQL Update (Gearon et al., 2013). While the CRAFTS API includes the necessary credentials for SPARQL Update (not explicitly shown in Appendix A), EducaWood also incorporates the STA ontology, as detailed in Section 3.2.
The CrossForest dataset was created as part of our involvement in the European CrossForest project (Cross-Forest, 2020). This comprehensive resource encompasses national forest inventories and land cover maps from Spain and Portugal. A detailed description of the ontologies we designed to define the required forestry terminology, as well as the process of transforming the source databases into LOD, is provided in Giménez-García et al. (2024). Within EducaWood, the CrossForest dataset serves two primary purposes: (1) providing access to tree data from the Spanish National Forest Inventory (IFN), which includes approximately 1.4 million native trees; and (2) serving the IFN species taxonomy to support tree species annotations. Each tree species in CrossForest is annotated with scientific and multilingual common names, linked to higher taxonomic ranks (e.g., genus, family, and class), and aligned with external knowledge bases such as Wikidata and DBpedia.
The remaining data sources, Wikidata and DBpedia, are well-established within the Semantic Web community. While their role in EducaWood is not central, they exemplify the advantages of Semantic Web-enabled data integration. By leveraging the alignments between CrossForest and these sources, EducaWood retrieves additional information such as species images and links to Wikispecies (2025), Wikimedia (2025), and the Global Biodiversity Information Facility (GBIF, 2025) from Wikidata, as well as multilingual textual descriptions from DBpedia.
Rendering Maps
EducaWood addresses CHALLENGE #3 (efficient visualization of large geospatial semantic datasets) using a novel approach for rendering maps. At launch time, the Data manager prepares the taxonomy of tree species in a bootstrapping routine by sending several C0 and C1 calls (see Table 5). C0 serves to obtain the hierarchy of taxons that derive from the ancestor class Gymnospermae (ifntx:Class2) by using the subclasses template query included in the EducaWood API; a trivial replacement of ifntx:Class2 with ifntx:Class1 serves to gather the hierarchy of taxons that derive from the ancestor class Angiospermae. 9 C1 is then used to retrieve representations of the different taxons found, using the RDF resource Species from the model in Appendix A 10 ; while C1 includes three taxons for illustration, the Data manager will make C1-like calls packing a larger number of taxons so as to limit exchanges with the EducaWood API.
The Map handler is in charge of supporting the map navigation functionality (FR4), showing the trees on the map view using LOD as source (EducaWood and CrossForest endpoints). An interactive map is used for this purpose, supporting typical panning and zooming operations that are naturally supported for both point-and-click and touchscreen interfaces. The Map handler carries out this task by handling R1-compliant routes. Upon an incoming request, the map view is centered on the location extracted from the browser URL, and with the indicated zoom level. Then, a rectangular grid, centered at point LAT=0, LONG=0, is employed to fill the map view; cell side is configured to 12
A grid cell is the unit of work to display trees on the map. The Map handler begins by identifying the cells corresponding to the map view and subsequently sends individual data requests for each of these cells to the Data manager. When a cell request is received, the Data manager gathers only the Request tree #1001 of the map cell (call C2 in Table 5) (finish if tree #1001 exists, otherwise continue). Count the number of trees within the map cell (C3) (finish if the count is 0 or greater than 100, otherwise continue). Discover the trees within the map cell (C4) Obtain basic representations of the trees found in step #3 (C5).
Step #1 serves to assess whether there is a large number of trees within a cell, that is, more than 1000, without requiring to count them all (an expensive operation in SPARQL). If this is not the case, the actual count is obtained in step #2. In the range of 1–100 trees, it makes sense to display individual markers, so step #3 serves to discover the IRIs of the trees and then step #4 to retrieve their basic representations. This procedure illustrates the case of the EducaWood endpoint; if the IFN dataset is selected (parameter ifn in route R1), a similar procedure will be carried out with the CrossForest endpoint using alternative query templates and RDF resources, for example, treesinbox instead of educatreesinbox (check Appendix A for more details). Taxon filtering (FR6) is also supported in cell requests: the sample C4 call in Table 5 contains a P. pinea filter, while all the query templates employed for map exploration include an optional taxon filter parameter. It is also relevant that responses from the EducaWood API are always cached, thus allowing for the reuse of previous cell results when requested again. Moreover, the Data manager exploits the Data cache to derive new information without making further API calls, as in the following cases: If cell If cell If cell If cell Etc.
Once cell data is retrieved, the Map handler can proceed with rendering. Figure 3 shows the map interface of EducaWood in different places of the world (requirement R4 in Table 2) at different resolutions (FR5). Figure 3 (c) illustrates tree filtering by taxon (FR6), in this case ifntx:Species23 (P. pinea). Trees from the IFN dataset are displayed in Figures 3(b) and 3(c), thus illustrating requirement FR7. The map controls in Figure 3 include a download button in the right panel for supporting FR8.
Snapshots of the map interface of EducaWood. (a) Route /map?loc=41.843949,0.548121,6z, corresponding to a large area in South–West Europe. (b) Route /map?loc=41.752276,-4.585411,10z&ifn=true, focused on a mid-size area in North Spain. (c) Route /map?loc=41.751849,-4.585419,10z&ifn=true&esri=true&taxon=ifntx:Species23; this is the same area as (b), but restricted to Pinus pinea species and using the Esri satellite base map. (d) Route /map?loc=41.986754,-4.516886,18z&esri=true, showing a tiny urban area with numerous tree markers.
Snapshots of the tree creation and tree view pages of EducaWood. (a) Form for creating a tree associated with route /newtree?loc=41.611668,-4.777814,20z; the position is extracted from the route, while the user has set Pinus pinea in the tree taxon field; the remaining fields are currently blank. (b) View of a modal window that appears upon selecting the information button for a tree taxon (P. pinea in this case). (c) Visualization of the tree at route /tree/Neik7P0woiDY; source data corresponds to the RDF snippet in Listing 1; this view belongs to the creator of the tree, so there are controls for deleting the tree, creating new annotations, and removing existing annotations (with the exception of the photo, which was contributed by another user).
Here we focus on CHALLENGE #1 (support of semantic annotations by nonexperts on Semantic Web technologies) by providing a holistic view of how the EducaWood components work together when viewing and creating tree annotations. We outline the sequence of significant API calls, illustrating how the requirements in Section 3.1 are satisfied.
The creation of a new tree (FR1) uses an R2 route. The Tree creation handler is responsible for rendering a tree creation form with various fields, each corresponding to different types of annotations in the STA ontology (see Section 3.2). Figure 4(a) shows the tree creation form; it employs different widgets to facilitate content authoring. The route enforces the inclusion of a valid position for the tree. The remaining form elements are optional and can be easily used to include additional types of annotations (FR4). Once the user pushes the “Create tree” button, the Tree creation handler generates a unique ID for the tree and uses the creation form to prepare a JSON object that follows model educatree in Appendix A. The Tree creation handler will transfer this object to the Data manager to actually create the tree in the dataset. This will be simply achieved by making a C7-like call in Table 5 to the EducaWood API with the JSON object enclosed in the body request. The API will validate this call and will then make an INSERT DATA operation with the triples to be inserted into the EducaWood endpoint.
EducaWood uses R3 routes to provide comprehensive visualizations of trees (FR0). The Tree handler is in charge of this functionality; upon extracting the treeId from the route, it will ask the Data manager to obtain the tree record. If it is not cached, the Data manager will make a C6-like call to the EducaWood API. With the response, the Tree handler will prepare a webpage that adequately presents data to users, as illustrated in Figure 4(c).
The Tree handler may include controls to make tree annotations and delete the tree depending on the user identity (FR2 and FR3). New annotations are supported for each annotation type with appropriate widgets to easily include new values, as shown in Figure 4(c). The Tree handler will gather the value introduced by the user and prepare a JSON PATCH (Bryan, 2013) referred to the model educatree in Appendix A. The patch will be transferred to the Data manager that will make a C8-like call to the EducaWood API. The latter component will validate the call and then proceed with the update of the EducaWood endpoint.
Deletion of tree annotations is handled very similarly to annotation creation. Once the user has confirmed the deletion of an annotation, the tree has to be updated with a PATCH to reflect changes: the Data manager will make a C8-like call to the EducaWood API. Additionally, it will delete the dangling annotation by making a C9-like API call. As for tree deletion, this case requires a C10-like call to remove the tree; the Data manager will also make explicit C9-like deletion calls to each associated annotation. This is because CRAFTS does not propagate deletions to other RDF resources by design (Vega-Gorgojo, 2022).
Regarding Last trees handler and User handler in Figure 2, these components are simpler than the previous handlers as they only provide visualizations and do not deal with data updates. Last trees handler is purposed for displaying the latest trees and annotations produced in the application. As always, the Data manager obtains the content by using query templates mostRecentEducatrees and mostRecentAnnotations of the API (check details in Appendix A). Unsurprisingly, the User handler prepares webpages of users in EducaWood. The Data manager employs the model Person to retrieve essential information such as nick or creation date (see Appendix A). As user webpages also contain their latest trees and annotations, query templates mostRecentEducatrees and mostRecentAnnotations are reused for this purpose, in this case setting parameter user to only obtain their created trees and annotations.
Implementation Details
EducaWood is coded in JavaScript; this programming language is the natural choice for developing web applications. We use the JavaScript module syntax (Mozilla Foundation, 2025), the recommended way for developing modern web applications, Node Package Manager (npm; npm, Inc., 2026) as package manager, and Parcel (Govett & Parcel Contributors, 2025) as build tool. Notably, the Map handler relies on Leaflet (Agafonkin, 2025) for the interactive map through the use of markers, popups, map controls, and interaction capabilities. As base maps, we employ OpenStreetMap Contributors (2025) and Esri World Imagery (2025).
We use Bootstrap (Bootstrap team, 2026) as a front-end framework to easily accommodate different browsers and screen sizes in a responsive way. The top-left bar of the map view in Figure 3 uses Bootstrap components. Web pages for tree creation (Figure 4(a)), tree visualizations (Figure 4(c)), last trees, and users are entirely based on the Bootstrap framework. We use Mustache (Wanstrath, 2026) templates in the creation of HTML pages, greatly simplifying the rendering of tree and user pages. We also employ the utility functions of Underscore (Ashkenas & Underscore.js Contributors, 2024) for handling collections along the code.
We use several modules of the Firebase suite (Google, 2025) for different purposes. We employ Firebase Authentication with Google Sign-in as identity provider; we extract the user’s unique ID from this service to assign user IDs in EducaWood. 13 Tree images are stored in Cloud Storage for Firebase. We employ Google Analytics for Firebase to track user activity on EducaWood.
The EducaWood API is deployed on a test site of CRAFTS, accessible at https://crafts.gsic.uva.es/apis/educawood/. EducaWood includes a configuration file with the URL of this API along with a token for accessing CRAFTS through Bearer authentication (Jones & Hardt, 2012). This configuration file also contains access data to a Solr (The Apache Software Foundation, 2025) text search server for looking up worldwide places; this can be seen in the text search box in Figure 3.
Since EducaWood needs to be localized to English and Spanish (requirement NFR2), EducaWood API is configured to extract all labels and descriptions in these two languages. Moreover, the application includes a multilingual string file with all the labels employed in the user interface. Users can choose their language preferences in the application menu (hamburger button in Figure 3).
The source code of EducaWood is available on GitHub (Vega-Gorgojo, 2025). A live version of the application (Vega-Gorgojo, 2023) is openly available for anybody who wants to use it.
Usage of EducaWood
We showcase the functionalities of EducaWood in Section 4.1. A forestry educational scenario of the application is presented in Section 4.2.
Illustration of EducaWood Functionalities
A typical session with EducaWood begins with the map interface, where users can freely explore any location worldwide. Navigation controls for panning and zooming operate in the same way as common map applications. Tree data is rendered according to the approach described in Section 3.5. For instance, Figure 3(a) shows a vast area (zoom level six) in South–West Europe, with a large cluster labeled “430” and numerous tree markers distributed across South and North Spain, South France, and North Italy. When the IFN button is activated, additional trees from the IFN dataset are displayed. This is illustrated in Figure 3(b), which covers a medium-sized region (zoom level 10) in the northern Spanish plateau: tree clusters proliferate with labels ranging from “101” to “+1K,” while tree markers in pale green represent IFN trees.
The Taxon button in the upper bar allows filtering by taxon, and the Layer button in the right bar switches the base map. Figure 3(c) is positioned in the same area as Figure 3(b), but with the esri query parameter enabled and the taxon filter ifntx:Species23 (P. pinea). As a result, the Esri satellite base map is displayed, and only P. pinea trees remain visible: clusters are fewer, while individual tree markers predominate, shown mostly in pale indigo (IFN trees) with a few in solid indigo (from the EducaWood endpoint). Figure 3(d) zooms in further to a small area (zoom level 18) at the Yutera campus of Universidad de Valladolid, with the esri parameter still active. The map shows university buildings surrounded by numerous tree markers, all in solid green (EducaWood endpoint). One marker is expanded, revealing a pop-up with detailed attributes: a photo, nickname, tree status, height, diameter, creator, and creation date.
The right-hand bar in Figure 3 also features a Download button. When activated, users can draw a polygon on the map to define their area of interest. They can then specify the desired level of detail—either summarized tree reports or full tree annotation—and select the output format (GeoJSON, CSV, or KML). The Map handler will obtain the set of trees within the polygon and proceed with the download.
When the “More information” button of a tree marker is clicked (see Figure 3(d)), a detailed visualization of the tree is presented, as illustrated in Figure 4(c). The underlying source data is shown in Listing 1, which provides a complete example of a tree annotated with STA and formatted in Turtle. Each annotation type employs the corresponding terms defined in STA (see Section 3.2. This example includes two species annotations,
Tree creation is initiated from the map interface by clicking the tree icon button 14 (see Figure 3), and then selecting the desired position on the map. A creation form, such as the one in Figure 4(a), is then displayed. The position can be fine-tuned by dragging the red marker on the map. While a position is always required, all other fields in the form are optional. In the running example, the user adds a taxon annotation: P. pinea (ifntx:Species23). Taxon information can be readily explored (Figure 4(b)) and is obtained from multiple sources during the bootstrapping routine described in Section 3.5: the CrossForest endpoint (scientific and common names), DBpedia (descriptive text), and Wikidata (images and links to GBIF, Wikidata, Wikipedia, and Wikispecies). When the “Create tree” button is pressed, the JSON object shown in Listing 2 is sent to the EducaWood API via call C7 in Table 5. Then the API maps the object to triples and inserts them into the EducaWood endpoint.
All created trees and their annotations are publicly accessible. However, only registered users are permitted to make edits. If a user is not logged in, tree data remains visible, but editing controls are disabled. Registered users can add new annotations (blue “+” buttons in Figure 4(c)) and delete their own annotations (red “x” buttons), but they cannot remove annotations created by others. Tree creators additionally have the right to delete their own trees (red “Delete the tree” button in Figure 4(c)).
When a user submits a new annotation, the application generates a JSON PATCH similar to the one in Listing 3. This example illustrates the creation of a taxon annotation (
Users may also delete their own annotations. Once confirmed, the application generates a JSON PATCH such as the one in Listing 4, which includes a remove operation to eliminate
Finally, tree creators may choose to delete their trees entirely. After confirmation, the application issues call C10 to remove tree:yUhX0LzFP-57. Deletion of the tree does not automatically remove its annotations; the application will then send C9-like calls to delete each associated annotation (spann:yUhX0LzFP-57 and posann:yUhX0LzFP-57 in this case).
A Forestry Education Scenario
We present an urban tree management scenario that can be supported with EducaWood. It is inspired by the educational design of the “Reforestation, Nurseries, and Gardening” course in the third year of the Forestry and Environmental Engineering degree at the Universidad de Valladolid. The scenario has three main learning goals: (1) managing urban tree inventories; (2) identifying and calculating the key variables of an urban tree management plan; and (3) writing a strategic plan based on those variables.
In the first stage, students collaboratively create a tree inventory with EducaWood. The target area should be an urban garden of suitable size to ensure a manageable workload for students. Using the application, they annotate trees by recording positions, species identifications, images, dendrometric measurements, tree status, and textual observations. This activity may be conducted in a single session or distributed across several sessions, depending on time constraints and contextual factors. A preliminary training session with EducaWood is recommended to familiarize students with the application’s functionality. Optional follow-up sessions may also be scheduled to correct missing or inaccurate annotations, for example, an incorrect species identification.
In the second stage, students work with the previously created tree inventory. With EducaWood, they select the target area and download the tree data, which serve as the basis for calculating several variables: quality indicators (number of trees per inhabitant or per hectare), biodiversity indicators (number of species, proportion of the most abundant species), dimensional indicators (distribution of trees by diameter classes or height ranges), and condition indicators. Finally, students draft an urban tree management strategic plan informed by these calculated variables.
EducaWood in Practice
In Section 5.1, we present evidence regarding the impact of EducaWood thus far. Additionally, we report a pilot in an urban tree management activity with forestry engineering students in Section 5.2.
Preliminary Impact
In 2021, we presented an early demonstrator of EducaWood in the 16th European conference on technology enhanced learning (EC-TEL 2021; Andrade-Hoz et al., 2021). Although the functionality of this demonstrator was limited, it allowed testing key system components, particularly the creation of trees through a CRAFTS API. Following this, EducaWood received the third award in the “III Desafío Aporta” (Ministerio para la Transformación Digital y de la Función Pública, Gobierno de España, 2021), a Spanish open data challenge sponsored by the Spanish Ministry of Digital Transformation.
Encouraged by this early success, we worked on a new version of EducaWood that meets the requirements outlined in Section 3.1. In July 2023, we released a new prototype (Vega-Gorgojo, 2023), aimed at supporting forestry education scenarios. We tested the application with a selected group of forestry experts, who provided very positive feedback and valuable suggestions, leading to the incorporation of features such as a tutorial, satellite-based map, drawing tool for defining data download areas, support for tree nicks and text observations, and tree form improvements to facility data entering. More recently, we expanded the outreach of EducaWood by sharing it with academic contacts and running a pilot with forestry students, which is summarized in Section 5.2.
Since traffic on the EducaWood website is tracked with Google Analytics, we can report some figures in the period from July 2023 to January 2025. Table 6 summarizes the collected data; 653 active users have employed EducaWood in 1,471 engaged sessions 15 with an average duration of 2 min and 30 s. Most users are from Spain (52.5%), while the rest come from Italy (8.9%), the Netherlands (6.4%), Sweden (6.3%), Finland (4.9%), United States (4.9%), and other countries (16.1%). Devices employed include desktop computers (51.0%), mobiles (48.4%), and tablets (0.6%). We also tracked page views (32.3K in total), finding that the map interface route is the most intensively used (77.8% of all page views); activity in the remaining routes ranges from 7.8% to 1.1% (see Table 6).
Uptake of the Test Site of EducaWood.
Uptake of the Test Site of EducaWood.
We have also analyzed the annotations created in the EducaWood dataset. As of January 2025, the dataset contains 48K triples, corresponding to 1,682 trees and 4.5K tree annotations. Notably, 51 users contributed to content generation, constituting 7.8% of the application user base.
The tracked data also includes latencies for
Context of the Study
We have carried out a pilot study of EducaWood within the context of a “Reforestation, Nurseries, and Gardening” course in the third year of the Forestry and Environmental Engineering degree at Universidad de Valladolid. The course has two teachers and 20 enrolled students. The learning scenario corresponds to the one presented in Section 4.2. To achieve its learning goals, and considering that the students did not have prior knowledge about tree management, the teachers structured the scenario in three main stages.
First, a 2 h training session in November 2023 familiarized students with EducaWood through a classroom demonstration, followed by a practical tree annotation session in the campus gardens, and a subsequent verification of the accuracy of tree labeling in the classroom. During the classroom demonstration, the teachers introduced the application by showing its interface, explaining all available options, and providing examples. A first annotation session took place immediately after the classroom demo. During this session, the teachers were available to answer any questions and doubts in relation to the use of EducaWood. Afterwards, the teachers reviewed the students’ annotations. Errors detected included missing annotations and unclear observations that were difficult to interpret by other users. A follow-up classroom session was conducted to provide feedback on these mistakes and guide students on how to correct them.
Second, the students were asked to collaboratively create a tree inventory at the Yutera Campus throughout November and December 2023. Each student had to annotate a minimum of 20 trees with EducaWood. The minimum of 20 trees per student was estimated to ensure that the entire tree population on campus would be recorded, while keeping the workload of the students within the course restrictions.
Third, students had to prepare an urban forestry management plan for the Yutera Campus, utilizing the collaboratively created tree inventory. This involved downloading tree data from EducaWood, calculating various variables, and preparing the tree management strategic plan.
While the pilot was ongoing, the resulting tree inventory could be accessed and verified using EducaWood by both teachers and students—Figure 3(d) provides an example at the target location.
Method
We followed a mixed-methods, embedded (concurrent-nested) design with qualitative preference (Creswell & Creswell, 2022), trying to understand, from an interpretive perspective, how EducaWood supported the teachers’ practice in terms of pedagogical alignment, assessment affordances, and usability challenges. Two data gathering instruments were employed: students and teachers were asked to fill the standardized System Usability Score (SUS), a validated quantitative survey widely employed in usability studies (Brooke, 1996); and, a semistructured interview between one of the researchers and the teachers focused on usability issues and pedagogical alignment of EducaWood. Descriptive statistics were employed for analyzing the SUS data, while inductive coding was applied to the transcribed interview, using the technique known as “solo coding” in which the whole research team discusses and agrees upon the emerging codes identified by one of the researchers (Saldaña, 2021).
It is important to underline that our interpretive approach in this pilot study does not aim to provide statistically generalizable evidence about the educational affordances or usability of EducaWood. Rather, our goal is to gain a sufficiently deep understanding of how the application is used within an authentic, yet specific, learning context—one that exemplifies the challenges identified earlier in the paper.
Results
Each student annotated a similar number of trees, as the scenario design and teachers’ estimation of the tree population ensured balanced assignments. Teachers verified that all students completed at least 20 annotations and maintained quality standards. The activity score was based entirely on the strategic forest management plan, and all enrolled students successfully passed the activity. We received 16 responses, 16 obtaining an average SUS score of 75.2, with a standard deviation of 11.5. This figure is good, given that SUS scores range from 0 to 100. According to the grading scale interpretation of SUS scores in Sauro and Lewis (2012, chapter 8), EducaWood was graded with a B. This indicates a good level of usability. Nevertheless, the teachers also reported some minor usability problems during the semistructured interview: “There are some format issues; I had to call [researcher’s name] for help. The system exports data as a CSV file, but when converting to Excel, some problems arise.” Another issue raised by the teachers was the need for better documentation and tutorials: “I missed having tutorials. At a minimum, there should be a video or a tutorial for data collection.”
Also, during the semistructured interview, the teachers provided their feedback about the impact of EducaWood when supporting the described learning scenario. Interestingly, one of them highlighted the potential of EducaWood for supporting forestry engineering educational activities related to tree management, from a more practical perspective: What is interesting is that students not only label the trees but also calculate a series of indices that could be incorporated. In urban tree management plans, such as those from Madrid, I ask them to calculate the indices listed in the plan. Similar indices exist in plans from other cities like Seville, Barcelona, and Valencia. These indices help determine age, size, species diversity, pruning needs, and overall tree management. Once students have a database, EducaWood allows them to put numbers to their knowledge, which is often lacking in urban tree management. A major issue in urban tree management is the lack of inventories and tools to create them continuously and easily. EducaWood has enormous potential beyond its role as an educational tool.
Furthermore, the teachers explained that this was the first time they carried out this type of learning scenario, thanks to the affordances of EducaWood: [EducaWood] is an easy thing, it allows you to resume the activity when you had stopped before, it allows you to review data, it allows you to check, it allows you to work with the data from others. It gives you a lot of possibilities, a big lot of possibilities. It is a powerful tool, a very powerful tool.
In fact, the teachers pointed out that EducaWood solves one important existing problem when planning educational activities in relation with tree management plans: One of the problems we have in relation with urban tree management is that we do not have tree inventories and we do not have tools that allow to create those inventories on a sustainable basis. Well, this is a very great potential for EducaWood, very very great. EducaWood is truly an educational tool, but it could even go beyond.
EducaWood has also provided support during the assessment of the learning activities: I have assessed two aspects. One, the inventory that they have created with EducaWood, and, another, the report. Then, the inventory, what I check is that they have 30 trees and that they are completely described, more or less. And this is assessed on the one hand, and then the report they write with the data from the whole database.
Discussion
EducaWood is a LOD-based application for forestry education that successfully meets all the requirements in Table 2. It enables multiauthor tree management and geospatial data visualization, integrating diverse data sources through a CRAFTS API. Tree annotation relies on the STA ontology, offering a flexible model for annotating trees and including a conflict resolution mechanism via primary annotations—Section 3 gives multiple examples of the use of this ontology for annotating trees. STA can be extended in different ways and we have already received suggestions from foresters, including: new annotation types like microhabitats (cavities, excrescences, exudates, epiphytics, nests, etc.)—as shown in (Larrieu et al., 2018); additional spatial entities such as down deadwood (Maser et al., 1979); and, specialized terminology for urban tree management (e.g. tree pits and pruning).
EducaWood addresses three major challenges in handling semantic data for forestry education. Regarding CHALLENGE #1, human–computer interaction with the Semantic Web, the user interface of EducaWood follows good practices in web application design to simplify interaction with Semantic Web technologies. It provides an interactive map to visualize tree data at various zoom levels, complemented by form-based interfaces for both viewing and authoring trees. Page URLs are designed to encapsulate all application state—check the routes in Table 4—ensuring that a URL will produce the same view regardless of the device employed and allowing users to safely bookmark and share EducaWood URLs. Findings from the pilot indicate that this user interface design effectively addresses two key objectives: (1) concealing the intricacies of Semantic Web technologies, and (2) facilitating user tasks. This is supported by the good SUS score and the successful creation of a tree inventory with EducaWood—see Section 5.2. The application streamlined the tree annotation workflow, which traditionally involves collecting data on paper, transferring it to a computer, and then sharing it. With EducaWood, students uploaded data in situ in a consistent format, reducing positioning errors and eliminating the need for manual data transfer. This also significantly reduced teachers’ workload, as they no longer needed to collect, aggregate, and redistribute annotations. It is noteworthy that neither pilot students nor teachers have a background in Semantic Web or databases, highlighting the challenge of user interaction with Semantic Web technologies (Charalampidis & Keramopoulos, 2018; Dadzie & Rowe, 2011; Heath et al., 2006). The use of form-based interfaces for semantic annotation aligns with established good practices in usability and has proven effective, as demonstrated in EducaWood and other systems such as Wikidata.
Accessing data in EducaWood can be demanding due to the mixture of write and read operations across multiple data sources (CHALLENGE #2). Nevertheless, the utilization of a CRAFTS API significantly streamlines this process by providing a centralized access point for all data operations. This required a thorough authoring of the configuration file in Appendix A to support the different features of EducaWood—Table 5 gives a good overview of the API calls used in the application. Template queries are primarily employed during the bootstrapping routine and map exploration, with careful attention given to meeting latency requirements, as elaborated in Section 3. In this regard, we employ client-side caching along a user session to avoid duplicated requests to the API, as well as exploiting geospatial relations among cells to derive new information without making further API calls. Tree management essentially involves the use of model educatree with the appropriate HTTP methods (GET, PUT, PATCH, DELETE) for retrieving, creating, updating, and deleting trees. All in all, the application only sees JSON data and REST API calls; CRAFTS automatically makes the translation of API requests into SPARQL queries.
When addressing CHALLENGE #3, EducaWood employs various techniques to efficiently handle semantic geospatial data. Our grid of cells for requesting tree data is inspired by tiled web maps (Sample & Ioup, 2010), a prevalent strategy for enhancing the cacheability of web maps. By dividing a map into a grid, EducaWood ensures that identical API calls are made for data within the same cell by different users, optimizing server caching at CRAFTS. To manage cells with varying tree densities, EducaWood uses a procedure that limits data requests when numerous trees are present. Moreover, EducaWood also exploits geospatial relations among cells to reduce the number of API calls (see Section 3.4). We have tested this approach with the 1.4 million trees in the IFN dataset across various regions of Spain and at different zoom levels. The application processes them efficiently, maintaining response times below one second without significant delays. These techniques hold broader applicability to scenarios involving semantic geospatial data. For instance, they can be applied in Forest Explorer (Vega-Gorgojo et al., 2022) to improve the handling of forestry data. We are currently refining Forest Explorer with techniques from EducaWood, including a CRAFTS API, a grid of cells, exploitation of geospatial cell relationships, and URL redesign to facilitate their sharing. While Forest Explorer and EducaWood share some similarities, they are fundamentally different in scope and functionality. Forest Explorer does not support collaborative tree annotation (requirements FR0–3 in Table 2) and is limited to Spain and Portugal, so worldwide tree exploration (FR 4) is not supported. Additionally, EducaWood focuses exclusively on trees, whereas Forest Explorer also includes administrative regions, land cover patches, and inventory plots. Given such differences, it is not possible to make a quantitative comparison between the two applications.
Thus far, EducaWood has been tested by more than 650 users, with 7.8% of them actively contributing content. This creator-to-consumer ratio surpasses the 1% rule of thumb often observed in Internet communities (Arthur, 2006), although collected data in EducaWood is still limited. To moderate its emerging community, we have defined several roles within the application: normal users can create trees and annotations, with the ability to delete their own contributions only; superusers can delete any content and ban normal users; while banned users are restricted from authoring. Each annotation includes its creator, facilitating swift action against vandalism.
While EducaWood presents significant advancements, it also has some limitations. First, the application has been tested primarily in a pilot study in a University course. While the results are promising, broader testing across different educational contexts and user groups is needed to validate its effectiveness. Second, while the STA ontology is flexible, it may require further refinement and expansion based on user feedback and evolving educational needs, as discussed earlier. Lastly, EducaWood could benefit from explicit support for tree annotation tasks that teachers can design, thereby better aligning the application with specific educational objectives, similar to CHEST (García-Zarza et al., 2025) in the Cultural Heritage domain.
Conclusion and Future Work
EducaWood emerges as a versatile educational tool poised to enhance environmental education across various educational levels, spanning from secondary to university master’s programs. The learning objectives of EducaWood can encompass a broad spectrum, aiming to cultivate various skills and knowledge among students, depending on the activity designed by teachers. This paper has illustrated how the annotation capabilities of EducaWood can be used in one particular authentic learning scenario in the context of forestry engineering education: tree management. However, other interesting learning scenarios might include, for example, the differentiation of main groups of forest species, fostering a deeper understanding of ecosystem diversity, and igniting a greater interest in nature among learners. Also, interdisciplinary learning can be favored by incorporating mathematical concepts such as calculating structural diversity indices and carbon sequestration rates, thereby enhancing students’ quantitative reasoning skills. So EducaWood promotes collaborative learning experiences, nurturing teamwork and communication skills essential for effective problem solving and group dynamics. Nevertheless, and in order to better understand the educational affordances of EducaWood, we plan future research lines aimed at defining different personas of educational user types and linking their requirements with the application functionalities more explicitly, on top of those more specific to tree annotation. For example, while teachers and students are the primary user types of EducaWood, we can take a step further by identifying distinct teacher personas based on their experience, goals, behaviors, and needs. This allows us to assess how well EducaWood supports a diverse range of teaching approaches. Some teachers may use EducaWood solely as an annotation tool—as illustrated in the study presented in this paper—whereas others might design more complex learning activities centered around specific trees of interest. Indeed, we are currently working on adding to EducaWood a teacher interface for the creation of different types of geolocalized learning tasks, such as multiple-choice questions, comparing trees, etc. This is an approach that we have explored in the domain of Cultural Heritage education (see, e.g., García-Zarza et al., 2025).
By bridging classroom learning with real-world experiences, EducaWood extends the educational landscape beyond traditional confines, fostering active and contextualized learning. Moreover, it amplifies ecological awareness by spotlighting forests’ pivotal role in climate change mitigation and biodiversity conservation. Its innovative features, such as collaborative annotation functionalities, not only facilitate remote learning but also enable students from diverse backgrounds to engage with forest ecosystems regardless of geographical constraints. This adaptability is very valuable, especially in navigating challenges such as those posed by the COVID-19 pandemic, where traditional in-person educational activities may be impractical. Our future work includes new pilots in forestry education to gather feedback and further improve EducaWood, thereby bolstering its utility for environmental education. We also plan to conduct additional tests to evaluate scalability, as well as to improve EducaWood with the possibility of combining annotations and data analysis at different layers (e.g., highlighting a large number of dead trees in an area).
Footnotes
Acknowledgment
The authors thank the participants in the pilot study.
Funding
The authors disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This work has been partially funded by the European Commission through “Small4Good” (101135517), by the Spanish Research Agency through “LOD.For.Trees” (TED2021-130667B-I00), “H2O” (PID2020-112584RB-C32), and “GENIELearn” (PID2023-146692OB-C32) projects, by the Junta de Castilla y León through project “iuFOR Institute Unit of Excellence” (CLU-2019-01) of Universidad de Valladolid and co-financed by the European Regional Development Fund (ERDF “Europe drives our growth”).
Conflicting Interests
The authors declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.
ORCID iDs
Notes
Appendix A. CRAFTS API Configuration of EducaWood
We include here the CRAFTS API configuration file employed in EducaWood. For further information on the use of CRAFTS, refer to Vega-Gorgojo (2022).