Semantics & SOA - part 1 "Survey"

Over the next month we are going to take an in depth view of how Semantic Integration is being applied to SOA. The notion that the Semantic Web and SOA might be linked began to emerge in 2005 & 2006. Since then it's been gaining some momentum. Keep in mind though that "Semantic Integration" & "Semantic IT" do not by their nature narrowly confine themselves to SOA or the Web. However, Services Oriented Architecture is a natural, ready-made proving ground for what we're describing on this Blog.

This first post reviews some interesting resources on the web that illustrate the genesis and evolution of the combination of Semantics and SOA.

Conceptual Framework:

• Bringing Semantics to Service-Oriented Architecture:Ontology-based Mediation for eGovernment

This is an excellent briefing which lays out basic concepts and potential applications for SOA, presented by the Chief Scientist at Top Braid, a semantic web technology provider.

• Managing SOA Semantics Using Ontologies and Supporting W3C Standards..."Web 3.0?"

A concise overview from the Zapthink crew.

• Semantic service oriented architecture

The wikipedia take, or one of them anyway...

Semantic coupling

An excellent assessment of why many SOA efforts are falling short...
excerpt "Unfortunately, syntactic coupling is the easy part. Semantic coupling is the harder part of the problem, and SOA does little or nothing to address this challenging issue. Semantic coupling refers to the behavioral dependencies between components or services. There’s actual meaning to the interaction between a consumer and a service."
We will be taking a much closer look at this issue soon...

Interesting Applications:

• Semantic SOA to Promote Integration of Heterogeneous B2B Services
• The Axiom Project (we will look at this further soon)
• SAIC Building Semantic SOA
• Semantic Interoperability - Revelytix
  

More links Courtesy of Mills Davis:

• Smartlogic - Semantic Middleware
• Fighting Fraud with Semantic Technology
• Business Semantics, Enterprise Architecture & Data Architecture
  

In our next post we will try to outline the architectural imperative for using "Semantic SOA."


copyright 2008, Semantech Inc.

Semantics & Governance

Someone asked me recently whether or not there some type of tangible relationship between Semantic Integration and governance - it was an excellent question and the answer is a resounding "Yes."

Let's approach this at each of the levels where it applies:

Level 1 - Understanding the Nature of Governance at a Conceptual Level

Level 2 - Using Governance as an enterprise process medium

Level 3 - Using Governance as a foundation for detailed policy management (at the technical level)

While much of the current dialog in IT has focused on SOA Governance, IT or Enterprise Governance has a much wider scope than Services Oriented Architecture. And of course all of this extends into business areas or domains that go beyond IT. One of the great things about Semantic Integration is that at its heart it is not limited to Information Technology per se, Semantics provide the foundation for Every aspect of an organization, not just its IT capabilities.

So let's return to level 1 - our first problem is that most organizations don't currently agree on what Governance is. As evidenced by our discussion thusfar, Governance can be directed at many specific areas or be viewed holistically across them all. Semantic Integration helps us determine the core definitions and relationships in this conceptual competition - at the heart of all Governance definitions lies the need to conduct "Oversight." The corollary to that is the ability to engage in active remediation of issues discovered within the scope of oversight. These are both 'management' activities.

Our next post will explore level 1 Governance in more detail...


Copyright 2008, Semantech Inc.

The Here & Now of Semantic Integration

I've read some articles again this week explaining that the promise or potential of Semantic Integration is still a bit far off from being able to engender significant impact to the enterprise. Perhaps, it is worth examining the subject more as a practice approach rather than a standards or technology dependent facilitation medium.

By that, I'm simply reiterating that "Semantic Integration" is not synonymous with the "Semantic Web." There is a quite a bit that can be done right now with the techniques being described here (in concert with a limited but growing set of Semantic tools, although they aren't always required). As our previous post highlights, one of the first places where this can occur is with Enterprise Architecture. Anyone who has ever spent the time reading through DoDAF data models or building meta-models in Metis can testify quite convincingly that the entire field of EA is essentially one giant semantic exercise. I still tend to describe myself as an Enterprise Architect or Integrator; it was specifically because of my roles that I was drawn to Semantics as a way to solve a number of persistent and related challenges.

Take that further, what underlies UML, design patterns and J2EE language syntax ?... more semantics. It's already here, it's already pervasive within IT, but what we haven't done yet is fully appreciate this linguistic tower of babel we've created (and unlike the real world where the approximate number of languages is more or less stable with several universal translation modes, IT adds new semantics EVERY DAY).

Semantic Integration begins with this realization - that all enterprises represent ecosystems or cultures with unique semantic perspectives. Furthermore these virtual ecosystems are unlimited in regard to how many relationships may develop (we not only have individual entities within communities and communities within communities, we also have dynamic re-alignment both externally and internally). So step one is simple, define our enterprise perspective - this is the foundation for all other IT efforts and can be done using any number of tools starting with pencil and paper. How many data standardization or MDM efforts skipped this step and focused on defining core data elements that were already biased toward DBMS paradigm or another?

Semantic Integration is IT's first, future and favorite natural language activity. Eventually all discovery and all IT-related capabilities will be managed using natural language rather than XML, SQL , J2EE or some other technical proxy language or syntax. The sooner that occurs, the sooner that we will recognize the benefits both of IT and Semantic Integration. So how does one get started - it seems daunting, well maybe it is if you are too tied to one architectural perspective or language but if you can view this situation with an open mind there are several ways to get started.

(Next Post - Getting started with Semantic Integration...)




This view illustrates a real-world example of how Semantic Integration was introduced into a large enterprise without requiring a radical influx of Semantic Technology...

Copyright 2008, Semantech Inc.

Semantic Integration & Enterprise Architecture

In many ways, Enterprise Architecture (EA) is as misunderstood as Semantics. Although EA has been practiced across a much wider community of IT professionals for a longer period of time, it still suffers from an identity crisis. Is EA the mandatory precursor for model driven development, or is it part of a bigger picture and if so, what is that picture?

It is my contention that the reason Enterprise Architecture is still misunderstood in many quarters and often unsuccessful in practice is precisely because it does exist within the context of a larger picture. All too often, that larger picture is simply ignored leaving those executing EA projects somewhat perplexed as to find meaningful ways to make their efforts relevant to the organization sponsoring their efforts.

Enterprise Architecture represents a practices, tools and techniques which have evolved to help define the nature and state transitions of an organization from an IT perspective. The business view of the enterprise is of course included within this perspective but EA at its heart is and always has been driven by technology. The EA perspective is of a virtual entity, perhaps even the cyber-identity of an organization. This view allows those who manage and maintain complex system of systems ecosystems through exploitation of a holistic characterization of all capability elements. However, like most things in IT, EA as a discipline suffers from a lack of clarity regarding its core principles and approaches. In other words, there is no agreed upon definition for any aspect of Enterprise Architecture right now.

Seeing a big picture - an example of a "Meta-EA view"

So, Semantics and EA come together on many different levels; first in the need for one to clarify the other, secondly in the ability to build that larger context and big picture view of where EA fits along with all of the other aspects of IT. To understand the complexity of the problem, it is worthwhile to capture some of the competing definitions that one current finds associated with the term “Enterprise Architecture:”

• Enterprise J2EE Architecture – This has been formalized within the curriculum and certification paradigm of the Sun Java Enterprise Architect designation. [http://www.sun.com/training/certification/java/scea.xml ]

• Federal Enterprise Architecture (FEA) – This has been defined by the Federal Government and supported through certification paradigms. http://www.enterprise-architecture.info/EA_Certification.htm

• Department of Defense Architecture Framework (DoDAF) – A wholly separate framework paradigm from FEAF.

• ToGAF, Zachman Architecture Frameworks – Commercially driven approaches.

• Unified Modeling Language – Often included within the context of other approaches but also often used standalone to manage EA efforts.

• Agile Enterprise Modeling & Architecture – Much more application development focused, generally less formalized than strict UML.

• Other Technical Specific Architecture – This is a long list and can include things such as .NET, Web 2.0, and literally 100’s of other software products.

• Service Oriented Architecture – This often now is bundled with business modeling using BPEL.

• Semantic Architecture – Yes, there a few people using this now although mostly within the context of semantic web technology or pure Ontological development.

So, what then is Enterprise Architecture, really? Is it a framework or set of frameworks, is it product specific skills, is it language specific skills, is purely technical or partially business focused, is it the metamodels and notation language used to characterize design?

Semantics allows us to integrate Systems & Architectures

The simple answer is that EA has been and will be what it needs to be to those who need it. There is no one approach now because no one approach will handle all of the related duties that architects are saddled with. The more important question has always been, will we find a way in which we can coordinate the various types of EA activities. This is an exact corollary to the questions that helped launch EA as a discipline (of set of disciplines) some twenty to thirty years ago. At that time pioneers in EA were looking for a way in which they could combine and coordinate the complexity of their systems environments. So, now its seems that EA has lead us to meta-integration. And what is the one approach we now have to tackle the problem at the top of complexity pyramid – Semantics.

copyright 2008, Semantech Inc.

Semantic IT Practices

As noted in a previous post, the current set of methodologies employed in the day to day IT operations of a typical enterprise is poised for perhaps its most significant paradigm shift in several decades. This evolutionary shift is not the introduction of Semantic technology or standards per se, but rather the complete re-visioning of how IT works in the context of Semantic Interoperability. Semantic IT provides us with two crucial capabilities that we simply never had before:

1 – The ability to abstract the governance and maintenance of the systems under our control in an automated fashion.

2 – The ability to link all the various disparate IT-related processes through that same abstracted Semantic governance layer.

What’s really missing at this stage are the semantically enabled methodologies and/or practices that will allow us to exploit these capabilities effectively.

So what exactly is a semantically enabled practice or methodology? The difference that Semantic Enablement brings to enterprise operations is the deliberate focus on operational fusion or merger of processes in an effort to achieve a holistic management paradigm. This means that there are no longer any “stove-piped” approaches or technologies, all efforts must have the capability to inter-relate with all other capabilities and share the same foundation.

This holistic approach will require several new or at least modified IT practices with updated methodologies designed to take advantage of both the philosophical and technical shift in thinking. It is likely that this should lead to a certain level of consolidation in the number or diversity of existing IT practices as the central tenet involved is essentially holistic awareness and interoperability. Once it is realized that all aspects of IT architecture and operation are in fact related, the need for diversification and specialization will be reduced. There should not for example, need to be separate disciplines for Master Data Management and Semantic Integration, as MDM represents a specific application of Semantic Integration across multiple data sources. In fact, many or most aspects of data architecture or integration could at some point be considered within the umbrella of Semantic Integration.

One of the real benefits of viewing IT methodologies or practices this way is the deliberate attempt to keep them technology agnostic. These practices are not driven by vendor solutions. Previous practice approaches based upon individual or categories of vendor solutions have often proved short-sided and counter-productive, leaving the enterprises which adopted them vulnerable in many ways. The application of operational IT capability (i.e. business services) doesn’t require specialization of support infrastructures, instead it should have a flexible common framework that can be redefined as needed. Our goal is not to be able to predict all possible permutations of our solutions and build that into some rigid roadmap – the true goal is to give control of that map to those who need to adapt their solution in their own context, according to their needs.

That foundation then is an abstracted governance or management layer which mediates between all others aspects of IT architecture. It is accessible to and modifiable by stakeholders, which allows for much more economical and efficient governance processes. One of the most exciting parts of this is the opportunity we now have to merge design, architecture and governance using semantic modeling. This will likely manifest itself in a blending of ontology management and EA framework or even agile modeling techniques.

I’ve taken an initial stab at defining a set of Semantic IT practices, these have all been developed to replace existing counterparts and designed to be interoperable with one another. These practices encompass most if not all current IT processes and include:

Semantic Integration (most generic in nature, next generation solution for enterprise systems integration).

• Service Oriented Integration (service & application logic).
• Program Lifecycle Management (program, product, project, portfolio, process synergy).
• Dynamic Learning Orchestration (organizational and personal learning and knowledge management).

In my next blog entry, I will describe Program Lifecycle Management, the new PLM, in more detail.

Semantic Integration & IT

In many ways the practice of information technology has changed little over the past 30 years or so. It may not seem so on first appearance - but the premises upon which our current technologies are still operating are largely based on philosophical constructs that date back 30 years or more.

Those constructs include:

• The Relational Database.
• The Data Warehouse.
• System Management (system as self-contained entity).
• "Static" Business Rules Management (more or less permanent view of the nature of rules within the enterprise) - exemplified by maturity models.
• The notion of IT service provision as separate and distinct from the elements of the business which they serve.

Of course, there are exceptions to this but in many ways these basic foundational elements still represent the core of most IT activity within the typical enterprise. Each of these areas and others has arisen to meet certain needs; there has been an ever-increasing level of specialization within IT that has more or less extended the basic model without really changing it. This has made some areas of IT management more effective but has hindered the ability to truly unify IT capability. Some people refer to these phenomena as 'sub-optimization' or 'compartmentalization.' In the government arena it is sometimes referred to as 'stovepiping.'

The dilemma is the same though, how does one make progress and get work done while solving near-term specific problems and simultaneously leverage the full potential of all enterprise assets? This can be done and can occur in the near-term using existing technologies - the problem we face now though is one of perception and philosophy. IT is used to working in its current sub-optimized mode, its relative detachment from the primary functions of the organizations it serves tends to provide a disincentive to view the big picture requirements they always receive yet never truly fulfill.

The paradigm shift that needs to occur and that will occur within the next five years is this - The realization that the enterprise is a dynamic entity. In other words, it is not something that can ever be fully coded or captured in advance. A 'pre-determined' enterprise family of systems is obsolete before it ever deploys. The other element of the realization is that the key to all integration within the enterprise is already embedded within it. The enterprise as a holistic capability will be achieved once we understand that regardless of the specializations involved, all aspects of the mission are related and that the unifying code embedded throughout it can be managed, mediated and coordinated as a single semantic exercise.

I truly believe that this represents more of a philosophical change than a technical one. It requires new methodologies and IT practices that view problems from this updated perspective. Eventually it will lead to modifications in many commercial software products and networking technologies, but those changes are not necessary to begin experiencing the benefits of the Semantic Enterprise.

Copyright 2008, Semantech Inc.

Semantic Integration - The SI of Tomorrow

Currently when people use the acronym “SI” they tend to refer to something known as ‘Systems Integration’ or specifically to ‘Systems Integrators.’ However, the nature of what a 'system' is and how that concept is evolving are going to change the way that we look at this particular term in the relatively near future. I predict that within the next ten years, ‘SI’ in the context of information systems technology will primarily refer ‘Semantic Integration.’

The Evolution of Systems Integration

What I mean when I say that Systems Integration and the notion of Systems are evolving is that new design concepts and technologies are having a radical and disruptive influence on current integration practices, processes and design approaches. What was a ‘system’ under distributed computing environments is now undergoing a transformation – taking on aspects of both the distributed model used today and centralized models from yester-year. This is largely coming about due to the advent of Services Oriented Architecture (SOA) technology and design principles. It is important to note here that SOA, like Semantics, is a practice area based upon design philosophies and technical standards – the tools being developed in relation to those philosophies standards or applied to it are not the drivers for these trends. Folks who focus on the software tools only and not the underlying principles tend to run into many difficulties in implementing these types of new capability.

Our previous or current experience with System of Systems architectures is what led to the need for System Integration and Integrators largely as an afterthought or mitigating action in response to the need for rapid deployment of multiple, new distributed technologies. Most enterprises have spent the last twenty years playing catch-up in this environment and few are truly architected in any comprehensive sense of the term. System Integration is often a tactical activity – ensuring data passes between systems silos, connecting various applications point-to-point or through limited middleware capabilities, deploying portals and unified sign-on and security management and so forth. Piece by piece, an enterprise becomes more unified under this type of scenario, but at a cost – that cost is increased complexity and expense for maintaining non-standard integration.

The future is upon us; that future is just now promising something new – the ability to coordinate architectures across tiers, across federated domains and across all related lifecycles. The new enterprise can be viewed as a single organic system, consisting of dozens or hundreds of services that operate as a single unified yet dynamic entity that is often federated across geographic and logical domain or boundaries and orchestrated at runtime. This is SOA but it is more than SOA, because SOA doesn’t yet have the necessary philosophical framework for exploitation of Semantics to help achieve this enterprise unification. That’s where Semantic Integration comes into the picture.

What is Semantic Integration ?

Semantic integration is not is not confined to or restricted to the ability to operate or configure or utilize specific semantic technology or software packages. Semantic Integration represents a specialized field of practice dedicated to using Semantic Design Principles, Methodologies and technology as a facilitating mechanism (often alongside SOA) to help solve enterprise-level problems for IT. SI as a practice area is relatively new (it is only now being defined), it is much more than the “Semantic Web” yet is obviously built upon the capabilities inherent within the emerging set of Semantic standards that can be used to express and ultimately visualize semantic entities, RDF, OWL and so forth).

Copyright 2008, Semantech Inc.

A Conceptual Framework for Semantic Integration

Let’s take a moment to elaborate on the core premise. What we’re really looking for is a mechanism that can tie together the ever-growing spectrum of specialized information, tools and techniques that we are forced to deal with in a typical enterprise today. The natural trend has pushing away from unified management or control over this environment and we have been playing catch-up for years as we attempt to impose order over enterprise entropy.

This situation applies equally to the development as well as the production environment. The fact is that no single control mechanism has yet been successful at tying together either environment (or both). And as we well know, complexity costs us big – in money, in time and in failure to meet expectations. SOA held promise in that it in contained control elements for both development and production. We are extending this to the next logical step – comprehensive control or at least direction over everything.

But ‘control’ is a frightening term for many, it may imply micromanagement which we know from experience doesn’t work too well in environments where change rules supreme. We don’t wish to stifle innovation or slow down the pace of change – any attempt to do so would surely lead to failure. What we need to do is understand or set the parameters of our known universe, to consciously design it in advance at a high level and guide all of its constituent elements along an evolutionary path that falls with those defined parameters. This could be viewed as ‘loose conformance’ rather than strict compliance.

Our enterprise universe is no longer restricted to any one organization, so the framework for accomplishing this definition must be a shared endeavor. This doesn’t necessarily imply technical standards; technical standards must all be subordinated to the true control mechanism – Semantics. Semantics allows us for the first time to design for scenarios where 100’s or 1000’s of applications share the same type of data and deconflict both their functions and information output.

The conflict between what appears to be redundant functionality and competing data elements is the most serious and complex challenge in every enterprise today. Many solutions have tried to address this by tracking metadata across the enterprise or by imposing governance rules – however both of those attempts still lack the most important key to success – the overall context in which all of the data and rules will operate – across not one but all potential enterprises. Semantic Integration will provide this context.

Copyright 2008, Semantech Inc.

Ontology Abstraction

For Ontologies to serve as a mechanism for reconciling diverse systems and as an integration engine, they must be flexible and separable from the rules (and the systems applying those rules) that would define the nature of the interactions. This is what is referred to as "Ontology Abstraction."

Ontologies are also separate and abstracted from meta-data. One reason that most data standardization efforts have either failed or seriously underperformed is the idea that anyone can fully define the nature of all enterprise data and predict how that will evolve over time - it always has been and will remain wholly unrealistic.

What we need instead are less painful ways to capture and characterize the changing nature of our enterprise data environment. Using Ontologies for this will allow us to manage data in human readable formats that can readily be shared with end users as well as functional experts. Those groups will define Ontologies based upon generic long term expectations (formal sets), dynamic evolution and discovery (dynamic sets) and the business logic logic needed to manage both (interaction rules).



One of the key concepts underpinning Semantic Integration is Ontology Abstraction

Copyright 2008, Semantech Inc.

Taxonomy & Mind Maps

The other day someone asked me what was the best method to build a taxonomy, my initial response was a high level overview outlining the pragmatic nature of the beast but what I forgot to mention is the specific technique/s I use to get started. Over the years I've tried a number of different approaches, none of them perfect. I've used Powerpoint, the Outline feature in MS Word, a pencil and paper, other EA modeling tools and so on. But about two years ago, I became acquainted with Mind Mapping. Mind maps are very well suited for the initial part of the semantic integration process - they are easy to learn, very quick to use and provide a fairly comfortable visual interface to your resulting "Brainstorm" products.

Most Mind Mapping tools have a bit of a constraint though in that they capture "Dual Hierarchies" - in other words they split out trees in only two directions. There are many times when I had thought that the ability to have one tree, centered, would be preferable, but there are some advantages to the dual tree approach. With two trees you can begin to do some preliminary semantic reconciliation or you can use the the second tree (for me this is usually the left side) to capture a set of assumptions or constraints which underlie whatever is built into the right side tree.

The tool I use for this is Freemind - because as the name implies, it costs nothing. There are many other mind-mapping tools on the market and they have a wide variety of features - but for me this tool now fits a specific niche with my lifecycle. While having the ability to save it as data would be nice, it isn't absolutely essential this early in the process. This is a tool that was designed for brainstorming and it doesn't necessarily need to be linked to the initial design as long as that initial design is then linked through the rest of the lifecycle.




an example of a rapidly produced "Dual Branch" Mind Map Taxonomy

Copyright 2008, Semantech Inc.

Linkedin.com Response: Open Source CMS

Are corporate intrantets generally custom coded, or are they increasingly using either Open Source CMSs / Wikis or commercial intranet or CMS packages?

Well, the USAF (several 100 thousand users) is deploying its ECM solution using a combination of IBM content management & Sharepoint technology. The Army is using a portal based COTS which is not really mainstream software and the Navy is using Sharepoint in many instances. None of these mega-enterprises has yet fully embraced open source content management. In answer to your question, it makes no sense for a larger or global enterprise to develop it's own intranet - many have done this though over the years because they felt it would be cheaper than paying the license fees.

However, as user expectations become more prolific the development team is faced with higher costs and the cost benefit business case starts to fades away. The case for open source CMSs is compelling and will likely help move more IT shops away from custom development towards packaged applications.”


Copyright 2008, Semantech Inc.

What is a SUO?

A SUO is something that was talked about quite a bit a year or two ago but seems to be fading a bit of late. SUO stands for "Shared Upper Level Ontology" and represents a baseline of sorts for complex semantic mapping activities. The problem I noticed immediately with the concept was two-fold:

1 - High level taxonomies are extremely useful in situations where an organization (or shared community) has the ability to manage it strictly. For example, there is essentially one shared interpretation of the Animal "Kingdom" originally proposed by Linneaus in the 1700s. However once you move from universal consensus to competing interpretations things start to get complicated. How many official variations of English dialects could be recognized as SUOs and how might they relate to an "Oxford" version?

2 - It is unrealistic to expect that a fairly rich understanding of the potential relationships can be captured within a SUO - which means then it becomes less of a true Ontology and more of a taxonomy. Folks working on on SUOs some years back tried to take this into account:

IEEE SUO working group

Thusfar the largest SUO project is the Suggested Upper Merged Ontology (SUMO) initiative. I'm not too sure how useful this is though as the standard for exchanging the Ontology data is rather narrowly focused (KIF Knowledge Interchange Format). For us to be able to include semantic integration into larger enterprise integration projects a more standard XML-based approach is required.



Copyright 2008, Semantech Inc.

The Future of Semantic Technology

I had a very interesting conversation today that got me thinking. The topic revolved around where this particular segment of the larger IT domain might go - in terms of both scope and success.

In many ways, Semantic Technology has been totally defined within the context of the "Semantic Web" and the set of standards related to that W3C initiative. My contention to the colleague I was speaking to was that I had never pegged the nature or scope of what Semantic Technology is to the "Semantic Web" concept. I think they are quite complementary but the Semantic Web represents a narrower view in many respects to how Semantics ought to be viewed in the context of Information Technology as a whole.

Before the latest round of proponents of web-based or web-focused semantic applications, there were folks like Chomsky, who began to illustrate the deeper connections between meaning and representation - some used to refer to this as computational linguistics, but the scope was wide - it necessarily encompassed the entire spectrum of architectures and processes that surround any or every automation solution. I was pleased to see that Steven Pinker, an author coming from that original community of linguistic-focused academics writing a book about Ontology last year. This is a good sign the broader-base of thought leaders may be converging.

The problem that I see with the current practice of Semantic Integration and the current crop of Semantic technologies is that they have been too easily shunted off into their own relatively small niches. Granted, there have been and are still exceptions to this, but for many the notion of building vocabularies, ontologies and so forth seem more or less disconnected from the reality of their everyday challenges. Semantics is not an endeavor that serves itself, if it is viewed as the primary building block for everything in IT – the nature of the products and practices supporting it will change.

I’ll provide a concrete example – why should an enterprise architecture be managed separately from systems requirements and why should those both be separate from the BPEL workflow logic that drives a SOA-based portal? The short answer is they shouldn’t and don’t have to and this is only part of the larger synergy possible. We may be able to begin to apply Semantic Web technology or standards by passing RDFs back and forth, but the real leap we’re making here is more conceptual in nature.

The future of Semantic Technology is entirely dependent on the ability for us to make it relevant to this larger context or higher calling perhaps. I’ve spent more than a decade working in mostly larger, system of systems enterprise integration or transformation initiatives – many have claimed that they had the silver bullets which would simplify this arena (CORBA, J2EE, EAI, SOA etc.). The problem has always been perhaps though that we focused on the bullets instead of the gun…

Copyright 2008, Semantech Inc.

Context Mapping

What if in the same organization a word such as, let’s say “SOA,” meant one thing to the majorityof stakeholders (our best criteria ought to be some sort of official or community endorsement) on May 20th, 2006and then meant something slightly different on November 11th, 2006 and then something completely different on July 10th, 2007? Which meaning is valid? In most cases, we’d simply go with the latest version of the meaning. But life is never that simple is it? It just so happens that we’ve been given the charter to integrate with four other organizations who all have various interpretations of the same word that all have evolved over time. How can we reconcile this; or even study it?

Now you begin to see the value of Context and Dynamic Context. Without the ability to view the variations andtheir respective evolutionary paths it will be difficult for us to determine an appropriate, Integrated reconciliation for that term – one that will be accepted by all the constituents of all groups (or most of them anyway). Context Mapping is the ability to visualize the evolution or comparison of Vocabulary terms, Taxonomies, Ontologies or Sets within or across constituent perspectives, i.e. Contexts. Once a reconciliation has been chosen it can be used to generate a Dynamic Set or Sets. Of course, part of the reconciliation process for Context Mapping could include generating “What If” Dynamic Sets to see how these would perform against Semantic Rules and Formal Sets. This process would be used to determine what types of logic and data will be used to integrate organizations across domains, it will determine the structure of all systems or systems involved as well as the processes which link them.

Put another way, Context Mapping represents one of two core analytical processes involving Contexts; Mapping supports the reconciliation of both Context and Dynamic Contexts into “Integrated Contexts.” Integrated Contexts are the building blocks for Dynamic Sets and Semantic Rules.

Copyright 2008, Semantech Inc.

Context & Dynamic Context

Semantics must be able to support analysis as well as application interoperability.Context represents our most powerful analytic mechanism. Generically, Context refers to the specific perspective ofany group, individual or entity in regards to any combination of Semantic information. Dynamic Context takes this astep further by combining any given Context with a unique point in time. The reason for this is clear, Context is not a permanent state; perspectives change with time. The only way to accurately determine true Context is to capture it in its relative state. Context can also be tracked across time to illustrate the evolution of any given perspective.

The reason that most data standardization efforts have failed in IT is that unless one is working in a highly controlled environment, differing Contexts cannot be accommodated. Ultimately, someone or some group always feels left out and in fact they are. When dealing with information across hundreds, thousands or even millions of users or organizations, traditional data standardization methods and techniques can never hope reconcile the differences and support interoperability on a global scale. If Context or Dynamic Context is understood we can then determine how to construct Dynamic Sets that allow us to Interact with Shared Formal Sets. The future of all integration may very well become centered around the creation of Dynamic Sets and Dynamic Semantic Rules. These tools will determine the exact information (structured and unstructured) and logic we may need to accomplish any given task, answer any given question or solve any given problem.

Copyright 2008, Semantech Inc.

Levels of Semantic Information, Boundaries & Interaction

There are far too many collisions occurring on the information superhighway; information and data colliding, combining, losing identity and integrity. The traffic outlook today is grim. There is no effective traffic control or organization mechanism; routers and packet data flow are different than information flow control. Several years ago, the concept of the Semantic web was introduced by the founders of what we consider to be the Internet. It was understood back then that the torrent of information being made available online would soon become unmanageable unless some context was provided.

Context is shared meaning, in order words, Semantics. A lot of work has gone into developing semantic standards that enhance the ability to add meaning to resources available on the web or across any complex environment; examples include XML-based standards such as OWL and RDF. That begins to cover the realm of unstructured data or information, allowing us to build shared ontologies at multiples levels. In the realm of structured data, there is a proliferation metadata mechanisms already in place, some of those are capable of interfacing with semantic resource standards, others aren’t.

What does not yet exist are sets of community-developed, shared information and the ability to define interactions between resources within and across their boundaries under a variety of conditions. Any realistic adoption of this type of framework would necessarily include the ability to define overlapping Boundaries or Dynamic Sets based on real-time discovery or idiosyncratic needs. The key is making sure that one understands which Sets are more or less permanent (and this notion is subject to community consensus) and which ones are created for semantic mining (the near-term exploitation of resources within the dynamic set). This process is something that cannot and should not be managed by any one technology or software product – it does however require a shared capability. That capability involves the ability to define Formal and Dynamic Sets of meaning. Sets contain Semantic Information such as Ontologies, Taxonomies and Vocabularies.

Copyright 2008, Semantech Inc.

Our Semantic Terminology

As one might expect, the terminology for Semantic Integration is in itself extremely important - it represents our "meta-semantics."

Let’s also explore what these terms signify for us in their enterprise integration
context:

• Vocabulary – This is the atomic level view and is analogous to a data entity.

• Taxonomy – This includes the vocabulary, is a straight forward hierarchy and is analogous to earlier DBMS design paradigms.

• Ontology – This includes both of the above and represents a structure that expresses both a hierarchy and a set of relationships between vocabulary ‘elements’ within that hierarchy. This is roughly analogous to the design paradigms involved in Relational Database technology, although a schema is not necessarily an ontology and tends to be restricted to the system level.

• Semantic Set – This is the recognition that data design (in fact all design) for the enterprise extends beyond the bounds or scope of any one system. The enterprise must deal with multiple ontologies, taxonomies, and vocabularies and reconcile them on an ongoing or evolutionary basis.

Copyright 2008, Semantech Inc.

What is Semantics?

So, what is Semantics? It is an often misunderstood term; even moreso in regards to its technical applications. In philosophy, Semantics refers to the study of meaning. The representation and dissemination of meaning though is what IT is all about. Every data element, every character in a string, every variable in an equation; they all express meaning in one form or another.

Furthermore that meaning is enhanced through frameworks of syntax and grammar as well as through countless explicit and implicit relationships. All system design is predicated upon a contract of shared understanding between stakeholders, developers and service providers; when something goes wrong this is often the first place to look.

There are a number of specific standards and tools that have emerged over the past few years to support Semantic Integration; however first we need to examine the problem space from a philosophical and business level. To understand how Semantics can be used to facilitate enterprise integration, we must first understand how Semantics relates to the practice of IT. Semantics is heavily focused upon hierarchies of meaning and relationships and as one might expect Semantics has its own hierarchy.



Copyright 2008, Semantech Inc.

Introduction

Hello and welcome to Semantech's Semantic Integration Blog.

Semantic integration is a relatively new topic of interest represents and completely new way of looking at issues relating to enterprise integration. The goal of this Blog is to help explore the issues and contexts for application of Semantic Integration to real-world integration challenges.

| View | Upload your own