A mix of issues and questions

[rat10]

Thank you for your work on Traqula! It looks very promising, and I'm especially curious to explore the round tripping feature. I'd like to use Traqula in a project where I need to parse many queries on one specific quad store. I tested Traqula with a few hundred queries, and 85% of them pass without issues. The issues I ran into are varied. Some of them are idiosyncracies of the quad store the queries are run against, some might be missing features, one seems to be a small bug. In any case I'd be glad to get your opinion on how to best tackle them. I'm trying to assess how much effort it will take to create a patch that fixes all of them.

1. Validation errors
   In some cases Traqula is able to parse a query but rejects it for semantic reasons. There seems to exist an option to ignore validation errors and return a JSON object anyway via the skipValidation argument, but I can't get it to work.

try {
  parser.parse(sparql, args.skipValidation ? { skipValidation: true } : undefined);
  ok++;
  if (!args.quiet && ok % 1000 === 0) {
    console.log(`Parsed ${ok} ok...`);
  }
} catch (e) {
  // ...
}

It seems like in @traqula/rules-sparql-1-1/dist/esm/lib/grammar/queryUnit.js, the selectQuery rule calls queryIsGood(ret); unconditionally, without if (!C.skipValidation) guard. Am I doing something wrong?

2. Variables starting with a digit
   It seems like Traqula doesn't accept variables that start with a digit. IIIUC those are legal according to spec. Am I wrong, and/or is this how you want it to be? In any case a patch should be reasonably easy.

3. Missing WHERE keyword in nested SELECT statements
   Again it seems like this is legal in SPARQL, but not supported in Traqula. And again it seems quite easy to patch. What's your take?

4. Jena textMatch
   Some queries use textMatch syntax, an ARQ/Jena text search function / “magic property” that is not part of SPARQL. Do you have ideas on how to support this, or even plans to do so?

5. Property path repetition
   Some queries use {n} syntax for property path expressions. IIUC this idiom is also used in other RDF stores. Do you have an idea of how it could be supported in Traqula, or even plans to do so?

6. LATERAL
   Some queries use lateral { select ... }. I guess I'm on my own with that one. [EDIT or maybe not?]

7. Aggregate shorthand in SELECT
   Some queries use count(*) without defining a variable name, i.e. omitting the AS ?count part. That is non-standard syntactic sugar and I don't assume you have any interest in supporting it. Should be easy to patch locally.

I'd be glad to get your opinions on these issues before I start to work on them.

[jitsedesmet]

Hi @rat10 thank you for reaching out and expressing your interest.

1. Very good point indeed. I must admit, I forgot about implementing these guards. The Traqula's API is partly copied from SPARQL.JS. That being said, Traqula should definitely be updated to contain these guards. I cannot give a timeline at this point since I am in/out of office for two more weeks. But after that, I suspect this could be resolved quickly.

2. They should indeed be allowed to start with a digit. And at least in my test suite it looks like this is supported. Can you provide some more info here as to what fails?

3. Here again these tests are present in my test suite (optional-subquiery.sparql and subquery.sparql) so I would expect this works? We can look at the issues you have together.

4. Now we come to another interesting part of Traqula. We created Traqula to be a modular parser, meaning you can add, remove and replace grammar rules at will using our builder-based API. A detailed guide on this is still in the making, but you could already take a look at the vision paper for Traqula and our current implementation for both the SPARQL 1.2 and SPARQL 1.1 + ADJUST parsers. Both of these parsers are simple modifications ontop of our SPARQL 1.1 parser. Since we have this modularity, we need to carefully think on what kind of parsers we (Traqula repo) want to provide (I expect this will stay in line with what Comunica needs). Interesting Extensions #27 is a running issue for this.

5. I have not seen this extension before, but If you provide a link I can add it to Interesting Extensions #27. The same modularity can help you here, though.

6. Aha, lateral, with this one, you are on luck because Comunica has interest in supporting this. An implementation of this already exists on a separate branch of Comunica (Feature/lateral prototype jitsedesmet/comunica#11) Note that I am still updating it to target the updated main branch.

7. One again the modularity can help you.

I am personally delighted the modularity feature can help you in many cases. :D
I will edit this message when the lateral branch gets updated.

EDIT: the lateral branch I spoke of can be found here

[rat10]

Hi @jitsedesmet thank you for your detailed response!

1. Good, I'll wait for you.
2. I will have to check if maybe multiple failures coincided.
3. Same here.
4. I'll check the paper out. Maybe ping me when the detailed guide is available. I'm looking forward to learn how you tackled modularity.
5. It's a feature that was at some point in time a candidate to be included in SPARQL, but ultimately wasn't. I'm not sure if any other store implements it. Probably not interesting enough for for Traqula to support.
6. Fine! I'll check how far my data is compliant with your implementation (I guess there are different dialects of LATERAL)
7. Yep, that should be a good place to start getting my hands dirty.

Thanks again for your response! I expect it will take me a few weeks before I can get back to this. I will then update this issue.

[jitsedesmet]

The latest addition to Comunica's documentation already goes into closer detail on Traqula's modular design from Comunica's perspective.