Closed TBoonX closed 1 year ago
The problem was introduced recently with https://github.com/apache/jena/issues/1272 and I yet need to forward it to Jena in order to find a solution that would allow for relative base IRIs.
RPT used to use an empty base URL (in conjunction with a reflection hack to inject a custom IRIxResolver) to retain relative IRIs - however the fix for the issue above now rejects ANY relative base IRI in the iri function. Arguably, the IRI function should just use what's given rather then validating it.
Workarounds
iri:asGiven("http://foo")
is the ugly one. The iri namespace is implicitly available any resolve to http://jsa.aksw.org/fn/iri
.BASE <http://example.org/>
)this is fixed now right?
Yes, its fixed. RPT no longer uses an empty base URL hack but instead by default uses an absolute file URL to the current working directory.
/tmp$ rpt integrate 'IRI("http://example/") {}' --out-format csv
# file:///tmp/example/
The rationale for this is to allow for out-of-the-box simple relative references to files such as <myfolder/data.csv> csv:parse ?row
.
The recommendation is to use iri:asGiven
explicitly when needed. Also, with ExprTransformIriToIriAsGiven
we have a transformer that can replace all IRI expressions with iri:asGiven
when desired. This way we can transparently change the semantics of IRI to (a) allow for relative IRIs without having to alter Jena ARQ's standard SPARQL machinery and (b) avoid the expensive IRI validation.
Running the jena-4.6.0 branch rpt, the IRI function does not return something.
IRI("http://example/")
does not create an IRI.Example:
There is no error.