本文详细描述了 note IDs，并且解释了 Domino or Notes 任务 (复制等)使用 note ID 的组件时有什么不同以及 API 程序怎么使用他们. note ID 包括如下部分:
UNID (Universal Note ID) - 唯一地确定了文档(note), 不管它(note)是位于何处或所处何时.另一方面, 每个文档(note)的复本拥有相同的 UNID, 并且 UNID 不会因为文档的更改而变化.
OID (Originator ID) - 确定文档(note)的特殊的修订版本,不管它(note)位于何处，也就是说，每个文档(note)的复本拥有相同的 OID, 但是当文档(note)更改时OID也会随之修改.
GNID (Global Note ID) - 确定一个特殊数据库中的一个特殊文档(note)，GNID 不会随文档(note)的改变而变化。一个文档(note)复本的GNID可能会不同，因为毕竟他们在数据库中的位置可能不同。
NID (Note ID) - 确定给定数据库中的一个特殊的文档(note)。NID 不包含数据库的信息(只在数据库内定位有效：译者注)，并且文档(note)修改时不会变化。
IID (Instance ID) - 确定一个给定数据库中的一个文档(note)的特殊修订版本，IID 不包含数据库信息，文档(note)修改时，IID会变化。
GIID (Global Instance ID) - 确定一个特殊数据库中的一个文档(note)的特殊修订版本. GIID 包含数据库信息。The GIID 文档(note)修改时，IID会变化。
你可以从 Notes 用户界面可以检查 ID 的信息。在视图中选择一个文档并且打开它。然后选择菜单 文件 - 文档属性。Notes 显示“文档属性”信息框。在信息页，Notes 显示和这个文档相关联的数据信息，包括文档创建和修改的日期和时间以及note ID 信息。 note ID 信息显示成三行，包含关键字和16进制字符。
对于一个典型的文档，通常是这个样子：
ID: OF0000039D:3836C29F-ON85255DC9:0056FB94
SD00255DF4:0057B8FA-SN00000003
DB85255CD9:00567287-NT0000C092
这三行包含所选文档 Originator ID (OID), Universal Note ID (UNID), Global Note ID (GID), 和 Note ID (NID) 。
The Universal Note ID (UNID) and the Originator ID (OID)
第一、二行组成了完整的 Originator ID， Originator ID 由 Universal Note ID (整个第一行)加上序列时间和序列号(第二行)：
Originator ID (OID) =
ID: OF0000039D:3836C29F-ON85255DC9:0056FB94
SD00255DF4:0057B8FA-SN00000003
DB85255CD9:00567287-NT0000C092
Universal Note ID (UNID) =
ID: OF0000039D:3836C29F-ON85255DC9:0056FB94
SD00255DF4:0057B8FA-SN00000003
DB85255CD9:00567287-NT0000C092
Sequence Time =
ID: OF0000039D:3836C29F-ON85255DC9:0056FB94
SD00255DF4:0057B8FA-SN00000003
DB85255CD9:00567287-NT0000C092
Sequence Number =
ID: OF0000039D:3836C29F-ON85255DC9:0056FB94
SD00255DF4:0057B8FA-SN00000003
DB85255CD9:00567287-NT0000C092
Originator ID (或 Universal Note ID)的前两部分由文件号(File member)和文档号(note member)组成。第一行由 "OF" ("Originator ID - File")，紧跟16个16进制字符，然后是连字符 "-" ，然后是 "ON" ("Originator ID - Note")，后面又是16个16进制字符。 "OF" 后面连字符之前的16个16进制字符构成了OID的文件号(File member)。"ON" 后面连字符之前的16个16进制字符构成了OID的文档号(note member)。
OID.File =
ID: OF0000039D:3836C29F-ON85255DC9:0056FB94
SD00255DF4:0057B8FA-SN00000003
DB85255CD9:00567287-NT0000C092
OID.Note =
ID: OF0000039D:3836C29F-ON85255DC9:0056FB94
SD00255DF4:0057B8FA-SN00000003
DB85255CD9:00567287-NT0000C092
在头文件 nsfdata.h 中包含了下面的定义 ORIGINATORID 数据结构和 UNIVERSALNOTEID 数据结构：
typedef struct {
DBID File; /* Unique (random) number */
/* (Even though this field is called "File," */
/* it doesn't have anything to do with the file!) */
TIMEDATE Note; /* Original Note Creation time/date */
/* (THE ABOVE 2 FIELDS MUST BE FIRST - UNID */
/* COPIED FROM HERE ASSUMED AT OFFSET 0) */
DWORD Sequence; /* LOW ORDER: sequence number, 1 for first version */
/* HIGH ORDER WORD: flags, as above */
TIMEDATE SequenceTime;/* time/date when sequence number was bumped */
} ORIGINATORID;
#define OID ORIGINATORID
typedef struct {
DBID File; /* Unique (random) number */
/* (Even though this field is called "File," */
/* it doesn't have anything to do with the file!) */
TIMEDATE Note; /* Original Note Creation time/date */
} UNIVERSALNOTEID;
#define UNID UNIVERSALNOTEID
文档的 Originator ID (OID) 确定了同一个文档(note)的所有复本。OID 由两部分组成：Universal Note ID (UNID) 和序列号(sequence number)、序列时间( sequence time)。 UNID 唯一的确定了同一个文档(note)的所有场合的复本。序列号(sequence number )和序列时间( sequence time) 放在一起区别同一文档(note)的不同版本。
Universal note ID (UNID) 确定了驻留在所有服务器上的同一个文档(note)。然而，UNID 缺少直接访问一个给定数据库中的文档(note)的信息。UNID 用于从一个文档来(note)引用另一个指定的文档(note)。答复文档中的"$REF" (FIELD_LINK) 域包含了其父文档的 UNID ， DocLinks(参见nsfdata.h中的 NOTELINK 数据结构)包含了链接文档(note)的 UNID ，和链接视图的 UNID 以及链接文档所在数据库的 ID (ViewLinks 包含了相同的信息，不同的是链接文档的那部分全部设为0， 而 DatabaseLinks 包含的信息是链接文档和链接视图的部分全部设为0) 。UNID 的重要特征是它能总是确定同一个文档()，不论它是否更新过。
UNID, the OID, 和复制器( Replicator)
Universal Note ID (Originator ID的第一部分) 唯一的确定了同一文档(note)的所有版本和复本。如果两个文档(note)具有相同的UNID则它们互为复本。因此，相同文档(note)的所有复本的不同版本都有相同的 UNID。这就导出一个必然的结论：一个数据库中不能含有两个具有相同UNID的文档(note)。如果复制器(replicator)发现同一个数据库中两个文档(note)具有相同的UNID，它就会产生一个错误消息写到日志里，并且不对文档进行复制。
完整的 Originator ID, 从另一个方面唯一地确定了一个文档(note)的一个特殊版本。就是说，一个文档的相同版本的复本具有相同的OID。同时，一个文档(note)复本修改后，它就会有不同的OID。因为在文档(note)被编辑后， Domino 和 Notes 会增加序列号(sequence number)和序列时间(sequence)。 当文档(note)的一个复本保持不变，而另一个复本被编辑并修改，于是这两个复本具有相同的 UNID但是序列号(sequence number)和序列时间(sequence times)不同，因此OID也不同。
Domino 复制器(replicator)使用UNID 来匹配数据库中的文档(note)，例如：如果数据库A和数据库B进行复制，数据库A中有个文档含有特殊的UNID，但是数据库B中没有，于是复制器(replicator)在数据库B中创建一个该文档的复本拷贝。
如果数据库A中包含一个文档(note)同时数据库B中有个文档(note)和它有相同的UNID，复制器(replicator)推断这两个文档 (note)是同一个文档的两个复本。这种情况下，复制器(replicator)继续检查两个文档的序列号(sequence number )和序列时间(sequence time)，然后复制器(replicator)推断是否是同一时间更新过需不需要复制。如果序列号(sequence number )或序列时间(sequence time)其中有一个或两个都不同，复制器必须决定哪一个是最近更新的哪一个比较旧一点。
如果其中一个更新过，而另一个未更新过，这样第一个复本的序列号会比第二个复本的序列号大，复制器(replicator)根据这种情况使用第一个复本覆盖第二个复本，从而达到两个数据库同步的目的。
复制冲突
复制冲突(Replication conflicts)发生在同时编辑并保存同 一个文档(note)。如果用户修改了数据库A中的一个文档复本，而另一个数据库B中的文档复本也被修改(所作修改都在上一次成功复制之后，下一次复制之 前)，于是两个文档复本具有相同的序列号()但是序列时间不同。这种情况下，复制器产生一个复制冲突，因为一个文档的两个复本在同一时期都进行了修 改。(如果把一个文档的多个复本看成是同一个文档的话，这就表示同一个文档同时被修改。)
复制器通过生成复制冲突文档处理这种复制冲突。序列时间较早的文档(document)被标志为冲突文档。两个数据库中将会具有两个文档，只不过序列时间较早的文档会成为序列时间较晚的文档的答复文档。
复制器产生复制文档冲突，会在冲突文档前标志黑色菱形标记。复制器把序列时间较晚的文档拷贝到序列时间较早的文档所在的数据库中，并完整的保持它的 OID。 然后复制器把序列时间较早的文档转成一个新的文档生成一个截然不同的 OID 并给它增加一个特殊的条目 "$Conflict" (VIEW_CONFLICT_ITEM) 。 这个 $Conflict 条目会使文档在视图的左边显示一个黑色的菱形标记，表示它是一个冲突文档。 复制器也会给这个冲突文档增加一个$REF 条目使他变成答复文档，$REF 条目中含有其父文档(序列时间较晚)的UNID。
