I think the thing that trips people up is that the "semantic" in semantic web is talking about the semantics of the schemas, not the the data.
I think a) RDF is a pain in the ass to scale and b) fails to deal with public social systems, which almost always need to record the creator and time of a triple, and this is a pain to always represent in RDF (reify every statement?)
Very early on, I considered using RDF as a data store for delicious, but it was not even close to performant.
Things change; I wonder how much has changed since "very early on" -- Oracle 11g's RDF support is extremely scalable, for example. Of course Oracle is evil so YMMV, but there's nothing timeless or essential in Joshua's claims here.
Until now, Semantic Web applications have been a solution in search of a problem. There are some cool apps out there, but no killer apps ... at least not yet. I got excited when I saw the OpenCalais demo, but very few other people would get pumped about what basically boils down to a platform that tags, categorizes, and calculates relevancy for text content.
It kind of reminds me of the hype relating to grid computing. Everyone sees the potential, but when most apps address the needs of science and finance wonks, it's hard for the excitement to scale.
I still don't know many people that like working with RDF. The ideas are pretty simple, but I feel like they've been poorly conveyed and are hiding behind a veil of ontology terminology. In the Directed Edge webservices API I debated supporting it (and may still add such in the future) but instead went with using a much simpler to read / write self-rolled XML format.
The problem is that RDF adoption assumes that people know how to work with RDF ... or honestly, even get what it really is (which I find often isn't the case).
Another thing that seems to be confused by this article is that "semantic" has two very different meanings in current web technology. In one case it's semantic analysis, in another it's structured data.
In my experience, there is not a real use case for RDF or the other Semantic Web standards. You always have to write domain specific code to actually drive an application with RDF - so why not ditch RDF and write a domain specific data store too? How does RDF contribute, if it neither automatically drives any part of your application, or facilitates linking or relating of mulltiple datasets?
its true that it was designed by academics and seems very dry on the surface, but it is an amazingly capable and complete stack. people have been reimplementing various parts of it in various ways on many sites today.
regardless, if it doesn't succeed, then something a lot like it eventually will.
There are TONS of RDF apps...On corporate and gov't intranets. For some reason or reasons, adoption has been very asymmetrical between public Web and private intranet when it comes to much of the SemWeb stack. For example, see this: http://www.w3.org/2001/sw/sweo/public/UseCases/Nasa/ Which describes a production NASA application -- expertise location tool -- for the 80,000 person NASA workforce, which uses RDF extensively internally.
I think a) RDF is a pain in the ass to scale and b) fails to deal with public social systems, which almost always need to record the creator and time of a triple, and this is a pain to always represent in RDF (reify every statement?)
Very early on, I considered using RDF as a data store for delicious, but it was not even close to performant.