Discussions on None
Start a New Discussion
-
-
"None" is squatting on "Independent" -- please split this into two topics.
-
+1
-
How about we just split off the "Political Party" section?
I now know how to use this handy little Split Tool here ...
-
That'd need someone to move the Wikipedia keys as well (which you won't be able to do), but it's a good start.
You'll probably want to use the dev version of the Split Tool, as there are a number of issues with the current released version. Note that the new version actually does the write for you, rather than expecting you to copy it into the Query Editor!
-
Thanks. I just used the dev version of the Split Tool and split off the "Political Party" section to a new "Independent" topic. It seems to have mostly worked, in that the new Independent political party has a lot of politicians, and those politicians now show their party as Independent; however, they're also still listed under "None" here ...
Could someone please move over the Wikipedia keys to the new topic?
-
My mistake (think I was looking at a cached version) - "None" is no longer a political party and has no candidates.
-
Looks good to me. Could somebody with appropriate privileges please move the Wikipedia keys? (and possibly the /en key as well).
-
Cross-posting to /freebase in the hope the admins there may action this.
-
(From Jamie Taylor, via email):
I'm very hesitant to suggest splitting the semantics of WP keys since the source (WP) treats them all as equivalent (i.e., all keys are opaque - splitting them makes an assumption that there is a specific semantic associated with each.)
By splitting the key set we are assuming that WP contributors are making a distinction between keys and that they make a specific selection among all the keys for use in Infoboxes, etc. WP contributor don't actually see the full collection of "keys" referring to an article - and thus will use whatever the current canonical name of the article is - thus our attribution of a special semantic to each key is probably a bad assumption.
I think it is great that we are splitting a topic - but I don't think we can separate keys from an external sources when the external source does not recognize the difference between keys. -
I would normally agree completely with this. Topic Updater does not like wikipedia keys to be split between topics; in fact, the enw version would automatically "fix" these splits if we did not put special logic in to not overwrite manual key swaps.
However, this looks like a special case. For some reason, the wikipedia keys for the Independent Party got merged into the uber-topic (or black hole, depending on your viewpoint) "None". AFAIK, there is no reason that "None" should have any wikipedia keys at all.
+1 on the split, and moving all wikipedia keys for the Independent Party on to the split topic. We'll make it happen today. -
Precisely. We're just trying to unpick the merge which happened on the 7th April; there is no "external source" which thinks that "Independent" is the same as "None".
Here's a question for anyone interested: why did Merge Bot decide to merge the two? As far as I can see, it was due to this duplicate collection, which led to this merge task, which got two "don't merge" votes. So what's merge bot doing here?
-
My icon shows up next to the "status completed" line in the history, so it's likely that I voted for the merge as admin, but there's no record of the admin vote that I can find. My rationale was presumably that the "independent" political party is equivalent to "none" -- that is, it's not a political party at all, it's just the conventional way that "none-ness" is expressed for politicians' party affiliation.
-
-
-
Originally this topic was about "independent" as a political affiliation. How did it morph into a topic for "None", which is now the parent/spouse/child of hundreds of people, as well as the political party of politicians, the host of Academy awards shows, the gender of fictional characters, the degree of dubious students, a TV program, and much much more?!?
-
-
-
Is there a better type for this? This is not actually a party.
-
True. However, see the discussion on None concerning absence of information vs. information of absence. Freebase does not have a good way to express the positive knowledge that a politician was in no party, as opposed to a lack of knowledge about party membership. Perhaps this should be merged with None, so that if and when that topic is treated specially the politicians will be properly understood.
In fact, I am going to mark it for merge. Thanks for bringing this up.
-
-
-
Freebase generally conflates the absence of information with information of absence, a distinction that many other knowledge representation systems make. If there is a discussion of the logic behind this stance, this would be a good place to link to it.
-
Ah, this page is no longer marked for deletion. Cool.
-
This page should be marked for deletion. It serves very little purpose. The absence of information is a sufficiant indicator that a property is empty or invalid.
-
I disagree with Daniel that absence of information is sufficient. However, I agree that this peculiarly polymathic poymorphic None is a poor way to indicate it. As a concrete example, on my Person topic, I have no value for the Spouse or Children properties. In one case, it is because of privacy for the other party or parties involved, and in the other, it is because of a positive lack of value. A way to concretely indicate known, negative value would definitely be useful.
-
On another note... even if we deleted "None", it would keep popping up again and again as people kept trying to use it.
-
This topic may be poor substitutition for indicating the absense of something, but the fact that it's extremely well-used in so many situations by so many different users suggests that it serves a real purpose.
Freebase, after all, is an open data community, and the community has found a need for a "None" topic. Unless or until a better alternative is provided, this well-used topic is simply too relevant to be removed from the system.
Please keep.
-
The problem is that "None" as a topic creates issues for people who are using Freebase for web applications. When creating lists of links, none now has to be checked for in every instance so as not to link to it. If "none" was a property like an integer or a date that wasn't issued a GUID and its own topic page, we might be able to avoid any problems.
-
I agree that the "none" topic is unnecessary and, as joquinn stated, an outright problem for those seeking to use Freebase's services in web applications. The great strength of the internet and of Freebase's information is the ability to link information together based on shared information.
The properties of having no dissertation, no children, no spouse, or no college attended are completely separate informational details, yet this topic links them all together as if they are the exact same attribute of knowledge when viewed from the perspective supplied by MQL.
Thus, with this "none" topic, you are creating completely misleading nodes of informational links which leads to more DISINFORMATION than it does of useful "information of absence."
For example, you might be "better" able to describe basketball players who had no college education by marking that property as "None," but now you've created the disinformation of a university named "None", which returns a full roster of players who attended this "institution." Not only have you failed to improve on the sufficient concept of the null property, you have made the situation even worse.
The lack of information is a property and should remain as such through null to avoid disinformation rather than the false nodes of relationship created by an informational topic.
If this topic remains, I feel that it will seriously hinder the ability of Freebase to provide a logical system of linking related information together. This none topic completely compromises the vast amount of strength present in Freebase's relational database, and is at best a crude and misguided "solution" that simply replaces a lack of information with disinformation. It is an approach that is one illusory step forward followed by an exponentially growing number of steps backwards as more and more topics are improperly related to each other throughout Freebase.
Please remove the "none" topic. -
For additional thought: I thought I'd provide another example of the ridiculous amount of disinformation this topic creates. As queried and represented by Freebase's query system:
James Buchanan had a relationship with the Person "None" which also happens to be a Gender. This Gender is actually Ralph Nadar's Spouse whom he shares with Peter Fenton and is a recurring Saturday Night Live Host. This Spouse is siblings with the only-child Jeremy Polen and is also part of a Film Series which includes the Literature Into the Wild. In the last election, "None" ran for the 2004 Democratic nonimation and lost, which makes sense because Sports Teams cannot be elected President, they can only be married to one...
I think you can see where this is going. Freebase now has this ridiculous joke of a chain of informational relationship just to say that James Buchanan was single. "None" should be trait represented by null, and not a relational topic.
-
Can't "none" be reserved to indicate a known null? What would be a better way to represent a known null that could not be confused with placeholder null indicating a lack of knowledge for a potential relationship? What about making
"none" a super topic with extraordinary powers of blocking connections within the graph? -
What is the benefit of "none" being any kind of topic at all? By making it a topic instead of some kind of non-linked property, you're opening the door to all sorts of silly scenarios like bluedude6 posted above. It's painfully obvious that the system in which "none" is permitted to exist as a linkable property instead of either a null property or a property like an integer that has no topic is flawed, at best.
Another issue to consider is that when I asked for a "current" head of state property or type, I was told to indicate "current" status by leaving the end date blank. What we have here is a case where blank is sufficient to indicate the absence of a one thing, but not sufficient enough to indicate the absence of another. It's a standardization issue.
-
I like the idea of making "none" a reserved word in MQL. It could look something lke this:
{
"id" : "/en/christie_hefner",
"type" : "/people/person",
"children" : [{
"none" : true
}]
}
or even like this
{
"id" : "/en/christie_hefner",
"type" : "/people/person",
"children" : "none"
}
-
This is a great idea. We should definitely do this. How do we go about making this change?
-
Yes! This is a great idea. How do we get this to happen?
-
I'd suggest raising a ticket in our bug tracking system, describing in detail the problem being addressed and your proposed solution. This is probably a graph-level change, so we can then pass it over to that team for evaluation.
-
Scott Meyer seemed to indicate on the data-modeling list that the graph-level folks were not interested in implementing this. I'll vote on this ticket if someone from Metaweb opens it but I suspect that the issue is pretty much decided now.
-
I read his response but couldn't cut through the jargon, to be quite honest. It seemed as if he agreed that typing "none" and keeping it as a topic was an acceptable solution, but I just can't see how that can be. It's a novelty on Freebase, to be sure, but it certainly goes against the legitimacy of a data set when one of the items a) doesn't exist and b) doesn't exist with the types of relationships that it claims to. I'll open a ticket in the bug tracking system to this effect, but if what you say is true, I don't know that it'll do any good.
-
The bug has been created and resides here:
-
This none topic does not only hurt people who are using freebase's database to create web apps, but it also hurts users who are trying to find certain information on freebase alone. If i go to the Automobile Model and tell it to find auto models that have a predecessor and a successor, I see the Ford Mustang and the Pontiac GTO at the top of the list. This is of course wrong because they have no predecessors or successors. Now a freebase user is severely miss led about Auto Model knowledge.
-
