N-Quads are written if N-Triples are requested and graph is supplied

[thombohlk]

When using a Writer with format N-Triples and adding quads that include a graph, the writer will output in N-Quads format.

Code (using N3.js version 1.0.4):

var N3 = require('../N3');
const writer = new N3.Writer({ format:'N-Triples' });
writer.addQuad(
  N3.DataFactory.namedNode('http://example.org/cartoons#Tom'),
  N3.DataFactory.namedNode('http://www.w3.org/1999/02/22-rdf-syntax-ns#type'),
  N3.DataFactory.namedNode('http://example.org/cartoons#Cat'),
  N3.DataFactory.namedNode('http://example.org/cartoons#Graph')
);

writer.end((error, result) => console.log(result));

Output:

<http://example.org/cartoons#Tom> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://example.org/cartoons#Cat> <http://example.org/cartoons#Graph> .

I would expect the writer to ignore the graph when I ask for the N-Triples format.

[RubenVerborgh]

That is currently indeed intended behavior; in the sense that the write assumes you are sending the right input for the format.

Not sure what we should do in this case. Silently ignoring the graph might not be best, dropping it isn't great either; just leaves an error in my opinion.

What do you think?

[thombohlk]

I see your point, didn't look at it from that perspective.

Our current use case is one where we want to export a dataset (which can or cannot contain a graph field) in a certain format. From this point of view it would be weird if we would have to adapt the data to the format we want. I would say N3.js should contain the logic which fields are required for which format.

In my opinion the package should output the format that is requested and only that format. It should check whether or not all data for the requested format is available, and throw an error if it is not.

[RubenVerborgh]

Our current use case is one where we want to export a dataset (which can or cannot contain a graph field) in a certain format. From this point of view it would be weird if we would have to adapt the data to the format we want.

That makes sense on the one hand (as N3.js controls the format), but not on the other hand (given that only the source app knows how to deal with the graph).

It should check whether or not all data for the requested format is available, and throw an error if it is not.

Small issue there is that it is streaming, so we cannot check "all" the data, or at least not in advance. We could send an error the moment we encounter invalid data.

[bergos]

@thombohlk maybe you want to try rdf-transform-triple-to-quad. You can feed it also with factory.defaultGraph() to create triples with that transformation.

[jimsmart]

Arguably, if the caller specifically asked for N-Triples, the library should really only output valid N-Triples.

— So perhaps the writer should be able to enforce that?

Just my 2p!

[RubenVerborgh]

That is a possible argument; the other being that valid input should be sent for valid output. N3.js is a very low-level library; part of its speed comes from assuming valid input. My original point of view on this issue is simply that the behavior of sending quads to a triple writer is undefined. (Especially given that defining it correctly and universally is an impossibility.)

[jimsmart]

Sure, understood. I can see both sides.

— Maybe it just needs more/improved documentation? (Certainly no perf impact with this option! 😉)

[RubenVerborgh]

Open to that! Let’s give people some more time to discuss, and then we can pick.

[jimsmart]

Another possibility would be: when the caller asks specifically for N-Triples, swap out the existing code that writes quads, for a function that only writes triples (completely ignoring the graph).

This would not only solve the problem at hand, but wouldn’t affect the performance of writing N-Quads in any noticeable way (adding only an ‘if’ test at construction time) - and it would, theoretically at least, actually improve the performance of N-Triple writing! 👍 (because there would be one less ‘if’ statement in the core looped method that writes the quads/triples)

Edit: I say all that, but it’s possible that the extra indirection may have some negative impact — JavaScript virtual machines can be a little cranky to predict performance on, without measuring.

[RubenVerborgh]

(completely ignoring the graph).

This would not only solve the problem at hand

It wouldn't; who says it is correct to place triples in non-default graphs in the default graph? That is highly context-dependent. (For the same reason, dropping them is not the perfect solution either.)

[jimsmart]

Ok, well that’s your call. I was just offering a solution that I hadn’t seen being discussed yet.

[RubenVerborgh]

Definitely, proposals welcome (I didn't intend to sound negative, apologies if I did). I like the bit about the performance (we do a similar swapping for line mode versus Turtle/N-Quads), but I'm hesitant to make decisions on behalf of the caller.

[RubenVerborgh]

…it could be configurable though, as in { handleQuads: 'ignore' / 'drop' / 'error' }

[jimsmart]

That’s a good idea!