This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-01-16
Channels
- # announcements (2)
- # babashka (51)
- # beginners (165)
- # biff (39)
- # clara (1)
- # clj-kondo (20)
- # cljsrn (6)
- # clojure (64)
- # clojure-belgium (11)
- # clojure-conj (2)
- # clojure-europe (12)
- # clojure-nl (3)
- # clojure-norway (7)
- # clojure-uk (6)
- # clojurescript (11)
- # conf-proposals (1)
- # conjure (1)
- # core-async (19)
- # cursive (6)
- # data-science (16)
- # datomic (6)
- # deps-new (4)
- # fulcro (60)
- # funcool (3)
- # graalvm (9)
- # helix (14)
- # introduce-yourself (4)
- # jobs-discuss (13)
- # joyride (1)
- # kaocha (2)
- # malli (12)
- # off-topic (25)
- # polylith (9)
- # portal (3)
- # practicalli (1)
- # rdf (43)
- # re-frame (7)
- # reagent (5)
- # releases (5)
- # remote-jobs (8)
- # sci (5)
- # shadow-cljs (42)
- # squint (6)
- # xtdb (5)
Has anyone tried to use the jena libs with GraalVM? I'm trying the first time, and getting a ClassNotFoundException. I've seldomly used graal, and never with java libraries in a clojure project, I'm running against a wall here. Pure clojure projects work fine with this setup. Demo project: https://github.com/virtual-earth-de/jena-graal
All love to Andy, but this is one of the reasons why I reimplement these things in Clojure 🙂
one of the big reasons for Graal to fail on Java libs is when reflection gets used. I can't tell you where that's happening, but that's a first thing to look for.
…thanks, I got over the reflection bit for the queryparser but now I'm seeing a new one with xerces :) It woud be great to have a working semantic web environment in clojure - it's on my todo list to check out asami for RDF. Right now I'm testing / benchmarking commercial triple store & found RDFox with it's main memory implementation quite impressive. > 4 billon triples in 512Gb, not too shabby. And query performance is impressive, compared to it's on-disk contenders. I'm wondering how much work it would be to import test data from e.g. the berlin sparql benchmark into clojure datalog stores, maybe I'll work on that, maybe I can even use fluree's sparql parser to run the tests…
Apologies if this sounds narcissistic for promoting my own libs, but looking at your code you might want to check out https://github.com/yetanalytics/flint, the Clojure -> SPARQL compiler I made.
I also wrote https://github.com/yetanalytics/flint-jena, which is a version that builds Jena Query/UpdateRequest instances directly instead of strings.
I’m curious how they would actually work in GraalVM. Vanilla Flint should work just fine since that’s 100% Clojure, but flint-jena might run into issues since it calls a lot of low-level Jena methods directly
Have you traced reflective calls with the -agentlib:native-image-agent
?
I’ve not done this with Jena, but have done it with RDF4j and using the agent to trace the reflective calls, generated the configs I needed just fine. IIRC it does tend to give you much more config than you need (which IIRC can bloat the binaries a bit) but you can then go through them by hand and clean up the config you don’t require easily enough.
@U039VREN8F5 Asami is not there for RDF yet. I have started on this, but other solutions will be better
Speaking of Asami I wish there was a “Korra” library that would allow you to use Asami with SPARQL
I am trying to create a transform library that takes SPARQL and generates Asami queries. Why do it that way? Because Asami queries are data structures, and the structures are executed directly
I spend my days doing SPARQL queries now, and it seems ridiculous that I don’t have it on Asami. And embarrassing
That would be a pretty cute addition to asami for sure What I’d really like though would be a something to go from SPARQL to flint (though IIRC it doesn’t have 100% coverage of the SPARQL grammar) or an intermediate data representation of SPARQL. We currently rewrite SPARQL queries by parsing the AST with Jena, munging it as the AST and then printing it back to SPARQL, for execution against the database. All written in clojure; but the Jena APIs for this aren’t ideal. That said if such a thing existed I probably wouldn’t replace what we have, as it’s battle tested and works in a bunch of production settings… However if I were to do something again and were in less of a hurry I’d probably go down this route 🙂
> though IIRC it doesn’t have 100% coverage of the SPARQL grammar Yeah unfortunately it doesn’t, which is why I never made a SPARQL -> flint parser
Asami’s functionality has been driven by SPARQL. There were a couple of occasions when Asami implemented a query option before Datomic did. However, there are a couple of minor semantic differences between SPARQL and Datomic. Whenever that happened, I always took the SPARQL route
(I had lots of reasons for this, but probably the real reason was laziness… I already understood the SPARQL semantics)
Going back to the original statement that started this thread… My biggest reason for reimplementing things from scratch is platform neutrality. My company has a big investment in .net, and I don’t want to write C# 🙂
This is also why I try to build each component as a library, rather than a monolithic project. The smaller the dependencies for a web page, the better
Nothing worse than going through module A only to see it reach into the internals of something else
I appreciate that they describe their queries plans in a lisp-like syntax, but that’s it
Even as late as 2004, they did BGP matching against triples using a filter.
Yes, a filter.
If you inserted 1000 triples, in which you have 10 instances of my:Type
, and you did a basic query of:
SELECT ?y
WHERE { ?x rdf:type my:Type . ?x rdf:value ?y }
Then you would iterate through that data with 10,000 testsyeah I always much preferred the code quality and cleanliness of RDF4j to Jena… Though it’s not quite as fully featured as Jena.
Actually, I guess it was 11000 tests. 1000 to match the type, and then for each of the 10 matches you’d iterate through 1000 statements
it’s still basically the same — though they repackaged all the classes under org.eclipse
and have made a few breaking changes along the way
Jeen Broekstra is still very active
It is of course still a huge java project with lots of modules etc