bring back BSBM

[VladimirAlexiev]

(#79 describes how LinGBM was initially based on BSBM but is now based on LUBM)

There are some benefits to BSBM:

• in BSBM resultset size doesn't increase with dataset size. In large LUBM variants, response time is dominated by the time to return the result. GraphQL results don't have streaming, so this may represent a further problem
• Some databases have been tested on very large BSBM variants
• Other virtualization frameworks (eg ONTOP, Morph-GraphQL) have been tested against BSBM

And some disadvantages:

• BSBM uses named graphs, and I don't know how this could be mapped to GraphQL, and none of the GraphQL-RDF frameworks I know supports named graphs

Neutral:

• BSBM results are often dominated by one query that uses regexp. But LUBM QT5 does the same
• I think BSBM has a relational variant

(Some of the info above is from @vassilmomtchev, Ontotext CTO)

Would it be a lot of effort to support both?

[hartig]

Several of your points here seem to assume that the query templates we had for the BSBM-based version of LinGBM and the query templates we have now for the LUBM-based version of LinGBM resemble the templates from these two SPARQL benchmarks. That's not the case at all! We are using only the datasets.

[VladimirAlexiev]

1. Of course, GraphQL and SPARQL queries will be very different.
   But I assume you reproduced the intent and choke points of each query?
   Otherwise nobody can examine "GraphQL compared to SQL or SPARQL implementations", which would he a pity

2. BTW, if we decide to revive BSBM , where should we look?

[hartig]

1. [...] But I assume you reproduced the intent and choke points of each query? Otherwise nobody can examine "GraphQL compared to SQL or SPARQL implementations", which would he a pity

No. It is not the purpose of the benchmark to be used for comparisons of GraphQL implementations versus SQL or SPARQL implementations. Instead, the benchmark is meant for comparisons of different GraphQL implementations or, more precisely, different approaches to implement a GraphQL server. Of course, some such implementations may be based on translations to SQL or to SPARQL, but that's a different thing than comparing to native SQL or SPARQL implementations of the queries.

Therefore, we did not aim to reproduce the intent and the choke points of the LUBM queries (or the BSBM queries). In contrast, the choke points that we have defined focus on challenges specific to GraphQL implementations. Of course, some of these challenges may also be challenges for SQL or SPARQL implementations, but that is more a by-product rather than a deliberate intention.

2. BTW, if we decide to revive BSBM , where should we look?

https://github.com/LiUGraphQL/LinGBM/releases/tag/v1