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 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]> 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 == 'lop' > > cocreators ==> created ==> projects > cocreators.age == 29 > }.select(creators.name, 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]>> 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]>> 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]>> 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 > > > >
