Facts don't change.
Facts are verifiable statements and things that are verifiable are verifiable repeatably. This is not a verifiable statement.
Yes, of course.
> So, no statements about political geography at all, then.
Absolutely not, you just have to make time explicit.
Edit: It seems we're arguing about what a priori knowledge is capable of serving as a base for factual deductions. The Kantian approach is to say that we all agree on time and space and everything can be based off of these self-evident truths. I think there is not such a clear boundary between objective truth and induction.
Edit2: I'd also like to take this moment to point out that "you're" is the proper contraction of "you are", since we're getting all semantic.
> I'd also like to take this moment to point out that "you're" is the proper contraction of "you are", since we're getting all semantic.
I know, it annoys me too. By the time I'd realized it was too late to edit. Typos happen.
But they definitely were true. I thought you were making a distinction between 'something that is true' and 'something that is a fact (ie: is unchangingly true)' which I don't think most people make.
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.
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.
This is not a fact database. This is:
X Married Y 2009-01-01
X Divorced Y 2013-01-01
X Married Y 2013-02-01
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.