Clojurians Log v2

I wonder if it makes sense to create a simple QName type and then devise protocol which uses @eric.d.scott's conversion method for safe conversions between QName, URI, and keyword.

@eric.d.scott What do you think about this? https://github.com/kuhumcst/qname/blob/main/src/dk/cst/qname.clj Others are also welcome to weigh in.

(should probably have been .cljc)

FWIW I’ve spent a while thinking about this, as it’s 9 years now since I created grafter. Grafter’s approach was to use symbols and mount them in namespaces, and simply name them like rdfs:label, and bind the names to URI’s. We also used a simple “prefixer” function which you could give a base uri too, and it would concatenate the URI for you; and then adopted the convention of binding that prefixer to the prefix’s symbol in the namespace. https://github.com/Swirrl/grafter-vocabularies/blob/082ec0a05651316cd406faa13cc23671bfd83827/src/grafter/vocabularies/dcat.cljc#L4. At the time I was intending to build something fancier on top of this; in particular dynamically generating such namespaces from RDF vocabularies etc, and attaching more clojure metadata forms… but in the end I thought better of it; because I didn’t want to bake these kind of side effects and global state in at the bottom, as I wanted something pure. In my mind if you include state in a system you’re building a framework, and frameworks/state stray too much into application concerns; rather than library concerns, and I wanted to build a library. IIRC @eric.d.scott took this sort of approach; I vaguely remember discussing some of this with him at the time… Anyway in the past 9 years, we’ve seen clojure/rich-hickey re-emphasise the fact that keywords are namespaced, and even extend clojure require with better support for keywords and namespaces with :as-alias. So ever since then I’ve also wanted to help close this gap. Our in memory graph database library Matcha also allows the use of keywords as identifiers to support this. Matcha was born around the same time as asami, and shares a similar rationale (schemaless to support RDF), though doesn’t care to be like datomic. If I’d known about Asami back then I’d almost certainly have used it instead of making Matcha. Anyway, one of the biggest issues in my mind around this concerns prefixes and equality; as (not= (URI. "") :rdfs/label); hence handling qnames-as-keywords requires either a special comparison function (likely preloaded/partially applied with the prefixes) or a canonicalisation step. Also you can’t override equality deeply enough, such that it’s integrated into clojure sets etc without conversions, as it’s hard/impossible to make .equals commutative across types where you don’t control both of them. There’s a bunch of other approaches I’ve tried; for example you can modify print-methods to use prefixes you’ve defined, and to pretty print URI’s as prefixed keywords (but for them not to actually be keywords). The issue there is that you can’t copy/paste printed forms back into the REPL and have them read; though arguably you can’t really do that with URI’s either - at least not without adding *data-readers*, which also works by the way, but you then have the extensiblity mutable/state problem — which personally I can’t abide. I think it’s worth mentioning I’ve often thought the other option is to use tagged readers and symbols for this, for example you could have #rdf/iri rdfs:label or #rdf/iri ../foo/bar and the reader could do some canonicalisation for you; you then of course have the problem of injecting state into the reader which is gross — but there are other options/trade offs you could make here.

I think you need to be clear about what problems you want to solve… 1. Printing of URIs at the REPL is gross as they’re very noisy… so removing this noise in printed output at a REPL is nice… e.g. you’ve run a big sparql query and are inspecting intermediate rdf/edn data in memory. 2. You want a terser clojure syntax for supplying URIs/identifiers in queries / data. 3. You want a homoiconic short hand for expressing a subset of URIs which can be both read/written (copy/pasted in REPL sessions)

4. I want a valid QName shorthand for representing an RDF resource in Clojure that is compatible with keywords, since most of Clojure wants and expects those. I think reader tags are definitely part of the solution too, but before one has tags, one must create conversion functions 🙂

yes definitely keywords are part of this too

and there are many possible conversion functions / scenarios

And it really bothers me that I can't write :prefix/123 because the Clojure reader breaks, so I guess the next best thing is to have something like #rdf/qname "prefix:123" .

I’m just trying to put more options on the table for you 🙂

yes, thank you for your valuable input 🙂 I do appreciate it

FWIW I think the next best thing is actually #rdf/qname prefix:123

Now that I’m on a keyboard… I like using keywords, since the syntax is so close to QNames, and it’s convenient in code (e.g. :rdf/type). @rickmoynihan is correct about state, but on that I have a few things to say: • Some namespaces will never change (well, they could, but that’s such a terrible idea that you deserve what you get if you try it 😜). So :rdf/type, :rdfs/range :owl/TransitivePredicate and so on can always presume that their namespaces are the standard ones. • Any use of another namespace has to occur within a context. That means passing around the context as an argument. Bind it to a dynamic var if you don’t want to pollute your function signatures, but there is always a possibility of error if you don’t make the current context available. That second point is especially important in syntaxes like Turtle, since a prefix can get rebound during a document. I can’t say that would be best practice, but it’s possible, and if you don’t support it then you’re going to have a hard time when someone gives you a valid document that you can’t deal with.

yeah I totally agree with all that @quoll… It’s a good point about rebinding prefixes in turtle; there are numerous edge cases like that. My answer to that particular one is don’t trust 3rd party user supplied prefixes, or rather expand them on sight unless they are in your supplied context’s prefix map… Basically prefixes and IRI shorthands are useful in your context; typically they represent the vocabulary terms you are targeting in your app at a given point… i.e. the prefixes are a little like the schema for that bit of your application, if you never look at or match on the IRI terms it doesn’t matter. The issue is of course, sometimes the other terms do matter; e.g. when you want all ?p but don’t know what they are; and you’re combining results across contexts — which is when the equality issues strike.

This is why I save IRIs in databases, and not QNames. It bothers me though… QNames are: • Smaller, and take less space • Often the original representation of the data • What the user wants to see

Yeah.

I’ve argued similar things… e.g. in JSON-LD, if you have an API people want to use the context to provide a nice surface syntax… but the issue is that if unprefixed data leaks out, it’s a breaking change to apply a prefix later to it… hence I’ve argued people need to use the JSON-LD framed syntax, which has all the URI’s expanded. It sucks, but it’s consistent and at least there’s no risk of it breaking for cosmetic reasons.

The other option is to store the prefixes… which is nicer; but requires buy in from the upstream producers etc.