Discussion Forum

Rule of Transitive Multiple Relations

Dear all,
Considering this scenario:

Here are many entities, and the relationships of them are:

A -> B1 -> Z
A -> B2 -> C2 -> Z
A -> B3 -> C3 -> D3 -> Z

From A to Z, there are many different relation ways and different entities among relation.

Now I have one A instance a_inst, I want to retrieve all Z instance which transitive related to a_inst.

I believe the rule below can only transfer one relationship, which means it only works for A->B1->Z.

when {
($x, $y) isa dependency;
($y, $z) isa dependency;
} then {
($x, $z) isa transitive-dependency;
};

If so, maybe I should define rule-2 to express A->B2->C2->Z, and so on.

Is there a way that one rule of transitive multiple relations?

Thanks in advance!

Hi dear,

Is there any solution about this problem?

I found a way, but it seems not good.

define
rule multi-dependency-transitive-rule:
when {
($x, $y) isa DEPENDENCY;
($y, $z) isa DEPENDENCY;
} then {
(from:$x, to:$z) isa DEPENDENCY_TRANSITIVE;
};

which DEPENDENCY and DEPENDENCY_TRNASITIVE are

define
DEPENDENCY sub relation, abstract;
DEPENDENCY_TRANSITIVE sub DEPENDENCY;

After rule has been define,

I can just query like this. It returns answers very quickly.

match
($x, $y) isa DENENDENCY_TRANSITIVE;
$x iid 0x966e8002800000000000006c3;
get $y;
limit 10;

In my scenario, I need to find out all instance of $y that the entity I specify.
But once I specify the $y, it takes long time and reports error. Like

match
($x, $y) isa DENENDENCY_TRANSITIVE;
$x iid 0x966e8002800000000000006c3;
$y isa X86VM;
get $y;
limit 10;

Would someone help me? Thanks!

Hi there -

for your modeling question, we’d normally just write two rules:

when {
  (from: $x, to: $y) isa dependency;
  (from: $y, to: $z) isa dependency;
} then {
  (from: $x, to: $z) isa transitive-dependency;
};

and

when {
  (from: $x, to: $y) isa transitive-dependency;
  (from: $y, to: $z) isa transitive-dependency;
} then {
  (from: $x, to: $z) isa transitive-dependency;
};

and make these unrelated types:

define
  dependency sub relation, relates to, relates from;
  transitive-dependency sub relation, relates to, relates from;

your way isn’t actually such a bad idea either! But then every query for dependency can also trigger rules for transitive dependency, which you may or may not want to be able to separate!

Regarding the last issue, about it getting slow: I suspect this is a known reasoning planning issue that we want to resolve. Basically the issue is that

match
($x, $y) isa DENENDENCY_TRANSITIVE;
$x iid 0x966e8002800000000000006c3;    [available starting point]
get $y;
limit 10;

has only 1 starting point, which happens to be a very good and specific starting point and leads to the answer very quickly, whereas:

match
($x, $y) isa DENENDENCY_TRANSITIVE;
$x iid 0x966e8002800000000000006c3;     [available starting point, good!]
$y isa X86VM;                           [available starting point, bad!]
get $y;
limit 10;

in this case it can choose to search from two places and probably picks the isa rather than the iid.

is there any other kind of identifier you can use to pin x86VM instead of an isa for the time being??

Lastly, I would generally say it’s good practice to write explicit roles (from: $x, to: $y) isa DEPENDENCY; because it reduces the search space of the queries.

I’m looking forward to fixing the issue.
Thank you for your advise, very much!

Hi, I noticed that new version 2.2 has been released a few days ago and it fixes some memory issues.
And, has the reasoning issue been resloved?

I’ve tested the version 2.2 on the above scenario, but it seems like before.
Thanks!

Hi -

yes, it is not resolved yet. What kind of timeline are you working on/is this a blocker for you?

Cheers
Josh

We are now in functional testing about TypeDB on our project. And this reasoning function is the key function to our project.
It will be great beneficial to us if this function works. :grinning_face_with_smiling_eyes:
Thank you very much!

Hi there -
I just realised that you can work try something to around this issue for now:

instead of running the more specific query (which is slow when it picks the bad plan):

match
($x, $y) isa DENENDENCY_TRANSITIVE;
$x iid 0x966e8002800000000000006c3;     [available starting point, good!]
$y isa X86VM;                           [available starting point, bad!]
get $y;
limit 10;

can you just get ALL the answers for the less specific query and do a filtering operation on the client side?

match
($x, $y) isa DENENDENCY_TRANSITIVE;
$x iid 0x966e8002800000000000006c3;    [available starting point]
get $y;

using this query in for example the python client:

for ans in tx.query().match(dependencies_query):
  if ans.get("y").get_type().get_label().name() == "X86VM":
    [do some processing with this answer]

let me know if that works!

Hi joshua,

If I query without a limit condition(such as ‘limit 10’):

I think it means that all relating instances will be retrieved. The amount of instances maybe very large.
I’ve tried this method. It took very very long time and I couldn’t wait till it ended.

Okay! How deep (eg. how long) can your transitivity chains be?

According to our model architecture, there are over 10 models in the deepest chain on paper.
Frequently used query chains are about 3-6 models.