Issues parsing url encoded json-ld `@id`

[fpotier]

Version

v6.1.0

Question

RDFParser.create()
        .base("https://example.com")
        .fromString(
            """
              {
                "@id": "dir/filename%20with%20spaces",
                "@type": "http://schema.org/Dataset"
              }
            """)
        .lang(Lang.JSONLD11)
        .build()
        .toModel();

Produces the following warning:

2026-06-30 14:16:15,527 WARNING [com.apicatalog.jsonld.deseralization.JsonLdToRdf] (executor-thread-1) Non well-formed subject [https://example.com/dir/filename with spaces] has been skipped.

I'm not sure if this a bug or if this behavior is expected. jsonld.org playground doesn't seem to produce any error.

[afs]

Not a complete question!

15:26:26 WARN  JsonLdToRdf     :: Non well-formed subject [https://example.com/dir/filename with spaces] has been skipped.

JsonLdToRdf is part of titanium-jsonld, which Jena uses for JSON-LD processing.

It seems to be converting the %20 while resolving the IRI. Absolute IRIs are not affected.

Decoding happens in java.net.URI.getPath.

(on the 1.7.0 release tag source code; code in the repo has been reshuffled).
UriResolver.resolveAsComponents(... , URI relative)
String componentPath = relative.getPath();

    public String getPath() {
        String decoded = decodedPath;
        if ((decoded == null) && (path != null)) {
            decodedPath = decoded = decode(path);
        }
        return decoded;
    }

Maybe as simple as using relative.getRawPath() but also it may have knock on effects for titanium-jsonld; it might be required by the JSON-LD spec.

RFC 3986 Percent-Encoding Normalization isn't usually done until the application decides it is the right thing to do.

There are other URI.getRaw*.

cc @filip26

[filip26]

It seems to be a bug in the expansion when composing a new URI from a base and a relative part that causes the issue. Absolute percent-encoded URIs are unaffected and pass correctly.

> ld-cli expand
{
  "@context": {
    "@base":"https://example.com/"
   },
   "@id": "dir/filename%20with%20spaces",
   "@type": "http://schema.org/Dataset"
}
[{"@id":"https://example.com/dir/filename with spaces","@type":["http://schema.org/Dataset"]}]

> ld-cli tordf
{
   "@id": "https://example.com/dir/filename%20with%20spaces",
   "@type": "http://schema.org/Dataset"
}
<https://example.com/dir/filename%20with%20spaces> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://schema.org/Dataset> .

[fpotier]

Not a complete question!

Apologies, I wasn't entirely sure if it was a bug or not, and forgot to ask my question.

I stumbled upon URL validation policy and was wondering what are the implications in jena? For my application it didn't seem to cause any issue (only warnings) but I would like to know if there is a list of known operations that would break with invalid IRIs.

Should I create an issue in the titanium-jsonld repo?

[afs]

@fpotier - when the warning message says "skipped" it means no output. It won't fail but ti won't have all triples,

Titanium-java does all the work parsing JSON-LD (thank you @filip26!)

Jena isn't part of the URL validation policy. If a relative URI were to be returned, they would be resolved against the base Jena gave iniitially, not the @base. Jena isn't aware of any base URI set within a JSON-LD document. Jena passes in the initial base setting to Titanium but that's all.

After parsing, Jena converts the output from Titanium stream of quads to Jena triples etc. Jena is receiving URIs from Titanium after they have been resolved (any still relative URI would be resolved by Jena but that is not happening here).

@filip26 - is there likely to be a 1.7.1 or is it now the 2.x line?

I don't think JSON-LD says anything special about %-encoded URIs.
The fix looks like it is to change relative.getPath() to relative.getRawPath().

The complete list is getRawUserInfo, getRawPath, getRawQuery, getRawFragment, getRawAuthority, and getRawSchemeSpecificPart.

[filip26]

@afs Yes, the bug fix seems straightforward, but there won't be any more releases in the 1.x.x line, it will have to wait for 2.x.x.

@fpotier If the validation policy is set to UriValidationPolicy.SchemeOnly, then it should relax this restriction. It won't be dropped, but an "incorrectly" encoded IRI would be produced. See:

https://github.com/filip26/titanium-json-ld/blob/30cecf015ab43bc7182a63fc54139e1134839345/src/main/java/com/apicatalog/jsonld/tordf/JsonLdToQuads.java#L146

[fpotier]

@afs Yes, the bug fix seems straightforward, but there won't be any more releases in the 1.x.x line, it will have to wait for 2.x.x.

@fpotier If the validation policy is set to UriValidationPolicy.SchemeOnly, then it should relax this restriction. It won't be dropped, but an "incorrectly" encoded IRI would be produced. See:

https://github.com/filip26/titanium-json-ld/blob/30cecf015ab43bc7182a63fc54139e1134839345/src/main/java/com/apicatalog/jsonld/tordf/JsonLdToQuads.java#L146

Thanks for your answers.

Sorry my previous comment probably wasn't clear but I switched to UriValidationPolicy.SchemeOnly and tested my use-case which seem to work just fine.
I just wondered if there was any known pitfalls in jena when the graph contains non valid IRIs.

[afs]

I just wondered if there was any known pitfalls in jena when the graph contains non valid IRIs.

Depend on how bad invalid they are. Raw newlines - real problems, relative URIs often work but may cause stability problme in published data.

Nothing is guaranteed especially for output that isn't JSON-LD. RDF/XML must be able to split properties into qnames. In Turtle/TriG, there is checking and plain <...> is used if needed but some code reading that may complain about bad URIs.