« what's so magic about Gartner's latest Magic Quadrant update? | Main | Unix as a platform for DI is fading quickly »
December 8, 2009
Semantic rationalization blog series: part 2 - business rules and the Semantic Web
In my previous blog on semantic rationalization, I introduced you to our semantic rationalization concepts, our goals to make data integration more affordable and easier to use, and I drew an analogy between pipeline processing and collaborative development. I also highlighted the fact that the ETL developer often tends to be the bottleneck on an ETL project, which is why we believe it is so important that other user roles can contribute to the project.
Another domain of tasks that could benefit from contributions of non-ETL-developers is management of rules used during the data integration project. The holy grail of ETL tools, tracing back to Bill Inmon's Prism Solutions days, was the idea of having business analysts create the 'business rules' that would drive the ETL process. Unfortunately, this has proven beyond the capability of today's ETL technologies. Most tools require the business analyst to learn C, Java, ksh, or SQL to build these rules, an unrealistic expectation in most business environments, where Excel is the 'lingua franca.'
While there are business rule engines available now, these typically don't easily integrate with ETL tools, technically or 'religiously.' Even if we can't provide an interface for the business analyst to develop rules (I believe that this is, in fact, technically feasible), we should at least provide an interface that allows analysts to review and validate the rules created by the developer or other analysts - but rules engines typically can't help with this.
At this point (assuming you've read my previous blog on this topic) I hope you now have a reasonable understanding of the problems expressor is trying to address through semantic rationalization. On the surface, they are significantly different than the problems addressed by the use of semantics in Web 2.0, which may seem unfortunate, given that the names are so similar. In fact, on closer inspection, the problems are remarkably similar, and expressor's solution might eventually be used in combination with the semantic Web approach in the context of data integration. But that is a topic for a different, more abstract discussion.
So enough theory for now. Next time, I'll start digging into the actual mechanics of the expressor semantic data integration system.
- Michael Ruland, field engineering
Posted by expressor software at December 8, 2009 1:00 PM
Twitter 
LinkedIn 
YouTube