rdflib is encoding local names in Turtle incorrectly

[jgonggrijp]

When I go to my landing page in development, the tally of my items never updates:

Looking into the dev console, they are properly fetched from the backend, but notice the parentheses on line 106:

The frontend parser is rejecting this:

According to the Turtle specification, the parser is right; those parentheses should be escaped.

Consequence: anyone who has created an item with an ontology class that contains parentheses in the IRI, will not be able to load their own items (or the tally of those items). So far, not many people have created items, so hopefully nobody is suffering from this yet. Still, it seems somewhat urgent to fix.

I can currently think of four non-ideal solutions:

• Forward BlazeGraph query result as-is #307 is arguably the most "correct" solution, if BlazeGraph does a better job at Turtle encoding, but is quite involved.
• Edit the ontology again, so none of the IRIs contain reserved characters. This seems somewhat defensible, but is also cumbersome, as it will require another migration and there many classes and properties with parentheses in their IRIs.
• Somehow monkeypatch rdflib in order to fix the Turtle encoding. This is the ugliest possible solution, but might be the only remaining option if the others turn out to be infeasible.
• Don't include the ontology prefix: in the frontend query, so the backend hopefully also doesn't abbreviate the ontology IRI's and writes them full-on between angle brackets instead. The frontend parser seems to be fine with it that way. This is probably the fastest solution, but also the least certain and the least robust, because we already know that rdflib will occasionally create ad hoc prefixes when it feels like it (ns1:, ns2:, etcetera), and future encoders such as BlazeGraph might do the same.

For now, I have worked around this in my local development database by simply deleting the affect item and the annotation it was linked to.

[jgonggrijp]

Update: I just noticed that if any annotation in a source has an affected class or property, then no annotation will be visible in the explorer, neither in the source panel nor in the annotation list panel next to it. This makes the bug extra urgent.