But there's a heck of a lot that this simple point-to-point integration doesn't really give you.
You haven't really captured the semantics of anything -- any formal relationships or any kind of metadata around what that relationship is about. The page doesn't know that what's referenced on it is actually a task, and the task doesn't know that it's represented on the page. When you go to the task in an issue tracking app, for example, it doesn't tell you that it's been referenced on a page. It couldn't tell you what that reference is or what that relationship is. Is that page representing a design document, a requirement, or is this just a comment? It can't tell you.
Then there's another dimension of this. What if you want to know this relationship -- not just between the wiki page and the task, where you have referenced it -- what if you want to know it somewhere else? Maybe there's a customer case associated with either the task or requirement in Salesforce. You have no idea whether that case has any relation to the task, nor do you know if there're any documents associated with it in the wiki. You cannot access these relationships in other applications.
Knorr: You're talking about capturing context.
Nath: That's right. The simple example that I described illustrates that in typical point-to-point integration schemes, you don't capture the context between the two. Not only do you not capture the formal context, it's not available anywhere else. Nobody else can interpret that or know anything about it.
Maybe the requirement has multiple tasks associated with it, but each task is associated with a different version of that requirement. So even though it's a single page and five tasks referenced in it, the relationship between each task and the requirement is actually a different relationship, meaning that it has some different attribute values. Without semantic context you can't capture that.
Finally there's the problem of synonyms, both broad terms and narrow terms. Many enterprises are investing in creating their own internal vocabularies and taxonomies. They're doing that because they need to get on the same page when they're talking across geographies and across departments.
Semantics gives you support for all of those things. It's a very simple capability.
Knorr: To what degree do applications need to be compatible with semantic technology?
Nath: That's the magic of it -- applications don't have to care. The bottom line is that you have a mechanism for mapping whatever applications represent. The application does what it does. Our platform and our framework are different than Trigo, because we're not creating a single source of data that everyone then goes after. What we're doing is capturing the semantics in a central location and interrelating concepts with each other, based on pre-defined domain-specific metamodels, so the semantics can both be consistent and available to all applications whenever the context is needed.