'Yugoslavia is a country'. Are you really going to exclude that? So, no statements about political geography at all, then. Same problem for physical geography ('New Moore Island exists'). Nothing about climate (because 'the rain in Spain' could change at any time), nothing about population levels. Even the sample 'average weight of an apple' is pretty suspect. I think your database is going to be quite limited.
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.
This has suddenly become very philosophical. My view is that a database of facts should contain things that are believed to be facts. It should be possible to remove facts that are shown to be incorrect, but those things should never have been true.
> 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.
"My view is that a database of facts should contain things that are believed to be facts. It should be possible to remove facts that are shown to be incorrect, but those things should never have been true."
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.
It's pretty obvious you'd didn't consider statements like that. There are a large number of examples that make your statement of the invariance of facts absurd.
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.
> 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).
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.
> 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.
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.
