Archive for the ‘Versioning’ Category

Synchronizer Based on Operational Transformation…

Monday, July 28th, 2014

Synchronizer Based on Operational Transformation for P2P Environments by Michelle Cart and Jean Ferrié


Reconciling divergent copies is a common problem encountered in distributed or mobile systems, asynchronous collaborative groupware, concurrent engineering, software configuration management, version control systems and personal work involving several mobile computing devices. Synchronizers provide a solution by enabling two divergent copies of the same object to be reconciled. Unfortunately, a master copy is generally required before they can be used for reconciling n copies, otherwise copy convergence will not be achieved. This paper presents the principles and algorithm of a Synchronizer which provides the means to reconcile n copies, without discriminating in favour of any particular copy. Copies can be modified (concurrently or not) on different sites and the Synchronizer we propose enables them to be reconciled pairwise, at any time, regardless of the pair, while achieving convergence of all copies. For this purpose, it uses the history of operations executed on each copy and Operational Transformations. It does not require a centralised or ordering (timestamp, state vector, etc.) mechanism. Its main advantage is thus to enable free and lazy propagation of copy updates while ensuring their convergence – it is particularly suitable for P2P environments in which no copy should be favoured.

Not the oldest work on operational transformations, 2007, nor the most recent.

Certainly of interest for distributed topic maps as well as other change tracking applications.

I first saw this in a tweet by onepaperperday.

Time-Based Versioned Graphs

Wednesday, June 18th, 2014

Time-Based Versioned Graphs

From the post:

Many graph database applications need to version a graph so as to see what it looked like at a particular point in time. Neo4j doesn’t provide intrinsic support either at the level of its labelled property graph or in the Cypher query language for versioning. Therefore, to version a graph we need to make our application graph data model and queries version aware.

Separate Structure From State

The key to versioning a graph is separating structure from state. This allows us to version the graph’s structure independently of its state.

To help describe how to design a version-aware graph model, I’m going to introduce some new terminology: identity nodes, state nodes, structural relationships and state relationships.

Identity Nodes

Identity nodes are used to represent the positions of entities in a domain-meaningful graph structure. Each identity node contains one or more immutable properties, which together constitute an entity’s identity. In a version-free graph (the kind of graph we build normally) nodes tend to represent both an entity’s position and its state. Identity nodes in a version-aware graph, in contrast, serve only to identify and locate an entity in a network structure.

Structural Relationships

Identity nodes are connected to one another using timestamped structural relationships. These structural relationships are similar to the domain relationships we’d include in a version-free graph, except they have two additional properties, from and to, both of which are timestamps.

State Nodes and Relationships

Connected to each identity node are one or more state nodes. Each state node represents a snapshot of an entity’s state. State nodes are connected to identity nodes using timestamped state relationships.

Great modeling example but you have to wonder about a graph implementation that doesn’t support versioning out of the box.

It can be convenient to treat data as though it were stable, but we all know that isn’t true.

Don’t we?

Delta-flora for IntelliJ

Sunday, March 31st, 2013

Delta-flora for IntelliJ

From the webpage:

What is this?

This is a plugin for IntelliJ to analyze project source code history. It has two parts:

  • transforming VCS history into .csv format (csv because it’s easy to read and analyze afterwards)
  • analyzing history and displaying results using d3.js (requires a browser). This is currently done in a separate Groovy script.

Originally inspired by Delta Flora by Michael Feathers. It has now diverged into something a bit different.

WARNING: this is work-in-progress.


There seems to be a lot of interesting data captured in version control systems, yet we don’t tend to use it that much. This is an attempt to make looking at project history easier.

Interesting for visualization of project version control but I mention it as relevant to data versioning.

What if in addition to being in narrative prose, “facts,” such as claims about “yellow cake” uranium, were tracked by data versioning?

So that each confirmation or uncertainty is liked to a particular fact. Who confirmed? Who questioned?

There is a lot of data but limiting to to narrative structures means reduced access to track, re-structure and re-purpose that data.

A step in the right direction would be to produce both narrative and more granular forms of the same data.

Are there lessons we can draw from project source control?


Monday, December 3rd, 2012


From the webpage:

What is Meld?

Meld is a visual diff and merge tool targeted at developers. Meld helps you compare files, directories, and version controlled projects. It provides two- and three-way comparison of both files and directories, and has support for many popular version control systems.

Meld helps you review code changes and understand patches. It might even help you to figure out what is going on in that merge you keep avoiding


  • Two- and three-way comparison between files and directories
  • Auto-merge mode (in development version)
  • Comparisons update as you type
  • Visualisations make it easier to compare your files
  • Actions on diff chunks make for easier merges
  • Supports Git, Bazaar, Mercurial, Subversion, etc.
  • …and more

Coming on the heels of Kevlin Henney’s Cool Code [Chess Program in 4.8 Tweets], I may have paid closer attention to this program than otherwise.

Still, source code has semantics and different ways of expressing those semantics, just like the usual topic map examples.

I first saw this in a tweet by Scientific Python.

Era of the Interest Graph

Tuesday, March 15th, 2011

Era of the Interest Graph

From the blog:

Social media is maturing as are the people embracing its most engaging tools and networks. Perhaps most notably, is the maturation of relationships and how we are expanding our horizons when it comes to connecting to one another. What started as the social graph, the network of people we knew and connected to in social networks, is now spawning new branches that resemble how we interact in real life.

This is the era of the interest graph – the expansion and contraction of social networks around common interests and events. Interest graphs represent a potential goldmine for brands seeking insight and inspiration to design more meaningful products and services as well as new marketing campaigns that better target potential stakeholders.

While many companies are learning to listen to the conversations related to their brands and competitors, many are simply documenting activity and mentions as a reporting function and in some cases, as part of conversational workflow. However, there’s more to Twitter intelligence than tracking conversations.

We’re now looking beyond the social graph as we move into focused networks that share more than just a relationship.

What struck me about this post was the sense that the graph was a non-stable construct.

Whereas most of the topic maps I have seen are not only stable, but their subjects are as well.

Which is fine for some areas of information, but not all.

A dynamic topic map seems to have different requirements than one that is a fixed editorial product, or at least it seems so to me.

Rather than versioning, for example, a dynamic topic map should have a tracking mechanism to show what information was available at any point in time.

So that say a physician relying upon a dynamic topic map for drug warning information can establish that a warning was or was not available at the time he prescribed a medication.

Oh, that’s not commonly possible even with static topic maps is it?

Hmmm, will have to give some thought to that issue.

It may just be the maps I have looked at but there is a timeless nature to them.

Much like governments, whatever is the case has always been the case. And if you remember differently, well, you are just wrong. If not subversive.