Archive for the ‘Federation’ Category

Ad for Topic Maps

Monday, February 17th, 2014

Imagine my surprise at finding an op-ed piece in Information Management flogging topic maps!

Karen Heath writes in: Is it Really Possible to Achieve a Single Version of Truth?:

There is a pervasive belief that a single version of truth–eliminating data siloes by consolidating all enterprise data in a consistent, non-redundant form – remains the technology-equivalent to the Holy Grail. And, the advent of big data is making it even harder to realize. However, even though SVOT is difficult or impossible to achieve today, beginning the journey is still a worthwhile business goal.

The road to SVOT is paved with very good intentions. SVOT has provided the major justification over the past 20 years for building enterprise data warehouses, and billions of dollars have been spent on relational databases, ETL tools and BI technologies. Millions of resource hours have been expended in construction and maintenance of these platforms, yet no organization is able to achieve SVOT on a sustained basis. Why? Because new data sources, either sanctioned or rogue, are continually being introduced, and existing data is subject to decay of quality over time. As much as 25 percent of customer demographic data, including name, address, contact info, and marital status changes every year. Also, today’s data is more dispersed and distributed and even “bigger” (volume, variety, velocity) than it has ever been.

Karen does a brief overview of why so many SVOT projects have failed (think lack of imagination and insight for starters) but then concludes:

As soon as MDM and DG are recognized as having equal standing with other programs in terms of funding and staffing, real progress can be made toward realization of a sustained SVOT. It takes enlightened management and a committed workforce to understand that successful MDM and DG programs are typically multi-year endeavors that require a significant commitment to of people, processes and technology. MDM and DG are not something that organizations should undertake with a big-bang approach, assuming that there is a simple end to a single project. SVOT is no longer dependent on all data being consolidated into a single physical platform. With effective DG, a federated architecture and robust semantic layer can support a multi-layer, multi-location, multi-product organization that provides its business users the sustained SVOT. That is the reward. (emphasis added)

In case you aren’t “in the know,” DG – data governance, MDM – master data management, SVOT – single version of truth.

The bolded line about the “robust semantic layer” is obviously something topic maps can do quite well. But that’s not where I saw the topic map ad.

I saw the topic map ad being highlighted by:

As soon as MDM and DG are recognized as having equal standing with other programs in terms of funding and staffing

Because that’s never going to happen.

And why should it? GM for example has legendary data management issues but their primary business, MDM and DG people to one side, is making and financing automobiles. They could divert enormous resources to obtain an across the board SVOT but why?

Rather than across the board SVOT, GM is going to want a more selective, a MVOT (My Version Of Truth) application. So it can be applied where it returns the greatest ROI for the investment.

With topic maps as “a federated architecture and robust semantic layer [to] support a multi-layer, multi-location, multi-product organization,” then accounting can have its MVOT, production its MVOT, shipping its MVOT, management its MVOT, regulators their MVOT.

Given the choice between a Single Version Of Truth and your My Version Of Truth, which one would you choose?

That’s what I thought.

PS: Topics maps can also present a SVOT, just in case its advocates come around.

Teiid (8.2 Final Released!) [Component for TM System]

Thursday, November 22nd, 2012


From the homepage:

Teiid is a data virtualization system that allows applications to use data from multiple, heterogenous data stores.

Teiid is comprised of tools, components and services for creating and executing bi-directional data services. Through abstraction and federation, data is accessed and integrated in real-time across distributed data sources without copying or otherwise moving data from its system of record.

Teiid Parts

  • Query Engine: The heart of Teiid is a high-performance query engine that processes relational, XML, XQuery and procedural queries from federated datasources.  Features include support for homogenous schemas, hetrogenous schemas, transactions, and user defined functions.
  • Embedded: An easy-to-use JDBC Driver that can embed the Query Engine in any Java application. (as of 7.0 this is not supported, but on the roadmap for future releases)
  • Server: An enterprise ready, scalable, managable, runtime for the Query Engine that runs inside JBoss AS that provides additional security, fault-tolerance, and administrative features.
  • Connectors: Teiid includes a rich set of Translators and Resource Adapters that enable access to a variety of sources, including most relational databases, web services, text files, and ldap.  Need data from a different source? A custom translators and resource adaptors can easily be developed.
  • Tools:

Teiid 8.2 final was released on November 20, 2012.

Like most integration services, not strong on integration between integration services.

Would make one helluva component for a topic map system.

A system with an inter-integration solution mapping layer in addition to the capabilities of Teiid.

Sebastian Hammer on Federated Search

Tuesday, June 12th, 2012

Sebastian Hammer on Federated Search

From the post:

Recently our own Sebastian Hammer was interviewed by David Weinberger of the Harvard Library Innovation Lab and a member of the Dev Core for the DPLA. Sebastian explained the strengths and limitations of federated search. You can listen to the 23-minute podcast here or read the transcript attached.


Short but interesting exploration of federated search.

I first saw this at Federated Search: Federated Data Explained.

Simple federated queries with RDF [Part 1]

Thursday, May 10th, 2012

Simple federated queries with RDF [Part 1]

Bob DuCharme writes:

A few more triples to identify some relationships, and you’re all set.

[side note] Easy aggregation without conversion is where semantic web technology shines the brightest.

Once, at an XML Summer School session, I was giving a talk about semantic web technology to a group that included several presenters from other sessions. This included Henry Thompson, who I’ve known since the SGML days. He was still a bit skeptical about RDF, and said that RDF was in the same situation as XML—that if he and I stored similar information using different vocabularies, we’d still have to convert his to use the same vocabulary as mine or vice versa before we could use our data together. I told him he was wrong—that easy aggregation without conversion is where semantic web technology shines the brightest.

I’ve finally put together an example. Let’s say that I want to query across his address book and my address book together for the first name, last name, and email address of anyone whose email address ends with “.org”. Imagine that his address book uses the vCard vocabulary and the Turtle syntax and looks like this,

Bob is an expert in more areas of markup, SGML/XML, SPARQL and other areas than I can easily count. Not to mention being a good friend.

Take a look at Bob’s post and decide for yourself how “simple” the federation is following Bob’s technique.

I am just going to let it speak for itself today.

I will outline obvious and some not so obvious steps in Bob’s “simple” federated queries in Part II.

Knowledge Federation 2010: Self-Organizing Collective Mind

Tuesday, January 3rd, 2012

Knowledge Federation 2010: Self-Organizing Collective Mind

The proceedings from the Second International Workshop on Knowledge Federation, Dubrovnik, Croatia, October 3-6, 2010, edited by Dino Karabeg and Jack Park, have just appeared online.

Table of Contents


  1. The Praxis of Social Knowledge Federation
    Arnim Bleier, Patrick Jahnichen, Uta Schulze, Lutz Maicher
  2. Steps Towards a Federated Course Model
    Dino Karabeg

  3. On Nature and Control of Creativity: Tesla as a Case Study
    Dejan Rakovic
  4. Semiotic Perspective on Sensemaking Software and Consequences for Journalism
    Shiqin “Eddie” Choo
  5. Towards a Federated Framework for Self-evolving Educational Experience Design on Massive Scale (SEED-M)
    George Pór
  6. Context-Driven Social Network Visualisation: Case Wiki Co-Creation
    Jukka Huhtamaki, Jaakko Salonen, Jarno Marttila, Ossi Nykanen
  7. Boundary Infrastructures for Conversational Knowledge Federation
    Jack Park
  8. Combinatorial Inquiries into Knowledge Federation
    Karl F. Hebenstreit Jr.
  9. An Ark for the Exaflood Rushing upon Us
    Mei Lin Fung, Robert S. Stephenson
  10. Webbles: Programmable and Customizable Meme Media Objects in a Knowledge Federation Framework Environment on the Web
    Micke N. Kuwahara, Yuzuru Tanaka
  11. Causality in collective filtering
    Mario Paolucci, Stefano Picascia, Walter Quattrociocchi
  12. Images of knowledge. Interfaces for knowledge access in an epistemic transition
    Marco Quaggiotto
  13. New ecosystem in journalism: Decentralized newsrooms empowered by self-organized crowds
    Tanja Aitamurto

DOD looks to semantics for better data-sharing, cost savings

Sunday, November 27th, 2011

DOD looks to semantics for better data-sharing, cost savings by Amber Currin.

From Federal Computer Week:

In its ongoing quest to catalyze cost efficiencies and improve information-sharing, the Defense Department is increasingly looking to IT to solve problems of all sizes. The latest bid involves high-tech search capabilities, interoperable data and a futuristic, data-rich internet known as semantic web.

In a new RFI, the Defense Information Systems Agency and Deputy Chief Management Office are looking to strengthen interoperability and data-sharing for a vast array of requirements through an enterprise information web (EIW). Their envisioned EIW is built on semantic web, which will allow better enterprise-wide collection, analysis and reporting of data necessary for managing personnel information and business systems, as well as protecting troops on the ground with crucial intelligence.

“At its heart, semantic web is about making it possible to integrate and share information at a web scale in a simple way that traditional databases don’t allow,” said James Hendler, senior constellation professor of the Tetherless World Research Constellation at Rensselaer Polytechnic Institute.

One way semantic web helps is by standardizing information to enable databases to better communicate with each other – something that could be particularly helpful for DOD’s diverse systems and lexicons.

“The information necessary for decision-making is often contained in multiple source systems managed by the military services, components and/or defense agencies. In order to provide an enterprise view or answer questions that involve multiple services or components, each organization receives data requests then must interpret the question and collect, combine and present the requested information,” the RFI reads.

Oh, and:

“DOD historically spends more than $6 billion annually developing and maintaining a portfolio of more than 2,000 business systems and web services. Many of these systems, and the underlying processes they support, are poorly integrated. They often deliver redundant capabilities that optimize a single business process with little consideration to the overall business enterprise,” DOD Deputy Chief Management Officer Beth McGrath said in an April 4 memo. “It is imperative, especially in today’s limited budget environment, to optimize our business processes and the systems that support them to reduce our annual business systems spending.”

Just in case you are interested, the deadline for responses is 19 December 2011. A direct link to the RFI.

I may actually respond. Would there be any interest in my posting my response to the RFI to get reader input on my responses?

So I could revise it week by week until the deadline.

Might be a nice way to educate other contenders and the DoD about topic maps in general.


BTW, if you are interested in technology and the U.S. federal government, try reading Federal Computer Week on a regular basis. At least you will know what issues are “up in the air” and vocabulary being used to talk about them.

Smallest Federated Wiki

Sunday, November 6th, 2011

Smallest Federated Wiki

Interesting wiki application that enables moving of information between wiki pages, yours, theirs, ours and yet they retain integrity for the original author. I have just started watching the videos.


Videos at Github

Video’s at YouTube

I had sent Jack Part the link (he was already aware of it) and Jack sends back:

Wiki inventor Ward Cunningham in Conversation with Tom at HealthCamp Oregon

with a note to watch this space. Jack has good instincts so take heed. The Tom is Tom Munnecke, inventor of the data core that supports half of the operational electronic health records today. (VistA) I take that as credentials for talking about data systems. Ward Cunningham is the inventor of the wiki. Yeah, that Ward Cunningham. I think Jack is probably right, this is a space to watch.

Enterprise Federated Query is a hoax!

Thursday, June 30th, 2011

Enterprise Federated Query is a hoax! by Enoch Moses, January 9, 2008.

Everyone uses the federated query example as a great application in the Service Oriented Architecture (SOA) paradigm. Via SOA paradigm, the application developers can integrate their client application to numerous services and this will allow the client application users to search and browse various data sources. This sounds great in theory however an enterprise federated query application is not possible. Before we look into why an enterprise federate query application will be a reality, we need to understand what is a federated query application (fqa).

Problems listed:

  • High number or infinity number of data sources
  • Security
  • Data Source variation
  • Result set Aggregation
  • Governance

It has been a little over three (3) years since that post.

True? Still true? Ever true? True then but not now? True then but not in the near future (our next IPO)?


Sunday, May 22nd, 2011


From the webpage:

The intent of the “Semantic Information Modeling for Federation” (SIMF) RFP effort is to directly tackle the “data problem” where interoperability, federation, reuse and sharing of information is made difficult due to variation in terminology, viewpoint and representation. Our belief is that this is best tackled with a semantic approach, one which is tuned to the needs and viewpoints of those who create and federate data and messaging models. Currently none of the data modeling capabilities, from E/R to UML to XSD handle the integration of independently conceived models. Even the structural mapping techniques that are used today are non-standard (With the exception of OMG-QVT). On the other hand, the semantic technologies are not providing standard conceptual frameworks or notations that resonate with these users. There has been sufficient progress in existing tools and techniques in this area, with divergent solutions, that suggest the need for standards.

The opportunity exists to make substantial gains in solving the data problem – a problem that has a multi-trillion dollar impact on unnecessary cost and lost opportunity. A 100% solution is not required or expected, providing incremental improvements will be a success. Note that as an OMG effort this is not research or an academic pursuit, but would bring some order to already developed approaches to foster the development of mainstream tools and industry support.

As part of the Semantic Architecture Track, SIMF can also be seen as a start to a semantic approach to architecture, one where multiple viewpoints of systems can co-exist yet share information and be mutually supportive. Models and modeling languages (including those from OMG) have not been sufficiently integrated, causing users problems when they want to look at more than just process, just objects or just information, for a single application or service. In that UML has many diagrams it has served that purpose to some extent, but was not designed for that role and the issues with more and more UML profiles suggest it is not the right foundation for a wide family of architectural languages at all levels. For this reason SIMF is expected to federate with UML, not be based on it.

Status: The status of SIMF is that we are still writing the RFP, which will be presented at the next OMG meeting in Salt Lake City. Note that writing the RFP requires a good specification of what is being asked for, not of the solution – the solutions come in responses to the RFP.

From OMG.

Sound familiar?

I’m signing up for the mailing list at least.