This post originated from an RSS feed registered with Ruby Buzz by Obie Fernandez. Original Post: Semantic Enterprise Architecture Feed Title: Obie On Rails (Has It Been 9 Years Already?) Feed URL: http://jroller.com/obie/feed/entries/rss Feed Description: Obie Fernandez talks about life as a technologist, mostly as ramblings about software development and consulting. Nowadays it's pretty much all about Ruby and Ruby on Rails. Latest Ruby Buzz Posts Latest Ruby Buzz Posts by Obie Fernandez Latest Posts From Obie On Rails (Has It Been 9 Years Already?)

Dug up this little gem from my archives, from June 2005. Back from the days of Madrid and Protege, when I was really excited about this stuff. Anyway, it's more relevant today than ever, probably, which is why I decided to post it. I wonder if the Semantic Web Education and Outreach interest group (SWEO) would accept me.

Semantic Enterprise Architecture

There are a number of factors contributing to my recommendation for a Semantic Enterprise Architecture as the basis for ongoing and future development projects.

First of all, our integration effort is expected to be high. We are dealing with a large number of geographically-dispersed development assets at various skill levels, and that is just within this organization. Nevermind the myriad external systems we need to integrate with. To maximize success for our integration goals, we should rely on technologies that lend themselves easily to generated documentation and flexible toolsets for integration analysts.

Mapping should be accomplished at the conceptual level rather than at the document-type level.

We already know that the basic premise of tying all our disparate software assets and development teams together with a service-oriented strategy is going to involve a substantial integration effort. According to EAI experts, 35-65% of the costs of that integration effort is consumed by the difficulty in resolving semantic mismatches between systems. This is globally referred to as the “mapping problem” and there are many vendors that sell mapping solutions to facilitate the task of mapping (i.e. BIE). However, the emerging technology of the Semantic Web, long used by medical research software engineers and other esoteric IT niches is finally achieving recognition as the foundation of a wise and cost-effective integration platform.

We plan for web services to be ubiquitous and we are encouraging reuse, therefore we have to plan and deploy them characterized not only in terms of their input and output parameters specified with XML Schema (RELAX NG would be better!) but also in terms of their semantics (using RDF/OWL) – a.k.a. metadata.

Indeed, we’ve already spent a considerable amount of time and energy thinking about common XML schemas, with an example being our logistic XML plans, meant to be used as a common vocabulary between collaborating services. The principle problem with limiting standardization efforts to generalized XML document types is that they lose a significant amount of semantic meaning that would otherwise be present if they were modeled based on specific application domains. The main reason is that semantic meaning is captured in XML Schema is via the syntax and structure of the document itself. The schema represents a class instance with its contained data type instances and object references. We should still have a rich set of XML schemas that we make available to integration partners, but they should be written in such a way that they are extensible and generate RDF-compatible instance data.

All resources a.k.a. web services a.k.a. system components in our proposed architecture should provide information about themselves. This is commonly referred to as “metadata”, but we prefer calling it semantic data or more simply, ontologies, in order to convey the full intention of this plan.

• Ontologies should be in a standards-based machine-processable format
• Components of the architecture should be able to “reason” about (meta) data
• Process for collaborative authoring and maintenance of ontologies should be defined
Marketing should take into account how the parts of our ontologies that are made public help the industry and map to leading global standards. I also believe that we can get substantial good P.R. (if desired) about our support of Semantic web standards.
• Vendors that provide tools to support the initiatives described above should be considered. In many cases, these vendors have rich toolsets available which will minimize our need for custom application development.

Justification primarily exists in the form of massive cost savings, both short-term and long-term.