3 ms·

In the absolute sense, you're right they don't; but in the practical sense they do, especially open time-dependent statements. The easiest example is this: We'

In the absolute sense, you're right they don't; but in the practical sense they do, especially open time-dependent statements. The easiest example is this: We're in 2010. X has been married to Y since 2009; In the DB it would be represented exactly like that: a "from" time period, no "to" time period, meaning "it is still true now". They divorce in 2013. X married to Y from 2009 to "now" isn't true. It should be downvoted. but X married to Y from "2009" to "2013" is actually true. It should be created and upvoted. That fact surely won't change overtime.

Buttons840 14y ago
How can you say how the data will be structured? I thought you weren't enforcing any type of data structure? I like the new approach though. You appear to be focused on simplicity and ease of use, and hopefully your find ways to fix the resultant problems. For example, some fancy graph theory might be able to determine that the graph node "Apple" refers to two different ideas.
- christophe971 14y ago
  You're right, nothing is enforced, if people choose a different way to present the data, it's totally fine.
hcarvalhoalves 14y ago
> The easiest example is this: We're in 2010. X has been married to Y since 2009; In the DB it would be represented exactly like that: a "from" time period, no "to" time period, meaning "it is still true now". This is not a fact database. This is: X Married Y 2009-01-01 X Divorced Y 2013-01-01 This way you can represent any number of facts: X Married Y 2013-02-01 Think how convoluted it would be for you to represent X and Y marrying again in your example, if not outright wrong (because you update/delete information).
- christophe971 14y ago
  I can be wrong, but being in a state of marriage with Y is a fact. And since the DB handle time periods, with my way you can actually search who X is married to with one request, without checking if he divorced, if Y is dead, disappeared, or else.
  - hcarvalhoalves 14y ago
    > I can be wrong, but being in a state of marriage with Y is a fact. This is akin to your bank storing the total amount of your account in their database, instead of the transaction history and deriving the total from that. There's nothing wrong with that, until there is. Consider this situation: X marries Y, divorces, marries again. Now you would have the date of divorce prior to the date of marriage. How do you make sense of this data? > And since the DB handle time periods, with my way you can actually search who X is married to with one request, without checking if he divorced, if Y is dead, disappeared, or else. The fact Y is dead doesn't mean X wasn't married to it. So despite the obvious technical implications of keeping all this data in sync (e.g., Y dies so you would update X to reflect that?), you're simply obliterating information. A fact is immutable, therefore a fact database, by definition, only appends, never updates. It is, indeed, a hard problem.

Buttons840 14y ago

How can you say how the data will be structured? I thought you weren't enforcing any type of data structure? I like the new approach though. You appear to be focused on simplicity and ease of use, and hopefully your find ways to fix the resultant problems. For example, some fancy graph theory might be able to determine that the graph node "Apple" refers to two different ideas.

christophe971 14y ago
You're right, nothing is enforced, if people choose a different way to present the data, it's totally fine.

hcarvalhoalves 14y ago

> The easiest example is this: We're in 2010. X has been married to Y since 2009; In the DB it would be represented exactly like that: a "from" time period, no "to" time period, meaning "it is still true now". This is not a fact database. This is: X Married Y 2009-01-01 X Divorced Y 2013-01-01 This way you can represent any number of facts: X Married Y 2013-02-01 Think how convoluted it would be for you to represent X and Y marrying again in your example, if not outright wrong (because you update/delete information).

christophe971 14y ago
I can be wrong, but being in a state of marriage with Y is a fact. And since the DB handle time periods, with my way you can actually search who X is married to with one request, without checking if he divorced, if Y is dead, disappeared, or else.
- hcarvalhoalves 14y ago
  > I can be wrong, but being in a state of marriage with Y is a fact. This is akin to your bank storing the total amount of your account in their database, instead of the transaction history and deriving the total from that. There's nothing wrong with that, until there is. Consider this situation: X marries Y, divorces, marries again. Now you would have the date of divorce prior to the date of marriage. How do you make sense of this data? > And since the DB handle time periods, with my way you can actually search who X is married to with one request, without checking if he divorced, if Y is dead, disappeared, or else. The fact Y is dead doesn't mean X wasn't married to it. So despite the obvious technical implications of keeping all this data in sync (e.g., Y dies so you would update X to reflect that?), you're simply obliterating information. A fact is immutable, therefore a fact database, by definition, only appends, never updates. It is, indeed, a hard problem.