Hacker News new | past | comments | ask | show | jobs | submit login

I don't want to say anything negative about them, because both are fine initiative on their own. But I'm not hugely optimistic about them (yet). Both can succeed, but both are pretty far from what I'd consider succeeding.

First of, I want to highlight what you already said: this approach is the opposite of an incremental. Both approaches are fine and have their own value, but they are truly different, and not somehow philosophically "opposite, but the same".

This is not a perfect example by any means, but just to be less abstract, let's pretend you want to dig a really big hole.

1. "Disruptive innovation" approach is spending a lot of resources on research without any real output for a long time, in hope that in the end it will produce an excavator, which will surpass the work of 1000 mortal men. These projects are costly and provide no guarantee, they are usually successfully done by small research groups in facilities like "Google X". Any such project is always a huge bet, it either works out or not. And even "almost working out" e.g. producing engineering schemes that will be improved upon in a 100 years to actually produce an excavator, mostly counts as "not working out" for any individual project and organization.

2. More conventional approach would be to motivate 1000 men to dig a hole using shovels and buckets, maybe developing a better shovels and buckets in the process, if possible. The trickiest part here is actually motivating 1000 men: using money, violence, "gamification" or whatever.

Wikimedia foundation is not known so much for "disruptive innovation", as it it for crowdsourcing. And even if it was: every moonshot is unlike any previous one. In fact, it motivates hundreds of thousand of people to contribute without directly paying them money, which is a huge feat.

Now, let's get to Wikidata. Web 3.0 ideas with OWL and knowledge graphs are older than actual Wikipedia. And maybe if I'll say they weren't successful, somebody will retort by mentioning some projects where OWL and RDF are actually useful... I mean, sure. But are they as successful as Wikipedia? Are they as successful as Web 1.0? This is rhetorical, of course.

"Why" can be arguable, but I feel like it's actually pretty clear why: people do not willingly contribute to something they don't understand, and maintaining a data graph still requires a lot of manual contribution and editing. This kind of contribution has to be made an effortless by-product of what they actually want: putting something on the internet they (and other people) can access in a human-understandable format. They don't care about stuff being machine-readable. You may know that they actually want it, because the possibilities it will open are enormous, but most of contributors don't know it. It's easy to see why I should edit an article on the subject I care about, that contains wrong info or is incomplete. It's not as obvious why I should edit some abstract "item" somewhere out there, and care about some "data graph" I've never seen... That is, until I need to access it using SPARQL myself.

I'm more optimistic about Abstract Wikipedia for that reason as well: there are plenty of biligual Wikipedia users, and many of them know that sometimes reading the same article in 2 different languages reveals that there exist almost parallel universes, with communities speaking different languages having their own "truth". Sometimes it's actually useful, because you get to see that there is actually "no truth", but it's also apparent why something like "Abstract Wikipedia" may be useful. But that is too early in the concept phase to seriously speak about it, anyway.

So, once more: these will either succeed or will they fail. That remains to be seen.

What I was talking about is much more approachable, I think. This is not an "all or nothing" undertaking. There are plenty of very real improvements that can be made to the data model of each and every article, and they will remain regardless of whether they help to create "Wikipedia:Web 3.0" or not (and I actually think they have very real prospect in helping with that, because it will literally get people editing the data graph without even knowing about it). They are useful on their own.

And unlike my "friend" exacube in the neighbour thread I actually think this kinda is about UI. Because unlike with abstract data graph, people care about approachable, clear and uniform interfaces. A random example, to clarify what I mean. You can look up some "List of birds of CountryX" kind of articles in different languages and different countries. Semantically, all of these are the same thing, there can be a single "best UI" for that, that any given encyclopedic organization can decide on. Wikipedia doesn't have one: sometimes it's a table, sometimes it's a list. Sometimes there are picture of a bird thumbnail, because that's useful. Sometimes (for a table of the same length for the same country in a different language) there is not, because it's obviously a lot of work to make such a table, and person who did it just didn't bother. Yet these photos exist in the `BirdName` articles, so you could prefetch them automatically, if there was a common structure to all of it. Same for many other data. And there are countless examples of this kind.




Thanks. That is an interesting perspective and i agree with a lot of it.

I would point out in the bird example though - the normal way of having a "data model" in wikipedia is through templates (yes it is very definitely mixing view/model/controller in a questionable way). These templates do have the ability to fetch data from wikidata (with some restrictions) and wikidata does store an image for most animal entries.

So its entirely possible to have a template on wikipedia, that just takes a list of species names, and turns that into a pretty table listing the species, a picture, and perhaps other fields as required.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: