Sveriges dataportal, DIGG - Myndigheten för digital förvaltning
Sök data Nyheter Om oss Community
  • Hem
  • Kategorier
  • Senaste
  • Taggar
  • Populära
  • Användare
  • Grupper
  • Sök
  • Ser ut som din anslutning till %1 gick förlorad, vänta medan vi försöker att återansluta.
  • Registrera
  • Logga in

Navigering

    Wikibase and the EU Knowledge Graph as an use case

    Meetups och evenemang
    4
    15
    305
    RSS Feed
    Laddar fler inlägg
    • Äldst till nyaste
    • Nyaste till äldst
    • Flest röster
    Svara
    • Svara som ämne
    Logga in för att posta
    Det här ämnet har raderats. Endast användare med ämneshanterings-privilegier kan se det.
    • J
      jonor @ej aktiv Senaste redigerad av

      @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

      dd670682-2627-4d64-bb00-2dc236dac1b3-image.png

      E Ett svar Senaste svaret Svara Citera Gilla 2 Post Tools Trigger
      • E
        ej aktiv @jonor Senaste redigerad av ej aktiv

        @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...

        J Ett svar Senaste svaret Svara Citera Gilla 2 Post Tools Trigger
        • J
          jonor @ej aktiv Senaste redigerad av

          @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.

          E D 2 svar Senaste svaret Svara Citera Gilla 0 Post Tools Trigger
          • E
            ej aktiv @jonor Senaste redigerad av

            @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 😉

            J Ett svar Senaste svaret Svara Citera Gilla 0 Post Tools Trigger
            • J
              jonor @ej aktiv Senaste redigerad av

              @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.

              D Ett svar Senaste svaret Svara Citera Gilla 2 Post Tools Trigger
              • D
                Dennis_Priskorn @jonor Senaste redigerad av

                @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

                Ett svar Senaste svaret Svara Citera Gilla 1 Post Tools Trigger
                • D
                  Dennis_Priskorn @jonor Senaste redigerad av 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 🙂

                  Ett svar Senaste svaret Svara Citera Gilla 2 Post Tools Trigger
                  • E
                    ej aktiv Senaste redigerad av ej aktiv

                    @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

                    54d52e53-0625-4864-87ce-0fcaf052bbbf-image.png

                    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_ Ett svar Senaste svaret Svara Citera Gilla 2 Post Tools Trigger
                    • Nina_
                      Nina_ @ej aktiv Senaste redigerad av

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

                      1. Tips om en sakfråga
                      2. 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.

                      Moderator på community för Sveriges dataportal. Anställd på DIGG.

                      Ett svar Senaste svaret Svara Citera Gilla 0 Post Tools Trigger
                      • D
                        Dennis_Priskorn Senaste redigerad av

                        @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 🙂

                        Ett svar Senaste svaret Svara Citera Gilla 1 Post Tools Trigger
                        • Första inlägg
                          Sista inlägg