Uche Ogbuji
SemanticWeb.com Contributor

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 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.

This URL openness leads to a free-for-all where links are used in a million places with a million nuances, and no clear order or control. There is no schema, no neat wrapping application. Your main hope of figuring out what’s wrong is to view source. This sounds like chaos to an enterprise data architect, but these are the very characteristics that make it work. And despite appearances, there is indeed order. And it comes not from central planning, but from the marketplace.

Google provides the order.

Obviously, it’s more than just Google Inc., The point is that open URLs and uncontrolled linking means that anyone can contribute to the chaos, but it also means that anyone can work on innovations for providing some means of management and control, which they can then sell to users.

Clearly no enterprise is interested in a public marketplace for its internal, proprietary data, but this doesn’t mean they have to be closed to some of the benefit. In the marketplace for applications and services to integrate into your enterprise, Web architecture shines the spotlight on features and innovation, rather than nit-picky application and version support. The same openness built on lightweight standards, and the same resulting view-source mentality means that systems integration doesn’t mean losing integrity, but rather sharing benefits.

Enterprise architects have much to gain by using URLs for application IDs, and making it easy to share these URLs. These don’t have to replace the internal IDs of traditional databases. They are just another little bit of information to be related through Web architecture. There is plenty of real-world experience available in the design of such systems, and plenty of real-world proof that open information ecosystems may be sloppy, but that they work, and that they endure.

Announcing Semantic Tech & Business Conference - San Francisco 2012

Semantic Tech & Business Conference is returning to San Francisco in June! Join us from June 3-7 for complete coverage of Big Data, Linked Data, Extreme Information Management, and Semantic Web. From breakthrough approaches to solving business problems to the big data implications of fast–evolving technologies, SemTechBiz provides you with an unparalleled interactive experience and delivers tangible business value. We're offering a special early rate when you register by February 17. Sign up now!