Question: Expressing paths in TypeQL

TypeQL
1

Hi all, does TypeQL have a path language as,f or example in SPARQL or in CYPHER ? Can you express paths of variable length? I couldn’t find this in the documentation. If not, are there alternatives to express similar queries, e.g. is it necessary to write rules to propagate properties through?

1 Like
2

Rules are the only option you have in 2.x versions of TypeQL.
The upcoming 3.0 release is set to have functions, and you could pass the length as an argument.

You can work this into TypeQL 2.x as well, with a bit of effort. What kind of lengths are you thinking about?

I have an example of a rules to this in a previous discussion on discord. We tag each path (n-hop-parentship) with the number of hops (n-hops)

define

# Base-case: Infer a nhp for each parentship
rule base-nhp-rel:
when {
    (parent:$x, child: $y) isa! parentship;
} then {
    (parent: $x, child:$y) isa n-hop-parentship;
};

# Attach the attribute to the inferred nhp
rule base-nhp-hops:
when {
    (parent:$x, child: $y) isa! parentship;
    $nhp (parent: $x, child:$y) isa! n-hop-parentship;
} then {
    $nhp has n-hops 1;
};

# Standard recursive case for transitivity. We do the depth-check to prevent infinite recursion
rule rec-nhp-rel:
when {
    $nhp (parent: $x, child:$y) isa! n-hop-parentship, has n-hops $d;
    (parent:$y, child: $z) isa! parentship;
    $d < 100; # Keep a hard-limit on n-hops in case of infinite recursion
} then {
    (parent: $x, child:$z) isa n-hop-parentship;
};

# As before, attach the depth to the newly inferred nhp. 
rule rec-nhp-hops:
when {
    # Same condition as the previous rule + The conclusion and an extra line to increment $d
    (parent: $x, child:$y) isa! n-hop-parentship, has n-hops $d;
    (parent:$y, child: $z) isa! parentship;
    $d < 100; # Keep a hard-limit on n-hops in case of infinite recursion

    $nhp (parent: $x, child:$z) isa! n-hop-parentship;
    ?d1 = $d + 1;
} then {
    $nhp has n-hops ?d1;
};
3

Thank you for your detailed answer @krishnan. I understand that there is no equivalent to SPARQLs path language at the moment, and that typedb proposes rules instead to propagate specific properties through the graph. But that seems to be difficult to do adhoc at query time. Without having much practical experience with the rule-based workaround, it sounds quite limiting if you have a large highly connected graph and looking to explore longer paths in it. Are there any plans to add a more elaborate path language to typedb as well? Are there any fundamental reasons for not providing it?

4

As an addendum: I’m specifically interested in equivalents for SPARQLs * or + operators.

5

Hi, path navigation will change significantly in TypeDB 3.0 with the introduction of functions. This should provide a more intuitive may to navigate and return paths as query results, but will still be as “mechanical” as rules in terms of how the navigation is described.

There is no fundamental reason that specialised path traversal syntax could not be introduced into TypeQL. In fact, it is one of our key priorities. It is unlikely to be included in the 3.0 release, but will be included in a following version.

1 Like
6

Thanks @jameswhiteside . I guess this means we shouldn’t count on it medium term. But really looking forward to seeing it! TypeDB seems like a great product in our tests but we probably need this particular feature.

7

No worries. Please let us know how you get on, and if there are any other features you’d like to see!

1 Like
8

Another change coming in 3.0 is that you can define ad-hoc functions at query-time. You’ll still need to define the path functions, but can do so at query time.

Unless we find a more general solution to make path queries more ergonomic (templated standard library functions maybe?), it’s a common enough use-case to be added to the core-language

1 Like