Notes-style replication with relational databases

The Anatomy of a Note ID provides some fundamental ideas how Lotus Notes style replication can be used with little embedded databases like Derby.
The parts of a note ID are:

• UNID (Universal Note ID) – Identifies all the copies of a note, regardless of location or time. In other words, every replica of a note has the same UNID, and the UNID does not change when a note is modified.
• OID (Originator ID) – Identifies a particular revision of a note, regardless of location. In other words, every replica of a note has the same OID, but the OID changes when the note is modified.
• GNID (Global Note ID) – Identifies a particular note in a particular database. The GNID does not change as the note is modified. The GNIDs of replica copies of a note will probably be different, since the various copies will occupy different positions in their databases.
• NID (Note ID) – Identifies a particular note in a given database. The NID does not contain information about the database being referred to, and it does not change when the note is modified.
• IID (Instance ID) – Identifies a particular revision of a note in a given database. The IID does not contain information about the database being referred to. The IID changes when the note is modified.
• GIID (Global Instance ID) – Identifies a particular revision of a note in a particular database. The GIID contains information about the database being referred to. The GIID changes when the note is modified.

Charles Cook reports that SSE (Simple Sharing Extensions) for RSS works on a similar principle.

There is a competing standard known as SyncML. DeveloperWorks has an example of SyncML in use with JDBC for heterogenous database replication.