Hacker News Reader

Comment by georgespencer | Hacker News Reader

Tantek is still alive, if that's what you mean.

Jokes aside: microformats started to get pretty good traction, but the biggest challenge (as I see it) has always been adoption in software, rather than encoding the data itself.

Flock was the great white hope in this space for a browser which (somewhat sensibly) used the semantic web to enrich people's lives, but there wasn't really a killer app for it. It did a lot of interesting stuff, but none of it was omfg can't live without youuuuu.

If browser vendors start building great features to take advantage of the semantic web, then developers will start adopting and consumers will start [tacitly] demanding it.

Interesting point: if you go back to the SciAm article which kickstarted a lot of interest in the semantic web amongst relative laypeople, then you'll find that actually it's not dissimilar to where we are today, but we are getting there without the semantic web.

View on HN

If browser vendors start building great features to take advantage of the semantic web, then developers will start adopting and consumers will start [tacitly] demanding it.

I think browsers have little to do with the Semantic Web. The semantic web is more M2M.

I'm trying to think of real world applications for the semantic web, in 2014, which do not require a browser. Struggling.

I just mean that there's not necessarily a need for any Semantic Web tech in the browser specifically. An application may certainly have a browser interface, but, to my mind, most of the "stuff" that involves working with RDF, OWL, SPARQL, etc. is server-side / behind-the-scenes stuff that the user wouldn't touch directly. The various browser plugins that let you look at embedded RDFa, microformats, etc. are nifty, but I don't personally consider that kind of stuff a primary use-case for semweb tech.

My problem with that is: Most modern web-apps run much (up to completely) in the browser. And the Semantic Web Stack is very heavy if you want to use it client-side. Here every kilobyte counts.

Well, you could directly query a SPARQL database, but thats the one scenario where a server still makes sense, to provide some decoupling from the database model and the client.

My problem with that is: Most modern web-apps run much (up to completely) in the browser.

"Use the right tool for the job". :-) There's no particular reason a "modern web-app" has to run completely in the browser... it still makes perfect sense to put heavyweight process intensive stuff, persistence, business logic, etc. on the server-side. If I'm building an app that uses a lot of "semantic stuff", most of that stuff is, indeed, happening on the server side.

Well, there are reasons and it's getting more common. In fact most modern browsers, even on a smartphone, may have more computing power than a server if you consider that the client has only to serve itself and the good performance of modern JavaScript engines. And having to do a lot of networking with a server slows a lot too, since network is one of the slowest and unreliable parts of an app.

So your answer sounds more like an excuse than a solution to me, sorry.

Reply on news.ycombinator.com