Parse error when query result contains quads (named graphs) in the output

[opl-]

import { n3reasoner } from 'eyereasoner';

await n3reasoner(
	'<http://dbpedia.org/resource/Belgium> <http://dbpedia.org/ontology/PopulatedPlace/areaTotal> "30528.189856530433"^^<http://dbpedia.org/datatype/squareKilometre> <http://example.com/graph>.',
	'{ ?s ?p ?o ?g } => { ?s ?p ?o ?g }.',
	{
		outputType: 'quads',
	},
);

Throws the following error:

Error: Error while parsing query result: [Error: Expected punctuation to follow ""30528.189856530433"^^http://dbpedia.org/datatype/squareKilometre" on line 1.]. Query result: [<http://dbpedia.org/resource/Belgium> <http://dbpedia.org/ontology/PopulatedPlace/areaTotal> "30528.189856530433"^^<http://dbpedia.org/datatype/squareKilometre> <http://example.com/graph>.

This appears to be caused by the Parser from the n3 package throwing when a graph name is present in the output. I'm not sure if this is a parser bug, eye-js passing the wrong format when configuring the parser, or EYE returning data in an invalid format.

[jeswr]

It'll be that we are parsing the query result as text/n3 format using the N3 parser - and the N3 Parser does not accept named graphs for this content type.

@josd How do detect what content type the output of eye is?

[opl-]

For now my workaround is manually parsing the data manually using outputType: 'string' and new Parser({ format: 'quads' }) and passing --no-numerals --no-qnames as extra EYE arguments (by directly modifying transformers.js in node_modules). Obviously not ideal in the long run.

[josd]

@josd How do detect what content type the output of eye is?

You will have to check what you give it and what you ask it.
If you give quads and ask for quads you will get quads (and yes, we still call that n3 because N3 ought to be and extension of rdf).
If you give it rules using log:outputString you can get any content type (see for instance https://github.com/eyereasoner/eye/tree/master/reasoning/ttl-to-rdfa)

[jeswr]

and passing --no-numerals --no-qnames as extra EYE arguments

I'd accept a PR which adds an eyeArgs option to

eye-js/lib/transformers.ts

Line 12 in 6adf240

export type ICoreQueryOptions = {

which would be a list of extra arguments to pass in.

If you give quads and ask for quads you will get quads (and yes, we still call that n3 because N3 ought to be and extension of rdf).

Does the current N3 (CG) spec allow for n-quads - i.e. is it N3.js or eye that is not spec compliant here?

[josd]

Does the current N3 (CG) spec allow for n-quads - i.e. is it N3.js or eye that is not spec compliant here?

eye

[josd]

So eye is not anymore just n3, we now even run everything we did so far in n3 using just SPARQL CONSTRUCT WHERE https://github.com/eyereasoner/eye/tree/master/let-sparql#eyelet-sparql

[opl-]

A parsing error is also thrown if the result contains a literal as a quad subject. Let me know if I should open a separate issue for this.

import { n3reasoner } from 'eyereasoner';

await n3reasoner(
	'"abc" <http://www.w3.org/2002/07/owl#sameAs> "abc".',
	'{ ?s ?p ?o } => { ?s ?p ?o }.',
	{
		outputType: 'quads',
	},
);

Throws Error: Error while parsing query result: [Error: Expected entity but got literal on line 1.]. Query result: ["abc" <http://www.w3.org/2002/07/owl#sameAs> "abc".

[jeswr]

A parsing error is also thrown if the result contains a literal as a quad subject.

That's a known N3.js bug rdfjs/N3.js#328

[jeswr]

Triage update (agent-assisted, for @jeswr): reproduced exactly on eyereasoner@21.1.10. Root cause is in parse() (lib/transformers.ts:119): results are parsed with Parser({ format: 'text/n3' }), and N3.js disables named-graph/4th-term support in n3 mode, so any quad in the output throws. Verified fix: when the text/n3 parse throws, retry with a default-format new Parser() (permissive mode accepts N-Quads-style statements); this parses the quad output with the graph term preserved, keeps rule/formula output on the existing n3 path, and still rejects garbage. Note simply forcing _supportsNamedGraphs = true on the n3-mode parser does NOT work — it breaks {...} => {...} parsing. The literal-as-subject sub-case remains an upstream N3.js bug (rdfjs/N3.js#328). A draft PR with this fallback plus a regression test from this issue's snippet is being prepared; the eyeArgs option suggested above would be a separate enhancement PR.

[jeswr]

🎉 This issue has been resolved in version 21.1.11 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release
• v21.1.11

Your semantic-release bot 📦🚀