Page 93 - Kaleidoscope Academic Conference Proceedings 2022

Extended reality – How to boost quality of experience and interoperability

3. BUILDING THE KADASTER KNOWLEDGE accessible through a GraphQL endpoint. An internally
GRAPH developed microservice, denoted in the figure above as the
Enhancer, is then used to query the data and return the results
Kadaster, in its role as the national mapping and land registry, in JSON-LD serialization format. This microservice also
publishes and maintains several key geospatial registers. publishes the resulting data to the triple store, an instance of
Contained in these datasets is administrative and spatial data TriplyDB (https://triplydb.com/), which in turn makes the
concerning property ownership and real estate rights; both on data available in a number of serialization formats based on
a national and international level. In carrying out this role, the instantiation of services (e.g. a SPARQL service) as
the organization provides Dutch society legal certainty with shown above. A preceding step to the loading of data into the
regards to all administrative and spatial data on property and triple store is a SHACL validation step which ensures any
rights involved. Recently, Kadaster has also actively loaded data complies with a defined data model and to ensure
developed an approach for publishing and maintaining that data has not been partially lost or fundamentally changed
several key registers and geospatial datasets as linked (open) over the course of the transformation. Indeed, the process is
data, a standards-based approach to linked data publication automated as much as possible, in order to avoid any human
which has recently been updated [1] and which is central to errors in the transformation.
the initial and ongoing development of the Kadaster
Knowledge Graph (KKG). The SPARQL endpoints for all For each dataset, the linked data model used for publication
key registers, the KKG itself and information about any is made available in linked data ‘as-close-to-the-source’ as
updates to datasets can be found and used in Kadaster’s triple possible. This approach is taken for a number of reasons.
store environment (https://data.labs.kadaster.nl/). Firstly, data models for key registers are often defined in
Dutch law, supporting the legal certainty of the registered
The KKG is composed of several key registers including the using a given data model. Keeping the linked data model as
Key Register for Addresses and Buildings (BAG), the Key close to the source supports, to a certain extent, the extension
Register for Large Scale Topography (BGT) and the Key of this legal certainty to the linked data from of the register.
Register for Topography (BRT). Each key register and the Beyond this step, no other legislation requirements were
dataset is first made available as a siloed linked data source included in the scope of linked data publication at Kadaster.
through an Extract, Transform and Load (ETL) process Additionally, the linked data publication of a siloed key
based on several steps extensively discussed by [1] and as register is then also recognizable for domain experts and
illustrated in Figure 2. ensures that the linked data is directly usable for these users.

When combining these datasets for the construction of the
KKG, a central data model is used which simplifies some of
the complexity seen in the siloed datasets with the goal of
making the KKG more suited for a wider range of user
groups, including domain experts and developers as well as
interested citizens, researchers and industry experts. In the
initial development of the KKG, the data model used for
2
publication was based on the schema.org specification .
Current versions of the KKG use the same architecture
defined above for publishing linked data in the KKG but are
now using the first version of the Samenhangende Object
3
Registratie (SOR) ; a data model in development by
Geonovum (https://www.geonovum.nl/), a Dutch
government foundation which supports the standardization
and management of geospatial information in the
Netherlands. This data model, which in English is called the
Connected Object Registration, is being developed to
improve the way the base registers and other related datasets
Figure 2 – Architecture supporting the ETL process are connected based on, for example, the KKG.
which produces linked data [6]
As illustrated in Figure 3 (below), the KKG is realized
To briefly summarize this process, each key register or through the creation of a layer on top of the key registers as
dataset is loaded from a relational database source to the linked data and is created by performing mappings between
PostgreSQL instance following a Geography Markup the data models of the source datasets and the SOR data
Language (GML) indexing step [7] and is then made model. As extensively discussed by [1], the implementation

2 https://schema.org/ . 3 https://www.geobasisregistraties.nl/basisregistraties/
doorontwikkeling-in-samenhang/objectenregistratie

– 47 –