Clojurians Log v2

I asked https://clojurians.slack.com/archives/C09GHBXRC/p1691793693974709 a while back. For TTL, there’s https://github.com/quoll/raphael. JSON-LD is hard.

yeah I've basically given up on JSON-LD. It seemed promising but I think I'm going to settle for Turtle. I'll give raphael a go, thx.

Can you elaborate on what you mean by load?

@bhlieberman93 @max.r.rothman I'd love to learn what you found hard about JSON-LD, or make it possibly not worth going for. I'm considering it as a more accessible way to create Linked Data without bothering devs to learn Semantic Web stuff, so your experiences could be of value to me.

@bartkl which library are you planning to use?

Mostly https://clojurians.slack.com/archives/C09GHBXRC/p1723722108402759?thread_ts=1723655993.747289&channel=C09GHBXRC&message_ts=1723722108.402759, I was using existing JSON-LD from a public ontology in that project

I'm not currently at the stage where I'm actually considering specific libraries. JSON-LD from a more architectural/organisational level seems promising to enrich existing APIs to become semantically meaningful to machines (LD). I guess I interpreted the critical remarks here as applying generally to JSON-LD, but probably it was meant (in context) wrt parsing as @max.r.rothman clarified. (Not trying to hijack this thread, sorry)

Yeah exactly. Something you’ll want to consider in that architectural decision is the lack of tooling support for json-ld in the Clojure ecosystem

That's good to know. Thanks!

@bartkl I am also pretty new to the RDF zone so definitely take that under advisement. But essentially I had a similar experience to Max. My initial encounter with JSON-LD was through Fluree, which I was evaluating for usage in a personal project for interacting with DBPedia. However, Fluree's JSON-LD parser did not work with the DBPedia data, which was not a roadblock I encountered elsewhere (I am also looking at RDF tooling in OCaml.) I came to this channel and various people mentioned Java libs for JSON-LD, but in spite of my relative confidence using Java interop, I thought the libraries looked a little too complicated for my use case. So I've opted to stick with TTL, because I have a basic grasp of how to use it already (and the library support is more robust).

Hmmm, this sounds like an opportunity. Either creating a new JSON-LD parser, or fixing the one from Fluree. @bhlieberman93, was it the complete DBPedia download? Did it fail completely, or did it load but with errors?

I'd have to retrace my steps and get back to the errors I was seeing, but it didn't load. I recall having to modify the shape of the JSON in order for it to fit to the schema specified by Fluree, but that also did not work. I have some free time today, so I can look into what I was seeing. @quoll

There's also Aristotle (Apache Jena) if you want an entire RDF solution around it.

I’ve used Java libs for JSON-LD, but haven’t liked them. Fluree suggested theirs, and I’ve meant to look at that code. I did consider doing it myself, but it’s kind of painful, especially since the context is stack based (not so hard, but fiddly) and you can import other files into the context at any time (that’s the trickier part). I figured it was better to use Fluree’s

Please let me know if there are any problems with Raphael! It works for me in the places I’ve employed it, but I’m always happy to tweak it if anything shows up that isn’t quite right for you

I looked at Jena initially but I was running into dependency conflicts unfortunately. I will check out Raphael and see what's to see, thanks @quoll!

I am playing around with grabbing some Turtle files off the web and loading them into memory for exploratory purposes. Possibly graphviz, etc. @drewverlee

Raphael would probably be the way to go then. It’s very light on dependencies (they’re both things I’ve written which aren’t dependent on anything else).

It creates a map containing the base, namespace mappings and a seq of triples, which are just 3-element vectors. By default, the 3 elements are IRIs, blank-nodes, and typed literals, as defined by the RuDolF library (one of the 2 dependencies), though the typed literals are replaced by doubles, longs, strings and java.util.Dates when those types are recognized. So it’s usually easy to work with. If you want different behavior, that’s straightforward, since the element generation is handled by a protocol (with a default that I just described), and triples themselves are also handled by a protocol, so you can generate something other than vectors that accumulate in a seq.