traqula and rdfjs - is there a place for a convertor

[ailintom]

Thank you very much for your work on traqula. I have a rather general question related to the migration from SparqlJS to Traqula.

One of the best features of SparqlJS was that it was part of the rdfjs infrastructure natively supporting rdfjs Terms, such as NamedNode, Variable, Literal, etc. This allowed directly plugging SparqlJS as a sparql generator into a project using other rdfjs-compatible libraries, including rdf-ext.

Traqula AST uses a different convention for these entities. Hence, there is a need to convert rdfjs terms to traqula terms to for example pass a literal from an rdf-ext dataset quad directly to a traqula query generator. What would be a suitable place in the traqula architecture for such a convertor utility for traqula terms <=> rdf/js terms?

[jitsedesmet]

Hey @ailintom
Thank you for the feedback.
I think such a function would be an excellent feature.
Traqula could house a function converting Term to rdfjs.Term and vice versa as part of the utils in both packages/rules-sparql-1-1/lib/utils.ts and packages/rules-sparql-1-2/lib/utils.ts. (the file for 1.2 will need to be created)

In case the whole AST tree needs to be transformed, one could use the AstTransformer provided by those same packages. (Although getting the types to match in this case would be less trivial).

You are free to submit a PR if you want :)

[jitsedesmet]

FYI: the algebra structure of Traqula (so the equivalent of SPARQLAlgebra.js) does use rdfjs.
So maybe using the algebra might help as well.

Can I ask what your current use case is that you use the AST (instead of algebra) and depend on rdfjs?
(just to get a mental Traqula's users and their needs)

[ailintom]

@jitsedesmet thanks, will try to make a PR.
I am building a TypeScript framework for making rdf-based database user interfaces with a SPARQL backend. It should allow building custom query forms, defined in the instances as JSON-like structures, and then each search element in the custom query form has a path property, which is defined as a fragment of the AST, so that a SPARQL query is generated from the combination of all the query form elements (a form-driven query builder). This allows querying the data in a rather flexible way, when for example the user enters a name that should match either the last of the first name of the author or the editor, and this whole flexibility is defined in a modular way through JSON (that's where the AST fragments come into play: some come from the path property, some from the value of the elements which are custom components, returning rdf/js literals and namednodes as values). I implemented this using sparql.js, but now it is discontinued and I should probably migrate. I find the Algebra representation, which assumes a complete query structure, less suitable for modular UI <-> backend operations, where single AST elements come from different UI components, but I may give it another thought.

[jitsedesmet]

I see. As a general rule of thumb, if you do not care about how the generated query looks, it's better to use the algebra since it provides you with a higher level abstraction then the AST.
If you do care about what the generated query looks like and wan to control that very precisely, use the AST.

That's also why Traqula has it's own structure for terms. For example when you have a NamedNode, the AST will allow you to say precisely whether it is generated using a prefix, or as a full iri (<> syntax).