WOQL Readable Issue?

‘Seems that the WOQL is not as human readable compare to other graph query languages. I understand that WOQL’s design is base on JSON but I think there’s lot of avantage of having a query language that is more human readable and similar to the major players in the market (easier for users to switch to us). Also in a user point of view, have a easy to understand query language will give a bigger drive to try the new database technology. What do you think?’

   new WOQL()
  .and(new WOQL.not().abstract()).

Or to put it another way, we agree - we’re currently working on the tinkerpop-like programmatic interface which works as above and greatly simplifies the writing of queries.

We should stress that the first open source release that we put out was focused on getting a fully working version out the door and having it be correct and work properly.

The next release (mid-November) will have a bunch of usability improvements including the WOQL programmatic library that works as above. We prefer that style of serialisation to the old-school sql version of simple strings with no structure. The most important stakeholder is the developer - making it easy for developers to read and write queries is the key - json is not too bad for sending over the wire - its nested structure captures nested query clauses well but not so great for terseness and readability. old-school sql queries are also painful for coders to write - they work ok on the command line but require you to string concatenate in code which leads to untold errors and injection attacks. We think the tinkerpop like serialisation style above is the best compromise. Easy for coders to write and read.

From the point of view of non-coder end-users, we have a drag and drop model building tool and a full query-building UI to come - that’s where we will optimise for end-user usability. Otherwise, we will be making it as easy as possible for regular coders to integrate into existing workflows - so the simple, programmatic like interfaces like the above are what we will target - in Python we want to extend this to have features like:


Which will do all the marshalling between query, results and frames for the user.

I do think that WOQL.js is way more readable. If I understand correctly, the WOQL JSON is more meant as a data inter-exchange format than the part that the user will write. Is that correct?

Yes, now we have WOQL.js and WOQLpy. Javascript client and Python client.

Is there a reason that this is only ‘tinkerpop-like’ and not Tinkerpop-compatible? It would be great if TerminusDB aligned with existing (de-facto) standards regarding this, especially since WOQL is your own custom query language (and still has to prove itself)?

1 Like

We have gone a slightly different direction since this was posted. The previous version of TerminusDB used JSON as an interchange for WOQL ASTs. The new version (2.0) will use JSON-LD, which is a serialisation of RDF. This enables us to store WOQL queries in a database and provides a schema documentation of the WOQL query language.

We are keen on W3C standards where possible and use RDF and OWL. I agree that WOQL has to prove itself - but it is a type of datalog which has a solid history in query. We have JS and python clients, which should make it more familiar to a broad range of users.

That said, everything is very much on the table and we’ll consider the suggestion!

Thank you, it sounds wonderful. Regarding Tinkerpop javascript-wise do you intend to align? It would be great to see you on the lists in this page: http://tinkerpop.apache.org/

But maybe that is not feasible as there are too many incompatibilities…

1 Like