> This piece is based on two talks I gave in the spring of 2005 -- one at the O'Reilly ETech conference in March, entitled "Ontology Is Overrated", and one at the IMCExpo in April entitled "Folksonomies & Tags: The rise of user-developed classification." The written version is a heavily edited concatenation of those two talks.
Ontology Is Overrated: Categories, Links, and Tags (2005)
11–20 of 94 posts
Re: Ontology Is Overrated: Categories, Links, and Tags (2005)
#12The same is so true for programming, in particular OOP. In my experience, code is much easier to change when a loosely coupled set of interfaces is built as opposed to an hierarchy of classes.
For example, why is it not easy to add an "onClick" event handler method to a particular button in a Java GUI? One has to use lambdas instead. Attempts to reorg the GUI engine to remedy such create side-effects. Java's OOP model is simply not powerful enough to do GUI's naturally. Conway's Law seems to apply to domain structures as well. Fit matters.
Something like Lisp allows one to create behavior-containing "structures" that are customized to a domain or need, but can get too confusing. Lisp can easily get too hard to read and follow for most mortals, and is why it never became mainstream despite being around for 60-ish years.
We need something in between traditional OOP and "full meta".
Re: Ontology Is Overrated: Categories, Links, and Tags (2005)
#13I enjoyed this piece, mostly because I disagree so strongly with it :-). Clay takes the topic of Ontology, contextualizes it into an impractical domain, and then calls it overrated. Cars are overrated too because they can't cross oceans right? When done correctly, ontology combined with knowledge graphs can make an impractical problem much more practical. Consider for the moment the problem of 'fake news'. What chara…
You might be able to say that fake news doesn't align with true facts that aren't part of the facts being reported as news. That is you can tell that "the color of the sky unexpectedly changed from green to yellow yesterday" is fake news, but you can't use true facts to tell that ""the color of the sky unexpectedly changed from blue to yellow yesterday" is fake news. (I mean, yes, you might still use true facts about atmospheric composition, light scattering, and the spectrum of solar output, but you can't use "the sky is blue".)
Re: Ontology Is Overrated: Categories, Links, and Tags (2005)
#14Re: Ontology Is Overrated: Categories, Links, and Tags (2005)
#15All I see is a giant ad for ED pills. This is what I see: https://archive.fo/rZchC over time: https://archive.fo/http://www.shirky.com/writings/ontology_o...
Re: Ontology Is Overrated: Categories, Links, and Tags (2005)
#16I enjoyed this piece, mostly because I disagree so strongly with it :-). Clay takes the topic of Ontology, contextualizes it into an impractical domain, and then calls it overrated. Cars are overrated too because they can't cross oceans right? When done correctly, ontology combined with knowledge graphs can make an impractical problem much more practical. Consider for the moment the problem of 'fake news'. What chara…
Re: Ontology Is Overrated: Categories, Links, and Tags (2005)
#17The same is so true for programming, in particular OOP. In my experience, code is much easier to change when a loosely coupled set of interfaces is built as opposed to an hierarchy of classes.
Indeed. This is also why I think OOP is missing something to scale better in terms of flexibility and domain size. The ideal code structure for a particular need is rather arbitrary. OOP "prefers" things in a hierarchy, both in terms of inheritance, and in terms of an object being less powerful than a class (in most languages). You can force or use OOP outside of these, but it's unnatural in my opinion. For example,…
I increasingly advocate F#, and many people recommend Elixir for these purposes too (though I'm not familiar with it myself).
Re: Ontology Is Overrated: Categories, Links, and Tags (2005)
#18I enjoyed this piece, mostly because I disagree so strongly with it :-). Clay takes the topic of Ontology, contextualizes it into an impractical domain, and then calls it overrated. Cars are overrated too because they can't cross oceans right? When done correctly, ontology combined with knowledge graphs can make an impractical problem much more practical. Consider for the moment the problem of 'fake news'. What chara…
I'm not sure about that. In Shannon's Information Theory, stuff that aligns with the existing knowledge base contains 0 bits of information. Things that contain new information cannot line up with the existing knowledge base; "news" is exactly the word for such things. You might be able to say that fake news doesn't align with true facts that aren't part of the facts being reported as news. That is you can tell that…
If you get 5 streams of bits and four of them correlate with some epsilon number of new bits, and the fifth has 10x epsilon new bits, one of things is likely true. Either the odd stream out is corrupted or the stream has changed.
Apply that to news stories where the ontology (O) and knowledge graph (KG) are combined to "error correct" the content of the story. "Error bits" would be defined as relationships that don't match what the ontology says can be true, or facts that are different than those facts already in the knowledge base. You can flag the odd news story as lacking alignment with the existing KG&O, further you can quantify that lack of alignment fairly precisely.
So if the news story has 0 bits of information it correlates very strongly with other existing stories. If it has many bits of information it contrasts with other existing stories. At some number of stories on the same topic you can begin to reason about which are more likely 'true' and which are more likely 'false.'
Re: Ontology Is Overrated: Categories, Links, and Tags (2005)
#19Re: Ontology Is Overrated: Categories, Links, and Tags (2005)
#20Earlier quoted context omitted.
Indeed. This is also why I think OOP is missing something to scale better in terms of flexibility and domain size. The ideal code structure for a particular need is rather arbitrary. OOP "prefers" things in a hierarchy, both in terms of inheritance, and in terms of an object being less powerful than a class (in most languages). You can force or use OOP outside of these, but it's unnatural in my opinion. For example,…
I think most ML-derived languages strike the right balance - functional languages that incorporate enough OOP principles to get things done in the real world. I increasingly advocate F#, and many people recommend Elixir for these purposes too (though I'm not familiar with it myself).