Re: Groovy as knowledge graph

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
> >      >
> >
>
>