One of the things we vehemently agreed upon was that "apps must die" for the reason that "apps" are a new way of isolating (both physically and semantically!) data and preventing interactivity; whereas Sedvice/M3 specifically was designed to break down the semantic isolation and ultimately reduce "apps" to be nothing more than domain specific user-interface manifestations of information - and ideally in some cases, become a novel user-interaction mechanism.
After tonight's discussion, I make a quite search on the "apps considered harmful" meme and found an article "Apps Considered Harmful: Part1" at Elderlore's blog. I really like this quote:
"So,what can we do? In part two of this article,I will talk about moving beyond the fragmented experiences of App World into something more interesting,where data and programs are explicitly represented as objects that you are empowered and invited to interconnect. Consider something like GNU Emacs:the separate “applications”in the Emacs Lisp space are delivered as bundles of functions and variables and hooks,not as single-screen apps that cannot interact or share data. You get things done in Emacs by customizing variables and hooking things together;potentially,any function in any Elisp application can call any other function or access any other data in the system,regardless of which package implements the functionality,and most of the coolness of emacs is in being able to coordinate things this way when solving problems,and to save these coordinations as resuable elisp code."
and also
"I want to smash the App World into pieces;that is to break apps into smaller,reusable pieces or “blocks”which can be visually clicked together like MIT Scratch,but on an industrial scale. Apple already banned this type of software from the iPad;perhaps they know something they aren’t telling us?"
So do we! So de we! Even the EU has started talking about data liberation!
Much of the reasoning behind promoting the "Apple style of app" (remember Nokia's Widsets made years earlier - actually they were coming quite close to our ideal?!) is based around locking-in the developer and especially the user. Indeed pretty much every piece of functionality in most "apps" found on all smart phone operating systems is for consumption of data and recording in specific detail the user's behaviour associated with that particular consumption interaction. Ironically all that functionality is present in the generic browser (eg: Opera, Firefox etc) and usually, much more control over your individual privacy too.
Privacy however is a side issue here for the moment and our focus is actually on what an "app" is in the information consumption context above. Indeed as we demonstrated in M3 it is little more than a query over an information space. In the case of M3 and the RDF/OWL graph view of information, a navigation between chunks of information. Indeed this is the basis of Facebook's social graph.
The power here doesn't just come from the ability to easily navigate over information but also the ease in which reasoning is built on top; from the simple subclassing inferences to complex context specific, non-monotonic rules.
Through this reasoning and suitable ontological structures it becomes almost trivial to add functionality into the graph, eg: new messaging types, and apps which are designed to query for super-types of those automatically pick-up on these new objects. This is hard to do in an "app" - which are more like the traditional applications of old: fixed and unexpandable - who thought of Twitter and Facebook contacts when writing contact book apps all those years ago?
The point where we're heading here is that what we think that "apps" should have been are just queries over information with reasoning at the information store level, that is, pushing the logicl that gives semantics, interoperability and expandability down into the lower-levels of the information stack.
One can argue that "apps" in their current manifestations are optimised for the devices they run upon, eg: an app for iOS delivers the content in the form best for that device. However we would go further (and we made an amazing demo with M3 of this back in 2009), where we encoded how the information should be displayed in various manifestations, eg: list, tile etc - there was an ontology for this, and then let the device pick the best rendering for that informtaion based upon its local context. What made this interesting was the reasoning mechanism searched the information itself, the contained or linked chunks of information as well as searching the type hierarchy for display hints.
We did the same with actions too...and we even started on serialising computations and passing these around...true cloud computing...quite away from the humble, locked-in current definition of "app"...
References
[1],
,
(2004) sTuples : Semantic Tuple Spaces. Access (2004) IEEE, Pages: 268-277
[2] ,
Personal Semantic Web Through A Space Based Computing Environment. Middleware for the Semantic Web Second IEEE International Conference on Semantic Computing.
