Wikibase and the EU Knowledge Graph as an use case

Magnus Sälgö

16 November 14.00-15.30 (CET): Wikibase and the EU Knowledge Graph as a use case

The largest part of the graph is represented by projects financed by the European Union Cohesion funds. This data is exposed to citizens in Kohesio available at https://kohesio.eu.

jonor

@salgo60-ej-aktiv sa i Wikibase and the EU Knowledge Graph as an use case:

The largest part of the graph is represented by projects financed by the European Union Cohesion funds. This data is exposed to citizens in Kohesio available at https://kohesio.eu.

Det var en väldig massa projekt i Portugal och Italien jämfört med övriga länder, och en del länder verkar sakna data. Hur går man tillväga för att göra summeringar på belopp per region t.ex.?

Magnus Sälgö

@jonor bra fråga

i bakgrunden i denna app finns #Wikibase men verkar vara en enormt trött installation.... timar ut
kollar vi på ett projekt https://kohesio.eu/projects/Q2659862
- så heter projektet Q2659862 --> så ligger budgeten i Property:P474

sökspråk är SPARQL och endpoint query.linkedopendata.eu ==>

SPARQL (gissar lite hur datat lagts in att det skall ha land, start stop och budget i Euro)

Svenska projekt = 1626 projekt.... --> summa Euro 2 318 000 000
- liten test Item:Q2660492 heter "New technology for energy-efficient particle separation from flue-gases" och verkar ha budget 802 873 Euro
summerat och grupperat per land där SPARQL timar ut om jag skall visa ländernas namn i klartext
** Q13 = Polen
** Q7 = Spanien
** Q18 = Portugal
** Q15 = Italien
** Q11 = Sverige
beloppet är summerat och avrundat på miljonen....om jag tänkt rätt

Magnus Sälgö

Fick SPARQL hjälp tweet och det löstes med en nestlad SPARQL fråga

SPARQL summering per land i linkedopendata.eu

jonor

@salgo60-ej-aktiv Tack för demonstrationen. Det verkar som det kan vara ganska prestandakrävande att ställa intressanta frågor.

Jag provade som en övning att hämta folkmängd och budget per capita också. Population har flera värden över tid, men det verkar som det senaste värdet väljs automatiskt på något vis.

Som sagt vore det ju roligt att ha med namnen på länderna, men det orkar tydligen inte frågetjänsten med. Jag vet inte om man i praktiska sammanhang brukar kombinera olika typer av databastjänster och verktyg för att göra analyser.

java.util.concurrent.TimeoutException
at java.util.concurrent.FutureTask.get(FutureTask.java:205)
at com.bigdata.rdf.sail.webapp.BigdataServlet.submitApiTask(BigdataServlet.java:292)
at com.bigdata.rdf.sail.webapp.QueryServlet.doSparqlQuery(QueryServlet.java:678)
at com.bigdata.rdf.sail.webapp.QueryServlet.doGet(QueryServlet.java:290)
at com.bigdata.rdf.sail.webapp.RESTServlet.doGet(RESTServlet.java:240)

https://tinyurl.com/ye3qj5rc

Portugal (Q18)
Estonia (Q23)
Croatia (Q30)
Slovakia (Q26)
Latvia (Q24)
Greece (Q17)
Poland (Q13)
Romania (Q28)
...

jonor

@salgo60-ej-aktiv Aha ok, hade inte sett uppföljningen. Det gäller då att veta lite mer om hur systemet samlar ihop datan när man konstruerar frågor.

Med etiketter:
https://tinyurl.com/ye8lt2u2

Magnus Sälgö

@jonor japp snyggt tacka Tagishsimon min variant https://tinyurl.com/yh3xpk27 verkar galet att Portugal har 20 ggr mer än Sverige jämfört per capita....

video om detta med rank och federated search etc...

jonor

@salgo60-ej-aktiv Ok, jag hade av något skäl fått för mig att preferred rank skulle ligga högre upp i listan, men den låg längst ned där då. Ser nu att uppåt-pilen för rankning är fylld i den aktuella posten, förutom att det också framgår av egenskapen om "reason for preferred rank".

BNP är förstås också en intressant faktor att ta med i sammanhanget.

Det ser ut att finnas en hel del klurigheter i SPARQL att läsa in sig på, och körordningen är ju inte helt uppenbar, men kanske en tumregel är att körning av grupperade satser sker inifrån och ut. På Wikidata finns väl en förenklad query builder också, men jag vet inte hur långt man kommer med den, om det t.ex. skulle gå att formulera federerade frågor.

Magnus Sälgö

@jonor sa i Wikibase and the EU Knowledge Graph as an use case:

körordningen

första gången jag ser detta problem men det beror nog mer på att bra öppna data inte finns och mina SPARQL ofta är "koppla ihop" objekt
- utan vara databasmotor guru så känns det som en liten brist i SPARQL motorn (Blazegraph) att den "måste" ha nestlade sökningar för att optimera sökningen... borde inte vara raketforskning att inse att en Group by borde styra hur frågan exekveras (i detta fall etiketter...)
Tyvärr så är vi inte bortskämda med bra öppna data och SPARQL endpoints...
- vore trevligt om Vinnova, NSÖD, DIGG hade endpoint och levererade dataset. Känns udda att man inte designar med API first utan DIGG skapar websidor, att NSÖD verkar sakna verksamhets förankring och knappt fått fram data utan fokus verkar vara skapar några specar utan tydlig kravbild...
  - vän av ordning känner att vi bara kastar bort skattepengar när vi inte jobbar mer strukturerat och det saknas ett "urgency" och ett commitment från kommuner, myndigheter....
Känns även som rollen som IT arkitekt som har visioner och känner ett ansvar för Öppna data är ledig

jonor

@salgo60-ej-aktiv sa i Wikibase and the EU Knowledge Graph as an use case:

första gången jag ser detta problem men det beror nog mer på att bra öppna data inte finns och mina SPARQL ofta är "koppla ihop" objekt

utan vara databasmotor guru så känns det som en liten brist i SPARQL motorn (Blazegraph) att den "måste" ha nestlade sökningar för att optimera sökningen... borde inte vara raketforskning att inse att en Group by borde styra hur frågan exekveras (i detta fall etiketter...)

Jo jag håller med, jag blev lite förvånad att den inte kunde optimera frågan på egen hand. I så fall skulle man behöva lite mer stöd för att kunna analysera och jämföra prestandan i delar av frågor.

Dennis_Priskorn

@jonor sa i Wikibase and the EU Knowledge Graph as an use case:

Jo jag håller med, jag blev lite förvånad att den inte kunde optimera frågan på egen hand. I så fall skulle man behöva lite mer stöd för att kunna analysera och jämföra prestandan i delar av frågor.

Känner du till https://github.com/ad-freiburg/QLever? Jag har korresponderat huvudarkitekten, Hanna Bast, som doktorerat inom algoritmer och specialiserad sig på optimering. Den motorn visar tydligt vilka delar i frågan som tar längst tid och den är väldigt överlägsen BlazeGraph när det gäller sökoptimering. Detta kommer med en kostnad i form av den tid och energi som går åt att skapa ett index.

BlazeGraph är gjort för data som ändras snabbt och inte optimerat särskilt mycket verkar det som och tyvärr underhålls den inte alls sen flera år.

Se https://phabricator.wikimedia.org/T291903

Dennis_Priskorn

@jonor sa i Wikibase and the EU Knowledge Graph as an use case:

Det ser ut att finnas en hel del klurigheter i SPARQL att läsa in sig på, och körordningen är ju inte helt uppenbar, men kanske en tumregel är att körning av grupperade satser sker inifrån och ut. På Wikidata finns väl en förenklad query builder också, men jag vet inte hur långt man kommer med den, om det t.ex. skulle gå att formulera federerade frågor.

Japp, klurigt är det. BlazeGraph har hemsnickrat syntax också som inte är med i specifikationen också (tex named subquery som behövdes här).

Det går inte i dagsläget med Query Builder vad jag vet. SPARQL är en hel vetenskap verkar det som och det är en rätt brant inlärningskurva på språket tycker jag och ingen har gjort en överblick vad jag sett över vilka motorer som finns och vad de stödjer och inte. Dags för att bygga ut https://en.wikipedia.org/wiki/Comparison_of_triplestores med en ny tabell för vilka SPARQL features motorerna implementerad?

Om du vill kan du skapa ett ärende på https://phabricator.wikimedia.org/ för Query Builder och fråga efter stöd för federering

Magnus Sälgö

@Dennis_Priskorn @jonor det finns "stöd"... du kan lägga på &explain=details men då sitter jag på läktaren

Exempel din fråga https://query.linkedopendata.eu/sparql?query=SELECT....&explain=details

SPARQL advanced
Det finns några som är överjäkliga på SPARQL bland Wikidata folk Tagishsomon verkar vara det men den jag följer mest är Lucas Werkmeister.

Öppen ontologi
Med en öppen ontologi som Wikidata som skall innehålla all världens kunskap skapad av frivilliga dyker man på en hel del "utmaningar", ett är som vi i söndagens Wikidata snack pratade lite om är exempelvis landet Danmark wd:Q35 som "vi alla vet vad det är" men kollar du på

Q35#P1889 "ej samma som" -->
- Q756617 Kungariket Danmark som då är Danmark med Grönland et...

Min tro är skall Öppna data lyfta så måste vi bort från dagens SILOS med en spec utan data och skapa kunskapsgrafer som knyter ihop all data i Sverige Norden Europa världen.... och att det finns mönster för att spela i samma lag typ publika öppna prioriterade backlogs med seniora produktägare

ser dock inte detta komma känns som dagens laguppställning gör att vi fastnar på hur en koordinat definieras eller om tasks skall ha unika id:n....

Rekommenderas mer om SPARQL
Tycker Lucas live sessions ger en insikt hur SPArQL kan användas men även hur man navigerar en kunskpasgraf för att förstå hur den är skapad...

Lucas " rC3 recording: Querying Linked (Wiki)data with SPARQL"
Lucas 1 juni 2021 "Wikidata Live Querying"

Nina_Berlin

@salgo60-ej-aktiv Hej, det här inlägget verkar vara en blandning av

Tips om en sakfråga
Kritik om arbetssätt, organisation och bemanning av några aktiviteter.
De här två delarna mynnar ut i två skilda diskussioner.
Kan du dela upp inlägget i två så vi kan hantera frågorna var för sig? Som det är nu försvinner sakfrågan i kritiken, vilket jag tycker är synd.

Dennis_Priskorn

@salgo60-ej-aktiv sa i Wikibase and the EU Knowledge Graph as an use case:

Lucas 1 juni 2021 "Wikidata Live Querying"

Den hade jag inte sett! Tack för tipset