ChrisScott.org

Native apps – a necessary evil?

I recently saw a tweet quoting TBL, talking at Profiting From The New Web (which I’m very sad to have missed!), which went along the lines of: don’t develop apps, use open standards.

It’s a very interesting instruction. One I used to agree with…

Purely from a technical point of view it is difficult to argue with the logic. Being able to develop once and still create Web applications which work well on many devices – with different hardware features, screen sizes, etc – is very possible using the latest iterations of Web standards.

HTML5 allows developers to produce rich and interactive graphics and animations in their pages using the Canvas element. One can handle streaming media (fairly) effectively using it. Persistent client-side storage is even available, which can be used for offline applications, amongst other things. The very brilliant, and now widely supported, CSS level 3 specifications make it really easy to accommodate different devices and screen sizes by using Media Queries – an excellent example of that is colly.com (play with your browser window size or use your phone/tablet).

All of those technologies are very interesting in their own right but for the purpose of this post I won’t delve into the mucky details. If you are interested, or feel you need to brush up, I recommend following the excellent @DesignerDepot on Twitter.

The important point here, and I assume (which may be a dangerous thing!) the key point for the Open-Standards-over-native-apps argument, is that Web sites built using modern Web standards – running on a modern browser – have the potential to be just as feature rich as any native app.

That may not be quite true: to the best of my knowledge HTML/javascript does not support device specific features such as compasses and native buttons. So in that regard, apps have a slight edge. That said, I don’t think there are any huge gaps in the functionality available through the standard Web technologies. Certainly there are no insurmountable ones.

I do see one bit problem for the Web standards supporters, though. One big difference; one thing that Apple – and the others – offered which so far Web applications have failed to match. Micro-payments.

I’m sure there may be many people who disagree with that statement, but here me out.

Firstly, the importance of micro-payments. Whatever the difference in the functional capabilities of Web applications and native apps, Apple’s App Store essentially created an industry – or at least a sub industry. It was probably the first to market it’s applications as apps and certainly the most successful. 10 million apps have been downloaded and the App Store’s revenue in 2010 reached $5.2 billion. The median revenue per third party app is $8,700 – according to Wikipedia (and source) – and there are more than 300,000 apps available, equating to a $2.6 billion market for the app developers themselves. No doubt, then, this is big business. And (as big a fan as I am of FOSS) that kind of potential revenue has been the main driver in the success of the app movement, driven many software innovations in the name of competition and, most importantly, created an environment for entrepreneurs and developers to benefit financially from their creations. I would say – in my opinion unquestioningly – that the success of the App Store and its contemporaries is primarily down to a no-fuss micro-payment system where users feel safe and comfortable and not under pressure when parting with $3.64 (on average) of their hard earned cash.

You may argue that these micro-payment systems already exist on the Web; Amazon’s payment system – including 1-click – and Paypal could be seen as successful examples, amongst many others, no doubt. However, the argument which I’m contesting is not that Web-based systems are a better alternative to native apps but that open standards are… Amazon is no more open than Apple or Android. Google App’s – while very much Web based – doesn’t use a payment system which is compatible with any of it’s competitors or described in any specification (W3C or otherwise). In fact the W3C did look into this very issue in the 1990′s, although due to lack of uptake of micro-payments (how wrong they were) the working group was closed.

Anyway, to conclude this (now rambling) post…. it’s all well and good to plug open standards but, until the big issue of payments is resolved with an open standard, a healthy applications market – and hence the competitive pressures which have built pushed the boundaries of mobile software to what it is today – could not exist without closed systems and APIs.

I’m on the Semantic Web! Pt. 2

Ok. So in the last post I was talking about how I created an RDF graph to describe myself and found that I’d entered into a huge rambling geekfest about the design of the FOAF vocabluary. So, I decided to cut all of that out and post it here separately. For context, it follows directly from having created this RDF document. If your interested read on…

From that experience, of creating my own RDF graph, I had only one hiccup: using the FOAF vocabulary, while it is relatively simple to define a group (such as the company which employs you) and list its members (in that case, staff), it seems impossible to do it the other way around. Essentially, you cannot say “I work for OpenText” but can say “OpenText employs me”. I do understand why this is, though: it is fairly standard for predicates to assume ahas relationship not an is one (#me has foaf:name Chris, not is foaf:name Chris), and standards are essential for Linked Data to work.

You may think that the problem described above sounds pretty irrelevant (you may be right: read on), so let me run through my thought process:

Imagine two graphs, one describing me and one describing OpenText. In the OpenText graph there is a list of employees (as there is on Freebase) which include a reference to my graph. You could, then, search (for the purpose of an example) for the weblogs of OpenText employees fairly successfully. If, however, you were using my graph, you couldn’t find a list of colleagues of mine because I couldn’t add “Chris is employed by OpenText” to then graph and, hence, the two could not be connected.

Someone obviously agreed with that assessment as I discovered the RoleVocab vocabulary on the FOAF wiki. I used that vocab in my person profile document to assert that “Chris has a role in the organization OpenText”.

With hindsight, I think that might have been a mistake, though. My mind-frame was trapped in the resource – the me. Perhaps I should have been thinking about the whole RDF graph. Why couldn’t I include a separate resource about OpenText which only included my employment? Well, because the domain of the foaf:member property is foaf:Group and the foaf:Organization type is a direct subclass of foaf:Agent. Essentially, the foaf vocabulary is saying that you can only be a member of a group and not an organization. Personally, I think that the most semantically correct way around this issue would be to make foaf:Organization a subClass of foaf:Group or, failing that, foaf:Organization could be added as a second rdfs:domain property of foaf:member…. I may make the suggestion.

In the meantime, I’ve also added an OWL Object Property to the top of my RDF document which describes the predicate”employee”, as in “OpenText has employee Chris”.

So: apologies for the geeky and rambling post and please let me know your thoughts on the whole “Group has member Person”/”Person participates in Group” conundrum.

I’m on the Semantic Web!

That’s right. About a fortnight ago I decided it was about time to practice what I preach (well, specifically what I was due to preach at last weeks excellent ePublishing Innovation Forum) and get myself onto the Semantic Web. For those new to the concept of the Semantic Web, I’m talking about creating an RDF graph which includes a resource describing me.

So, without further ado, here I am:

http://chrisscott.org/about/card#me

The document at the end of that link is a FOAF Personal Profile Document. As you can see, the URI above includes the fragment “me”. This is a fairly important part of the Linked Data concept as it allows one of the axioms, that the URI is dereferenceable, whilst also identifying a resource, “me”, which can be used to link the graph to others. So, if you are curious, take a look at my personal profile and check out the “me” resource – it’s pretty simplistic but a good starting point.

So, how did I go about creating my personal profile on the Semantic Web? Well I started with a step I urge everyone to do: I signed up to the Opera community. You can do the same here. Once you’ve done that you can go to your profile and click on the “FOAF” link on the right hand side of the footer:

My profile page in the Opera community.

That’s the quickest and easiest way to get yourself represented on the Semantic Web but for me Opera do not give you enough control. For example, I cannot use the foaf:weblog predicate to point to this blog, only the one which Opera host for me (that said, they do support the rdfs:seeAlso predicate so my private personal profile is referenced by my Opera one). For that reason, I took the XML generated for my Opera community profile, tweaked it a bit and uploaded it onto this domain.

Give it a go! I’d love to hear how people get on…

NB: I ended up going on a bit in the draft of this post about the FOAF vocab design and got a bit technical, so I’ve seperated that content off into this post.

The future of video on the web

I’m getting rather excited about video media online. We’re on the cusp of a revolution in the way we produce and consume the medium.

I was working on a project recently which involved video content. It struck me that, although we have come on no end in terms of our ability to distribute video over the web in the last half decade, video content still has huge holes in the orthodox functionalities of more established media.

Most obviously, there is the dependency upon external codecs (i.e. not native to the browser). The solution to which, in the most case, is a Flash player. There are numerous Flash players available freely and cheaply on the web; they can usually play most of the common video types and depend only upon a single plugin, Flash. YouTube is probably the best known example of using Flash to play videos.

This approach creates problems all of it’s own, though:

• Flash players still have a dependency upon a browser plugin.
• The binary video – the original file – is not transparently available in the way that images and text are.
• Flash does not always cohere with de facto web standards: you cannot apply CSS to Flash, it does not respect z-indexes of objects (ever seen a drop-down menu disappear underneath a Flash component?).
• It does not have a full set of properties directly accessible for the content it wraps, as a other elements in a pages DOM do.

Don’t get me wrong, Flash has it’s place in the modern web. It is a fantastic platform for RIAs and rich, animated and interactive components of web sites. However as far as video presentation goes it is, essentially, a hack.

These drawbacks for video (and, in fact, audio) presentation, manipulation and playback have not gone unnoticed. One of the most important changes for HTML5 – first drafted back in January 2008 – is the handling of these mediums with the <video> and <audio> tags, now supported in both Gecko and Webkit.

The initial specifications for HTML5 recommended the lossy Ogg codecs for audio and video:

“User agents should support Ogg Theora video and Ogg Vorbis audio, as well as the Ogg container format”

The reasoning behind this drive for a single format seems obvious enough. Going-it-alone doesn’t really work as far as web standards are concerned (does it IE?). There were, however, some objections as to the choice of codec, namely from Apple and Nokia. The details of the complaints are not really relevant to this article but can be read in more detail on the Wikipedia page, Ogg controversy. At the end of the day it doesn’t really matter which format is used as long as it is consistent with the requirements of the W3C specifications; for this article I am going to assume that the Ogg codecs and container will be standard.

So, now that we have browsers (Firefor 3.5, Safari 3.1) which support the <video> tab and have native Ogg Coder/Decoders (At least FireFox) all of the deficiencies of video we discussed earlier become inconsequential. If video works as part of the HTML then it will behave as such. CSS, for example, will operate on a video element in exactly the same way as it would for an image element, z-index and all. The DOM tree for the page will include the video with all of its properties as expected. And, crucially, events and Javascript hooks allow web developers with no special skills (such as ActionScript) to control the behaviour of videos.

Silverorange.com have provided a nice example of using video with CSS. If you are running FireFox 3.5 or later you can check it out by clicking on the image.

But there is another – for me more interesting – feature of Ogg video (and, presumably, its alternatives): metadata. Now, metadata in video is nothing new, for sure, but having access to a video’s metadata as described above will lead to a whole new level of video media integration in webpages. The Ogg container, for example, supports a CMML (Continuous Media Markup Language) codec and, in a developmental state, Ogg Skeleton for storing metadata withing the Ogg container. Both of these formats facilitate timed metadata. In CMML one could define a clip in a video – say from 23 seconds into the movie up to 41 seconds in – and add a description, including keywords, etc, to that clip specifically. I will resist the temptation to go into a description of how Javascript listeners could be used to access that data but, in essence, the accessibility of the information to the web page containing it would allow a programmer to accomplish fantastic features with trivial techniques.

The most obvious example has to be for search. Being able to display a video from a specific point (where the preceding data may not be relevant) is not out of scope of the Flash based players but would be much easier to accomplish.

If we squeeze our imaginations a bit further, though, I think there is great potential for highly dynamic, potentially interactive sites to be based around video as the primary content. When demonstrating front-end templates for Nstein’s WCM I always pay particular attention to in-line, Wikipedia style, links which we create in a block of text using data derived from the TME (Text Mining Engine); in-line for text equates, with timed metadata, to in-flow for video. In the past video has, by and large, been limited to a supporting medium, a two minute clip to illustrate a point from the main article. With timed metadata this could be a thing of the past.

Imagine this: you have just searched for a particular term and been taken to a video of a lecture on the subject playing from 20 minutes through – the section relevant to your query. As the video is playing data is displayed alongside it, images relevant to the topic, definitions of terms, and as the video moves into new clips, with new timed meta data, the surrounding, supporting resources are changed to reflect – in-flow.

An example of using CSS3 with the video element from Mozilla.

As people appear in films and episodes links could be offered to the character’s bio and the author’s home page. Travel programs could sit next to a mapping application (GoogleMaps, etc) showing the location of the presenter at the current time. There are huge opportunities with this kind of dynamic accompanying data to enrich video based content. And, of course, all of the data from a particular clip can integrate into the Semantic Web seamlessly. RDF links and TME generated relations could easily be used to automate the association of content to a particular clip of a video.

The downside? Well the biggest one as far as I can see is the time-frame. Most publishers are continuing to commit to, and develop, black box style video players due to the fact that no one – a few geeks, such as myself, excluded – use cutting edge browsers. But when HTML5 gets some momentum behind it from a web developer/consumer point of view the horizons for video will be burst open wide.

Semantic Web? What’s in it for me?

There’s no doubt about it: the Semantic Web is the hottest thing in the on-line industry at the moment. It’s all over the web, on the speaker circuits, in multitudes of product labs. On-line publishers are being told again and again that they need to get there content into RDF triplets and create linked data. One of the questions they should be asking is: why?

This article assumes some knowledge of RDF although does not go into technical details. There are many good sites which introduce RDF, including RDF: about, which I recommend reading.

Okay, so some of the reasons why are obvious. Tim berners-lee‘s vision of linked data tying the WWW together has inarguable and massive benefits. The potential for applications utilizing knowledge gleaned from RDF triplets is mind-boggling. One of the points Dame Wendy Hall made at last months ePublishing forum was that if publishers felt that they missed out by not getting on board with the World Wide Web as sharply as they would have, with hindsight, then now was their opportunity to make up for that. Don’t miss the boat twice was the message; start thinking about the Semantic Web now.

And, for me, that sentiment – start thinking about the Semantic Web now – is even more pertinent than, perhaps, it was intended. In the mid nineties when the modern Web was taking off putting content on-line was a risky, uncertain business for publishers. There may have been some publishers who jumped in early and reaped the rewards, some were burned and some joined the party late, but knowing what we do now no publisher would have hesitated. So now the Semantic Web is the big, new thing; largely unknown and poorly understood (aren’t all new concepts?). But unlike the boom of the WWW – the scale of which was never predicted, even by TBL – we now do have some concept of the magnitude of what the Semantic Web could achieve. Certainly there is enough hype about it, now, that I, at least, can’t imagine the Semantic Web (in some form) not taking off.

So more than just looking at the augmentation of the Web with linked data as another opportunity to not miss the boat, we should be planning what we are going to do with this data. I can see the uses (visualisation?) of RDF triplets falling, broadly speaking, into two (non mutually exclusive) categories:

1. Representations of specific facts
2. Representations of generic facts

Currently there are a number of examples of interfaces for interacting with linked data available on the web. RKBExplorer is one of the best. There are also numerous examples of geo-data mapping applications, etc. These are representations of specific facts. That is, we have a question in mind and are displaying the answer(s). Take, for example, a set of triplets which link articles to there author, in the form:

Using this information a piece of software can now ask the question: who wrote this article? And it would get back the correct answer: me. Now, in reality, this would be an extremely over simplified knowledge base; a more likely set up would include a foaf:Person and possibly a bnode referencing some Dublin Core meta-data (don’t worry about the terminology). Then the scope of available questions widens dramatically. Where do the colleagues of the person who wrote this article live? Where can I find a photo of the author? By complying with these standard ontologies software can make pretty accurate assumptions about valid questions to ask.

In the same vien, whole new possibilities become achievible in terms of mash-ups. Say I’m writing a review of a new novel. If I can assume that Amazon and all the other big online vendors are producing RDF documents describing their stock I can simply query for ISBN which I know is stored as dc:Identifier and return all prices which I can assume (for the perpose of an example) are commerce:Price. In short, RDF is a great way of managing distributed data – which is something you’ll hear a lot of if you dig into the subject.

But even with applications utilizing complex webs of linked data in this way they are still only asking predefined questions. “I know how to display a latitude and longitude on a map so I’ll find out those details”. “If a foaf:Person has a picture I’ll display it by their posts”.

The second category of uses I described for RDF triplets was the representation of generic facts. This is something I haven’t seen done yet (with the possible exception of the SPARQL – which is not appropriate for this discussion) but seams, to me, at least, to be an obvious next step. Let me explain…

The beauty of the RDF approach – beyond any other – is that is allows the document owner to describe any fact with computers still able to extract some kind of meaning from it. This is where the predicate of the triplet comes in and why using a URI is so important. It goes without saying that if a well used standard exists for describing any component of the triplet then it should be used but if one doesn’t exist you can still describe the fact. I could create by own URI which describes the predicate ‘ate for lunch’, if I so pleased. And then I could publish the fact that I, Chris, ate for lunch beans-on-toast and, in theory, an application with no prior relation to me could understand what I meant (at least to some degree). The application in question would, possibly, not understand what “ate for lunch” means but it could point it’s user to the URI I created and, hence, explain the fact to them.

Finding new ways to represent these generic facts has to be on the horizon of anyone interested in pushing the Semantic Web into the mainstream. It may be through widgets and apps, it may require a new generation of browser, but it should happen. I have no doubt that the kind of mash-ups and queries that I described as representations of specific facts are achieved much, much more easily using RDF channels for data but, essencially, we could already represent those kind of links between data. I could build a database of all the authors who write on my site and produce a Google Maps integration to show you where they live. However, I could never – without a unified system of triplets – even concieve of displaying arbitrary facts to acompany an article unless someone had manually written them. Certainly, one could not display those facts dynamically, it would be impractical. But, as the RDF standard becomes more popular, allowing applications (widgets, etc) and search portals to do just that is very much a realistic prospect.

If we, as online publishers, are going to jump, two-footed, into the Semantic Web (which I firmly believe we should) we should also be thinking about our goals and reasons for doing so. No publisher’s target is to help search engines answer a searchers query without visiting their site; or contributing to the building a knowledge base of unparrallelled proportions. No. The goal has to be the same as it always was, to improve the users experience and to drive web traffic. So, sure, don’t get left behind, get content into RDF format, but why stop there? This is the time to be thinking about how to get ahead of the curve, how to use this data. Certainly I am…

Open Source v traditional Software (ding, ding, ding)

At the tail end of last month I spent two days attending talks at the yearly Internet World exhibition. I always enjoy listening to speakers and the quality was, by and large, very good. On the final day CMS Watch (@cmswatch) hosted a panel discussion in the Content Management theatre entitled: “Open Source v Traditional Software”. It’s was a strange title, I thought, as the line, for many vendors, between open and closed source becomes more and more vague. This blending was, however, represented in the panel, which included Stephen Morgan (@stephen_morgan) of Squiz – a commercial open source vendor.

On the whole the panel was very good and the debate interesting. The open source contingent argued eloquently  the pros of spreading knowledge throughout the community and of the response times to bug fixes compared with the release cycles of proprietary software. One of Stephen’s responses when asked for reasons to go with an open source system, however, struck me as – at best – ill conceived.

Stephen had argued that as a customer of a closed source software retailer you fall, entirely, to their mercy in terms of functional changes. The assertion was that when you – as a customer – have access to source code you can modify it to suit your needs. Conversely, he claimed that changes to a closed source solution could only be requested, may never happen and would be subject to a lengthy release cycle even if they were implemented.

Now I’m sorry but that is just not the case; as I told the panel once the discussion was opened to the audience. The software I work with, Nstein’s WCM, features an expansive and  well designed extension framework to do just what Stephen was referring to. In fact, I went further and put the polemic to the panel that hacking core source code is obviously not desirable and severely hinders an applications upgrade path. Stephen’s countered with the fact that changes made to the code-base can be submitted to Squiz (or almost any other open source software maintainer, for that matter) and may be committed into the core application.

Before I start a holy war here (and a succession of flames in this sites comments) I would like to state my position on open source: I love it. I love the concept. I love free software. I love the freedom to modify and distribute software. Basically, I get it. I’m a huge fan of Linux and at the end of the day a PHP programmer. Just yesterday, I spent my Saturday contributing PHPTs (that’s PHP tests, for non-geeks) with the PHP London user group. I really do dig open source. Also, for the record, I thought Stephen Morgan represented his brand and community very well and I enjoyed his commentary; this is not meant to be a personal attack ;-) .

In fact, this post is not criticizing open source software at all. The discussion here, as far as I am concerned is about best practices. Okay, sure, one can modify the source code to an open source project and that change may be incorporated into the software. May be incorporated; probably won’t be. And with closed source software that option is not available – you have less choice. But that is, I think, a good thing.

At least the prelude to a good thing. Software evolves, like all technology, and the beautiful simplicity of Darwinian evolution applies. It’s survival of the fittest. If we, at Nstein, were to compete with open source CMS projects with a solution which was not customisable, which had no mechanism for modification we would have died out. The fact is we make a vast amount of customisation possible – we’ve had to. Because we don’t encourage customers to delve into the core source code (it’s a PHP app so they can if they really want) we’ve had to employ other methods. Extensible object models built around best practices derived from industry experience. Plug-in frameworks. Generic extension frameworks. If one of our customers cannot extend or change something that they need to the chances out that another client will at some point want that same, absent flexibility. So, through good design practices we have constructed a system which clients can (and do) modify, yet when they decide to upgrade to the next point release it is a trivial process.

Now, I’m not saying that open source software is poorly designed. I’m writing this piece now on WordPress – a fantastic example of an open source project – which features an extremely rich and well documented plug-in framework. The sheer number of plug-ins and themes available for WorldPress is a testament to the system. And, as with Nstein’s software, when I upgrade WordPress all of my extensions still work (at least 95%, or more, of the time).

I doubt anyone would disagree with the merits of a plug-in based system. My interest, however, is in this question: how much of a temptation is there to hack open source software? I know I’ve done it in the past. I’ve heard a number of times that Drupal upgrades are nigh on impossible due to the nature of the inevitible customisations a Web content management system requires. I’m not in a position to answer that question authorititively, and I won’t attempt to. I would like to stir the debate up though. So, thoughts, please….

Creating compelling content in the Web 5.0 world

Whoa, there. Web 5.0?

Okay, so I made up web 5.0. Actually, I detest the numbered generations we’ve applied to the web. The main problem I have with these terms is that they imply a linear progression. They suggest that we are going to abandon the interactive web, Web 2.0, for the semantic web, Web 3.0. Obviously we aren’t. I doubt anyone would even suggest it. Web developers will continue to use both. Hence Web 5.0 (do the maths).

I’m going to drop the term now – it was just a joke. The modern World Wide Web is, in fact, much more than just the three so-called generations – although clearly they are very important. I can identify three main concepts (not technologies) which are facilitating the current evolution of the web:

• Interactivity (2.0)
• Semantic understanding (3.0)
• Commoditization (the Cloud)

Nothing ground breaking there. And we, as users, are certainly seeing more and more of these big three in our daily use of the web.

Interactivity is fairly obvious. I think the biggest revolution in interactive content came about as Wikipedia took off. Undoubtedly the most expansive (centralized) base of knowledge the world has ever seen – and written by volunteers, members of the public. It really is a staggering collaborative achievement. Then there’s blogging, micro-blogging, social networking, professional networking, content discovery (digg, etc), pretty much anything you might want to contribute, you can.

Semantic understanding is a little trickier to see. That’s hardly suprising as it is so much newer and far less understood. Believe the hype, though. The sematic web is coming and it will change everything (everything web related, that is). If you don’t believe me try googling for “net income IBM”. You should see something like this:

That top result is special. It’s special because it’s the answer; it’s what you were looking for. No need to trawl through ten irrelevant pages to find the data – it’s just there. Google managed to display this data because IBM published it as part of an RDF document. If you search for the same information about Amazon – who don’t, no such luck. (That particular example was given by Ellis Mannoia in a great Web 3.0 talk at Internet World this week – so thanks Ellis.)

That leaves us with commoditization. Specifically, the commoditization of functionality from a developers point of view. This concept is largely, although not exclusively, linked to the Cloud. The term “the Cloud” is used broadly to describe services make avalible over the internet. GMail, for example, is email functionality in the cloud. Users don’t need to install anything to use GMail (bar a web client) they just use it when they want, from any computer. Many of the Cloud services out there are available as APIs, and that leads to the commoditization of functionality. Say I want to add a mapping application to my web site to show my audience where I am. A few years ago that would have been a significant amount of development work. These days it’s trivial – you just make a call to the GoogleMaps API. And so map functionalities become a commodity.

The point of this post, however, is that these are not mutually exclusive concepts. There is no reason why you cannot combine semantic understanding with Cloud computing, or UGC, or both. Quite the opposite: combining the three should be the goal.

There are problems, however. Utilizing Cloud computing requires a certain amount of adherence to standards – fitting in to an API. And semantic understanding (and meta data, in general) takes time to accrue. In general those two constraints don’t work well with Web 2.0 functionality.

Let me give an example: If a user contributes a comment to an article they probably won’t take the time to add the meta data required for semantic understanding to be achieved. In the same way if they don’t give their location you can’t show them as a pin on GoogleMaps.

However semantic understanding is (IMHO) more than just the use of RDF documents. Tools like Nstein’s Text Mining Engine can be used to create a semantic footprint describing a piece of text. I’ve talked, in previous posts, about using the data gleaned by the TME in imaginative and experimental ways. Take the example above. If a user were to post a comment about a talk they attended the TME could extract, not only the concepts of the comment, but also data like the location of the subject. That semantic understanding can be used to programatically call the GoogleMaps API to add a new pin in your map.

And there you have it. Semantic understanding of interactive content used to harness the power of Cloud computing. One of the most important benefits of the TME, for me, is the flexibility it affords you. If you know that you can get access to that kind on information it opens up all kinds of possibilities. Exploring some of these possibilities has to be the focus for making a brand stand out against the plethora of content suppliers and aggregators available; for improving the users experience and gaining their loyalty.

So it’s time to stop thinking about Web 2.0 or Web 3.0 and start thinking about the technology and techniques available and how they can be used to the greatest effect.