The Semantic Web’s Controlled Chaos

The gospel of database architecture speaks of entities, which are related in very careful ways to construct information systems, the foundation of successful enterprise applications.

These entities are ethereal phenomena that take shape in the form of rows in enterprise databases, signified by identifiers. These identifiers are meant to be no more than a handle for the algebra of abstract entities, and they should not take on a significance of their own. They should be opaque. They should have no "business meaning."

More From Jupitermedia

Vote Now for Products of the Year Post a comment Email Article Print Article Share Articles Digg Newvine DZone Reddit Slashdot StumbleUpon del.icio.us Facebook FriendFeed Furl Military, Universities Team Up on Big CALO Project Radar’s Twine Ties the Semantic Web Together A Snapshot of Semantic Web Trends Semantic Web as Competitive Advantage Smartening Up Your Links If you want to comment on these or any other articles you see on Intranet Journal, we'd like to hear from you in our IT Management Forum. Thanks for reading. - Tom Dunlap, Managing Editor.

This database approach is a great way to enforce order. The schema provides strict rules that govern entities and their relationships. The application wraps this order neatly, and all users see is a well-oiled machine. The problem comes about when the real world begins to strain the boundaries of the abstract entities behind all this order.

Sometimes it just turns out that an entity needs additional properties or relationships to meet evolving needs. Such changes cause some pain, generally in the form of cross-your-fingers-and-"ALTER TABLE," and then the required application re-coding. In other cases the very nature of the information space evolves so that the original system of identifiers and relationships needs to be restructured. Sometimes integration projects force a leaking of identifier integrity through messy mappings.

Such major changes are inevitable in the case of major changes in regulation, or mergers and acquisitions, or the re-use of an application in another setting. But they can be triggered by even smaller forces, and in general -- despite the best intentions and skills of database engineers -- it's all too common for an application to show serious strain from real world changes, and before you know it, the sleek machine is leaking considerable oil.

Contrast this to the Web, which is sloppy by design. There is never as much order in even the smallest corner of the Web than in a well-designed enterprise application, and yet Web applications often retain their value and effectiveness despite being subjected most directly to the madness of real world change. It turns out that the sloppiness is a virtue. It means less disruption when entities change shape and even basic nature, and are stretched to fit wildly different viewpoints. When relationships bend and even break on the Web it causes inconvenience, but rarely fundamental problems. The Web is known for its ability to route around damage, and such resilience would serve enterprise applications just as well.

The main reason for this resilience is that rather than deprecating the role of entity identifiers, the Web embraces them. URLs are everywhere. They are made widely available for use and abuse, and they suffer plenty of both. When URLs are covered up, this is considered defect, as in the early generation of AJAX applications. Parts of URLs, specifically domain names, can be more valuable than the referenced contents.