Kadaster Data Platform. Architectuur & techniek

Transcriptie

1 Kadaster Data Platform Architectuur & techniek Joost Farla Marco Brattinga

2 Onderwerpen A. Architectuurkeuzes B. Transformatie naar Linked Data C. Triplestores: de opslag D. Data.pdok.nl: ontsluiting: API, Web, Linked Data 2

3 Kadaster Data Platform Architectuurkeuzes

4 Ambitie Rechtzekerheid Geo-platform Kwaliteit 4

5 Architectuurprincipes Breed inzetbaar Productdefinitie los van verstrekking Multi-channel verstrekking Multi-branded presentatie Opslag in vorm-vrij formaat Aandacht voor het gebruik Metadata net zo belangrijk als de data Ondersteunen gebruikerscommunity Verbonden data Open Web based, open standaarden Open source, tenzij Reuse before Make Eén best-of-breed oplossing Betrouwbaar en transparant Eigenaar blijft verantwoordelijk voor data en metadata Verstrekkingskanaal: beheer bij de bron Verstrekking is traceerbaar naar de bron 5

6 6 Kadaster Data Platform (onder de motorkap)

7 Kadaster Data Platform Transformatie

8 Transformatie Zeer diverse formaten Canoniek formaat Mutaties Transformatie naar betekenisvol model Document store voor snel raadplegen en geo-index 8 Ontsluiten en combineren externe bronnen: SPARQL, RDF4J, API s, RDBMS Graph store voor slimme queries

9 Kadaster Data Platform Triplestores

10 Het databaselandschap verandert 10

11 11 Het databaselandschap verandert

12 Het databaselandschap verandert 12

13 Het databaselandschap verandert Nietrelationeel Relationeel Oracle PostgreSQL MySQL SQL server Graph databases Key-value stores Wide column stores Document stores Neo4J Triple stores BerkeleyDB Redis Cassandra HBase MongoDB MarkLogic ElasticSearch Virtuoso MarkLogic GraphDB AllegroGraph Oracle S&G 13

14 ArcGIS Het databaselandschap verandert Geometrisch Nonrelational Relational Oracle PostgreSQL MySQL SQL server Graph databases Key-value stores Wide column stores Document stores Neo4J Triple stores BerkeleyDB Redis Cassandra HBase MongoDB MarkLogic ElasticSearch Virtuoso MarkLogic GraphDB AllegroGraph Oracle S&G 14

15 Onze ervaring De meeste oplossingen zijn goed in één -soms twee- specifieke vormen van data (geografisch, graph, document, relationeel) Onze behoefte heeft de eigenschappen van een federatief databasemodel Bij federatie ontstaan uitdagingen m.b.t. queryoptimalisatie. De 25 dichtstbijzijnde monumentale gebouwen uit de 19 e eeuw De 10 dichtstbijzijnde monumentale gebouwen ontworpen door Cuypers Er zijn heel veel monumentale gebouwen uit de 19 e eeuw Beginnen aan de GEO kant is handig Het aantal monumentale gebouwen ontworpen door Cuypers is overzichtelijk Beginnen aan de niet-geo kant is handig. 15

16 Geometrisch Graph databases Triple stores Requirements vs oplossing Database Schemaloos Performance (laden/opvragen) Mate van schaalbaarheid Mate van beschikbaarheid Connectiviteit SPARQL 1.1 GeoSPARQL RDF4j Support Eigen beheer Kosten Gebruik Eigen ontwikkeling Document stores Integriteit, Backup &Restore Performance Geo+Triples+Tekst Ondersteuning Support licentie Aanpasbaarheid Query engine aanpasbaar Relationeel Tijdreizen Goede documentatie Java-gebaseerd 16

17 Kadaster Data Platform Visualisatie en ontsluiting

18 Data.pdok.nl 18 data.pdok.nl

19 Data.pdok.nl 19 bag.basisregistraties.overheid.nl

20 Visualisatie en ontsluiting Maximale flexibilteit om eigen UI te maken Doelgroep: semantic/ld developers Deferenceable URI s Standaarden: Linked Data, JSON-LD, SPARQL Doelgroep: webdevelopers Hoge performance voor specifieke services Standaarden: JSON, OpenAPI, Swagger, Postman Web pagina s voor menselijke leesbaarheid van data EN metadata Content negotiation voor enkelvoudige data Dun laagje tbv API protocol UI uitbreidbaar en aanpasbaar Zware operaties in de back-end 20