I think that could be a way to experiment a bit with what might work in terms of match() and the future direction it has for TinkerPop 4.x.
I can't help wondering if there are other improvements Groovy users might want to Gremlin itself within the context of that language. We had some early interest from Gremlin/Groovy users on this thread. I'd be curious if there was anything they were looking for that would make things easier for them. On Tue, Aug 18, 2026 at 1:51 PM Jochen Theodorou <[email protected]> wrote: > hi, > > sorry for replying so late. I had to give some priority to some reviews. > Anyway... I think the basic style of the DSL is promising, but then I > would switch from Gremlin to GQL as primary target for TinkerPop. I > think there could still be a Gremlin variant, maybe even a backend only > is enough. > > Since this is not ready code and needs still development I would then > create a new repository for this under github.com/blackdrag and make it > public so people can contribute if they want and hopefully will. There > we would develop the DSL core plus specific backends for for example > GQL. Later, when the core shows signs of becoming more stable I would > plan to move the core-DSL module to Groovy (retaining the commit history > of course). The specific backends would maybe stay. The project would > initially use github issues for issue tracking and a jitpack structure > for releases. > > What do you think? > > bye Jochen > > On 8/14/26 00:12, Stephen Mallette wrote: > > added back dev > > > > I see familiar names popping up on this thread. :) > > > > I like that you used a motif style syntax for edge direction. I've often > > thought gremlin-groovy could have had something like that. Folks seem to > > like to work with symbols that way when specifying graph patterns. You > > started with Gremlin's match() step, but TinkerPop is changing how that > > works going forward. You could read more about that here: > > > > https://stephen.genoprime.com/snippet/2026/07/27/snippet-26.html > > <https://stephen.genoprime.com/snippet/2026/07/27/snippet-26.html> > > > > but basically, we're focusing match() on declarative query strings to > > offer cross query language support for GQL (or any declarative query > > language really - eg. openCypher). Of course, that match syntax may yet > > be interesting even in that context as it could produce the GQL query > > string somehow. I'll think about it some more. > > > > On Tue, Aug 11, 2026 at 5:29 PM Jochen Theodorou <[email protected] > > <mailto:[email protected]>> wrote: > > > > I think going for Gremlin actually moves away from the RDF idea a > bit. > > If I want a base for both I would have to do something that does > > neither > > look like Gremlin, nor like SPARQL... but I like the Spock idea. Not > > because of syntax, but because it combines imperative and declarative > > elements. > > > > So let me try to make a wild suggestion and you guys tell me if you > > think that goes in the right direction. Also this is no final form, > it > > is more to suggest something. > > > > Based on this Gremlin: > > g.V().match( > > > __.as('creators').out('created').has('name','lop').as('projects'), > > __.as('projects').in('created').has('age',29).as('cocreators') > > ).select('creators','cocreators').by('name') > > > > I was thinking of > > > > gremlin(g) { > > match(creators, cocreators) { > > creators ==> created ==> projects > > projects.name <http://projects.name> == 'lop' > > > > cocreators ==> created ==> projects > > cocreators.age == 29 > > }.select(creators.name <http://creators.name>, cocreators.name > > <http://cocreators.name>) > > } > > > > Such a DSL would be far from just some syntactic sugar though. After > > __.as('creators').out('created').has('name','lop').as('projects') we > > end > > up in the node that has been labeled projects. To continue from here > > and > > get the cocreators we actually need to go backwards again, is why we > > start with the node and go through in back to a node that we then > call > > cocreators. The DSL would infer that. This also means going a very > big > > step away from imperative to more declarative. But that is a key > > part in > > Spock as well. > > > > I can imagine such DSL to have a gremlin specialization and a SPARQL > > one, with a common core and each implementation may add something for > > its flavor, while the core is the biggest part and stays the same. > Also > > I could imagine having a super simple graph as base construct for > using > > the DSL without Jena or TinkerPop. That DSL could then define a > > reference implementation and Gremlin and SPARQL build on top. > > > > Not sure yet about the mapping part. > > > > Please write what you think about it. Or simply if you have other > > ideas. > > Or if you expected something totally different. > > > > bye Jochen > > > > On 8/11/26 16:57, Christopher Smith wrote: > > > Count me in. I have developed some in-house extension methods and > > > library facilities in this area, particularly around entity > > mapping, and > > > have had the idea of trying to clean them up for publication. > > > > > > Christopher Smith > > > > > > On Tue, Aug 11, 2026, 08:23 Matt Burgess <[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>>> > wrote: > > > > > > I use Gremlin and Groovy often so would love to discuss that > > angle > > > further, especially adding some more Groovy syntactic sugar > > to the > > > Gremlin DSL to make the queries super-clear, like Spock does > for > > > BDD/TDD. > > > > > > Regards, > > > Matt > > > > > > On Tue, Aug 11, 2026 at 9:15 AM Stephen Mallette > > > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > > > Hello, With knowledge graphs in mind, Apache TinkerPop > > has long > > > offered gremlin-groovy which contains, among other > things, a > > > sugar syntax that makes the Gremlin graph query language > > a bit > > > more Groovy. I've always thought it might benefit from > > experts > > > from the Groovy community who could build upon that > > foundation. > > > I think that some fast impact to making Groovy more > knowledge > > > graph ready could be some improvements there. Not RDF > > obviously, > > > but property graphs are riding in that same space in many > > ways. > > > Happy to talk about that angle further if there's > > interest from > > > anyone. > > > > > > On Sat, Aug 8, 2026 at 4:52 PM Jochen Theodorou > > > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > > > Hi all, > > > > > > I am recently learning a lot about knowledge graphs > and > > > started to > > > wonder if we should make a Groovy module for that. > > > > > > The idea(s): > > > * use Apache Jena as base > > > * provide one or more DSLs to allow semantic mapping > > from an > > > object > > > structure to an RDF style structure (RDF, RDFS, OWL) > > > * Use SPARQL/another Groovy DSL to query the > > knowledge base, > > > but also > > > allow building dynamic queries. Not sure that GINQ > > works for > > > this part, > > > maybe in some cases, but I certainly would want to > allow > > > similar features. > > > * provide semantic mapping DSL to map from query > > result to > > > object structure. > > > > > > but it makes only sense if there is interest in this > > by more > > > than just > > > myself. > > > > > > Also I am not sure about the time frame for such a > > project > > > > > > bye Jochen > > > > > > >
