Schema.org Mark-Up Vocabulary Mapped To The Web Intents Specification
Writing on the Semanticweb.org site, Jennifer Zaino describes how Schema.org and the Web Intents specification are mapping terminology (Vocabulary) from Schema.org to the Web Intents specification. She quotes from Michael Hausenblas of Digital Enterprise Research Institute (DERI), National University of Ireland, Galway:
“With Schema.org we have a way to describe the things we publish on our Web pages, such as books or cameras. And with WebIntents we have a technology at hand that allows us to interact with these things in a flexible way,” he [Michael Hausenblas] wrote. With Web Intents, a framework for client-side service discovery and inter-application communication, services register their intention to be able to handle an action on the user’s behalf.” [Read More]
On the Web Of Data blog, Michael Hausenblas gives an example of how this might be used practically to offer a search engine user actions they can perform in-line with search results. These might not seem like much of a big deal to those used to close-ended applications like DAM systems where there are options to download, request permission to use, transcode etc. are just a click or two away. But where things get more interesting is if one imagines that many systems that are not directly integrated were to use this protocol.
Right now, if you want to integrate DAM systems (or any content technology) with either other products or different systems, then you have to request API documentation from the other party and commence a complex process of mapping data and functionality from one system to another. As has been pointed out, APIs are not Lego and the exercise is akin to mid-flight aeroplane refuelling – full of logistical challenges and risks to all parties (and unlike that analogy, integration jobs never really have a defined conclusion either). The kind of ‘drive by’ integration that is discussed in the article opens up many possibilities for either vendors or users to leverage a wide range of other functionality that wasn’t necessarily included in the original application (or maybe even thought about).
The example used to illustrate the potential (purchasing cameras from Google) is interesting because it’s more consumer oriented than a business application. As seasoned tech observers will be well aware, to enable a given technology to become cheap enough for widespread use, it requires take up by the consumer market to generate the economies of scale and momentum that can force the price down. I have discussed in the past about how vendors are likely to need to partner up to service the full range of end user requirements, this type of protocol would make that task much easier to achieve. On the flip side it also allows end users to potentially ditch the option their vendor is proposing and use an alternative too.
Whether it will be these two protocols specifically that everyone uses in the future remains to be seen, but the direction of travel and the trend towards simplified integration of web systems is clearly in play with both time and money being applied to it by a wide range of parties.
Share this Article: