Reconsider using URIs instead of keywords for IRIs

[bartkl]

We use ont-app/vocabulary to have URIs from known standards such as OWL, RDFS, SHACL and SKOS be mapped to Clojure keywords. From a Clojure POV, this is idiomatic and from a developer POV very convenient.

However, there's a catch. If there's no known mapping for a given namespace, the full URI is simply converted to a keyword. Recently it has been discovered though that some of the characters in a URI are not valid when you read the (informal?) Clojure Reader spec.

Work is on the way (in version 0.1.8-SNAPSHOT) to fix this, but it comes at the significant cost of sacrificing the very readability that was the reason to use this is in the first place. And since our non-standardized CURIEs have namespaces that potentially differ over several files, as soon as you merge them (and we do) you no longer know how to resolve the potentially ambiguous CURIEs.

So, I'd like to consider switching to representing URIs using the Java URI type:

• As of Asami 2.3.2, Java URIs are supported. This includes recursively fetching
• This will guarantee URI validation to some extent. Types can be nice at times, and this might be one of those cases.
• Every URI is actually a fully qualified URI, no bells and whistles.
• In particular the complexity of the magic of how the mappings are done by the library are perhaps better to do without.
• You no longer have this discrepancy between full URIs sometimes, and CURIEs keywords at others: uniformity!

However, the developer experience is not to be underestimated, especially in Clojure where continuous feedback from the REPL is a major part of your workflow. To have readable (intermediate) data is very valuable. Perhaps we can think of ways?

[bartkl]

Important: for yet unknown reasons the recursive entity fetching with Asami's d/entity does not work well once you upgrade to ont-app/vocabulary 0.1.8-SNAPSHOT. It seems that the following of blank nodes does not work well there.

This makes this issue slightly more pressing!

[bartkl]

Important: it's easy to underestimate just how useful these IRI keywords are, especially (exclusively?) for standardized vocabularies such as prof and sh.

The code is literally littered with references to SHACL resources such as sh:property and sh:targetClass, and these would then all become very unwieldy.

Of course, RDF4j has its own internal vocabulary mappings, which could solve this issue. Instead of the keyword :sh/property, we would then get SHACL/PROPERTY (of type IRI). This is definitely not too bad, although we should look closely into the pros and cons.

[bartkl]

However, I wonder if RDF4j's vocabulary mappings also work with Java URIs. Or if we can get Asami to work with RDF4j IRI objects.

[bartkl]

I've given this a long and hard think.

Some key insights:

• Having keyword URIs is really, really valuable for writing, reading and debugging code. Also, test data will be far more readable.
• The validation benefit from URI objects have already been used after RD4j has parsed IRIs from the source into IRI instances. After that, you know they're fine (during this run) and there's no need to be able to validate again.
• Structure-related benefits from URI objects don't seem big enough to win. It's very easy to, whenever you need it, parse URI keywords into URI objects and then use the methods.
• The non-explicit magic that ont-app/vocabulary pulls is not ideal, but it's simple enough to wrap you're head around. In the future we may want to replace this implementation perhaps.
• RDF4j's vocabulary mappings are interesting, but difficult to extend and less readable and native to Clojure.
• When working with RDF4j IRIs, if we want to enjoy Asami's recursive entity fetching, we need to convert to Java URI objects.

Decision:

• Keep working with URI keywords this way.
• We should consider solving the naked full URIs for non-standard IRIs. Create a task for this.
• At some point in the future we may consider replacing ont-app/vocabulary with something more explicit.