About DAG

[LinXueyuanStdio]

Hi. I notice the line that mentions DAG and tree.

Although some processors claim to support DAGs, as of March 2023, there is no DAG-specific query dataset to faithfully reproduce those claims.

Those claims are obvious right for embedding-based methods. I think it does not require another dataset to clarify.

For example, given triples { (Mike, mother, Alice), (Mike, father, Bob) }, we want to query the parent of Mike.
Then the query can be written as ?V: exist V, (Mike, mother, V) or (Mike, father, V)

The computation graph of the query is a DAG instead of a Tree. Because the node Mike has more than one parent node (Alice and Bob). On the contrary, the node in the tree must have only one parent node.

Embedding-based methods do not have any constraints on the parent count of any node. Those methods only represent the node, execute the node, and decode the node. The execution follows the direction of edge, without consideration on the number of out edges of a node.

Besides, I think such examples like above are universal in the QE dataset, especially in 2i, 3i tasks. Therefore, I think the claims of those methods are OK, and it does not need DAG-specific query datasets.

[miselico]

The example does not form a DAG because it is a disjunction, not a conjunction.

There is a similar case which would be a DAG. ?V: exist V, (Mike, contributedToRepository, V ) and (Mike, ownsRepository, V). This time, it is a conjunction and forms a DAG. In 2i and 3i tasks as they are currently created, this kind of queries might occur (depending on whether the anchors are checked for uniqueness), but they are not separately evaluated.

[LinXueyuanStdio]

Yes, the new example is better!

By the way, I am still interested that what conclusion we could have if the results are different between tree-specific and DAG(except tree)-specific datasets (supposed we have these datasets).
What reason could it be?