N3 writer doesn't exhaustively use prefixes

[gezever]

const N3 = require('n3');
const { DataFactory } = N3;
const { namedNode, quad } = DataFactory;
const writer = new N3.Writer({ prefixes: {   ex1: 'http://example.org/' } });
writer.addQuad(
    namedNode('http://example.org/s1'),
    namedNode('http://example.org/p'),
    namedNode('http://example.org/1')
);
writer.addQuad(quad(
    namedNode('http://example.org/s2'),
    namedNode('http://example.org/p'),
    namedNode('http://example.org/_1')
));
writer.addQuad(quad(
    namedNode('http://example.org/s3'),
    namedNode('http://example.org/p'),
    namedNode('http://example.org/v1.0')
));
writer.end((error, result) => console.log(result));

expected results:

@prefix ex1: <http://example.org/>.

ex1:s1  ex1:p   ex1:1 .
ex1:s2  ex1:p   ex1:_1 .
ex1:s3  ex1:p   ex1:v1.0 .

results:

@prefix ex1: <http://example.org/>.

ex1:s1 ex1:p <http://example.org/1>.
ex1:s2 ex1:p ex1:_1.
ex1:s3 ex1:p <http://example.org/v1.0>.

[TallTed]

@gezever — I suggest that you edit your initial comment, and fence the expected results and results blocks with lines of three backticks (and nothing else), as —

``` 

This will prevent the content of those blocks from being treated as Markdown, as they currently are, making it difficult to see what you meant us to see.

(You should also delete the single backticks currently leading and trailing each block.)

[gezever]

@TallTed
I edited the issue.

[RubenVerborgh]

N3.js does not strive for the shortest form; it adds some prefixes but not exhaustively, and this for performance reasons. That said, in this case, the regex can easily be adjusted, presumably without performance impact.

[flyon]

just bumping this. I have the same question. Long repetative URI's in a project. the resulting .n3 files can be so much easier to read if the subjects and objects would also use prefixes.

Can this be a configurable option?

[flyon]

example

<https://dev.somedomain.net/data/n3-file-store/dynamic-development/history/Campaign/422212468658583/2024/11/2024-11-13-totals/1733857492878.1> a schema:Observation;
    schema:observationAbout <https://dev.somedomain.net/data/Campaign/422212468658583>;
    schema:variableMeasured <https://dev.somedomain.net/data/n3-file-store/dynamic-development/history/Campaign/422212468658583/2024/11/2024-11-13-totals/1733857492878.0>;

vs

_:1733857492878.1 a schema:Observation;
    schema:observationAbout campaigns:422212468658583;
    schema:variableMeasured _:733857492878.0;

[flyon]

I see now why the prefix is not matching. It's because the regex used in N3 doesn't allow for any slashes after the partial IRI that is prefixed.

Ive got long IRI's, and I can shorten them with prefixes, but it would leave some slashes because the common pattern in the IRI's only matches part of the IRI and some slashes remain afterwards.

It's matching my whole IRI when I add \/ at the end of the _prefixRegex.

But @RubenVerborgh do you know if it's against the standard to do so? Should a prefixed IRI not contain any slash? Because I see you're also checking a IRI is prefixed by ensuring there is no slash after : here with the first part of the regex

^(?:${prefixList})[^\/]*$

not matching:

now matching with added \/

[RubenVerborgh]

But @RubenVerborgh do you know if it's against the standard to do so?

It's not, but there could be cases where regex performance gets into exponential territory because of backtracking (typically loads of slashes in URIs).