A Low-risk Path to the Open World, Semantic Enterprise
OK, you’ve been reading the literature and perhaps have attended a conference or two. You have heard a lot about semantic technologies, but have some real questions and concerns:
- How do we get started, especially with smaller proofs-of-concept?
- Do we need to abandon our past practices and systems in order to gain semantic advantages?
- To gain the advantages of interoperability, do we have to convert everything into RDF or OWL?
- Are semantic technologies limited to open or public data; how do we accommodate our proprietary information?
Such questions — and more — are not infrequent when organizations first contemplate making the transition to become a semantic enterprise.
The diagram below shows a general workflow for migrating existing instance data into the semantic enterprise. The diagram is broken down into three parts. The first part is to characterize and stage existing data and information into the underlying structured data framework. This is what SD (that is, my firm,Structured Dynamics) does as data architects using our particular approach to adaptive ontologies. I’ll touch on this again in a moment.
Jumping to the right-hand side of the diagram is the access and display part. It is here that developers or users can make selections from dropdown lists and so forth to define the “slices” of diced results sets they wish to display. The results of those interactions are structured data results sets that are pre-staged to “drive” various applications and displays [1,2]. These same capabilities can also be embedded into standard Web end user applications, such as content management systems.
The third and middle part of the diagram is the critical part, the pivot point. It is the interface layer between the structured data on the left and the display and presentation of that data on the right. As provided by SD, this abstraction layer is thestructWSF Web services framework that “bridges” between the black box of what happens with RDF and semantic Web structured data characterizations on the left in order to feed, or “drive”, useful services and functions on the right.
We call this general design and architecture “ontology-driven applications”. The bulk of this posting explains each of these three parts in a bit more detail, organized from left-to-right by these Parts 1 to 3.