Supporting the RDF.JS interface

[jacoscaz]

As suggested by @elf-pavlik in levelgraph/levelgraph#43 (comment) .

See specs: https://github.com/rdfjs/representation-task-force/blob/master/interface-spec.md

Status:

• Sink interface (.import())
• Source interface (partial .match() without regexp support)
• Store interface (.remove(), .removeMatches(), .deleteGraph())

[jacoscaz]

The following guideline contained in the specs
Given the necessity of methods, plain objects (JSON) cannot be used.
introduces potential performance penalties as it requires transforming all plain objects to class instances.

To preserve access to the native interface, we could make the rdf interface available via some method such as const interface = store.getRdfInterface(); that would return a wrapper around a store instance which would take care of adding the necessary transform streams.

@elf-pavlik we welcome all thoughts and suggestions you might have on this.

[elf-pavlik]

@RubenVerborgh just mentioned on https://gitter.im/rdfjs/Representation-Task-Force?at=58c011fa1465c46a5602aaa1 switching from very minimalistic plain object N3.js used to those interface had minimal performance impact. I believe he can offer much more feedback on that and possibly soon report his experience in more detail on rdfjs/data-model-spec#67

[RubenVerborgh]

@jacoscaz There is no performance penalty associated with "transforming plain objects to class instances": plain objects are also class instances (Object), and all modern JavaScript engines are specifically tailored to excel on objects with the same shape (i.e., all property accesses will be translated to machine code).

The small performance penalty that I took with N3.js, as mentioned by @elf-pavlik, is because N3.js used single-level objects.

On the other hand, the "Given the necessity of methods, plain objects (JSON) cannot be used." is misleading in the RDF/JS spec, as these methods are not required for core data tasks (subject/predicate/object/graph) but rather for equality and conversion.

[jacoscaz]

Thanks to @elf-pavlik and @RubenVerborgh for the excellent brainstorming on Gitter. Strategy:

• implement an additional rdf layer on top of node-quadstore a subclass of QuadStore called RdfStore;
• accept a DataFactory instance as an option of the RdfStore constructor;
• use an instance of AsyncIterator to transform term values to instance of DataFactory.Term and then DataFactory.Quad using N3.js' utils to figure out term types;
• parse DataFactory.Term instances to strings in N3 format before storing quads

[jacoscaz]

Closing this. Will track bugs and enhancements in dedicated issues.