Wikidata/Development/Queries/nl
Hier wordt beschreven hoe query's in Wikidata worden geïmplementeerd. Aangezien query's een vrij groot onderwerp zijn, is dit document onvolledig en bevat het verschillende plaatsen die verder moeten worden verfijnd.
Overzicht
Over het algemeen negeert deze versie in principe kwalificaties en verwijzingen voor query's, maar houdt ze intact in de resultaten. Maar in de eerste iteratie is het niet mogelijk om ze te beperken, erop te sorteren of er iets mee te doen, behalve ze weer te geven. Ook worden alle query's alleen uitgevoerd op verklaringen die als voorkeursgegevens zijn gerangschikt. Alle andere verklaringen zijn tot nu toe genegeerd voor query's.
Wikidata kan een Query uitvoeren en een QueryResult retourneren. Een QueryResult kan op zijn beurt door een client (bijvoorbeeld een Wikipedia) worden gelezen om er een QueryResultVisualization van te maken.
Een Query bestaat uit
- een QueryConcept (of querybeschrijving, niet te verwarren met een entiteitsbeschrijving)
- een array van SelectionRequests, en
- een paar QueryOptions: Sort, Offset en Limit
Een QueryConcept maakt het mogelijk om te beslissen welke entiteiten kunnen behoren tot de QueryResult die een Query beantwoordt. Een QueryConcept kan worden
- een samenvoeging van concepten
- een disjunctie van concepten
- een eigenschap met enige waarde
- een eigenschap met een specifieke waarde of waardebereik
- een eigenschap met een waarde die voldoet aan een concept
- (verdere elementen van het queryconcept kunnen later worden toegevoegd om referenties en kwalificaties te behandelen)
Voorbeelden van queryconcepten zijn "alles met een 'bevolking van meer dan 1.000.000 dat 'een' 'stad'" is, "alles wat 'geboren is in' iets dat zich in 'land' 'Japan' bevindt, en dat 'geboren' is vóór 1500", of gewoon "alles met het 'ISBN' 3-237-233-443" (bij de laatste zal meestal slechts één resultaat zijn).
Een SelectionRequest beschrijft een "kolom" in de QueryResult. In het meest eenvoudige geval zou dat gewoon een eigenschap moeten zijn. Later kunnen we bepaalde claimpatronen toevoegen die de geselecteerde resultaten verder filteren, of die een berekening beschrijven zoals de populatie verdeeld over het gebied.
De QueryOption's hebben een array van Sort'eeringen, die elk verwijzen naar een Sorter naar een van de bestaande SelectionRequests, en een Limit, die het resultaat dat op een bepaald punt is ingesteld, afsnijdt op basis van de gegeven sorts. Een eenvoudig geval zou zijn om de resultaatset in afnemende volgorde te sorteren op hun populatie en alleen de eerste 5000 resultaten te nemen. (Over het algemeen wordt verwacht dat veel QueryConcepts geen QueryOptions nodig hebben, maar dat we de volledige QueryResult kunnen vasthouden en verder kunnen sorteren en beperken bij het visualiseren van de resultaten op de cliënt).
Terzijde: het zal waarschijnlijk niet mogelijk zijn om te sorteren per label of door waarden van type meertalige tekst.
Een QueryResult is een array van entiteiten, elk met claims. De claims worden geselecteerd of gemaakt op basis van de SelectionRequest. (In principe is een queryresultaat een tabelstructuur, waarbij de rijen de entiteiten zijn, de kolommen de selectieverzoeken en elk veld de respectievelijke claims bevat, inclusief kwalificaties en verwijzingen.)
Wikidata zal een module leveren die gegeven een Query een QueryResult retourneert. Wikidata beslist of de vraag ad-hoc beantwoord kan worden, en zo ja, beantwoordt deze. Als dit is toegestaan, wordt gecontroleerd of de queryresultaten in de cache zijn opgeslagen en worden de resultaten in de cache geretourneerd. Wikidata kan antwoorden dat het de vraag niet wil beantwoorden.
Een query kan worden opgeslagen in een query-entiteit, een pagina in de wiki. De pagina toont het concept van de vraag, de selecties, opties, enz., en ook, als deze al in de cache is geplaatst, de laatste zoekresultaten. De pagina, net als alle entiteiten, heeft labels, beschrijvingen en aliassen. Een Wikipedia, in het algemeen, zal een dergelijke vraag met zijn naam toegankelijk zijn en lokaal beslissen welke vormgever ze moet gebruiken om de zoekresultaten te weergeven (bijvoorbeeld een barkaart, een kaart, een tabel, een interactief widget), en ook of er verdere beperkingen en sorteren moeten worden gedaan.
De zoekresultaten worden in de cache opgeslagen en af en toe opnieuw berekend. Wikidata-gebruikers kunnen een vraag in een (prioriteit?) rij plaatsen om deze opnieuw te berekenen. Bij het "opbouwen" van de vraag kan ook een dergelijke (prioriteit?) wachtrij worden gebruikt. Dit zou ook toestaan om een zoekresultaat alleen op expliciet verzoek te herbereken of om een "zichtbare versie" van een zoekresultat te hebben.
Wikidata zal uiteindelijk ook een module leveren die een QueryConcept geeft en een entiteit zal een uitleg teruggeven waarom het item wel of niet in het concept staat.
Een eerste implementatiestap: Property-Value query's (SQL)
De eerste iteratie van de implementatie ondersteunt alleen ad-hoc query's (d.w.z. ze kunnen nog steeds in de cache worden opgeslagen, maar er is nog geen notie van query-entiteiten, en er is slechts één QueryConcept-type, een eigenschap met een specifieke waarde.
Technisch gezien zal dit worden uitgevoerd door alle eigenschapswaarden in een tabel en index te hebben over de eigenschap en waarde. Dit kan in SQL gedaan worden. Het type vragen is in wezen "in Duitsland" of "het ISBN 1-393-2334-X heeft". Deze vragen vereisen geen joins of zoiets.
Er zal per datatype één tabel zijn (d.w.z. een die naar strings wijst, een die naar items wijst, één die naar getallen wijst, enz. Dit is een korte lijst). De tabel zal de volgende structuur hebben: row-id (indien nodig voor huishoudelijke bewaking), entitity-id, statement-id, property-id, value (type hangt af van het datatype van deze tabel, bijvoorbeeld item-id voor items, string voor strings, enz.), statement-blob (met de gehele gestructureerde statement in JSON voor toegang - anders zouden we een zoekopdracht op de entiteit inhoud nodig hebben) (we zijn niet zeker of we de statement-blop willen hebben of niet). Deze tabel wordt bijgewerkt wanneer een verklaring (veelal) wordt gewijzigd. Deze tabellen zullen samen zoveel rijen hebben als de uitspraken, d.w.z. ongeveer 12,5 miljoen, waarvan wordt verwacht dat het een flinke groei zal opleveren (ongeveer 50 miljoen tot het einde van het jaar?). Vanwege frequente updates zal de row-id binnenkort het 32 bit bereik overschrijden.
Voor vragen wordt de tabel geïndexeerd op property-id / waardeparen (de entiteit-id kan aan deze index worden toegevoegd als dit de uitvoering van verbindingen via de entity-id later kan helpen); voor updates wanneer een entiteit wordt gewijzigd, is er een tweede (unieke) index op entity-ID en statement-id.
Er zal geen ondersteuning voor afstandsqueries op de Geodata worden geïmplementeerd in de SQL-benadering.
EntitiesByPropertyValues (eerste iteratie)
Parameters: property (verplicht), value (type hangt af van property, verplicht), entity type (verplicht, offset (optioneel), limit (optioneel)
Geeft terug: een lijst van alle entity-id's die een verklaring bevatten waarin de hoofd 'snak' de gegeven eigenschap heeft en de waarde precies de gegeven waarde is. Optioneel, indien nodig, de offset voor verdere resultaten.
(De waarde zal later worden losgelaten om misschien de bereikvragen te omvatten, d.w.z. groter dan, kleiner dan, enz.)
Een tweede implementatiestap: Bereiken, coördinaten en conjunctieve query's (Solr / ElasticSearch)
We willen dan voor de volgende stap overgaan naar de mogelijkheid om conjuncties (een stad en gelegen in Duitsland) en ook de geografische gegevens (dicht bij deze coördinaten) op te vragen. Dit werkt niet goed met SQL. Onze huidige denkwijzen en tests wijzen op Solr of ElasticSearch als goede technologieën om dit soort zoekopdrachten te ondersteunen.
In Solr of ElasticSearch zou elk item worden weergegeven als een document, en elke verklaring zou leiden tot een of meer kenmerken van het document. Solr of ElasticSearch ondersteunen ook geocordinaat, bereik en sorteren.