To promote more transparent and inclusive governance in the Tuscany region SIRIS Academic, a small Spanish company specialized in providing data management solutions, has developed Tuscany’s Observatory of Research and Innovation portal. They integrate Open Data in the Higher Education & Research field, including official Italian student and researcher data coming from the Ministero dell’Istruzione, dell’Università e della Ricerca (MIUR), and European data on FP7 and H2020 research projects. They follow the VKG approach and use the platform University Analytics (UNiCS) developed by SIRIS Academic. The platform uses Ontop to integrate open data repositories and to make them available via a dedicated SPARQL endpoint which is a query service for graph data. Then the platform shows the data as an interactive dashboard hosting data visualizations, with underlying data supplied by the UNiCS SPARQL endpoint.

Benefits

Over the last 200 years, countries have replaced their constitutions on average every 19 years and some have amended them almost yearly. A basic problem in the drafting of these documents is the search and analysis of model text deployed in other jurisdictions. In the Constitute Project [8], Ultrawrap was used to integrate the world’s constitutions into a single unified semantic endpoint for contextual searching. The project was launched at the General Assembly of the United Nations in 2013 and continues to integrate over 196 current databases of all of the world’s constitutions on the Web. Countries throughout the world can take advantage of this free service to modify and develop their constitutions.

Benefits

Semantic interoperability is essential when carrying out post-genomic clinical trials where several institutions collaborate, since researchers and developers need to have an integrated view and access to heterogeneous data sources. The work of Clinical data access shows how to query clinical data in HL7 RIM-based relational models using the Morph system. It presents a solution that uses R2RML mappings that relate an integrating ontology to the underlying relational database implementations. morph-RDB is used to expose a SPARQL endpoint to access the data in Semantic Web form too.

Benefits

The Italian Public Debt Directorate is responsible for various matters, such as issuance and management of the public debt, and analysis of the problems inherent to its management. The Directorate is organized into offices that deal with specific aspects, and each sub-unit has an understanding of a particular portion of the public debt domain. However, a shared and formalized description of the relevant concepts and relations in the whole domain was missing, since data were managed by different systems in different offices, and their structure had been heavily modified and updated to serve specific application needs. There was a clear need to coordinate and integrate the data of the various sub-units. The work of the Italian Public Dept Directorate presented a project for addressing this issue. They developed the Public Debt Ontology to formalize the whole domain of the Italian public debt. The VKG system Mastro Studio has been used to provide a comprehensive software environment. Users can take advantage of the wiki-like documentation of the ontology to access both its graphical representation and its OWL2 specification.

Benefits

With the heterogeneous environment of the construction sector, providing suitable product descriptions for any use case and software application is hard to achieve. While open source exchange formats, i.e., IFC and STEP, can be used to describe products in a uniform manner to realize a communication across domains, the amount of required geometric detail is not addressed. For example, lights to indicate emergency exits are needed in different geometric detail. The electrical engineer only needs to know the position of the lighting fixture, whereas the architect requires the bounding box to consider for the design and safety engineers want to know the material, color and shape of the lighting fixture to ensure that is clearly visible. On the other hand, the manufacturer needs to model the product in its highest geometrical detail for their own production chain.

If the manufacturer provides the highest geometrical detail, the product description will become too large to be handled if multiple instances are placed within the model. Hence, the geometrical detail needs to be broken down, ideally individually in respective of singular use cases, resulting in multiple geometry descriptions for the same object. By applying Linked Data, the attachment of multiple geometry descriptions to a singular object can be realized easily, maintaining means to differentiate between the descriptions and identify singular ones to connect them to their respective use cases. Yet, if the original geometry description changes, the derived geometry descriptions must be identified and updated, as well. This topic is, amongst others, considered in the Semantic Construction Project Engineering (SCOPE) research project funded by the German government and conducted by Ed. Züblin AG, Technische Universität Darmstadt and Fraunhofer Institute for Solar Energy (https://www.projekt-scope.de/).

Benefits

To assemble the lineage of data processed by multiple systems and perhaps also by humans, manually, a consistent yet flexible lineage/provenance model is needed. Consistency of patterning is needed to ensure interoperability for information from multiple sources and yet flexibility is needed to accommodate different granularities of processing steps recorded. The PROV Data Model [6] is a graph-based generic, but easily extensible/specializable model for provenance representation. PROV information can be sampled (queried) to aggregate detailed low-level provenance, or drilled into for deeper details where they exist. The standard RDF format used by ontology variants of PROV allow for its storage in standard Semantic Web systems and accessibility via standard SPARQL queries. The strong definitions within PROV prevent unknown log formats being encountered in the future. The Australian Bioregional Assessments Programme [7] used PROV to record both dataset-level provenance (what the ancestors of data sets are) and also fine-grained processing steps for individual data elements within data sets meaning this very varied provenance can, nonetheless, be stored in one system and accessed sensibly.

Benefits

To preserve the national heritage of countries, libraries and museums have the task to collect information about artifacts, relate artifacts to other similar artifacts in different museums and to create a historic context for people to understand the artifacts provenance. Those tasks are more and more frequently achieved using linked data technologies and ontologies modeling the necessary data using appropriate vocabularies. One example is the German National Library which since many years develops the "Gemeinsame Normdatei" GND ontology (https://d-nb.info/standards/elementset/gnd) including a geospatial component designed to locate the artifacts origins and the origins of their creators. The British museum created a SPARQL endpoint based on Blazegraph which contains similar information about the artifacts displayed in the British museum.

Benefits

During the design stages of a construction project, the building’s design changes quite rapidly, and often there are derived consequences of these changes. The cooling demand of a zone is dependent on the solar heat gain through windows and if the windows change, so does the cooling demand. This affects the capacity requirement of the fan coil in the room and potentially the size of the pipes supplying this fan coil, the pump circulating the cooling water and the size of the chiller.

The Danish consulting engineering company Niras uses Linked Data to model these interdependencies. The architect’s BIM model is translated from its internal data model through the vendor supplied Revit API into an AEC knowledge graph [13] described with the Building Topology Ontology (BOT) [14]. A direct communication between the BIM authoring tool and an OPM-REST API (https://github.com/MadsHolten/OPM-REST) ensures that property changes are captured and described using the Ontology for Property Management (OPM). Small task specific web applications access and extend the knowledge graph through SPARQL queries and uses OPM to relate a derived property to the properties that will affect it. In the current setup, 2D-geometry is extracted as WKT literals and 3D-geometry as OBJ literals. Geometry changes are registered by string comparison. In the UI, the state of the model geometry at the beginning and end of a given time interval is visualized.

Benefits

One of the common tasks for geologists at Equinor (Norway) is to find new exploitable accumulations of oil or gas in given areas by analyzing data about those areas in a timely manner. However, gathering the required data is not a trivial task since it is stored in multiple complex and large data sources, including EPDS, Recall, CoreDB, GeoChemDB, OpenWorks, Compass and NPD FactPages. Construction of complex queries is sometimes beyond Equinor geologists, so they have to communicate their needs to IT specialists who then turn them into queries. This drastically affects the efficiency of finding the right data to back decision making. The work of Equinor describes how the data access and integration challenges in Equinor have been addressed by adopting the VKG-based system Optique, which relies on the following tools:

Benefits

Siemens Energy runs several service centers that remotely monitor and perform diagnostics for several thousand appliances, such as gas and steam turbines, generators and compressors installed in power plants. For performing reactive and predictive diagnostics at Siemens, data access and integration of both static data (e.g., configuration and structure of turbines) and dynamic data (e.g., sensor data) are particularly important but very challenging. The work of Siemens addressed these data access requirements by using the Optique platform as a VKG solution, similar to the Equinor use case.

Benefits

Improving health care for people with chronic conditions requires clinical information systems that support integrated care and information exchange. The adoption of an approach based on semantic information simplifies the use of multiple and diversified Electronic Health Records (EHRs). Within the work described in E-health data access, a Diabetes Mellitus Ontology (DMO) has been developed, and has been used to diagnose patients with diabetes, and automatically identify them by analyzing EHRs. Specifically, by using Ontop, the EHR data from a general practice (with almost 1,000 active patients) could be queried via SPARQL. The accuracy of the algorithm for automatic identification of patients with diabetes was validated by performing a manual audit of the EHRs, and considered good enough for the purpose. Not surprisingly, the accuracy of the automatic method was influenced by data quality, such as incorrect data due to mistaken units of measurement, unavailable data due to lack of or wrong documentation, and data management errors.

Benefits

Historians, especially in Digital Humanities (DH), are starting to use new data sets to aggregate information about history. These are collections of data, information and knowledge that are devoted to the preservation of the legacy of tangible and intangible culture inherited from previous generations. In the project Production and distribution of food during the Roman Empire: Economics and Political Dynamics (EPNet), the work of EPNet project presents a framework that eases the access of scholars to much food information during the Roman Empire, distributed across different data sources. The proposed approach relies on the VKG paradigm to integrate the following data sets:

An ontology provides the historians with a clear point of access and a unified and unambiguous conceptual view over these data sets.

Benefits

Digital Archaeologists working in DH deal with a lot of heterogeneous data, which is not standardized at all. Semantic technologies and the use of Linked Open Data promises to revolutionize the digital workflow [https://eprints.soton.ac.uk/206421/]. As the most digital semantic DH project they are referenced by the International Committee for Documentation (CIDOC) Conceptual Reference Model (CRM) [http://www.cidoc-crm.org/] and its extensions, especially CRMgeo[https://link.springer.com/article/10.1007/s00799-016-0192-4]. Famous data collections which model object types in their domain and publish them as LOD are nomisma (coins) [http://nomisma.org/], kerameikos (ancient ceramics) [http://kerameikos.org/], Open Context [https://opencontext.org/], the iDAI world [https://idai.world/] of the German Archaeological Institute, finds.org [https://finds.org.uk/], and Regnum Francorum Online [http://francia.ahlfeldt.se/index.php]. Furthermore, Linked Data networks of the Computer Applications and Quantitative Methods in Archaeology (CAA) conference – Little Minions, Data Dragons – and of the Linked Pasts Community (related to the LOD Pelagios Commons network[http://commons.pelagios.org/) – Linked Pipes – try to build up a LOD network of tools, workflows and data of the CH domain[http://squirrelnator.squirrel.link/]. Moreover, smaller projects are publishing tools, e.g. for modelling vagueness in graphs like the Academic Meta Tool [http://academic-meta-tool.xyz/] to enable the scientific community to handle fuzzy (geographical) relations [http://unold.net/research/p_dls_20170320.pdf].

Benefits

The maritime security domain presents a need for efficient combining and processing of dynamic (real-time) and static vessel data that come from heterogeneous sources. The project Real-time Services for the Maritime Security (EMSec) needed to integrate static, real-time and geospatial data, including:

To address this objective, the system Real-time Maritime Situation Awareness System (RMSAS), which relies on the VKG technology, has been developed. RMSAS uses Ontop (with the Ontop-spatial extension) to expose the data mentioned above as SPARQL endpoints. The Web-based tool Sextantis then used to visualize the results on temporally-enabled maps combining geospatial and temporal results from different (Geo)SPARQL endpoints.

Benefits

During built heritage projects (e.g. restoration, maintenance, historical research) a large amount of stakeholders collaborate. Each stakeholder assembles and generates a wide variety of data, including 2D and 3D geometries ranging from survey geometry (e.g., a point cloud or complex mesh), over 2D plans and maps (historical situation, previous restorations, derived from survey data, etc.) to volumetric 3D models. These geometries are used to get an overview of the historical and existing situation of the building, for communicating the location of damages or valuable historical elements in the building or to express the intention of the restoration design. Because of the wide variety of geometric data, a large amount of common geometry schemas (text-based and binary, open and proprietary) are currently used in practice.

Instead of developing RDF-based geometry schemas for each existing geometry schema (OBJ, E57, X3D, STEP, WKT, etc.), alternative methods such as the application of RDF literals are considered. These literals can embed geometry descriptions (similar to GeoSPARQL 1.0 but for any geometry schema) or reference external geometry files in their original geometry schema. In that case, the usage of existing geometry schemas and their tools can be continued. Built heritage stakeholders need to be able to link such geometry descriptions to building elements, damages and building spaces they describe. Each described object can have multiple geometry descriptions (different geometry schema, describing an object at multiple moments in time, different amount of detailing/resolution, etc.), potentially coming from different stakeholders. Geometry metadata (accuracy, author, resolution, derived geometry descriptions, file size, etc.) is necessary to reuse the geometry in a collaborative setting as it gives an indication of the geometry provenance. Other metadata (used geometry schema, coordinate system, etc.) might help users in the automatic processing of the data by their geometry applications.

Three domain independent ontology modules have been developed in previous collaborative research and are applied in a built heritage PhD research project named “Flemish Cities in Transition” [9]. These ontologies include the Ontology for Managing Geometry (OMG - https://w3id.org/omg#) [10], the File Ontology for Geometry formats (FOG - https://w3id.org/fog#) [11] and the Geometry Metadata Ontology (GOM - https://w3id.org/gom#).

Benefits

Geometric data plays a central role in the geospatial domain, architectural design and construction industry. For upcoming, new approaches on how to store building data, such as the Semantic Web, however, no universal common agreement exists on the combination of geometric and non-geometric data. Thus, it can be unclear to users on how to represent their geometries, leading to a decelerated application and advancement of making building data available over the web. This gap can only be bridged if a common approach on the representation of geometries on the web is achieved.

In Ireland, the Ordnance Survey Ireland (OSi) has a substantial dataset (over 50 million objects), called Prime2, which includes not only GIS data (polygon footprint, geodetic coordinate), but also additional building-specific data (form and function). The ADAPT research centre working with the Ordnance Survey Ireland has begun publication of their geospatial data using GeoSPARQL [12], with a subset of their buildings data (building name, geolocation, and form and function) in the county of Galway now being available as RDF (http://data.geohive.ie/downloadAndQuery.html).

This provides authoritative URIs for Irish buildings which can be used to interlink building data from other domains, such as products, sensors, energy, etc. The potential also exists to support the conversion of their 2D building footprints into a simple 3D geometric model, given some additional properties (height). An existing schema such as the Industry Foundation Classes, and ifcOWL serialization can be supported, but tend to be overly verbose (use of lists for each vertex in a point for example) and geometric and non-geometric data are overly entwined. The possibility to define 3D geometries using less complex geometry schemas would be a huge advantage within the building information modeling domain. This is an important step towards the iterative integration of ever more complex BIM models which can support a range of different use cases into the wider web of data.

Benefits

Process mining techniques are able to extract knowledge from event log data, which is often available in today’s information systems. Process mining tools normally assume that the data to be analyzed are already organized in some specific textual (XML based) format, notably IEEE standard for eXtensible Event Stream (XES) for achieving interoperability in event logs and event streams. However, in practice, many companies have custom IT infrastructure that maintains the data relevant for process logs, e.g., in relational databases, and hence in forms not compliant with the XES standard. To cope with this kind of problem, the approach proposed exploits a VKG based framework and associated methodology for the extraction of XES event logs from relational data sources. This approach is implemented in OnProm, which provides a complete tool-chain that:

It has been tested in EBITmax, an Italian company that provides consultancy services in program management and business process management for small and large enterprises, and that has incorporated process mining to complement its standard consultancy services. The experimentation has shown the added value and flexibility of an approach based on semantics for the semi-automatic generation of process logs from legacy data.

Benefits

Smart City applications rely on large amounts of data retrieved from sensors, social networks or government authorities. Open data and data from existing enterprise systems are two valuable data sources. However, open data are often published in a tabular form with little or incomplete schema information, while enterprise applications typically rely on complex relational schemas. There is a clear need to make city-specific information easy to consume and combine at low cost, but this proves to be a difficult task. The work of IBM Ireland presents the system DALI, which exploits Linked Data to provide federated entity search and spatial exploration across hundreds of information sources containing open and enterprise data pertaining to cities. Ontop is used as the VKG solution, and mappings are created using a rule and pattern-based entity extraction mechanism to detect different kinds of entities. The DALI system has been evaluated in two scenarios:

Benefits

Implementations shall support the SPARQL Query Language for RDF [W3C SPARQL], the SPARQL Protocol for RDF [W3C SPARQL Protocol] and the SPARQL Query Results XML Format [W3C SPARQL Result Format].

Implementations shall allow the RDFS class geo:SpatialObject to be used in SPARQL graph patterns.

Implementations shall allow the RDFS class geo:Feature to be used in SPARQL graph patterns.

Implementations shall allow the properties geo:sfEquals, geo:sfDisjoint, geo:sfIntersects, geo:sfTouches, geo:sfCrosses, geo:sfWithin, geo:sfContains, geo:sfOverlaps to be used in SPARQL graph patterns

Implementations shall allow the properties geo:ehEquals, geo:ehDisjoint, geo:ehMeet, geo:ehOverlap, geo:ehCovers, geo:ehCoveredBy, geo:ehInside, geo:ehContains to be used in SPARQL graph patterns

Implementations shall allow the properties geo:rcc8eq, geo:rcc8dc, geo:rcc8ec, geo:rcc8po, geo:rcc8tppi, geo:rcc8tpp, geo:rcc8ntpp, geo:rcc8ntppi to be used in SPARQL graph patterns

Implementations shall allow the RDFS class geo:Geometry to be used in SPARQL graph patterns

Implementations shall allow the properties geo:hasGeometry and geo:hasDefaultGeometry to be used in SPARQL graph patterns

Implementations shall allow the properties geo:dimension, geo:coordinateDimension, geo:spatialDimension, geo:isEmpty, geo:isSimple, geo:hasSerialization to be used in SPARQL graph patterns

All RDFS Literals of type geo:wktLiteral shall consist of an optional URI identifying the coordinate reference system followed by Simple Features Well Known Text (WKT) describing a geometric value. Valid geo:wktLiterals are formed by concatenating a valid, absolute URI as defined in [RFC 2396], one or more spaces (Unicode U+0020 character) as a separator, and a WKT string as defined in Simple Features [ISO 19125-1]

The URI http://www.opengis.net/def/crs/OGC/1.3/CRS84 shall be assumed as the spatial reference system for geo:wktLiterals that do not specify an explicit spatial reference system URI.

Coordinate tuples within geo:wktLiterals shall be interpreted using the axis order defined in the spatial reference system used

An empty RDFS Literal of type geo:wktLiteral shall be interpreted as an empty geometry

Implementations shall allow the RDF property geo:asWKT to be used in SPARQL graph patterns

All geo:gmlLiterals shall consist of a valid element from the GML schema that implements a subtype of GM_Object as defined in [OGC 07-036]

An empty geo:gmlLiteral shall be interpreted as an empty geometry

Implementations shall document supported GML profiles

Implementations shall allow the RDF property geo:asGML to be used in SPARQL graph patterns

Implementations shall support geof:distance, geof:buffer, geof:convexHull, geof:intersection, geof:union, geof:difference, geof:symDifference, geof:envelope and geof:boundary as SPARQL extension functions, consistent with the definitions of the corresponding functions (distance, buffer, convexHull, intersection, difference, symDifference, envelope and boundary respectively) in Simple Features [ISO 19125-1]

Implementations shall support geof:getSRID as a SPARQL extension function.

Implementations shall support geof:relate as a SPARQL extension function, consistent with the relate operator defined in Simple Features [ISO 19125-1]

Implementations shall support geof:sfEquals, geof:sfDisjoint, geof:sfIntersects, geof:sfTouches, geof:sfCrosses, geof:sfWithin, geof:sfContains, geof:sfOverlaps as SPARQL extension functions, consistent with their corresponding DE-9IM intersection patterns, as defined by Simple Features [ISO 19125-1]

Implementations shall support geof:ehEquals, geof:ehDisjoint, geof:ehMeet, geof:ehOverlap, geof:ehCovers, geof:ehCoveredBy, geof:ehInside, geof:ehContains as SPARQL extension functions, consistent with their corresponding DE- 9IM intersection patterns, as defined by Simple Features [ISO 19125-1]

Implementations shall support geof:rcc8eq, geof:rcc8dc, geof:rcc8ec, geof:rcc8po, geof:rcc8tppi, geof:rcc8tpp, geof:rcc8ntpp, geof:rcc8ntppi as SPARQL extension functions, consistent with their corresponding DE-9IM intersection patterns, as defined by Simple Features [ISO 19125-1]

Basic graph pattern matching shall use the semantics defined by the RDFS Entailment Regime [W3C SPARQL Entailment]

Implementations shall support graph patterns involving terms from an RDFS/OWL class hierarchy of geometry types consistent with the one in the specified version of Simple Features [ISO 19125-1]

Implementations shall support graph patterns involving terms from an RDFS/OWL class hierarchy of geometry types consistent with the GML schema that implements GM_Object using the specified version of GML [OGC 07-036]

Basic graph pattern matching shall use the semantics defined by the RIF Core Entailment Regime [W3C SPARQL Entailment] for the RIF rules [W3C RIF Core] geor:sfEquals, geor:sfDisjoint, geor:sfIntersects, geor:sfTouches, geor:sfCrosses, geor:sfWithin, geor:sfContains, geor:sfOverlaps

Basic graph pattern matching shall use the semantics defined by the RIF Core Entailment Regime [W3C SPARQL Entailment] for the RIF rules [W3C RIF Core] geor:ehEquals, geor:ehDisjoint, geor:ehMeet, geor:ehOverlap, geor:ehCovers, geor:ehCoveredBy, geor:ehInside, geor:ehContains

Basic graph pattern matching shall use the semantics defined by the RIF Core Entailment Regime [W3C SPARQL Entailment] for the RIF rules [W3C RIF Core] geor:rcc8eq, geor:rcc8dc, geor:rcc8ec, geor:rcc8po, geor:rcc8tppi, geor:rcc8tpp, geor:rcc8ntpp, geor:rcc8ntppi

http://ogc.standardstracker.org/show_request.cgi?id=601

https://github.com/opengeospatial/geosemantics-dwg/issues/15

Semantic improvement

We request extensions to the GeoSPARQL OWL ontology that includes details it doesn’t cater for such as indicating spatial resolution, areas, proportional relations (e.g. area overlaps) and roles for multiple Geometry objects relating to a single Feature.

We have packaged the extensions we are already using in an ontology that is mostly built on GeoSPARQL but it also uses elements from QUDT and the some supporting datatype vocabularies.

The "GeoSPARQL Extensions Ontology" is online, and can be found here: https://github.com/CSIRO-enviro-informatics/geosparql-ext-ont/.

http://ogc.standardstracker.org/show_request.cgi?id=600

https://github.com/opengeospatial/geosemantics-dwg/issues/14

Accessibility

GeoSPARQL is currently lacking in semantics that are available on the semantic web. For example, the concept of Geometry is not explained in GeoSPARQL itself, but has in its text definition a pointer to ISO 19107: "This class is equivalent to the UML class GM_Object defined in ISO 19107". Should one look up that document on the web, a paywall from ISO is hit. Such fundamental definitions should be directly accessible to consumers, both human and machine, on the semantic web, either as part of GeoSPARQL or as another web vocabulary.

http://ogc.standardstracker.org/show_request.cgi?id=599

https://github.com/opengeospatial/geosemantics-dwg/issues/13

Geospatial processing

GeoSPARQL describes a number of SPARQL functions that can be implemented by developers of SPARQL endpoints. It would be beneficial for working with spatial data in SPARQL if more ways of interacting with spatial data were available. The routines and functions described in the Simple Features for SQL specification (06-104r4) are well known and have been implemented in different libraries and data storage systems. It could be a relatively simple effort to transpose the existing definitions to RDFS/OWL, so developers of SPARQL systems can implement those often very useful functions, either by using existing libraries, or by new development.

http://ogc.standardstracker.org/show_request.cgi?id=598

https://github.com/opengeospatial/geosemantics-dwg/issues/12

Semantic improvement

Descriptions of Coordinate Reference Systems (CRS) are important in correct interpretation of spatial data, and in working with that kind of data. However, CRS descriptions are not readily available as Linked Data. Therefore, it would be good to have GeoSPARQL use a standard ontology for describing CRS, either as an extension or module of GeoSPARQL itself, or an endorsed external ontology.

http://ogc.standardstracker.org/show_request.cgi?id=597

https://github.com/opengeospatial/geosemantics-dwg/issues/11

Semantic improvement

Numerical data published using GeoSPARQL often have an unrealistic amount of digits. At the same time, there is no standardized way to express spatial resolution yet. Both these problems can be addressed when numerical data, published using GeoSPARQL, are explicitly expected to have only significant digits.

http://ogc.standardstracker.org/show_request.cgi?id=594

https://github.com/opengeospatial/geosemantics-dwg/issues/9

Increased scope

GeoSPARQL’s scope is geographic data, as the name says. Less explicit, GeoSPARQL is only about vector data. However, there is a need for a web ontology that can be used to work with all kinds of spatial data. GeoSPARQL seems to be the best candidate for realization of a domain independent ontology for spatial data.

A universal, or domain independent ontology for spatial data is needed because space is a phenomenon that exists everywhere and is present in many kinds of human endeavor. Traditionally, universal phenomena like time and space have been modeled in different domains, according to domain specific requirements. Linked Data and the semantic web now offer a way to share data with many different perspectives, in a domain independent way. A domain independent ontology for time already exists: 0 . The time has now come for space to have a similar ontology. Practically, this will greatly increase interoperability of spatial data. Not only on the web: offline systems (e.g storage systems and libraries) could also benefit from having a single root model to depend on.

GeoSPARQL is a good candidate for evolving into a general ontology for spatial data because of the following.

This subject has been discussed in the Spatial Data on the Web Working Group and is a project proposal in the Spatial Data on the Web Interest Group, found here: https://github.com/w3c/sdw/issues/1095

http://ogc.standardstracker.org/show_request.cgi?id=591

https://github.com/opengeospatial/geosemantics-dwg/issues/8

Accessibility

The GeoSPARQL ontology is available online in XML and TTL formats. JSON-LD could be added as an additional publication format, supported by content negotiation of course. This will allow easier consumption of the ontology by web pages. This, in turn, allows easier consultation of the ontology by humans. For example, parts of the ontology could be visualized as diagrams, or definitions of terms could be rendered as tooltips on web pages.

http://ogc.standardstracker.org/show_request.cgi?id=585

https://github.com/opengeospatial/geosemantics-dwg/issues/6

Geospatial encoding

GeoSPARQL currently offers WKT and GML literal types which can be used to encode vector geometries. However, geospatial data formats are very heterogeneous and a variety of other data formats deserve to be encodable in GeoSPARQL in our opinion.

In the following we list the most likely candidates:

The following formats could be considered, but are in our opinion optional:

Implementations of most of the described literals can be seen in an extension for rdf4j and an extension for Jena, and in a proposed ontology here: https://github.com/i3mainz/geosparql2.0

Possibly, other literal implementations are useful and could be discussed.

This PDF provides links to all the dataformat specifications and proposes how literal representations could look like: https://github.com/opengeospatial/geosemantics-dwg/blob/master/CR585attachment.pdf.

http://ogc.standardstracker.org/show_request.cgi?id=627

https://github.com/opengeospatial/geosemantics-dwg/issues/41

Geospatial encoding

GeoSPARQL is currently incapable of encoding and dealing with raster data. However, raster data is essential for many geospatial applications and supported by many of relational geospatial databases such as POSTGIS. Raster data even provides semantics, as interpretations of raster data can be given by interpreting the color codes of raster bands. In order to integrate raster data into GeoSPARQL the following requirements need to be fulfilled:

http://ogc.standardstracker.org/show_request.cgi?id=629

https://github.com/opengeospatial/geosemantics-dwg/issues/42

Query language

If the GeoSPARQL ontology is able to support raster data, new query capabilities are needed in order to use raster data in daily applications. In particular the following query capabilities which are the norm in relational GIS databases should be adopted:

http://ogc.standardstracker.org/show_request.cgi?id=628

https://github.com/opengeospatial/geosemantics-dwg/issues/43

Ontology

GeoSPARQL currently only explicitly supports 2D geometries. However, work has already been done in defining ontologies for 3D geometries (e.g. https://github.com/w3c-geom-cg/geom or https://www.web3d.org/working-groups/x3d-semantic-web/charter). These ontologies should be checked and integrated into, or merged with, the GeoSPARQL ontology.

http://ogc.standardstracker.org/show_request.cgi?id=628

https://github.com/opengeospatial/geosemantics-dwg/issues/44

Ontology

The GeoSPARQL query language currently only supports functions capable of dealing with 2D geometries. However, with the emergence of standards such as CityGML which could be supported as GML literals, specific 3D-aware functions should be added to GeoSPARQL to accommodate such recent developments. Suggestions:

http://ogc.standardstracker.org/show_request.cgi?id=630

https://github.com/opengeospatial/geosemantics-dwg/issues/45

Query language

Many geospatial libraries such as JTS (https://github.com/locationtech/jts) provide explicit support for geometries with measurement (M) coordinates. These are useful in a variety of applications e.g. when a road is simplified in a query statement but users still would like to query the correct amount of kilometers since its start. The time coordinates (T) are useful when working with GNSS tracks in order to track per-point when a user went to a particular place. While the latter can also be achieved by modeling every point of a GNSS track as its own point geometry, it is unnecessary if the points provide no further semantic information apart from the time point. While the support XYZM or XYZMT coordinates is not a matter of GeoSPARQL itself but more of the formats which are supported as literals in the query language, GeoSPARQL could provide definitions of functions which are aware of these extended coordinate concepts such as:

http://ogc.standardstracker.org/show_request.cgi?id=631

https://github.com/opengeospatial/geosemantics-dwg/issues/46

Semantic improvement

In AEC, authoring metadata (e.g., author, date, revision, etc.) is of high relevance for multiple aspects of collaboration, such as coordination and legal issues. Hence, the domains requires authoring metadata to be attached to any kind of information — and with geometry oftentimes being the core structure for non-geometric information — this is even more important for geometry descriptions. To avoid inconsistent and varying attachments of authoring metadata, we suggest to formulate a best practice for enhancing GeoSPARQL triples with authoring information, ideally by reusing existing concepts of provenance ontologies, e.g., PROV-O, DCTerms, etc.

http://ogc.standardstracker.org/show_request.cgi?id=633

https://github.com/opengeospatial/geosemantics-dwg/issues/47

Semantic improvement / Increased Scope

The AEC domain struggles with geometric representations of planned objects and built objects and corresponding tolerances and inaccuracies, respectively. Planned objects are created on a scratchpad, while construction sites do not offer perfect conditions to recreate the planned geometry completely. Depending on the construction material, the geometry descriptions are commonly enriched with tolerance values, ranging from millimeters (steelwork) to centimeters (masonry). For the geometry of already built objects, the (measured) accuracy is also not perfect, as measuring techniques cannot provide flawless representations. Furthermore, by processing or simplifying geometry descriptions (e.g., from point cloud to mesh), inaccuracies can occur, which are also of interest to attach (represented accuracy) to the measure. Hence, the possibility to attach accuracies (measured or calculated accuracy) and tolerances would be beneficial for building geometry.

http://ogc.standardstracker.org/show_request.cgi?id=634

https://github.com/opengeospatial/geosemantics-dwg/issues/48

Semantic improvement

Some geometry schemes can contain a variety of geometry representation contexts (BREP, CSG, NURBS, etc.) but not all applications can deal with every geometry representation context. To ease the integration of geometry descriptions into applications, metadata regarding the geometry representation context at hand could help to automatically retrieve suitable descriptions only. Example: DWG can contain a 2D drawing, a 3D mesh, and/or 3D BREP geometry.

http://ogc.standardstracker.org/show_request.cgi?id=635

https://github.com/opengeospatial/geosemantics-dwg/issues/49

Modeling patterns

Currently, GeoSPARQL requires one intermediate node to attach geometry descriptions to objects. However, in some cases, this might be too complicated and reduce querying performance, while other cases might require additional nodes (e.g., version control). In the Ontology for Managing Geometry (OMG, https://w3id.org/omg), multiple levels for connecting geometry descriptions and objects exist. OMG level 1 implements direct connections between objects and their geometry description (omg:hasSimpleGeometryDescription and omg:hasComplexGeometryDescription), level 2 adds one intermediate node (omg:Geometry), similar to GeoSPARQL 1.0, and the third level adds another node (omg:GeometryState) for versioning purposes. The selection which level is used in a situation depends on the required features (balance between simplicity and functionality).

In AEC, for example, versioning, and thus level 3, is needed during (1) design phase of buildings and (2) for modeling change over time of a building (e.g., changes to building elements, geometry from multiple surveys over time), while data exchange without need for additional metadata would be most performant with level 1 and storage of certain planning stages would be ideally implemented with level 2 to allow multiple geometry descriptions.

Also see the following publications:

http://ogc.standardstracker.org/show_request.cgi?id=638

https://github.com/opengeospatial/geosemantics-dwg/issues/50

Increased scope

Geometry can be described in different ways than SFA/GML snippets in RDF literals. A uniform connector ontology with supplementary metadata would help collaboration across different domains and companies. Hence the different approaches to include geometry in a Semantic Web context should be allowed by the linking method: 1) RDF-based geometry following a dedicated ontology as the geometry schema (e.g. GEOM (https://github.com/w3c-geom-cg/geom), OntoBREP (https://github.com/OntoBREP/ontobrep), OCC (http://w3id.org/occ), etc.); 2) RDF literal embedding the content of a geometry file (~ GeoSPARQL 1.0 for 2D WKT and 2D GML); 3) RDF literal containing a reference to an external geometry file.

For each approach, a wide variety of geometry schemes exist for different use cases. All these schemes should be supported (i.e., binary or text-based, open or proprietary, 2D (vector or raster) or 3D (BREP, CSG, NURBS, point clouds, meshes), RDF-based or other (XML-based, JSON-based, SPFF-based, custom, etc.)). To achieve this support, we suggest the following adaptations.

By widening the scope via the proposed adaptation, the serialization of the geometry can no longer be defined in the datatype. Hence, a novel approach to identify the serialization for automated processing by software applications is required. In OMG this issue is solved by creating a taxonomy, the File Ontology for Geometry formats (FOG, https://w3id.org/fog), that extends the OMG properties. Each FOG property corresponds with a geometry schema and is specialized further via subproperties to indicate the schema version and — if the geometry schema demands/allows multiple files (e.g. a separate material, texture, … file) or serializations — the individual serialization.

Also see the following publications for OMG and FOG and their respective use cases:

http://ogc.standardstracker.org/show_request.cgi?id=634

https://github.com/opengeospatial/geosemantics-dwg/issues/51

Semantic improvement / Increased scope

If multiple geometry descriptions can be attached to one object, or if objects are related to each other, it would be useful to also define relations between the geometry descriptions directly, that are of other nature than purely topological. We propose to extend the schema to also describe the following relations:

These relations are currently implemented in the Ontology for Managing Geometry (OMG, https://w3id.org/omg). The individual use cases and current implementations are presented below.

Also see the following publications for OMG and FOG:

http://ogc.standardstracker.org/show_request.cgi?id=640

https://github.com/opengeospatial/geosemantics-dwg/issues/52

Semantic improvement / Increased scope

During the design phase of a building, a series of geometric descriptions are made based on input parameters (lengths, size, location, orientation). These parameters are commonly also part of the non-geometric description, causing redundant information. In traditional descriptions, such as the Industry Foundation Classes (IFC), this can lead to the non-geometric description contradicting the geometric one, since they are not updated accordingly. For example, a wall can be defined in IFC, where the height of the wall is a non-geometric property, while the extrusion of the geometry is stored separately. The non-geometric property is neither connected to the extrusion nor automatically updated, when the geometry changes, resulting in the potential of inconsistent data. Thus, a link between related properties from geometric and non-geometric descriptions should be established, to ease the detection of contradicting data and the subsequent updating process.

In the Ontology for Managing Geometry (OMG, https://w3id.org/omg), a first implementation of such links is realized. For one, the omg:isExplicitlyDerivedFrom property can be applied in cases, a geometric property of RDF-based geometry (object) and a non-geometric (subject) property describe exactly the same situation (e.g. the height/extrusion), where a chain axiom can be used to automatically update the according values. On the other hand, the omg:isImplicitlyDerivedFrom property can be applied to indicate that a non-geometric property (subject) can be derived from a geometry description (object), as is the case for volumes or surface areas.

http://ogc.standardstracker.org/show_request.cgi?id=626

https://github.com/opengeospatial/geosemantics-dwg/issues/56

Geospatial processing / Query language

Geospatial literals currently cannot be queried using traditional aggregate functions such as MIN,MAX,AVG. However it may be useful to get the minimum or maximum X,Y or Z coordinate for a given set of geometries, which is currently not possible in GeoSPARQL.

One use case could be: Finding a bounding box of a set of geometries for which a minimum X,Y and maximum X,Y coordinate of all geometries within a graph would be needed.

Proposal:

http://ogc.standardstracker.org/show_request.cgi?id=173

https://github.com/opengeospatial/geosemantics-dwg/issues/4

Documentation bug

Errors in example data and queries might lead to wrong implementations. In the given example data in B.1. (page 51) the LineString start with and ends with, although it must be single brackets.

In the third example query in B.2 (page 52) the subject of the fifth triple pattern is a variable called ?my:D although is should be no variable (my:D).

In the fourth example query in B.2 (page 54) the URL given in the prefix definition for geof is wrong. Instead of < 0 > it must be < 1 >

http://ogc.standardstracker.org/show_request.cgi?id=548

https://github.com/opengeospatial/geosemantics-dwg/issues/5

Documentation bug

There is a mismatch between the published GeoSPARQL standard v1.0 (11-052r4) and the schema v1.0.1 ( 0 ).

On 8.3.12, page 13, of the standard is defined the property hasDefaultGeometry. The schema defines the property instead as defaultGeometry but with an otherwise equivalent definition. The schema does not contain a hadDefaultGeometry property.

This mismatch prevents RDFS and OWL inferencing being performed correctly on a dataset written to comply with the standard.

Please can the schema be updated and new version issued.

http://ogc.standardstracker.org/show_request.cgi?id=595

https://github.com/opengeospatial/geosemantics-dwg/issues/10

Coordinate Reference System support

WKT seems a good way to easily encode geographic geometry, but the datatype geo:wktLiteral makes it hard to work with GeoSPARQL. In a next version, there should be an option to use only a WKT literal and use a different way to express the CRS of a geometry. Reasons why concatenation of CRS URI and WKT can be considered bad design are as follows.

It seems better to introduce a new property for CRS and to let WKT literals be just WKT literals. Should a new property for indicating CRS be introduced, it would be good to allow it to be applied not only to individual geometries, but to geometry collections too.