Change Management

This feature of our charting application aids the mundane processes of data evolution, QA, etc. It manages links shown under the 5th Pending chart column, which flags context adjustments made provisionally - they basically require two steps:

A change is added visibly, but scoped so as to leave it formally pending,
Later In a separate step, a set of related changes is approved or denied

There are many nice uses for such capabilities, which often treat a context as an on-line data resource, of interest to a group of people. Using any browser, they can share it, and interact independently of time or space about whatever Topics it models. .

Mechanics of the Process

Each open chart displays a graph made up entirely of typed, scoped triples. It is kept persistent by a Prevayler-like design pattern, and mutated using posted commands which can be logged to permit transactions, undoing, and crash-recovery.

Each command can be posted from a text box, visible in most page headers. But it can also come from any other client on the web able to access such a page, including programs able to run desired scripts, local or remore. (Very flexible specs :-)

Each command requests high-level additions and/or retractions of data in a chart. Queries are okay too, but change requests are what count here. They may be limited to clients with roles and permissions - so user registration is common for production sites.

But many charting web apps, such as this DEMO of Topic Map displays, keep all pending changes only TEMPORARILY. So if you like, you can just load up Context as you like, then post change requests with abandon. Help, training, and demo scripts are built-in

Benefits of the Overall Design

Web-based Change Management offers substantial advantages to any group using it, which may best be summed up by saying it eases on-line collaboration among those involved in dealing with any particular context:

Benefit #1: By making the change process itself more visible and systematic, it reduces barriers of distance or multiple time zones between those participating. By scheduling reviews and approval cycles, each group can fine tune these benefits

Benefit #2: Multi-lingual groups can also be supported, as each context supports simple localization of the display name for each topic. Adjust one user-specific run-time setting, and all names in context appear to switch, for example, from English into German.

Benefit #3: Using XHTML as a formal graph notation also makes each evolving context less confusing technically. Even if it eventually gets exported to RDF/OWL, XTM, or another semantic web standard, inside a chart all data stays easy-to-grasp triples

Benefit #4: Existing SQL data bases can be posted into a context from anywhere on the web, by merely converting each item in some result set to an equivalent HTTP request Later on, changes to that data base can be reposted in exactly the same easy way

Benefit #5: Simple scripts can be added on-line to check constraints, reformat posted values, or treat some changes in special ways - by logging or converting values, for example, or by reporting them to remote subscribers by email or RSS feeds

Benefit #6: Complex probes of a loaded context or its pending changes may also be made in PROLOG-like query languages. Stakeholders can use this; so can scripts that report to stakeholders what happened with each related type of change.

Some features above are not yet ISO-standard parts of Topic Maps, but they are being pursued under extensions for TMQL and TMCL, and/or in open-source TMAPI toolkits.

The exact mixture used by each group for each managed context will probably vary widely, but overall, a good toolkit for managing change is there when you require it. Meanwhile, you can learn about, try out parts, and influence its future in the WORDS MODELER.

Confidential; all rights reserved
© Lexikos Corporation 2004
Portland, ME and Knoxville TN
Email: Dan@Lexikos.com