Wow this looks great! It’s something I’ve been meaning to write for a long time; bravo!!! I’ve only looked at this for two minutes, and it looks like it works almost exactly how I’d imagine but a few questions: 1. Have you thought about adding a protocol for representing URI literals, and extending it to java.net.URI and perhaps letting users extend it to jena/rdf4j’s URI classes? Having to encode a string as "<>" feels wrong. What if you had an xsd string which was of the form "<[stuff]>" how would that be interpreted? 2. Similarly providing protocols for coercing other literals, e.g. xsd:date vs xsd:dateTime etc. (These protocols would presumably want to also define datatype-uri accessor.) Like 1 this would allow passing datatypes easily between this and an arbitrary RDF backend e.g. jena/rdf4j. 3. In the map bgp/triple syntax can you also write {:dc/publisher ?publisher} or do you always need to wrap a set over it? 4. Have you considered adding a parser that targets SPARQL 1.1. query strings and converts them into this edn query data structure?

This looks very useful. Thanks a lot!

@U06HHF230 1. I actually have not thought about using protocols to represent literals. Extending any such protocol to a particular Java library could be tricky, however, since Flint supports cljs (and doubly so for a particular Jena class, since I want it to remain implementation-agnostic). As of right now, angle brackets = IRIs, so any string surrounded by them is an IRI, and any IRI will have to be surrounded by them. 2. For the above reason (i.e. I haven't thought about using protocols), there isn't support for literals beyond strings, numerics, booleans, and dateTimes. I wasn't sure how I'd actually implement literals beyond that so thanks for the protocols suggestion; I figure that the already-supported literals will cover most peoples' cases, though, so this would not be a huge priority. 3. You always need to wrap an object in a set, as that is how they're written in https://github.com/ont-app/igraph#the-igraph-protocol. I understand that this can get annoying, though, so maybe in the future Flint can have syntactic sugar where ?obj becomes #{?obj}. 4. I actually did, but I abandoned that idea early on due to its complexity. A big problem is that there are certain valid SPARQL strings that Flint does not support, e.g. https://www.w3.org/TR/sparql11-query/#collections, as well as subtle syntax variations.

@U02FU7RMG8M: Thanks for the reply… perhaps we can take this discussion to #rdf?

I was not aware that there was an RDF channel, but sure we can talk more there.

:thumbsup: cool