Sparql query traag sinds nieuwe url

Hoi,

Bij de Kamer van Koophandel maken wij gebruik van het BAG SparQL endpoint in een van onze applicatie. Sinds we gebruik maken van de nieuwe url (https://bag.basisregistraties.overheid.nl/sparql) lijken queries een stuk trager te gaan. Daar waar mijn query normaal hooguit 2 seconde duurde, doet hij er nu minstens 15 seconden over. Dat is te lang voor een goede gebruikservaring. Is dit bekend bij jullie? Kan ik daar iets aan doen? Is wellicht het oude endpoint nog (tijdelijk) beschikbaar?

Bij voorbaat dank…
Groeten,
Michiel Mayer
Kamer van Koophandel

Het oude endpoint is niet meer beschikbaar, wel hebben we tegenwoordig ook een endpoint beschikbaar met alleen actuele voorkomens. Afhankelijk van je query kan deze sneller zijn, ook zou je kunnen kijken of je de vraag die je nu via sparql uitvoert ook via de API kunt uitvoeren, die is veel sneller.

Als je de query die je doet deelt zijn we ook bereid even met je mee te kijken en te kijken welke opties wij zien.

Hoi Jasper,

Ik heb het /sparql/now geprobeerd, maar ook die is erg traag. (Ook als ik de query sterk vereenvoudig) Ik heb even snel de REST API geprobeerd, en die lijkt inderdaad een stuk sneller. Ik heb hieronder mijn sparql query geplakt. Belangrijkste voor mij is dat ik op basis van een postcode/ huisnummer/ huisnummertoevoeging/ huisletter combinatie een nummeraanduidings id, status, en een verblijfsobject id, status en gebruiksdoel terug krijg. Ik denk dat ik een eind moet komen met de REST API beschrijving. Mijn beoogde aanpak in het kort: ik begin met het uitvragen van het /nummeraanduidingen endpoint, en vanaf daar volg nog een aantal links, die ik terugkrijg per nummeraanduiding. Klopt deze aanpak? Zijn er dingen waar ik aan moet denken?

Daarnaast nog een andere vraag hieraan gerelateerd: Wij zijn bij de KVK ook aan het kijken naar de mogelijkheden van Linked Data. Wij zijn jullie ervaringen hiermee? Het feit dat ik nu over moet schakelen naar de REST API, geeft nog niet heel veel vertrouwen. Of heeft dit een duidelijk aanwijsbare en oplosbare reden?

Dank voor de hulp zover.

Hieronder mijn Sparql query:
prefix bag: http://bag.basisregistraties.overheid.nl/def/bag#
prefix rdfs: http://www.w3.org/2000/01/rdf-schema#
PREFIX dct: http://purl.org/dc/terms/
PREFIX skos: http://www.w3.org/2004/02/skos/core#
select * {
bind("${postcode}" as ?postcode)
bind(${huisnummer} as ?huisnummer)
bind("${huisnummerToevoeging}" as ?huisnummertoevoeging)
bind("${huisletter}" as ?huisletter)

    graph ?nummeraanduidingVoorkomen {
        ?nummeraanduiding bag:huisnummer ?huisnummer;
                          bag:postcode ?postcode;
                          bag:identificatiecode ?nummeraanduidingID;
                          bag:status ?nummeraanduidingStatus.
    }
    filter not exists {
        ?nummeraanduidingVoorkomen bag:eindGeldigheid []
    }
    optional {
        ?nummeraanduiding bag:huisletter ?huisletter.
        ?nummeraanduiding bag:huisnummertoevoeging ?huisnummertoevoeging.
    }
    ?nummeraanduidingStatus rdfs:label ?nummeraanduidingStatusLabel.
    graph ?verblijfsobjectVoorkomen {
        ?verblijfsobject bag:hoofdadres | bag:nevenadres ?nummeraanduiding;
                         bag:oppervlakte ?oppervlakte;
                         bag:identificatiecode ?verblijfsobjectID;
                         bag:pandrelatering ?pand;
                         a ?verblijfsobjectType;
                         bag:status ?verblijfsobjectStatus.
    }
    filter not exists {
        ?verblijfsobjectVoorkomen bag:eindGeldigheid []
    }
    optional {
        ?verblijfsobjectVoorkomen bag:eindGeldigheid ?einde
    }
    ?verblijfsobjectType dct:subject / skos:notation ?gebruiksdoel.
    ?verblijfsobjectStatus rdfs:label ?verblijfsobjectStatusLabel.
    graph ?pandVoorkomen {
        ?pand bag:oorspronkelijkBouwjaar ?bouwjaar;
              bag:identificatiecode ?pandID;
              bag:status ?pandStatus.
    }
    filter not exists {
        ?pandVoorkomen bag:eindGeldigheid []
    }
    ?pandStatus rdfs:label ?pandStatusLabel
}
limit 100

Beste Michiel,

Het voordeel van het gebruik van het /sparql/now endpoint is dat je alleen actuele informatie bevraagt en hierdoor geen rekening hoeft te houden met het BAG historiemodel. Het gebruik van graph-clauses en het filteren op voorkomens zonder eindGeldigheid is hierdoor niet nodig. Als ik dat doorvoer in jouw query kom ik op de volgende query:

PREFIX bag: <http://bag.basisregistraties.overheid.nl/def/bag#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX dct: <http://purl.org/dc/terms/>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>

SELECT *
WHERE {
  BIND("7311KZ" AS ?postcode)
  BIND(110 AS ?huisnummer)

  ?nummeraanduiding bag:huisnummer ?huisnummer ;
    bag:postcode ?postcode ;
    bag:identificatiecode ?nummeraanduidingID ;
    bag:status ?nummeraanduidingStatus .

  OPTIONAL {
    ?nummeraanduiding bag:huisletter ?huisletter .
    ?nummeraanduiding bag:huisnummertoevoeging ?huisnummertoevoeging .
  }

  ?nummeraanduidingStatus rdfs:label ?nummeraanduidingStatusLabel .

  ?verblijfsobject bag:hoofdadres | bag:nevenadres ?nummeraanduiding ;
    bag:oppervlakte ?oppervlakte ;
    bag:identificatiecode ?verblijfsobjectID ;
    bag:pandrelatering ?pand ;
    a ?verblijfsobjectType ;
    bag:status ?verblijfsobjectStatus .

  ?verblijfsobjectType dct:subject / skos:notation ?gebruiksdoel .
  ?verblijfsobjectStatus rdfs:label ?verblijfsobjectStatusLabel .

  ?pand bag:oorspronkelijkBouwjaar ?bouwjaar ;
    bag:identificatiecode ?pandID ;
    bag:status ?pandStatus .

  ?pandStatus rdfs:label ?pandStatusLabel
}
LIMIT 100

Dit geeft bij mij in +/- 1 seconde het gewenste resultaat. Gebruik van de REST API is over het algemeen betrouwbaarder (hogere performance en beschikbaarheidsgaranties) en past dus beter bij bedrijfskritische toepassingen, al zul je in dat geval meerdere requests nodig hebben om deze informatie bij elkaar te rapen. Het mooie van SPARQL is natuurlijk dat dit in een enkele query kan.

@michielmayer, nog in aanvulling op Joost en specifiek reagerend op jouw vraag.
We hebben hele goede ervaringen met gebruik van RDF en Linked Data. Met name op het gebied van het generiek informatie-modelleren en generiek informatie ontsluiten. Daarnaast biedt Linked Data veel mogelijkheden voor het integraal bevragen van verschillende datasets. Ook onze REST APIs maken daar onder water gebruik van.

We zien inderdaad, na onze migratie naar onze nieuwe stack, een performance verschil in een aantal SPARQL queries. Het gebruik van GRAPH clauses levert momenteel een significant performance verschil op. We zijn dat met de leverancier aan het uitzoeken.

Ah, dit helpt. Hij is inderdaad weer snel. Hartelijk dank. De applicatie, die van jullie API gebruik maakt zit nu nog in pilot fase. Dus iets lage betrouwbaarheid is momenteel nog geen probleem. Misschien wellicht dat we op termijn over schakelen op REST dan.
Bedankt.

Dit topic is 180 dagen na het laatste antwoord automatisch gesloten. Nieuwe antwoorden zijn niet meer toegestaan.