Tarql outputs invalid RDF with URIs containing spaces

I have encountered several cases where I build a URI using code like:

bind(uri(concat("http://example.com/id/", ?ID)) as ?uri)

Where in the sample data all the values in ID column looked like usable identifiers. Only when the code is used to transform a complete dataset, it transpires that some of the values contain spaces.

In such cases, Tarql will happily output RDF where the spaces are not encoded in the URI, therefore invalid e.g. http://example.com/id/some text.

The issue is only discovered when some downstream tooling throws an error.

Preferably Tarql should throw an error when serializing the RDF so problems are discovered earlier.

Workaround: Always use ENCODE_FOR_URI function to properly encode any non-uri friendly characters.

[cygri]

That would be one reasonable behaviour. The advantage of treating it as an error would be that it would double as a way of checking whether a string is a valid IRI: isIRI(IRI(?x))

[cygri]

This is a known issue with Jena. The URI/IRI functions don’t do syntax checks. encode_for_URI is indeed the best workaround currently available. SPARQL has no concept of “throwing an error” during query execution, so we can’t write a query the aborts with an error if we detect a problem.

If this were fixed in Jena, the fix would probably be that ?uri ends up being unbound. That makes sense with the way SPARQL expression evaluation works, but would arguably be even worse for Tarql because with an unbound ?uri, the CONSTRUCT template will simply not produce any triples where ?uri is used. So, the result would be a valid RDF file, but with some triples silently missing.

Maybe Tarql needs a tarql:assert(...) function that aborts the entire query execution if the argument is false or unbound. Then one could do tarql:assert(isIRI(?uri)) or simply tarql:assert(?uri) to force execution to fail early.