3 ms·

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

mindcrime 12y ago
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.
- Fannon 12y ago
  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.
  - mindcrime 12y ago
    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.
    - Fannon 12y ago
      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.

mindcrime 12y ago

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.

Fannon 12y ago
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.
- mindcrime 12y ago
  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.
  - Fannon 12y ago
    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.