[Feature request] RDF-JS compliance

[pietercolpaert]

RDF-JS is an initiative to make javascript libraries for working with RDF interoperable by working on a common JS-based data model: https://rdf.js.org/data-model-spec/

This is well-adopted, for example by the Comunica ecosystem, and allows us to pipe triples/quads from one JS library into another.

I propose a compatibility layer in which you can export an async generator of RDFJS Quads as they get generated

[pietercolpaert]

Update: there’s now a return.js script that helps to convert TRiG to N3 and back https://github.com/eyereasoner/eyeling/blob/main/return.js

That could be the interface as well for the RDF-JS readable, if someone would like to PR that

[rubensworks]

Once this is supported, we could investigate if it would be relevant to migrate https://github.com/comunica/comunica-feature-reasoning/ to eyeling.

[josd]

Update: there’s now a return.js script that helps to convert TRiG to N3 and back https://github.com/eyereasoner/eyeling/blob/main/return.js

It is now called https://github.com/eyereasoner/eyeling/blob/main/tools/n3gen.js

Usage:
  n3gen <file.ttl|file.trig|file.srl>

Converts RDF 1.2 Turtle/TriG and SHACL 1.2 Rules to N3.

Examples:
  n3gen file.ttl > file.n3
  n3gen file.trig > file.n3
  n3gen file.srl > file.n3

[robsyc]

Experimenting with the library I found two things a bit awkward related to this issue:

1. The input, both facts and rules, are one N3 string. Right now I serialise my rdfjs dataset to n-triples and append it to the N3 rules string
2. The serialised output uses prefixes but lacks their definitions requiring manual binding of those declared in prelude.js

---

As a middle ground, could it be possible for the reason (or reasonStream) method to split its input into rules and data (facts)?

The data could be provided as a standard RDFJS stream, while the rules remain in N3. Looking at lib/engine.js, the core forwardChain function already accepts facts and frules/brules independently. If we had a small adapter to translate incoming RDFJS Quads into Eyeling's internal Triple / Term classes (like Iri, Literal, Blank in lib/prelude.js), the engine could initialize its facts from the stream.

For the output, the onDerived callback in reasonStream could then map the newly derived Triples back into RDFJS Quads and pipe them to an RDFJS-compatible readable stream.

Is this a feasible architectural direction, rather than requiring the rules and data to be combined in the exact same N3 input string?

[pietercolpaert]

I think splitting it would be very artificial. I think a nice approach could be optionally “adding a quad stream to the context” kind of functionality. @josd what do you think?

[josd]

Splitting is indeed artificial. It is not uncommon that people use a rule like true => { triples }. to assert those triples.

A while ago I was adding quads to the eye reasoner, and that turned out to be a big mistake. The eyeling reasoner is designed to work with triples, where graph terms can be used in any position.

As mentioned earlier, there is tools/n3gen to convert RDF 1.1 quads and RDF 1.2 triple terms into N3.

[giacomociti]

I understand splitting data and rules is artificial, but I often apply the same fixed set of rules to input triples and, besides RDFJS interoperability, I wonder if it's possible to avoid parsing the rules again and again.

Another options I see is, like eye, to accept multiple inputs