Should character-escaping be applied when generating JSON-LD IRIs?

[wouterbeek]

Observation

When a key includes characters that must be escaped in an IRI, it is currently unspecified what a JSON-LD processor should do.

The JSON-LD Playground currently exhibits different behaviours for such cases, depending on the character that is involved

When a greater than sign ('>') occurs inside a key, JSON-LD Playground generates a malformed triple:

{"@context": {"@version": 1.1, "@vocab": "https://example.com/"}, "a>b": "c"}

Result:

_:b0 <https://example.com/a>b> "c" .

Notice that this triple cannot be loaded in triple stores that check for IRI syntax.

When a space (' ') occurs inside a key, JSON-LD Playground generates no triple:

{"@context": {"@version": 1.1, "@vocab": "https://example.com/"}, "a b": "c"}

Notice that the current behaviour is difficult to predict: JSON-LD Playground already implements two different behaviours; other JSON-LD processors may do other things as well.

Expected

I expect that the JSON-LD standard prescribes what a JSON-LD processor must do when it encounters a character that must be escaped according to the IRI grammar. I see 5 options here:

1. It is up to the JSON-LD processor to choose what it does in such cases. The behaviour is undefined in the standard.
2. A JSON-LD processor must not apply character escaping, must generate any incorrect triples that result from this, and must either silently succeed or emit a warning.
3. A JSON-LD processor must not apply character escaping, must not generate any incorrect triples that result from this, and must silently succeed or emit a warning.
4. A JSON-LD processor must not apply character escaping, must not generate any incorrect triples that result from this, and must emit an error and fail.
5. A JSON-LD processor must apply character escaping, and can only generate correct triples as a result of this.

Notice that JSON-LD Playground currently implements options (2) and (3), for seemingly arbitrary reasons. JSON-LD Playground also (trivially) implements option 1.

My personal ranking of these options, from most to least desired: 5 > 4 > 3 > 2 > 1

Notice that all options are an improvement over the current situation, where the intended behaviour is unknown.