graphql4sparql 0.7.0 Released

We’re excit­ed to announce the release of graphql4sparql 0.7.0 — a fast, stream­ing GraphQL-to-SPAR­QL rewrit­ing sys­tem that brings the pow­er of GraphQL to query SPARQL end­points and RDF data.

What is graphql4sparql?

graphql4sparql trans­forms GraphQL queries into SPARQL queries at run­time, enabling you to:

  • Query SPARQL end­points using intu­itive GraphQL syntax
  • Define cus­tom map­pings between GraphQL fields and SPARQL graph patterns
  • Lever­age RDF’s flex­i­bil­i­ty while enjoy­ing GraphQL’s declar­a­tive querying
  • Get JSON respons­es direct­ly from SPARQL end­points with stream­ing performance

The sys­tem does­n’t use GraphQL-Java’s exe­cu­tion engine. Instead, it rewrites GraphQL doc­u­ments into SPARQL queries and post-process­es the result sets — a more effi­cient approach for RDF data.

Key Fea­tures

Declar­a­tive SPARQL Map­ping with GraphQL Directives

graphql4sparql intro­duces a pow­er­ful set of GraphQL direc­tives for map­ping to SPARQL pat­terns, such as:

  • @prefix — Define name­space pre­fix­es for your queries
  • @pattern — Map GraphQL fields to SPARQL graph patterns
  • @bind — Bind SPARQL expres­sions to fields (e.g., gen­er­at­ing IDs from enti­ty URIs)
  • @one / @many — Con­trol field car­di­nal­i­ty for sin­gle or mul­ti­ple values
  • @join — Explic­it­ly define how par­ent and child fields join
  • @index — Trans­form query results into indexed JSON objects
  • @array — Flat­ten sub-fields into a sin­gle array (field name becomes array container)

Apache Jena Fuse­ki Integration

The release includes a ful­ly func­tion­al Fuse­ki plu­g­in that adds a native GraphQL end­point type to Apache Jena Fuse­ki serv­er. You can con­fig­ure it with a sim­ple Tur­tle con­fig­u­ra­tion file and start query­ing your RDF data with GraphQL immediately.

See our exam­ple set­up for a com­plete work­ing con­fig­u­ra­tion with demo data.

Schema Gen­er­a­tor

Gen­er­ate GraphQL schemas from your RDF data with the graphql4sparql schemagen CLI tool. This removes the need to write SPARQL pat­terns man­u­al­ly and pro­vides type-safe query­ing out of the box.

Exam­ple Usage

Once the Fuse­ki plu­g­in is con­fig­ured, you can query your RDF data with sim­ple GraphQL syntax:

query Works @pretty @debug {
  Work {
    type
    title
    creator
  }
}

Or use the sophis­ti­cat­ed @index direc­tive to group data by sub­jects and predicates:

query spo {
  subjects @pattern(of: "SELECT DISTINCT ?s { ?s ?p ?o } ", to: "s") 
           @index(by: "?s", oneIf: "true") {
    predicates @pattern(of: "?s2 ?p2 ?o2", from: "s2", to: "o2") 
               @index(by: "?p2", oneIf: "false") {
      objects @bind(of: "?o2")
    }
  }
}

Get­ting Started

With Apache Jena Fuseki

  1. Down­load the graphql4s­par­ql-fuse­ki-plu­g­in JAR
  2. Place it in Fuseki’s run/extra directory
  3. Con­fig­ure your Fuse­ki ser­vice with the GraphQl4Sparql endpoint
  4. Start query­ing at http://localhost:3030/your-service/graphql

See our exam­ple set­up for a com­plete, work­ing configuration.

Tech­ni­cal Highlights

  • Fast stream­ing: Gen­er­ates effi­cient SPARQL queries with­out break­ing them into mul­ti­ple requests and process­es results as they arrive from the SPARQL endpoint
  • Bleed­ing-edge SPARQL fea­tures: Lever­ages cut­ting-edge SPARQL exten­sions like LATERAL joins. Note: These fea­tures may not be uni­ver­sal­ly sup­port­ed across all SPARQL engines
  • Apache Jena & GraphQL-Java: Built on proven, wide­ly-used libraries

Resources

Acknowl­edg­ments

graphql4sparql is devel­oped and main­tained by the AKSW research group at the Insti­tute for Applied Infor­mat­ics.

This work was par­tial­ly sup­port­ed by grants from the Ger­man Fed­er­al Min­istry of Trans­port (BMV) under the pro­gram mFund to the Moby­Dex project (19F2266A).

Artikel „Assessing SPARQL capabilities of Large Language Models“ nun in den Workshop-Proceedings von NLP4KGc@SEMANTiCS24 veröffentlicht 

Grafik 1: Überblick zu den 4 betra­chteten Task-Typen: Text2Sparql (T2S), Text2Answer (T2A), Sparql2Answer (S2A) und Spar­ql­Syn­tax­Fix­ing (SSF) 

Unser bere­its als Preprint veröf­fentlichter Artikel „Assess­ing SPARQL capa­bil­i­ties of Large Lan­guage Mod­els“ (Lars-Peter Mey­er, Johannes Frey, Felix Brei und Natanael Arndt 2024) ist nun offiziell veröf­fentlicht in den Pro­ceed­ings des Work­shop „NLP4KGC: 3rd Inter­na­tion­al Work­shop on Nat­ur­al Lan­guage Pro­cess­ing for Knowl­edge Graph Cre­ation in con­junc­tion with SEMAN­TiCS 2024 Con­fer­ence”. Wir stellen dort eine Ergänzung des LLM-KG-Bench-Frame­works vor, mit der die SPAR­QL-Fähigkeit­en von großen Sprach­mod­ellen (englisch: Large Lan­guage Mod­ells, kurz: LLMs; englisch: Knowl­edge Graph, kurz: KG, deutsch: Wis­sens­graph) automa­tisiert gemessen wer­den kön­nen. Das LLM-KG-Bench-Frame­work ist ein am InfAI e. V. entwick­eltes Werkzeug zum automa­tisierten Bew­erten der Fähigkeit­en von LLMs mit Wis­sens­graphen umzuge­hen. Wenn LLMs bess­er mit Wis­sens­graphen umge­hen kön­nen, wür­den LLMs vielle­icht weniger hal­luzinieren sowie die Arbeit mit Wis­sens­graphen für Men­schen erle­ichtern können. 

Das automa­tisierte Messen hil­ft dabei neue LLMs für fach­spez­i­fis­che Auf­gaben objek­tiv einord­nen zu kön­nen. Und durch die Automa­tisierung kön­nen viele Mess­wieder­hol­un­gen durchge­führt wer­den, um trotz dem nicht­de­ter­min­is­tis­chen Antwortver­hal­ten von LLMs ver­lässliche Ergeb­nisse zu erhalten. 

In der Welt von RDF-Wis­sens­graphen ist SPARQL die gebräuch­lich­ste Schnittstelle und Abfrage­sprache.  Deshalb geht es bei der nun vorgestell­ten Unter­suchung um die Syn­tax und Seman­tik von SPARQL SELECT Anfra­gen. Diese wur­den beispiel­haft für ins­ge­samt neun LLMs von Ope­nAI, Anthrop­ic und Google gemessen. Basierend auf den in Grafik 1 dargestell­ten 4 Auf­gaben­typen wur­den 13 ver­schiedene Auf­gaben­vari­anten zu fünf ver­schiede­nen Wis­sens­graphen betrachtet. 

Grafik 2: Auszug aus dem Artikel mit Ergeb­nis­sen für den Bere­ich Text2Sparql(T2S). Die Ergeb­nisse sind als Box­plots gezeigt mit Kreuzen für einzelne Mess­werte und Kreisen für den Mit­tel­w­ert. Bei dem Score bedeutet 1 ein opti­males Ergeb­nis, ein Score von 0,2 bedeutet ein syn­tak­tisch richtiges aber seman­tisch falsches Ergeb­nis, ein Score von 0 wird bei Syn­taxfehler vergeben. Für weit­ere Ergeb­nisse und Erläuterun­gen sei auf den voll­ständi­gen Artikel verwiesen. 

Zen­trales Ergeb­nis unser­er Arbeit ist: Zwis­chen den einzel­nen Auf­gaben und LLMs gibt es große Unter­schiede. Zusam­men­fassend kann man sagen, dass die besten der unter­sucht­en aktuellen LLMs kaum Schwierigkeit­en mit der Syn­tax haben, jedoch bei seman­tis­chen Auf­gaben auf Her­aus­forderun­gen stoßen. Für Details sei auf den frei ver­füg­baren Artikel und Repos­i­to­rien verwiesen. 

Die Arbeit wurde über ver­schiedene Pro­jek­te am InfAI e. V. gefördert: StahlDig­i­tal, ScaleTrust, KISS — KI-gestütztes Rapid Sup­ply Net­work, Coy­Pu — Cog­ni­tive Econ­o­my Intel­li­gence Plat­tform für die Resilienz wirtschaftlich­er Ökosysteme. 

Der Code zum LLM-KG-Bench-Frame­works ist bei Github sowie Zen­o­do zu find­en und die voll­ständi­gen Ergeb­nisse wur­den bei  GitHub und Zen­o­do veröffentlicht. 

Link zum Paper: