This paper presents a comparative analysis of three approaches for representing and processing geometric data within RDF frameworks: (1) RDF-based Geometry Modeling, (2) Extending Triplestore and Querying Capabilities, and (3) Integrating RDF-compliant Systems with Native Geometry Stores or Computer-Graphics Libraries. Each approach is evaluated based on expressiveness, complexity, geometric support, processing capabilities, validation, scalability, interoperability, and adherence to standards. The study highlights the strengths and limitations of these methods, particularly in the context of Building Information Modeling (BIM). The findings provide insights into the trade-ofs between RDF-native and hybrid solutions, ofering guidance on their applicability for handling complex geometric data in BIM workflows.
The Architecture, Engineering, and Construction (AEC) industry relies heavily on Building Information
Modeling (BIM) to digitally represent buildings and infrastructure. In this model, geometric data plays
a central role, supporting accurate positioning, integration, and alignment of building components [
The decentralized structure of the AEC industry, encompassing diverse disciplines such as architecture
and engineering, is subject to challenges such as fragmented collaboration, dificulties in data sharing,
and the need for efective coordination across multi-disciplinary domains [
CEUR Workshop Proceedings
ceur-ws.org
ISSN1613-0073
eficiently [
Thus, the lack of geometric processing capabilities in standard semantic technologies is often identified
as a major limitation [
In Section 2 we describe an industrial case study that illustrates the aforementioned limitations and provides the motivation for this research. The methodology we used is described in Section 4. Section 5 describes results of the comparative analysis. Finally, in Section 6, we elaborate on the results and implications for the case study. We conclude the paper with a short outlook and outline of future work.
The construction industry and building maintenance count as a major source of greenhouse gas (GHG)
emissions, around 37% [
Semantic knowledge representation as a data management methodology ofers the necessary data
integration, interoperability, and overall data linking capabilities to implement serial production of
buildings. Buildings are represented using models that leverage ontologies as a universal modeling
language. By utilizing RDF’s flexible data structure, teams across diferent disciplines can progressively
enrich the building model with specialized domain knowledge. Moreover, a systematic geometric
data representation is essential aspect for interoperability of any BIM [
The system must accommodate various geometry representations, e.g. BRep and CSG, as well as coordinate systems, e.g. local project coordinates, and GIS data. Additionally, a hierarchical geometry structure is required to accurately model elements relative to a reference coordinate grid. These capabilities ensure that the model remains flexible and interoperable across diferent teams and usecases. Given the premise of our study, which emphasizes the needs of serial production of residential buildings, we have deliberately excluded complex geometries such as curved surfaces, multi-curves, tessellated geometries, etc. Instead, our focus has primarily been on simple geometries, such as geometric primitives, simple solids, and CSGs, since they suficiently express the geometric data required for industrialized production of timber-elements and the overall building system they belong to.
As diferent teams contribute to the building model, it is critical to ensure that all geometric data is consistently structured and follows predefined conventions. While individual teams may validate their own datasets, a global validation mechanism is needed to enforce uniform standards throughout the model. For example, a polygon representation must always specify its points in counterclockwise order, with the first and last points being identical. Since parsers for serialized geometries, such as WellKnown Text (WKT), may not strictly enforce these conventions, inconsistencies can arise. Therefore, a comprehensive validation tool is required to perform a unified consistency check.
Processes require the ability to perform operations on geometric data, such as calculating the surface area of walls or the volume of solid elements. Moreover, translation is an essential operation to align local project coordinates with real-world geographic coordinates by shifting the origin between coordinate systems. These computations are essential for cost estimation, sustainability analysis, and resource planning within the building model. While these operations could be performed ofline by extracting the data and processing it externally using e.g. programming languages and libraries, integrating these capabilities directly into the query engine would significantly improve eficiency and streamline workflows. In addition, the RDF-based project dataset is simply an output of the design processes, which operate independently of the graph data. This means the RDF data does not require real-time updates with every design iteration. Instead, various design tools produce RDF datasets in predefined data-drops, which are planned to capture the project’s status at key milestones throughout its lifecycle.
A critical requirement is the ability to analyze spatial relationships between building components. For instance, determining whether two wall elements are touching or whether a device is within a wall relies on geometric processing. This capability is essential for two primary reasons: 1) to express enhanced validation constraints, e.g., to ensure that two walls do not touch if they should not, or to validate other spatial rules; 2) to support advanced use-cases, e.g. enabling building management tasks, such as device replacement, where accurately locating them is crucial. Spatial relationships typically occur at a higher level of abstraction, such as between rooms or large building elements. A simplified high-level geometric representation is preferred, as it enhances data processing and cross-domain integration. Combining geometric information with semantic power of graph data unifies data from diferent domains, such as spatial layouts, and IoT devices, and enables discovery of additional relationships.
Existing work has laid a strong foundation for representing and managing geometric data using Semantic
Web technologies across domains such as GIS, BIM, and 3D city modeling. A range of vocabularies and
ontologies have been proposed to express geometry in RDF, including GeoSPARQL, NeoGeo, W3C Geo,
and AGO. Atemezing et al. [
McGlinn et al. [18] categorize geometric data into 2D geospatial, simplified 3D, and semantically
rich 3D geometries, identifying tensions between modeling needs, visualization, and computation on
the Web. Wagner et al. [
Validation methods for RDF geometry models remain underexplored; for instance, Stolk et al. [21] apply SHACL to check data types and structural constraints in ifcOWL models but do not validate geometric correctness. Ioannidis et al. [22] provide a benchmark dataset of 2D geospatial points (WGS84) to evaluate triplestores with GeoSPARQL support, focusing on spatial selection queries like geof:sfWithin, though their work is limited to 2D geometries. Full-system approaches such as Hor et al. [23] and Vinasco-Alvarez et al. [24] demonstrate RDF transformation pipelines for CityGML and IFC models, enabling integrated queries over GIS and BIM data. However, they remain limited to data transformation and retrieval, lacking geometry processing capabilities and robust validation.
Despite these contributions, current approaches largely emphasize representation and integration while overlooking processing, validation, and performance challenges, particularly for complex 3D geometries. Our work addresses this gap by evaluating existing paradigms through the lens of geometric processing, validation needs, and scalable querying in RDF-based systems.
Our comparative analysis categorizes existing approaches into three key paradigms: A) RDF-based
category has been evaluated based on a set of defined criteria and practical examples, allowing us to systematically assess their suitability for addressing the above-mentioned challenges. The three paradigms are illustrated in Figure 1 and will be explained in the following sections. A) RDF-based Geometry Modeling: Our study covers RDF ontologies like GeoSPARQL [25], and ifcOWL [26]. These assessed ontologies have diferent degrees of expressivity and alone do not provide any processing capabilities for geometric data. One of the requirements from the use-case is the capability of supporting multiple geometry representations. This is particularly relevant in scenarios where the primary purpose of the geometric model is data exchange, with the actual processing of the geometry handled by external systems. As a result, the models used must ofer a high degree of expressiveness. Hence, this analysis is essential to understand which approaches support this, or whether multiple ontologies need to be combined.
B) Extending Triplestore and Querying Capabilities: Some approaches such as GeosSPARQL go
beyond the modeling scope and propose extensions to RDF-graph triplestores. These extensions enable
spatial functions and make the querying of spatial data possible, e.g. by introducing specialized indexes
or by means of SPARQL custom-functions [
C) Integrating RDF-based Systems with Native Geometry Stores or Computer-Graphics Libraries: Since, the two above-mentioned paradigms might not be a suitable solution for all usecases, we have explored integration strategies between RDF-triplestores and other systems more capable of carrying out geometry-related tasks. One example is PostGIS, an extension for the relational database PostgreSQL, which at a first glance ofers comprehensive 3D and 2D geometric operations, benefiting from advanced database capabilities [27]. There are plenty of computer-graphics libraries as well, which have been designed to model complex geometries, but are harder to integrate with a system based on the Semantic Web stack. The integration between hybrid systems obviously increases the overall system complexity, and hence, we aim to deeply understand the implications.
To evaluate diferent approaches for representing and processing geometric information in RDF, we define a set of key criteria that reflects both academic standards and practical requirements observed in industry. These criteria are grouped for clarity and space optimization in the summary tables1.
The criteria were chosen based on practical properties such as integration efort, maintainability, scalability, and tool interoperability. Evaluation was conducted based on modeling and querying tasks performed using actual buildings and corresponding RDF datasets. Verbosity and complexity were evaluated on RDF-based building projects with focus on comparing structural overhead and ease of use. Processing capabilities and interoperability were assessed through experiments on geometry-related operations and integration of RDF outputs in other tools. A qualitative scale is used to assess each criterion, as detailed in Section 5. While the evaluation remains qualitative, it is grounded in hands-on experience with RDF modeling, tool integration, and limitations encountered in practice.
Note that the requirements from the case study presented in Section 2 are related to these selected evaluation metrics. R1 (Support of Multiple Geometry Representations and Coordinate Systems) is mainly covered by expressiveness and interoperability. R2 (Reliable Validation of Geometric Data) essentially corresponds to validation support. R3 (Geometry-Based Computational Operations) and R4 (Understanding Spatial Relationships Between Building Elements) match processing capabilities and support for geometry translation.
In Section 4, we introduced three paradigms to address the requirements derived from our case study. This section presents a comparative evaluation of these paradigms using the criteria defined earlier. To support consistent interpretation across all tables, we apply a unified qualitative scale: none, low, moderate, and high. These terms indicate increasing levels of capability or integration. For example, none means no support or reliance on manual workarounds, while high reflects mature, scalable, and integrated functionality. This scale is used throughout Tables 2, 3, and 4. 1Grouped as: Expressiveness and Interoperability; Geometry Support and Verbosity; Processing Capabilities and Geometry Translation; Degree of Standardization; and Complexity and Scalability. See Tables 2, 3, and 4.
Description
This metric assesses how well the language or framework can represent complex geometric
structures. A more expressive system allows for a more detailed representation of geometries,
including intricate relationships between elements. It also assesses whether it supports
essential geometric modeling paradigms such as Boundary Representation (BRep) and
Constructive Solid Geometry (CSG)[
Evaluates the conceptual and structural complexity of the resulting model. An ideal approach should be intuitive and easily understood by users, ensuring that domain experts and nonexperts alike can work with the model eficiently.
Measures the level of verbosity required to define geometric elements. Some representations require highly detailed and explicit specifications, which may increase redundancy and hinder usability, while others provide more concise definitions.
Examines how well the approach integrates with existing BIM tools, data formats, and industry standards. High interoperability ensures seamless data exchange and reuse across diferent systems and platforms.
Determines whether the approach supports necessary geometric operations such as computing areas, volumes, intersections, and spatial relationships, ensuring eficiency in 3D geometric operations.
Evaluates whether the approach provides built-in mechanisms to validate geometric data.
Validation is critical for ensuring data consistency and correctness, particularly in 3D modeling scenarios where errors may lead to significant issues in downstream applications.
Examines whether the approach is based on widely adopted industry standards or proprietary implementations or it is widely adopted in specific communities, e.g. AEC, databases, etc. A higher degree of standardization facilitates long-term sustainability, compatibility, and industry acceptance. Standardization supports interoperability in AEC but may limit flexibility and innovation, especially when standards lag behind current practices or are dificult to integrate into existing workflows.
Assesses whether the approach supports geometry translation across reference systems, a key requirement for hierarchical geometric models. Geometry translation ensures spatial consistency and facilitates integration into larger BIM ecosystems.
Assesses how well the system scales when handling large BIM models and complex geometric datasets. Scalability is crucial for real-world applications where performance and eficiency are key factors in adopting a particular solution.
Several ontologies have been developed to model geometric representations or related aspects, such as coordinate systems, or geometry’s metadata, but alone they lack processing and validation capabilities. Our evaluation includes ifcOWL, GeoSPARQL, OntoBREP, OMG (Ontology for Managing Geometry), W3C Geospatial Vocabulary, Basic Geo (WGS84 lat/long) Vocabulary, SWEET Ontology, FOG Ontology, Geometry Metadata Ontology (GOM), and GEOM. Most of these ontologies cover only secondary aspects of geometry representation, such as geometry metadata or are just linking frameworks. Below we summarize the main ontology’s features.
• ifcOWL [28] – Developed to provide an RDF-based representation of Industry Foundation
Classes (IFC), the primary standard for BIM data exchange. It includes geometric constructs
such as extrusions, Boolean operations, and tessellated models, but lacks built-in validation and
computational geometry capabilities. It supports both BRep as well as CSG. However, the
resulting model is very verbose [29] and it does not address the problem of inconsistencies between
diferent representations [
While several ontologies exist to represent and link geometric data, most focus on metadata, spatial referencing, or linking RDF resources rather than providing a full geometry processing framework. The OMG and the FOG Ontology are designed to link geometry descriptions in various formats with nongeometric RDF resources. GOM also describes secondary aspects of geometry data such as coordinate systems, length units, file size and software of origin. Moreover, some ontologies are more focused on GIS concepts such as W3C Geospatial Vocabulary and Basic Geo (WGS84 lat/long) Vocabulary.
Table 2 presents a comparison of RDF-based geometry modeling approaches based on the revised evaluation criteria2. To clarify the diferences between the vocabularies, we provide a minimal example in Appendix A, showing how the same geometric object—a rectangular wall—is represented using ifcOWL, GeoSPARQL, and OntoBREP. This highlights the structural expressiveness and verbosity of each approach. Among the ontologies which enable geometric modeling, IfcOWL stands out as the most comprehensive ontology for geometry representation. It is the only ontology capable of 2In this table, the criterion ”Processing Capabilities and Support for Geometry Translation” has not been considered, as it is not applicable to this category. Approaches that extend beyond modeling and provide processing capabilities, such as GeoSPARQL, have been split into their ontology and query language components, and will be further discussed in the following section. representing both BRep and CSG. Additionally, it is the only one that supports hierarchical geometry structures with local placements, allowing transformations to be defined in a chain of reference points through transformation matrices. This makes it possible to accurately compute the absolute location of geometric elements. While IfcOWL provides the most detailed and structured representation of geometry, it still lacks built-in computational capabilities for processing and validating geometric data, a gap that remains unaddressed across all ontologies evaluated.
In addition to choosing an expressive ontology for RDF-based geometric representations, a triplestore
can be extended to provide additional processing functionality. This section explores solutions which
go in this direction, focusing on two major works: GeoSPARQL and BimSPARQL. We discuss their
respective functionalities, strengths, and limitations, particularly in handling 3D geometries.
GeoSPARQL Beyond its modeling aspects (described in the previous section), GeoSPARQL introduces
a standardized set of spatial functions for querying and manipulating geometries. These include
operations for computing distances, spatial relationships (e.g., intersection, containment, adjacency), and
transformations (e.g., bufering, simplification). While GeoSPARQL allows storing three-dimensional
coordinates, it does not fully support 3D geometry processing. The standard follows a 2.5D approach,
i.e. Z-coordinates are ignored in calculations. Consequently, true volumetric computations, such as
intersection detection for 3D objects, are not supported. To ensure RDF data consistency, GeoSPARQL
incorporates SHACL Shapes for validation. Despite its strengths in handling 2D spatial data, GeoSPARQL
lacks robust support for 3D geometric reasoning, limiting its direct applicability in BIM workflows.
BimSPARQL BimSPARQL extends SPARQL for querying BIM data in RDF, specifically for building
models in ifcOWL [
While extending triplestores with spatial capabilities ofers a promising approach for handling geometric data, existing solutions have notable limitations. GeoSPARQL provides a solid foundation for 2D spatial queries but lacks support for true 3D geometric processing. BimSPARQL, which aimed to bridge this gap by introducing building-specific geometric reasoning, is unfortunately no longer maintained or functional. This highlights the technological gap in RDF-based triplestores when it comes to advanced 3D geometry handling.
This paradigm consists of externally storing geometric data in systems such as specialized databases rather than embedding it directly as RDF-triples. By linking an RDF building graph to a spatial database, complex geometrical information can be eficiently managed and retrieved without overloading RDF datasets [33]. Depending on the type of external storage, the integration strategy could vary. For external stores with a JDBC driver, it shall be possible to create a virtual graph using OnTop and to use SPARQL federated queries to combine the geometric data with the building data. If no JDBC driver is available, more complex data flows are required, which might involve query rewriting or ETL processes. Among the available solutions, PostGIS—an extension of PostgreSQL—emerges as the only viable and fully developed system for integrating spatial databases with RDF-based knowledge graphs. 5.3.1. Geometry Processing in PostGIS PostGIS is a spatial extension for PostgreSQL that provides robust support for geospatial data, enabling it to function as a spatial database for GIS applications. PostGIS stores geometries in WKT and Well-Known Binary (WKB) formats and ofers a rich set of spatial functions for 2D and 3D geometry operations, including topological relationships, spatial transformations, and analytical queries. PostGIS supports a wide range of functions for 2D spatial analysis, including ST_Within to determine if one geometry is completely within another, ST_Distance, which computes the minimum Cartesian distance between two geometries. Other functions are ST_Intersects, ST_Contains, ST_Union.
A critical limitation of many RDF-based approaches is their inability to handle true 3D geometries. PostGIS partially overcomes this limitation by providing native 3D spatial functions, making it a viable solution for BIM-related processing. Key 3D operations include ST_3DDistance, which computes the shortest distance between two 3D geometries, and ST_3DWithin, which checks if two 3D geometries are within a specified distance. Additionally, PostGIS provides limited 3D geometry validation functions, e.g. ST_IsSolid(geometry A) checks if a given geometry is a valid solid. PostGIS also supports geometric transformations, enabling the manipulation of spatial data beyond simple storage. These transformations include ST_Translate, which moves a geometry by a specified ofset, ST_Affine, which applies an afine transformation (scaling, translation, rotation). Other functions in this category are ST_Rotate, ST_RotateX, ST_RotateY, ST_RotateZ, and ST_Scale.
Integrating RDF data with native geometry stores like PostGIS ofers an eficient way to manage complex spatial data. PostGIS is the only mature solution supporting both 2D and 3D geometries, enabling advanced spatial queries, indexing, and processing—critical for BIM applications. However, it remains a relational database and lacks native RDF support. While RDF-to-PostGIS mappings exist, there’s no standard for executing SPARQL directly on geometry objects.
Unexpected Behavior in Some 3D Functions Computation in PostGIS. PostGIS provides advanced 3D spatial functions, many of which rely on LWGEOM_mindistance3d and LWGEOM_maxdistance3d functions. The LWGEOM_mindistance3d function computes the shortest Euclidean distance by evaluating vertex pairs rather than true surfaces, leading to inaccuracies when the nearest point isn’t explicitly a vertex. Similarly, LWGEOM_maxdistance3d finds the greatest separation between vertices, which may not reflect the actual maximum distance for concave geometries.
These limitations afect functions like ST_3DDistance, ST_3DWithin, ST_3DFullyWithin, and ST_3DIntersects. For instance, in Figure 2, a red sphere is placed against a glass wall, where the expected minimum distance is zero. However, ST_3DDistance returns 4.99999, failing to capture surface contact. In contrast, when measuring the distance between a solid wall and the glass room, PostGIS correctly returns zero because the evaluated vertices coincide with the boundary. Since PostGIS relies on discrete vertices rather than continuous surfaces, users should be cautious when applying 3D spatial functions in precision-critical applications. 5.3.2. Computer Graphics Libraries Beyond ontologies and semantic web technologies, various computer-graphics libraries provide essential tools for geometric manipulation, analysis, and validation. They support tasks such as computational geometry operations, spatial analysis, visualization, and geometric validation, making them valuable for BIM applications and broader fields like GIS. We assessed the following libraries: Shapely, PyVista, Trimesh, SFCGAL, CGAL, and OpenCascade. Each of these tools provides unique capabilities. CGAL. The Computational Geometry Algorithms Library (CGAL) [34] is a robust C++ library that provides high-precision geometric algorithms for 2D and 3D processing. It is one of the most expressive libraries, supporting both BRep and CSG, making it particularly well-suited for computational geometry applications that require complex modeling capabilities. However, due to its mathematical rigor and algorithmic depth, CGAL has a high level of complexity and a steep learning curve. CGAL includes extensive processing capabilities that ofer robust Boolean operations, spatial reasoning, and validation tools. It also provides high-precision validation techniques for detecting geometric inconsistencies. OpenCascade. OpenCascade [35] is an open-source CAD kernel for 3D solid modeling and geometry processing. It supports BRep and CSG representations, making it well-suited for CAD applications. However, due to its focus on industrial CAD applications, OpenCascade is relatively complex, requiring expertise in geometric modeling. It is also one of the most verbose libraries, as defining and manipulating geometries requires explicit specifications. OpenCascade assures high interoperability and extensive processing capabilities including Boolean operations, feature recognition, and geometric analysis. Other. SFCGAL [36] extends CGAL with an additional parser for WKT and other features. It is used by PostGIS and it has similar limitations for 3D operations. From python libraries Shapely, PyVista, and Trimesh, only PyVista supports surface meshes and volumetric data, but it does not cover all functionality.
Summary. The evaluated libraries ofer a range of capabilities for geometric processing, each excelling in diferent aspects. SFCGAL extends 3D processing within relational databases, whereas CGAL and OpenCascade provide the most comprehensive solutions for computational geometry and solid modeling. Among these, CGAL and OpenCascade stand out as the most expressive libraries, fully supporting BRep and CSG representations, making them the best choices for advanced BIM applications requiring detailed geometric computations (see Table 4).
Comparison of Geometry Processing in PostGIS and Computer Graphics Libraries with Revised Evaluation Expressiveness and Inter- Processing Capabilities Complexity and Ver- Degree of Stan- Scalability operability and Support for Geom- bosity dardization
etry Translation High expressiveness, Provides advanced spatial Supports 2D and limited OGC integrates with spatial queries, but lacks compre- 3D geometries, moderate widely databases and RDF stores hensive 3D volumetric pro- verbosity (WKT/WKB) (high) (high) cessing (moderate) (moderate) standard, adopted Limited to 2D GIS applications, high interoperability with geospatial tools (low)
Basic spatial operations Supports 2D geometries (e.g., intersection, union), only, concise definitions lacks 3D support (low) (high)
Follows OGC Sim- Low complexity, scales well ple Features stan- for small datasets but not dard (high) optimized for large-scale geometry (moderate) High expressiveness for 3D visualization, integrates well with VTK (high)
Includes mesh transforma- Supports surface meshes No oficial standardtions, smoothing, and re- and volumetric data, mod- ization, commonly construction but lacks rea- erate verbosity (moderate) used in scientific soning functions (moder- computing (low) ate) Moderate expressiveness, optimized for mesh-based modeling (moderate)
Ofers Boolean operations, ray tracing, and collision detection (moderate)
Supports meshes only, definitions (high) triangular concise
No oficial standardization, widely used in robotics and 3D modeling (low)
Moderate complexity, highly scalable for 2D but limited scalability for complex 3D processing (moderate) Moderate complexity, highly scalable for large 3D models in visualization and simulation (high) Low complexity, highly scalable for large meshbased datasets (high) Expressive for solid model- Provides 3D Boolean oper- Supports full 3D geome- Follows OGC spa- High complexity, scales ing, tightly integrated with ations, volumetric compu- tries, moderate verbosity tial processing stan- well for database-driven PostGIS (high) tations, and spatial valida- (moderate) dards (high) spatial processing (high) tion (high) Highly expressive, supports both BRep and Mesh (high)
Ofers robust Boolean op- Supports complex 2D and Well-established High complexity, highly erations, spatial reasoning, 3D geometries, high ver- in computational scalable for precisionand geometric validation bosity (low) geometry research demanding geometry (high) (high) applications (high) Extremely expressive, de- Advanced CAD functionali- Supports detailed BRep Industry standard Very high complexity, signed for CAD/BIM work- ties including feature recog- and CSG models, very for CAD applica- highly scalable for indusflows (high) nition, Boolean operations, high verbosity (low) tions (high) trial and large-scale CAD and transformations (high) applications (high)
The analysis presented in this paper highlights the advantages and limitations of the approaches covered in the three explored paradigms for integrating geometric data into RDF-based systems. Storing multiple representations of geometric data, performing geometric operations, validating geometric objects, and computing derived data (such as the volume) is essential part of any future BIM framework. The findings of this study can be summarized as follows: RDF-based Geometry Modeling.
Many ontologies exist for representing geometric data in RDF, but only ifcOWL is specifically designed to support multiple geometry representations. Furthermore, IFC’s geometric modeling follows a hierarchical approach, meaning that footprints and other geometric elements are always defined relative to a reference point using local placements. Beyond the frameworks, ensuring interoperability with BIM-related processing tools requires the adoption of standardized geometry serialization formats, such as WKT. However, a key limitation remains: there is no standard serialization format for Constructive Solid Geometry (CSG), which restricts its broader adoption and the interoperability between diferent geometry tools. Extending Triplestore and Querying Capabilities. Standards such as GeoSPARQL introduce spatial functions that enhance triplestores with spatial querying capabilities. While this improves queryng functionality around geometries, our evaluation reveals that geometric operations, such as area or volume, are still constrained to 2D geometries. Validation is only partially supported for 2D data and is entirely absent for 3D geometries. Given that full 3D support is indispensable for the serial production case study, these limitations make triplestore extensions insuficient as a standalone solution. Integrating RDF-based Systems with Native Geometry Stores or Computational Geometry Libraries. We evaluated a widely adopted spatial database solution, PostGIS, which implements SQLbased and spatial standards. These solutions ofer better 3D support than any RDF-based alternatives but still have significant gaps. For example, there are no built-in functions to answer full 3D spatial queries, such as determining whether a device is contained within a 3D room. Similarly, validation mechanisms for 3D geometries remain lacking, and while some computations for 3D volumetric analysis are possible, they remain limited compared to specialized geometric libraries.
Among all reviewed approaches, only external computational geometry libraries, particularly CGAL and OpenCascade, seem to fully satisfy all functional requirements for 3D geometries. However, these libraries are also the most complex to use. Furthermore, as these are computer-graphics libraries, with a higher integration efort. A feasible approach would be to implement SPARQL custom functions that invoke external code written using these libraries. Even such a seemingly simple integration strategy poses challenges, as most RDF triplestores are written in Java, and CGAL and OpenCascade are implemented in C++. Such an integration would be feasible using technologies such as the Java Native Interface (JNI). However, even if this functionality was successfully implemented, performance trade-ofs remain a major concern. For instance, queries for containment operations (e.g., checking whether an object is inside another) are inherently quadratic in the number of geometric objects stored in the system. Thus, global optimization and pre-processing techniques might still be required to ensure eficient performance.
Summary This study provides valuable insights into the advantages and challenges of diferent paradigms for modeling geometries in RDF and extending RDF-based systems with geometric processing and validation capabilities. It reveals that there are trade-ofs between complexity, interoperability, performance, and scalability, which must be carefully considered based on specific application requirements. However, current RDF-based systems lack the flexibility needed to tailor strategies such as horizontal scaling, data partitioning, spatial indexing, and caching for geometric data. Most platforms rely on fixed implementations with limited configurability, requiring users to operate within the constraints of predefined system architectures. Our findings also align with ongoing eforts to extend semantic geospatial standards—particularly the development of future versions of GeoSPARQL.
In the future, we will continue exploring how to extend RDF-based building models with geometric information. We plan to implement a prototype based on SPARQL custom-functions and computergraphics libraries that supports higher-level geometric functions and integrates them into real-world applications. In addition, we will conduct a comprehensive performance and scalability evaluation to ensure the proposed solution meets the computational demands of large-scale BIM applications.
This research was supported by GROPYUS AG, Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) under Germany’s Excellence Strategy – EXC 2120/1 – 390831618, and the German Federal Institute for Research on Building, Urban Afairs, and Spatial Development, on behalf of the Federal Ministry of Housing, Urban Development and Building, through the Zukunft Bau research funding program (Grant Nos. 10.08.18.7-24.25).
The authors used ChatGPT-4 to improve grammar. All content was reviewed and edited by the authors, who take full responsibility for the final manuscript. volume 1 of Computing in Construction, European Council on Computing in Construction, Chania, Greece, 2019, pp. 304–313. doi:10.35490/EC3.2019.146. [18] K. McGlinn, A. Wagner, P. Pauwels, P. Bonsma, P. Kelly, D. O’Sullivan, Interlinking geospatial and building geometry with existing and developing standards on the web, Automation in Construction 103 (2019) 235–250. doi:10.1016/j.autcon.2018.12.026. [19] A. Wagner, M. Bonduel, J. Werbrouck, K. McGlinn, Geometry and geospatial data on the web, in: P. Pauwels, D. Shelden, J. Brouwer, D. Sparks, S. Nirvik, T. P. McGinley (Eds.), Buildings and Semantics: Data Models and Web Technologies for the Built Environment, 1st edition ed., CRC Press, London, 2022, pp. 69–99. doi:10.1201/9781003204381- 5. [20] P. Bonsma, I. Bonsma, A. E. Ziri, E. Iadanza, F. Maietti, M. Medici, F. Ferrari, R. Sebastian, S. Bruinenberg, P. M. Lerones, Handling huge and complex 3d geometries with semantic web technology, IOP Conference Series: Materials Science and Engineering 364 (2018) 012041. doi:10.1088/1757- 899X/364/1/012041. [21] S. Stolk, K. McGlinn, Validation of ifcowl datasets using SHACL, in: M. Poveda-Villalón, A. Roxin, K. McGlinn, P. Pauwels (Eds.), Proceedings of the 8th Linked Data in Architecture and Construction Workshop, Dublin, Ireland, June 17-19, 2020 (virtually hosted), volume 2636 of CEUR Workshop Proceedings, CEUR-WS.org, 2020, pp. 91–104. [22] T. Ioannidis, G. Garbis, K. Kyzirakos, K. Bereta, M. Koubarakis, Evaluating geospatial rdf stores using the benchmark geographica 2, Journal on Data Semantics 10 (2021) 189–228. doi:10.48550/ arXiv.1906.01933. [23] A.-H. Hor, G. Sohn, Design and evaluation of a bim-gis integrated information model using rdf graph database, ISPRS Annals of the Photogrammetry, Remote Sensing and Spatial Information Sciences 8 (2021) 175–182. doi:10.5194/isprs- annals- VIII- 4- W2- 2021- 175- 2021. [24] D. Vinasco-Alvarez, J. Samuel, S. Servigne, G. Gesquière, From CityGML to OWL, Technical Report,
LIRIS, UMR 5205, 2020. URL: https://hal.science/hal-02948955v1, accessed via HAL open archive. [25] Open Geospatial Consortium (OGC), Geosparql, https://www.ogc.org/standards/geosparql, 2024.
Created by OGC to model spatial data and topological relationships within GIS systems. [26] P. Pauwels, K. McGlinn, Buildings and semantics: Data models and web technologies for the built environment, 1st ed., CRC Press, 2022. doi:10.1201/9781003204381. [27] R. Obe, L. Hsu, PostGIS in Action, Third Edition, Manning Publications, 2021. URL: https://www.
manning.com/books/postgis-in-action-third-edition. [28] buildingSMART International, ifcowl, https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ ADD2_TC1/HTML/schema/ifcowl/, 2018. Developed to provide an RDF-based representation of Industry Foundation Classes (IFC). accessed: 2025-02-11. [29] D. Guo, E. Onstein, A. D. L. Rosa, An improved approach for efective describing geometric data in ifcowl through WKT high order expressions, in: C. Grueau, R. Laurini, L. Ragia (Eds.), Proceedings of the 7th International Conference on Geographical Information Systems Theory, Applications and Management, GISTAM, 2021. doi:10.5220/0010532302290236. [30] A. Perzylo, N. Somani, M. Rickert, A. Knoll, An ontology for cad data and geometric constraints as a link between product models and semantic robot task descriptions, in: 2015 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), 2015, pp. 4197–4203. [31] NASA Jet Propulsion Laboratory, Sweet ontology, https://sweet.jpl.nasa.gov/, 2024. A component of the Semantic Web for Earth and Environmental Terminology (SWEET) ontology suite. [32] RDF Ltd., RDF Ltd., https://rdf.bg/, 2025. Provides solutions for creating interactive 3D and 4D geometrical data, supporting various standards including IFC and STEP. accessed: 2025-02-11. [33] P. Pauwels, A. Costin, M. H. Rasmussen, Knowledge Graphs and Linked Data for the Built Environment, Springer International Publishing, Cham, 2022. doi:10.1007/978- 3- 030- 82430- 3_7. [34] The CGAL Project, CGAL Documentation, 2025. URL: https://www.cgal.org/, accessed: 2025-02-11. [35] Open Cascade SAS, Open CASCADE Technology Documentation, 2025. URL: https://dev.
opencascade.org/resources/documentation, accessed: 2025-02-11. [36] L. Bartoletti, R. Delhome, J. Felder, F. Fougères, Sfcgal documentation, 2025. URL: https://sfcgal. gitlab.io/SFCGAL/, accessed: 2025-02-11.
To illustrate the diferences in expressiveness and structure among the RDF vocabularies evaluated in Section 5.1, we provide a simplified example of a rectangular wall represented in three selected ontologies: ifcOWL, GeoSPARQL, and OntoBREP. The geometry is a basic 4-meter wide, 3-meter tall wall element, located at a specific coordinate system origin.
The geometry is modeled using an extruded area solid in the context of an IFC schema expressed as RDF:
Listing 1: ifcOWL representation of a wall using parametric extrusion @prefix :<http://www.example.com/> . @prefix ifc:<https://standards.buildingsmart.org/IFC/DEV/IFC4/ADD2_TC1/OWL#> . :Wall_1 a ifc:IfcWallStandardCase ;
ifc:Representation :WallGeom_1 . :WallGeom_1 a ifc:IfcProductDefinitionShape ;
ifc:Representations :ShapeRep_1 . :ShapeRep_1 a ifc:IfcShapeRepresentation ;
ifc:Items :Extrusion_1 . :Extrusion_1 a ifc:IfcExtrudedAreaSolid ; ifc:SweptArea :RectProfile_1 ; ifc:Depth "0.2"^^xsd:double ; ifc:ExtrudedDirection :ZDir . :RectProfile_1 a ifc:IfcRectangleProfileDef ; ifc:XDim "4.0"^^xsd:double ; ifc:YDim "3.0"^^xsd:double .
The same wall can be abstracted as a 2D polygon footprint without vertical information:
Listing 2: GeoSPARQL representation of the wall footprint using WKT :Wall_1 a geo:Feature ;
geo:hasGeometry :WallGeom_1 . :WallGeom_1 a geo:Geometry ; geo:asWKT "POLYGON((0 0,4 0,4 0.2,0 0.2,0 0))"^^geo:wktLiteral ; geo:crs <http://www.opengis.net/def/crs/EPSG/0/4326> . OntoBREP allows a more detailed structural description of surfaces:
Listing 3: OntoBREP representation using face-edge-vertex topology :Wall_1 a obrep:Solid ;
obrep:hasFace :Face_1 . :Face_1 a obrep:Face ;
obrep:hasEdgeLoop :Loop_1 . :Loop_1 a obrep:EdgeLoop ;
obrep:hasDirectedEdge (:Edge_1 :Edge_2 :Edge_3 :Edge_4) . :Edge_1 a obrep:Edge ; obrep:hasStart :V1 ; obrep:hasEnd :V2 . :Edge_2 a obrep:Edge ; obrep:hasStart :V2 ; obrep:hasEnd :V3 . ... :V1 a obrep:Vertex ; obrep:coordinates "0 0 0" . :V2 a obrep:Vertex ; obrep:coordinates "4 0 0" . ...
Discussion • ifcOWL provides high-level parametric representations, supporting domain-specific semantics but requiring deeper IFC knowledge. • GeoSPARQL simplifies spatial representation via literals and is easy to query but typically remains limited to 2D geometries. • OntoBREP captures topological precision and surface relationships, but it is verbose and lacks native support for geometric computation or visualization.
This example comparison complements the evaluation in Table 2 and clarifies the expressiveness and usability trade-ofs discussed in Section 5.1.