Yes. However, the openrdf upgrade has some potentially non-trivial aspects.
Probably the easiest way to work around this on the server is to modify the ServiceProviderHook class. It registers MIME Types and parsers that are not supplied by openrdf. This is done in a static initialization block.
* Note: These MUST be declared before the forceLoad() call or they will
* be NULL when that method runs.
TURTLE_RDR = new RDFFormat("Turtle-RDR",
Charset.forName("UTF-8"), Arrays.asList("ttlx"), true, false);
NTRIPLES_RDR = new RDFFormat("N-Triples-RDR",
"ntx", false, false);
JSON_RDR = new RDFFormat("SPARQL/JSON", Arrays.asList(
Charset.forName("UTF-8"), Arrays.asList("srj", "json"),
Currently only blazegraph specific extensions are registered here, but registering a MIME Type declaration here, however the declaration listed above (from openrdf 2.7) could be modified as follows:
NTRIPLES = new RDFFormat("N-Triples", Arrays.asList(
and also add the following declaration:
* The N-Triples file format. The file extension .nt is recommend for
* N-Triples documents. The media type is application/n-triples and encoding
* is in UTF-8. See also: N-Triples
public static final RDFFormat NTRIPLES;
Finally, modify the forceLoad() method to also invoke
Please note that the new MIME Type specifies UTF-8 while the original MIME Type specifies ASCII. I suspect that the N-Triples parser also needs to be modified in order to correctly handle UTF-8. This is why we have this as a dependency on
BLZG-1147. Finally, there will be UTF-8 aware N-Triples documents that can not be processed with the older ASCII specification precisely because they rely on Unicode support.
You are welcome to try this patch, and please provide feedback if you do. I suspect that the patch above will not work without also rolling forward to the openrdf 2.8 N-Triples parser. Perhaps that can be achieved as an isolated and backward compatible modification to the openrdf 2.7 version of the N-Triples parser?