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
>
