Two ways of doing reification with CONSTRUCT are not yielding equivalent and correct results
- Dominant language
- Go
- Stars
- 984
- Forks
- 65
- PR merge metrics
- No merged PRs in 30d
Description
To illustrate this issue I use the "family" and "grandparents" example below.
Given a `?family` graph with the following data:
```
INSERT DATA INTO ?family {
/u "parent_of"@[] /u .
/u "parent_of"@[] /u .
/u "parent_of"@[] /u .
/u "parent_of"@[] /u
};
```
(Note that "Joe" is the only grandparent here and his grandchildren are "John" and "Eve").
We can use `CONSTRUCT` to create a new `?grandparents` graph extracting only the "grandparent" relation from `?family`, while also adding a new information `"both_live_in"` for each grandparent / granchild fact (using a blank node - **reification**). For that, following the documentation [here](https://github.com/rogerlucena/badwolf/blob/master/docs/bql.md#building-new-facts-out-of-existing-facts-in-graphs), we can proceed in two directions:
### 1) Using ";" and partial statements
We can do:
```
CONSTRUCT {
?ancestor "grandparent"@[] ?grandchildren ; "both_live_in"@[] /city
}
INTO ?grandparents
FROM ?family
WHERE {
?ancestor "parent_of"@[] ?c .
?c "parent_of"@[] ?grandchildren
};
```
Now, to have a look at the `?grandparents` graph we can query all its triples using:
```
SELECT ?s, ?p, ?o
FROM ?grandparents
WHERE {
?s ?p ?o
};
```
Which returns:
```
Result:
?s ?p ?o
/_<110e9ee3-30dc-4915-ba70-5907c3ae22b5> "both_live_in"@[] /city
/_<20a64f0d-1523-4946-93d0-6cbe2ff284a0> "_predicate"@[] "grandparent"@[]
/_<20a64f0d-1523-4946-93d0-6cbe2ff284a0> "both_live_in"@[] /city
/_<20a64f0d-1523-4946-93d0-6cbe2ff284a0> "_object"@[] /u
/_<20a64f0d-1523-4946-93d0-6cbe2ff284a0> "_subject"@[] /u
/_<110e9ee3-30dc-4915-ba70-5907c3ae22b5> "_predicate"@[] "grandparent"@[]
/_<110e9ee3-30dc-4915-ba70-5907c3ae22b5> "_subject"@[] /u
/_<110e9ee3-30dc-4915-ba70-5907c3ae22b5> "_object"@[] /u
```
### 2) Using the explicit blank node notation
To generate this `?grandparents` graph we can also choose to use the explicit blank node notation below:
```
CONSTRUCT {
?ancestor "grandparent"@[] ?grandchildren .
_:v "_subject"@[] ?ancestor .
_:v "_predicate"@[] "grandparent"@[] .
_:v "_object"@[] ?grandchildren .
_:v "both_live_in"@[] /city
}
INTO ?grandparents
FROM ?family
WHERE {
?ancestor "parent_of"@[] ?c .
?c "parent_of"@[] ?grandchildren
};
```
In this case, if we query all the triples of `?grandparents` with the same `SELECT` query used in **1)** we get:
```
Result:
?s ?p ?o
/u "grandparent"@[] /u
/_ "both_live_in"@[] /city
/_ "_predicate"@[] "grandparent"@[]
/u "grandparent"@[] /u
/_ "_object"@[] /u
/_ "_object"@[] /u
/_ "_subject"@[] /u
```
Which diverges from the result got in **1)**.
Note that in the result for **2)** we have the expected triples `/u "grandparent"@[] /u` and `/u "grandparent"@[] /u`, whereas they do not appear in **1)**. Also, note that in **1)** we get two blank nodes, as predicted by the documentation, while in **2)** we get only one blank node with two `"_object"` relations (one for `/u` and another for `/u`).
Both ways should yield equivalent results, as it is detailed by the documentation [here](https://github.com/rogerlucena/badwolf/blob/master/docs/bql.md#building-new-facts-out-of-existing-facts-in-graphs) in the paragraph below:
> "The above query is _**equivalent**_ to the query above it, but it explicitly does the reification by using _:v, which express a unique blank node linking the reification together. The CONSTRUCT clause supports creating an arbitrary number of blank nodes. The syntax is always the same, they all start with the prefix _: followed by a logical ID. On insertion of each new fact, BQL guarantees a _**new unique blank node**_ will be generated by each of them. Example of multiple blank nodes generated at once are _:v0, _:v1, etc."
You can use the code in the file below to reproduce the aforementioned results.
[two_ways_reification.pdf](https://github.com/google/badwolf/files/4848637/two_ways_reification.pdf)
Contributor guide
Assessment
This issue has not been assessed yet.