-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy path寻人信息交换格式(PFIF) 1.4 规范.html
1053 lines (920 loc) · 50 KB
/
寻人信息交换格式(PFIF) 1.4 规范.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<html><head><link rel="stylesheet" href="http://zesty.ca/pfif/style.css">
<meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
<title>PFIF(寻人信息交换格式) 1.4 规范</title>
</head>
<body>
<div class="title">
<h1><a href=".">PFIF(寻人信息交换格式) 1.4 规范</a></h1>
2012年5月29日<br>
编辑: Ka-Ping Yee (ping<span style="display: none">spam</span>@zesty.ca)<br>
翻译: 利 嘉豪 (li<span style="display: none">spam</span>jiahao90@<span style="display: none">spam</span>gmail.com)
</div>
<p>这份规范的URL地址:
<a href="http://zesty.ca/pfif/1.4">http://zesty.ca/pfif/1.4</a><br>
常见问题，例子和其它PFIF的信息:
<a href="http://zesty.ca/pfif">http://zesty.ca/pfif</a>
</p><p>这份文档在 <a href="http://www.gnu.org/copyleft/fdl.html">GNU Free Documentation License 1.2</a>下.
</p><div class="toc">
<ol>
<li><a href="#abstract">摘要</a></li>
<li><a href="#principles">设计原则</a></li>
<li><a href="#life-cycle">数据生命周期</a>
<ol>
<li><a href="#incremental-export"> 递进式导出机制（Incremental export mechanism)</a></li>
<li><a href="#data-update">数据更新机制</a></li>
<li><a href="#data-expiry">数据失效机制</a></li>
</ol>
</li><li><a href="#model">数据模型</a>
<ol>
<li><a href="#person-records">PERSON记录</a></li>
<li><a href="#note-records">NOTE记录</a></li>
</ol></li>
<li><a href="#xml">XML格式规范</a></li>
<li><a href="#atom">Atom feed规范</a>
<ol>
<li><a href="#atom-person">Atom person feeds</a></li>
<li><a href="#atom-note">Atom note feeds</a></li>
</ol></li>
<li><a href="#rss">RSS feed规范</a>
<ol>
<li><a href="#rss-person">RSS person feeds</a></li>
<li><a href="#rss-note">RSS note feeds</a></li>
</ol></li>
<li><a href="#database">建议的关系型数据库架构</a></li>
<li><a href="#changes">相对于前一版规范的改动</a></li>
<li><a href="#acknowledgements">致谢</a></li>
</ol>
</div>
<h2 id="abstract">1. 摘要</h2>
<p>此文档定义了寻人信息交换格式， 包括了关于由天灾人祸导致的失踪人员的一个数据模型和一个基于XML的交流格式。
首先，我们会用一种不依赖于具体实现（如面向对象，关系型或XML）的方式解释这个格式, 然后会用一个RELAX NG架构解释PFIF的XML格式。
此文档也对PFIF数据提供了一个可能的关系型数据库模型作为例子。
</p><h2 id="principles">2. 设计原则</h2>
<ol>
<li>
PFIF旨在将人和数据整合在一起。这个设计的目标是提倡聚合(convergence)：搜索同一个人的人们的聚合，不同来源的关于同一个人信息的聚合，重复数据的聚合，以及失踪人员与他们亲人的聚合(团圆)。
</li>
<li>
数据应该是可追溯的。因为数据来自于未知可靠性的来源，所以数据来源的信息应该被保留，以帮助使用者确认其可信性。
</li>
<li>每一条记录都属于一个<dfn>源仓库</dfn>,
其中源仓库指的是该信息（PFIF或非PFIF）被首次创建的仓库。</li>
<li>
每一个数据收集者有它的世界观，有责任去选择可信任的数据来源以单一集中的权威来决定数据的真实性是不可能的。
</li>
<li>
因为多条记录有可能指向同一个人，PFIF允许这样的记录互相关联。但是，根据前一条原则，每一个数据收集者都有他的决定将哪些记录关联起来的权利；这里没有任何集中的权威</li>
<li>从不同数据路径输入的同一个记录的不同副本应该可以被解析(resolved)
</li>
<li>
所有的日期和时间必须是国际标准时间，断不能使用当地时区。因为数据记录会被传输到不同的时区。本格式使用
<a href="http://www.ietf.org/rfc/rfc3339.txt">RFC 3339 格式</a>格式的日期, 并只允许国际标准时间。不同的前台界面可以将日期和时间转换到当地时间来显示。
</li>
</ol>
<h2 id="life-cycle">3. 数据生命周期</h2>
<p>
每一个PFIF仓库可以包含 <dfn>原始记录</dfn> 和 <dfn>克隆记录</dfn>.
一个原始记录是存在于其原始仓库中的记录;
一个克隆记录是一个来自于其它仓库的记录。下图描述了一个PFIF记录从被创建到到被传输到其它仓库的生命周期。
</p><pre class="diagram"> .---------------------.
| 1. 现实世界的事实 |
'---------------------'
| |
由人输入 | | 由人输入
一个 PFIF 仓库中 | | 一个非 PFIF 仓库中
| |
entry_date, source_date, | |
source_name, source_url | |
由仓库设定 | |
v v
.-----------------------------. .------------------------------.
| 2a. 原始的 PFIF 记录 | | 2b. 原始的非 PFIF 记录 |
| 在它的源仓库中 | | 在它的的源仓库中 |
'-----------------------------' '------------------------------'
| |
导出为一个PFIF | | 通过人工或者程序
文档或者feed | | 解析并转换为 PFIF数据模型
| |
| | source_date, source_name, source_url
| | 由人工或程序设定
v v
.----------------.
.--------------> | 3. PFIF 记录 |
| '----------------'
| |
| | 被载入一个 PFIF 仓库
| |
| | entry_date被设为导入的 日期/时间
| v
| .--------------------------------------.
| | 4. 在 PFIF 仓库中的克隆记录 |
| '--------------------------------------'
| |
| | 导出为 PFIF 文档或 feed
'------------------------'
</pre>
<h3 id="incremental-export">3.1. 递进式导出机制</h3>
<p>当一个PFIF仓库加入一个新的原始记录或克隆记录时，它必须将<span class="field">entry_date</span> 字段设为当时的时间。
当更多的记录被添加时，这个时间值绝对不能减少。一个客户端可以以查询所有<span class="field">entry_date</span>字段大于上一次接收的记录中最大的<span class="field">entry_date</span>字段的记录的方式，来递进地更新它对于一个仓库的副本。
</p><h3 id="data-update">3.2. 数据更新机制</h3>
<p>一个记录的原始仓库 (上图中的2a or 2b) 在一个记录被创建后可以更新该记录的任意字段, 除了<span class="field">person_record_id</span> 字段.
每当一个PFIF仓库创建或者更新一个原始目录，它必须将<span class="field">source_date</span> 和
<span class="field">entry_date</span> 字段设成当时的时间。
当一个仓库导入一个跟现存记录有同样记录标示符的PFIF记录时，它应该保留那个有最新的<span class="field">source_date</span>字段的版本.
</p><h3 id="data-expiry">3.3. 数据失效机制</h3>
<p>
当 <span class="field">expiry_date</span> 字段存在时，它表示该记录应该被删除以保护它所包含的个人信息的隐私。
遵守PFIF的实现必须符合以下要求：
</p><ul>
<li>
在 <span class="field">expiry_date</span>后的一天内,对于任意外部客户端，包括用户和机器API客户端，
PFIF仓库不能再提供对<span class="type">person</span> 记录的内容和所有关联的 <span class="type">note</span> 记录的访问。</li>
<li>
在此之后，如果仓库要通过API导出它的数据，它应该在失效的<span class="type">person</span> 记录的位置继续导出一个placeholder记录。
This placeholder 应该保留和原纪录相同的
<span class="field">person_record_id</span> 和
<span class="field">expiry_date</span> 值,
并且将<span class="field">source_date</span>
和 <span class="field">entry_date</span>设为placeholder被创建时的时间。所有其它字段应为空或被忽略。
</li>
<li>
在
<span class="field">expiry_date</span>后的60天内,
一个PFIF仓库必须永久和不可恢复地将包含<span class="type">person</span> 记录
和所有关联<span class="type">note</span> 记录内容的副本（包括备份）删除,
除了
<span class="field">person_record_id</span>,
<span class="field">source_date</span>,
<span class="field">entry_date</span>,
和 <span class="field">expiry_date</span>
字段需要用来生成placeholder
</li>
</ul>
<p>
为了满足一个请求删除现存原始记录的请求，一个PFIF仓库应该将记录的
<span class="field">expiry_date</span> 字段设成当时的时间
(为了跟 <a href="#data-update">前一部分</a>保持一致,
仓库也会把<span class="field">source_date</span>
和<span class="field">entry_date</span> 设成当时的时间。)
这之后，上述的失效机制会将删除操作传播到其它遵守PFIF的仓库。
</p><h2 id="model">4. 数据模型</h2>
<p>有以下两种类型的记录
<span class="type">person</span>记录
是为了储存标识某个特定人员的信息，
<span class="type">note</span> 记录是为了储存特定人员现在状态的信息
每一个 <span class="type">note</span> 记录属于一个特定的
<span class="type">person</span>, 而一个
<span class="type">person</span> 记录可以拥有任意数目的关联 <span class="type">note</span> 记录。
</p><p><span class="type">person</span> 记录可以被找寻失踪人员的人创建，也可以被拥有失踪人员信息的人创建。特定人员的 <span class="type">person</span> 记录是所有parties聚合的重点;
而特定人员 <span class="type">note</span> 记录则储存着有关特定人员不断增加的分享信息。</p><p>一个 <span class="type">person</span> 记录只有在其信息不正确的情况下才应该被更新。如果一个特定的
<span class="type">person</span> 的状态或位置被改变,
这应该由加入一个新的关于该<span class="type">person</span>的<span class="type">note</span> 记录来反映。
</p><h3 id="person-records">4.1. <span class="type">person</span> 记录</h3>
<p>一个 <span class="type">person</span> 记录包含了25个字段。
对于一个特定人员，可能有多个
<span class="type">person</span> 记录。实际上，任意从不同来源导入数据的应用，都很有可能获得同一人员的多份
<span class="type">person</span> 记录。
应用对如何关联这些记录有决定权。
(详见下文 <a href="#database"> 建议的关系型数据库架构</a> )。
推荐的做法是保留所有记录的副本，分开地跟踪哪些记录对应同一个人。
</p><h4>关于记录本身的元数据 (9 个字段)</h4>
<p>为了让用户可以追踪数据和确保其可行性， 这些元数据必不可少。
</p><dl>
<dt><span class="field">person_record_id</span>
(ASCII 字符串，必需)</dt>
<dd>
该记录的唯一识别符, 包含了一个小写的ASCII域名，后面紧跟一个"/"和一个本地的识别符。该域名标识了此记录的原始（地址），而这个原始地址拥有对这个记录的权威性。 本地识别符的格式取决于原始地址。当person_record_id以一个不同于应用本身域名的域名开时，这标识该记录是一个克隆记录。
</dd>
<dt><span class="field">entry_date</span>
("年年年年-月月-日日T时时:分分:秒秒Z" 格式的ASCII字符串, 可选的):</dt>
<dd>
世界标准时间，表示该记录副本被存储的时间。（见上面的递进式导出机制）
(见上文 <a href="#incremental-export">递进式导出机制</a>).
</dd>
<dt><span class="field">expiry_date</span>
("年年年年-月月-日日T时时:分分:秒秒Z"格式的ASCII字符串, 可选的):</dt>
<dd>
世界标准时间，此日期过后该记录应该被删除
(见上文 <a href="#data-expiry">数据失效机制</a>)。
</dd>
<dt><span class="field">author_name</span> (Unicode 字符串, 可选的):</dt>
<dd>
录入该记录的作者的全名
</dd>
<dt><span class="field">author_email</span>
(电子邮件地址字符串, 可选的):</dt>
<dd>
录入该记录的作者的联系电子邮箱地址。
</dd>
<dt><span class="field">author_phone</span> (ASCII 字符串, 可选的):</dt>
<dd>
录入该记录的坐者的电话号码
</dd>
<dt><span class="field">source_name</span> (Unicode 字符串, 可选的):</dt>
<dd>
可读的该数据原始仓库的名字。</dd>
<dt><span class="field">source_date</span>
("年年年年-月月-日日T时时:分分:秒秒Z" 格式的ASCII 字符串, 必需):</dt>
<dd>
该记录原始副本在其原始仓库被创建的时间，世界标准时间。
</dd>
<dt><span class="field">source_url</span> (URL 字符串, 可选的):</dt>
<dd>
该记录在其原始仓库中的URL地址
(尽可能的详细，有可能的话具体到特定记录的URL地址）。
</dd>
</dl>
<h4>表示关于失踪人员的信息(16 个字段)</h4>
<p>
这些字段包含了用于标识一个人的信息；这些信息，除非是错误的，否则不要改变。
搜索 <span class="type">person</span> 记录时应该搜索这些字段.
</p><dl>
<dt><span class="field">full_name</span> (Unicode 字符串, 必需的):</dt>
<dd>
找到或失踪人员的全名，以该人员所用语言和所在文化所常用的顺序排列。比如，一个常见的英语名字会被格式化为名，中间名，姓，其中用空格隔开，同时一个常见的中文名字会被格式化为姓，名，其中没有任何空格。如果该人员有超过一个全名，（比如一个中文名一个英文名），以最常用的全名开始，并用换行符(Unicode U+000A)来隔开这些全名。
</dd>
<dt><span class="field">given_name</span> (Unicode 字符串, 可选的):</dt>
<dd>
找到或失踪人员的名。后面紧跟可选的一个空格符和任意中间名或中间名前缀。
</dd>
<dt><span class="field">family_name</span> (Unicode 字符串, 可选的):</dt>
<dd>
找到或失踪人员的姓。
</dd>
<dt><span class="field">alternate_names</span> (Unicode 字符串, 可选的):</dt>
<dd>
任何其它既不是该人员全名的一部分，又跟该人员关联的姓名，譬如昵称，其它拼法和音译。举个例子，日语汉字的片假名可以放进这个字段。用换行符 (Unicode U+000A) 来分隔不同的名字。
</dd>
<dt><span class="field">description</span> (Unicode 字符串, 可选的):</dt>
<dd>
自由格式文本的对于该人员的描述。在输入表格中，一个多行的文本框适用于该字段。
</dd>
<dt><span class="field">sex</span> (ASCII 字符串, 可选的):</dt>
<dd>
找到或失踪人员的性别。用以下三个字符串中的一个来表示：
<code>female</code>, <code>male</code>, 或 <code>other</code>。
如果性别是未知的，忽略这个字段。
</dd>
<dt><span class="field">date_of_birth</span>
( "年年年年", "年年年年-月月", 或 "年年年年-月月-日日" 格式的ASCII字符串, 可选的):</dt>
<dd>
找到或失踪人员的准确或模糊出生日期。
</dd>
<dt><span class="field">age</span>
(整型数, 或"最小-最大"格式的ASCII字符串, 可选的):
</dt><dd>
找到或失踪人员的模糊年龄，以从其出生日期到
<span class="field">source_date</span> 的日期为准。
这个字段的值可以是一个十进制的整数，也可以是一个由"-"隔开的两个十进制整数组成的闭区间。若<span class="field">source_date</span> 不存在则此字段没有意义。</dd>
<dt><span class="field">home_street</span> (Unicode 字符串, 可选的):</dt>
<dd>
找到或失踪人员的家庭地址的街道名称。为了保护用户隐私，应用通常避免在此字段中包含街道号码。
</dd>
<dt><span class="field">home_neighborhood</span> (Unicode 字符串, optional):</dt>
<dd>
找到或失踪人员的家庭住址所在社区。
对于其它地址字段不能反映的官方或非官方的地理区域名字，请使用此字段。例如XX小区。
</dd>
<dt><span class="field">home_city</span> (Unicode 字符串, 可选的):</dt>
<dd>
找到或失踪人员家庭住址所在城市。
</dd>
<dt><span class="field">home_state</span> (Unicode 字符串, 可选的):</dt>
<dd>
找到或失踪人员家庭地址所在地区或省份,
用一个大写的 ISO 3166-2 码 (首选) 或名字来表示。
</dd>
<dt><span class="field">home_postal_code</span> (ASCII 字符串, 可选的):</dt>
<dd>
找到或失踪人员的家庭住址的邮政编码，以该国家通常使用的格式为准。
</dd>
<dt><span class="field">home_country</span>
(ASCII ISO-3166-1 国家编码, 可选的):</dt>
<dd>
找到或失踪人员的家庭住址所在国家，用一个大写的两位ISO-3166-1国家编码来表示。
</dd>
<dt><span class="field">photo_url</span> (URL 字符串, 可选的):</dt>
<dd>
用来识别找到或失踪人员的相片的URL地址。
</dd>
<dt><span class="field">profile_urls</span> (URL 字符串, 可选的):</dt>
<dd>
该人员在其它网站上的个人资料页面的URL地址。用换行符 (Unicode U+000A) 来分隔不同的地址。
</dd>
</dl>
<h3 id="note-records">4.2. <span class="type">note</span> 记录</h3>
<p>每一个 <span class="type">note</span> 记录只属于一个 <span class="type">person</span> 记录。
一个特定的<span class="type">person</span> 记录可以和多个<span class="type">note</span> 记录相关联。
(见下文的实现提示。
一个可能的数据库实现是包含一个外键, <span class="field">person_record_id</span>,
来指向一个 <span class="type">person</span> 记录。
一个面向对象的实现可以是在<span class="type">person</span> 对象中加入一个
<span class="type">note</span> 对象的列表。)
</p><p><span class="type">note</span>记录被用来提供失踪人员的更新信息。
每一个NOTE记录有一个时间戳以及该记录的作者信息。不同的应用可以使用时间戳来决定一个给定字段的最新值。
</p><h4>Metadata about the record itself (8 fields)</h4>
<dl>
<dt><span class="field">note_record_id</span> (ASCII 字符串, 必需的):</dt>
<dd>
这个记录的唯一识别符，包含了一个域名紧跟一个"/"和一个本地识别符。
域名标识了这个记录的源仓库，而这个源仓库拥有对这个记录的权威性。
本地识别符的格式取决于源仓库。当 <span class="field">note_record_id</span>以一个不同于应用本身域名的域名开始时，这表示这个记录是一个从其它来源复制而来的克隆记录。
</dd>
<dt><span class="field">person_record_id</span> (ASCII 字符串, 必须的):</dt>
<dd>
改note记录所属的<span class="type">person</span>记录的
<span class="field">person_record_id</span>
</dd>
<dt><span class="field">linked_person_record_id</span> (ASCII 字符串, 可选的):</dt>
<dd>
与该<span class="type">note</span>记录所属的<span class="type">person</span>记录有关的另一条 <span class="type">person</span> 记录的 <span class="field">person_record_id</span>。当此字段存在时，它表明该note记录的作者相信<span class="field">person_record_id</span> 和
<span class="field">linked_person_record_id</span>标识的两条person记录指向同一个人。
如果该字段存在，那么 <span class="field">text</span> 字段应该解释为什么这些记录被判断为指向同一个人。</dd>
<dt><span class="field">entry_date</span>
("年年年年-月月-日日T时时:分分:秒秒Z"格式的ASCII字符串, 可选的):</dt>
<dd>
世界标准时间，表示了该记录该副本被储存的日期。
一个PFIF仓库在添加记录时必须保证这个值单调递增，以使得一个客户，可以通过查询所有
<span class="field">entry_date</span> 大于或等于他上一次接收到的记录的
<span class="field">entry_date</span> 的方式，来更新一个仓库的副本。
</dd>
<dt><span class="field">author_name</span> (Unicode 字符串, 必须的):</dt>
<dd>
写入这个note的作者的全名。</dd>
<dt><span class="field">author_email</span>
(电子邮箱地址字符串, 可选的):</dt>
<dd>
写入这个note的作者的优先联系电子邮箱地址。</dd>
<dt><span class="field">author_phone</span> (ASCII 字符串, 可选的):</dt>
<dd>
写入这个note的作者的优先联系电话号码。
</dd>
<dt><span class="field">source_date</span>
(form "年年年年-月月-日日T时时:分分:秒秒Z"格式的ASCII字符串, 必需的):</dt>
<dd>
该记录在源仓库被创建时的世界标准时间。多数情况下，note记录应该以此字段排列来显示。
</dd>
</dl>
<h4>失踪人员的状态信息 (6 个字段)</h4>
<p>The
<span class="field">author_made_contact</span>,
<span class="field">status</span>,
<span class="field">email_of_found_person</span>,
<span class="field">phone_of_found_person</span> 和
<span class="field">last_known_location</span> 字段储存了随时间变化的数据。当这些字段在 <span class="type">note</span> 记录中存在时,
该记录声明了这些字段的新的值，
而 <span class="field">source_date</span> 字段则表明这些新值生效的日期。
所以，举个例子，一个希望显示最新已知位置的应用可以寻找有有非空<span class="field">last_known_location</span>
字段和最大<span class="field">source_date</span>指的
<span class="type">note</span>记录。
</p><dl>
<dt><span class="field">author_made_contact</span> (ASCII 字符串, 可选的):
</dt><dd>
如果这个note的作者亲自联系过该失踪人员，那么这个字段值为字符串<code>true</code>，否则为 <code>false</code> 。
如果这个字段是<code>true</code>，
那么该记录的 <span class="field">text</span> 字段应该描述怎么样和什么时候，该失踪人员被联系到或者被看见。
</dd>
<dt><span class="field">status</span> (ASCII 字符串, 可选的)</dt>
<dd>
找到或失踪人员的状态，用以下5个字符串忠的一个来代表：
<dl>
<dt><code>information_sought</code></dt>
<dd>这个记录的作者正在寻找目标人员的信息。</dd>
<dt><code>is_note_author</code></dt>
<dd>这个记录的作者正是目标人员。</dd>
<dt><code>believed_alive</code></dt>
<dd>这个记录的作者已得到信息证明目标人员生还。</dd>
<dt><code>believed_missing</code></dt>
<dd>这个记录的作者有理由相信目标人员仍然失踪。</dd>
<dt><code>believed_dead</code></dt>
<dd>这个记录的作者已得到信息证明目标人员已经去世。</dd>
</dl>
</dd>
<dt><span class="field">email_of_found_person</span>
(电子邮箱地址, 可选的):</dt>
<dd>
找到人员现在的优先联系电子邮箱地址。
The current preferred contact e-mail address of the FOUND person.
仅当该人员被找到时此字段才存在。如果这个字段存在，那么这条记录的 <span class="field">text</span> 字段应该描述该人员的联系信息是怎样确定的。
</dd>
<dt><span class="field">phone_of_found_person</span>
(ASCII 字符串, 可选的):</dt>
<dd>
找到人员现在的优先联系电话号码。
仅当该人员被找到时此字段才存在。如果这个字段存在，那么这条记录的 <span class="field">text</span> 字段应该描述该人员的联系信息是怎样确定的。
</dd>
<dt><span class="field">last_known_location</span>
(Unicode 字符串, 可选的):</dt>
<dd>
关于该人员最后已知位置的自由文本描述。可以用十进制的经纬度以逗号分割的形式来表示地理坐标。（纬度在前，经度在后。北纬和西经为正值。）如果这个字段存在，那么这条记录的
<span class="field">text</span>字段应该描述该人员的位置是怎样被确定的。
</dd>
<dt><span class="field">text</span> (Unicode 字符串, 必需的):</dt>
<dd>
关于失踪人员的自由文本描述，其中包括该人员现在的状况和位置细节，最后一次在哪里被看到，对其它信息的更正，等等。在输入表格中，一个多行文本框适用于该字段。
</dd>
<dt><span class="field">photo_url</span> (URL 字符串, 可选的):</dt>
<dd>
与该记录一起的一幅图片的URL地址。</dd>
</dl>
<h2 id="xml">5. XML 格式规范</h2>
<p>
PFIF的XML命名空间是：
</p><ul><li>
<a href="http://zesty.ca/pfif/1.4">http://zesty.ca/pfif/1.4</a></li></ul>
<p>一个PFIF文档的MIME类型是:
</p><ul><li><code>application/pfif+xml</code></li></ul>
<p>一个有效的PFIF XML文档由一个一个单独的<span class="element">pfif</span> element元素组成，其中包含a)一个或多个<span class="element">person</span>元素, 或b)一个或多个<span class="element">note</span>元素。这些元素又包含了作为子元素的上述字段。
在一个 <span class="element">person</span> 元素中,
<span class="field">person_record_id</span>,
<span class="field">source_date</span>, 和
<span class="field">full_name</span> 字段是必需的。在一个
<span class="element">note</span> 元素中,
<span class="field">note_record_id</span>,
<span class="field">author_name</span>, 和
<span class="field">source_date</span> 字段是必需的。
所有其它字段都是可选的。子元素在 <span class="element">person</span> 或
<span class="element">note</span> 元素中的顺序不重要。
</p><p>
一个<span class="element">note</span>元素可以存在于一个<span class="element">person</span>元素的里面或外面。当一个<span class="element">note</span>元素出现在<span class="element">person</span>元素的外面时，这个<span class="element">note</span>必须包含一个<span class="field">person_record_id</span>. 当<span class="element">note</span>元素在<span class="element">person</span> 元素里面时，<span class="field">person_record_id</span>是可选的。如果在这种情况下<span class="field">person_record_id</span>存在的话，必需跟外部的<span class="element">person</span>元素的person_record_id一致。
</p><p>以下给出一个用RELAX NG Compact Syntax表示的PFIF的<a href="http://relaxng.org/">RELAX NG</a>架构：
</p><pre>namespace pfif = "http://zesty.ca/pfif/1.4"
start = element pfif:pfif { person* & note* } //译者标注：花括号里表明的是可以有任意数目的person和note以任意顺序排列。
person = element pfif:person {
<b>element pfif:person_record_id { record_id }</b> &
element pfif:entry_date { time } ? &
element pfif:expiry_date { time } ? &
element pfif:author_name { text } ? &
element pfif:author_email { email } ? &
element pfif:author_phone { phone } ? &
element pfif:source_name { text } ? &
<b>element pfif:source_date { time }</b> &
element pfif:source_url { url } ? &
<b>element pfif:full_name { text }</b> &
element pfif:given_name { text } ? &
element pfif:family_name { text } ? &
element pfif:alternate_names { text } ? &
element pfif:description { text } ? &
element pfif:sex { sex } ? &
element pfif:date_of_birth { approx_date } ? &
element pfif:age { approx_age } ? &
element pfif:home_street { text } ? &
element pfif:home_neighborhood { text } ? &
element pfif:home_city { text } ? &
element pfif:home_state { text } ? &
element pfif:home_postal_code { text } ? &
element pfif:home_country { country_code } ? &
element pfif:photo_url { url } ? &
element pfif:profile_urls { text } ? &
note*
}
note = element pfif:note {
<b>element pfif:note_record_id { record_id }</b> &
element pfif:person_record_id { record_id } ? &
element pfif:linked_person_record_id { record_id } ? &
element pfif:entry_date { time } ? &
<b>element pfif:author_name { text }</b> &
element pfif:author_email { email } ? &
element pfif:author_phone { phone } ? &
<b>element pfif:source_date { time }</b> &
element pfif:author_made_contact { boolean } ? &
element pfif:status { status } ? &
element pfif:email_of_found_person { email } ? &
element pfif:phone_of_found_person { phone } ? &
element pfif:last_known_location { text } ? &
element pfif:text { text } &
element pfif:photo_url { url } ?
}
record_id = xsd:string { pattern = ".+/.+" }
time = xsd:dateTime { pattern = "\d\d\d\d-\d\d-\d\dT\d\d:\d\d:\d\d(\.\d+)?Z" }
email = xsd:string { pattern = ".+@.+" }
phone = xsd:string { pattern = "[\-+()\d ]+" }
url = text
sex = "female" | "male" | "other"
approx_date = xsd:string { pattern = "\d\d\d\d(-\d\d(-\d\d)?)?" }
approx_age = xsd:string { pattern = "\d+(-\d+)?" }
country_code = xsd:string { pattern = "[A-Z][A-Z]" }
boolean = "true" | "false"
status = "information_sought" | "is_note_author" |
"believed_alive" | "believed_missing" | "believed_dead"
</pre>
<h2 id="atom">6. Atom feed 规范</h2>
<p>PFIF XML文档可以被嵌入到
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">Atom 1.0</a> feeds.
一个PFIF文档应该以XML命名空间嵌入和以 <span class="element">entry</span>的直系子元素被插入。
</p>
<p>Atom 1.0 定义了一个包含了任意数目<span class="element">entry</span> 元素的最高级 <span class="element">feed</span> 元素。
这个最高级元素应该声明一个PFIF命名空间。
推荐的前缀是<code>pfif</code>，所以最高级元素应该像这样
：
</p>
<pre><feed xmlns="http://www.w3.org/2005/Atom"
xmlns:pfif="http://zesty.ca/pfif/1.4">
...
</feed></pre>
<p>
这个部分的剩下内容提供了如何让应用populate标准Atom元素，使得feed会对于feed读取软件有意义的建议。但是，嵌入的PFIF文档对于任何在Atom元素中出现的冗余信息都具有优先级。
</p>
<p>
这里定义了两种PFIF Atom Feeds
<dfn>person feeds</dfn>，其中每一个entry包含了一个person；
<dfn>note feeds</dfn>， 其中每一个entry包含一个note。
一个person feed可以类比成一个拥有博客entries的博客feed；而一个note feed可以大致类比成特定博客entry的评论feed。例如，一个应用可能会subscribe到一个person feed， 为了将失踪人员的记录从其它数据库整合到一起；另一个应用则subscribe到一个note feed， 为了将特定人员的更新以记录的流形式显示出来。
</p>
<h3 id="atom-person">6.1. Atom person feeds</h3>
<p>一个Atom person feed在<span class="element">feed</span>元素内至少提供了以下元素：
</p>
<dl>
<dt><span class="element">id</span></dt>
<dd>
这个元素应该包含一个与这个feed关联的唯一URI。
这可以使网站的URL地址，对应到提供这个feed的数据库或服务。
</dd>
<dt><span class="element">title</span></dt>
<dd>
这个元素应该包含这个feed的名字。
它应该包括提供这个feed的数据库或服务的名称。
</dd>
<dt><span class="element">subtitle</span></dt>
<dd>
这个元素应该包含描述该feed的一个短语或一句话。
这里应该解释feed是怎么样被产生的，例如
"Scraped daily by FooMatic 2.3 from http://example.org/"。
</dd>
<dt><span class="element">updated</span></dt>
<dd>
这个元素应该包含这个feed上一次被更新的世界标准时间，
用"年年年年-月月-日日T时时:分分:秒秒Z" 格式来表达。
</dd>
<dt><span class="element">link</span></dt>
<dd>
这个元素应该包含一个可以得到这个feed的URL地址。这个元素应该有一个 <code>rel</code> 属性，而它的值是 <code>self</code>。
</dd>
</dl>
<p>一个Atom person feed在每一个<span class="element">entry</span> 元素里提供至少以下几个元素：
</p>
<dl>
<dt><span class="element">pfif:person</span></dt>
<dd>
这个元素包含了代表<a href="#person-records"><span class="type">person</span> record</a>的字段的子元素，和0或多个<span class="element">pfif:note</span> 元素。
一个希望提供完整导出的服务应该包含所有跟这个person有关的 <span class="type">note</span>记录。
</dd>
<dt><span class="element">id</span></dt>
<dd>
这个元素应该包含一个由"pfif:" 紧跟
<span class="field">person_record_id</span>的字段值所组成的URI字符串。
</dd>
<dt><span class="element">title</span></dt>
<dd>
这个元素应该包含
<span class="field">full_name</span> 的字段值。
</dd>
<dt><span class="element">author</span></dt>
<dd>这个元素应该包含一个含有<span class="field">author_name</span> 的字段值的
<span class="element">name</span> 元素 和一个含有了<span class="field">author_email</span> 字段值的
<span class="element">email</span> 元素。这两个字段都属<span class="type">person</span>记录。
</dd>
<dt><span class="element">updated</span></dt>
<dd>
这个元素应该包含了<span class="type">person</span> 记录中的
<span class="field">source_date</span>字段值。
</dd>
<dt><span class="element">content</span></dt>
<dd>
这个元素应该包含一个<span class="type">person</span>记录中信息的可读HTML格式。
怎么样将内容格式化取决于应用。
</dd>
<dt><span class="element">source</span></dt>
<dd>
这个元素应该包含一个这个feed的 <span class="element">title</span>元素的副本。
这个元素也可以包含feed元素的任意其它子元素的副本。
</dd>
</dl>
<h3 id="atom-note">6.2. Atom note feeds</h3>
<p>一个 Atom note feed在<span class="element">feed</span>元素内至少提供了一下元素：
</p>
<dl>
<dt><span class="element">id</span></dt>
<dd>
这个元素应该包含一个与这个feed关联的唯一URI。
这可以使网站的URL地址，对应到提供这个feed的数据库或服务。
</dd>
<dt><span class="element">title</span></dt>
<dd>
这个元素应该包含这个feed的名字。
它应该包括提供这个feed的数据库或服务的名称,后面跟一个更加具体的标题，来解释数据库或服务如何选择note。例如，对于一个关于特定人员的note feed, title应该是服务的名字加上目标人员的姓名。
</dd>
<dt><span class="element">subtitle</span></dt>
<dd>
这个元素应该包含描述该feed的一个短语或一句话。
这里应该解释feed是怎么样被产生的，例如: "Exported by CiviCRM 1.1, http://www.example.org/."
</dd>
<dt><span class="element">updated</span></dt>
<dd>
这个元素应该包含这个feed上一次被更新的世界标准时间，
用"年年年年-月月-日日T时时:分分:秒秒Z" 格式来表达。
</dd>
<dt><span class="element">link</span></dt>
<dd>
这个元素应该包含一个可以得到这个feed的URL地址。这个元素应该有一个 <code>rel</code> 属性，而它的值是 <code>self</code>。
</dd>
</dl>
<p>一个Atom note feed在每一个<span class="element">entry</span> 元素中至少提供以下元素：
</p>
<dl>
<dt><span class="element">pfif:note</span></dt>
<dd>
这个元素包含了
<a href="#note-records"><span class="type">note</span> 记录</a>的字段作为子元素。
</dd>
<dt><span class="element">id</span></dt>
<dd>
这个元素应该包含由"pfif:"和
<span class="field">note_record_id</span>字段值组成的URI字符串。
</dd>
<dt><span class="element">title</span></dt>
<dd>
这个元素应该包含<span class="field">text</span>字段的摘要。
</dd>
<dt><span class="element">author</span></dt>
<dd>
这个元素应该包含一个含有<span class="field">author_name</span> 的字段值的
<span class="element">name</span> 元素 和一个含有了<span class="field">author_email</span> 字段值的
<span class="element">email</span> 元素。这两个字段都属<span class="type">note</span>记录。
</dd>
<dt><span class="element">updated</span></dt>
<dd>
这个元素应该包含了<span class="type">note</span> 记录中的
<span class="field">source_date</span>字段值。
</dd>
<dt><span class="element">content</span></dt>
<dd> 这个元素应该包含一个<span class="type">note</span>记录中<span class="field">text</span> 字段的可读HTML格式。
怎么样将内容格式化取决于应用。</dd>
</dl>
<h2 id="rss">7. RSS feed 规范</h2>
<p>PFIF XML文档可以嵌入到
<a href="http://blogs.law.harvard.edu/tech/rss">RSS 2.0</a> feed中。
(用RSS 2.0的术语来说，这个部分定义了一个RSS 2.0模块)
这种PFIF文档应该用一个XML命名空间来指定，然后作为一个<span class="element">item</span> 元素的直系子元素嵌入。
</p>
<p>RSS 2.0定义了两个主要的元素，
<span class="element">channel</span> 和 <span class="element">item</span>,
而包含它们的是一个最高级 <span class="element">rss</span> 元素。
这个最高级元素应该声明PFIF的命名空间。
推荐的前缀是<code>pfif</code>，所以最高级元素看起来应该像这样：
</p>
<pre><rss version="2.0" xmlns:pfif="http://zesty.ca/pfif/1.4">
...
</rss></pre>
<p>
这个章节剩下的部分提供了推荐的做法，对于应用怎样填充标准RSS元素，以使得feed对于现有的feed-读取软件有意义。不过需要注意的是，嵌入的PFIF文档优先于RSS元素里的其它冗余信息。
</p>
<p>
像前一章节一样，这里定义了两种PFIFRSS feed：在每个item里都包含一个person的person feed, 和在每个item里都包含一个note的note feed。</p>
<h3 id="rss-person">7.1. RSS person feeds</h3>
<p>一个 RSS person feed 在其<span class="element">channel</span> 元素里至少提供以下的元素：
</p>
<dl>
<dt><span class="element">title</span></dt>
<dd>
这个元素应该包含这个feed的名字。
它应该包括提供这个feed的数据库或服务的名称。
</dd>
<dt><span class="element">description</span></dt>
<dd>
这个元素应该包含描述该feed的一个短语或一句话。
这里应该解释feed是怎么样被产生的，例如：
"Scraped daily by FooMatic 2.3 from http://example.org/".
</dd>
<dt><span class="element">lastBuildDate</span></dt>
<dd>
这个元素应该包含这个feed上一次被更新的世界标准时间，用<a href="http://www.ietf.org/rfc/rfc0822.txt">RFC 822</a>
日期格式来表示，比如： "Sat, 07 Sep 2002 00:00:01 GMT".
</dd>
<dt><span class="element">link</span></dt>
<dd>
这个元素应该包含一个提供这个feed的数据库或服务的网站的URL地址。</dd>
</dl>
<p>一个RSS person feed应该在每个 <span class="element">item</span> 元素内提供至少以下元素：
</p>
<dl>
<dt><span class="element">pfif:person</span></dt>
<dd>
这个元素包含了代表<a href="#person-records"><span class="type">person</span> record</a>的字段的子元素，和0或多个<span class="element">pfif:note</span> 元素。
一个希望提供完整导出的服务应该包含所有跟这个person有关的 <span class="type">note</span>记录。
</dd>
<dt><span class="element">guid</span></dt>
<dd>
这个元素应该包含<span class="field">person_record_id</span>的字段值。
</dd>
<dt><span class="element">title</span></dt>
<dd>
这个元素应该包含 <span class="field">full_name</span> 的字段值。
</dd>
<dt><span class="element">author</span></dt>
<dd>
这个元素包含的了包含了一个字符串。而该字符串是这样构成的：
<span class="field">author_email</span> 字段值后面加一个空格和
<span class="field">author_name</span>字段值，然后由一个小括号括起来。
</dd>
<dt><span class="element">pubDate</span></dt>
<dd>
这个元素应该包含了<span class="type">person</span>记录中
<span class="field">source_date</span>的字段值，转换成<a href="http://www.ietf.org/rfc/rfc0822.txt">RFC 822</a>
时间格式，例如： "Sat, 07 Sep 2002 00:00:01 GMT"。时区必须是格林威治标准时间而年份必须是4为数字。
</dd>
<dt><span class="element">description</span></dt>
<dd>
这个元素应该包含一个<span class="type">person</span>记录中信息的可读HTML格式。
怎么样将内容格式化取决于应用。
</dd>
<dt><span class="element">source</span></dt>
<dd>
这个元素应该包含<span class="field">source_name</span>的字段值。
</dd>
<dt><span class="element">link</span></dt>
<dd>
这个元素应该包含
<span class="field">source_url</span> 的字段值。
</dd>
</dl>
<h3 id="rss-note">7.2. RSS note feeds</h3>
<p>一个RSS note feed在每个<span class="element">channel</span> 元素里提供至少下列元素：
</p>
<dl>
<dt><span class="element">title</span></dt>
<dd>
这个元素应该包含这个feed的名字。
它应该包括提供这个feed的数据库或服务的名称,后面跟一个更加具体的标题，来解释数据库或服务如何选择note。例如，对于一个关于特定人员的note feed, title应该是服务的名字加上目标人员的姓名。</dd>
<dt><span class="element">description</span></dt>
<dd>
这个元素应该包含描述该feed的一个短语或一句话。
这里应该解释feed是怎么样被产生的，例如：
"Scraped daily by FooMatic 2.3 from http://www.example.org/".
</dd>
<dt><span class="element">lastBuildDate</span></dt>
<dd>
这个元素应该包含这个feed上一次被更新的世界标准时间，用<a href="http://www.ietf.org/rfc/rfc0822.txt">RFC 822</a>
日期格式来表示，比如： "Sat, 07 Sep 2002 00:00:01 GMT"。</dd>
<dt><span class="element">link</span></dt>
<dd>
这个元素应该包含一个提供这个feed的数据库或服务的网站的URL地址。
对于一个关于特定人员的note feed这个链接应该指向该人员记录的网页。
</dd>
</dl>
<p>一个 RSS note feed在每个<span class="element">item</span>元素里提供至少以下元素：
</p>
<dl>
<dt><span class="element">pfif:note</span></dt>
<dd>
这个元素包含了
<a href="#note-records"><span class="type">note</span> 记录</a>的字段作为子元素。
</dd>
<dt><span class="element">guid</span></dt>
<dd>
这个元素包含了<span class="field">note_record_id</span> 的字段值。
</dd>
<dt><span class="element">author</span></dt>
<dd>
这个元素包含的了包含了一个字符串。而该字符串是这样构成的：
<span class="field">author_email</span> 字段值后面加一个空格和
<span class="field">author_name</span>字段值，然后由一个小括号括起来。
</dd>
<dt><span class="element">pubDate</span></dt>
<dd>
这个元素应该包含了<span class="type">note</span>记录中
<span class="field">source_date</span>的字段值，转换成<a href="http://www.ietf.org/rfc/rfc0822.txt">RFC 822</a>
时间格式，例如： "Sat, 07 Sep 2002 00:00:01 GMT"。时区必须是格林威治标准时间而年份必须是4为数字。
</dd>
<dt><span class="element">description</span></dt>
<dd>
这个元素应该包含一个<span class="type">note</span>记录中<span class="field">text</span> 字段的可读HTML格式。
怎么样将内容格式化取决于应用。</dd>
</dl>
<h2 id="database">8. 建议的关系型数据库架构</h2>
<p>
此部分推荐了一种可能的对于PFIF数据的关系型数据库架构。
数据库设计的具体细节取决于每个应用；这只是一个可能的开始点。一个关系型数据库可以在两个表中储存PFIF数据：
一个储存<span class="type">person</span>，另一个储存
<span class="type">note</span>。
</p><pre>PERSON table:
string person_record_id primary key
datetime entry_date
datetime expiry_date
string author_name
string author_email
string author_phone
string source_name
datetime source_date
string source_url
string full_name
string given_name
string family_name
string alternate_names
text description
string sex
string date_of_birth
string age
string home_street
string home_neighborhood
string home_city
string home_state
string home_postal_code
string home_country
string photo_url
string profile_urls
NOTE table:
string note_record_id primary key
string person_record_id foreign key not null
string linked_person_record_id foreign key or null
datetime entry_date
string author_name
string author_email
string author_phone
datetime source_date
boolean author_made_contact
string status
string email_of_found_person
string phone_of_found_person
string last_known_location
text text
string photo_url</pre>
<p>
为了将一个外部 <span class="type">person</span> 记录连接到一个本地的 <span class="type">person</span> 记录,
这个应用增加了一个 <span class="type">note</span>
并关联到本地的 <span class="type">person</span> 记录, 这个<span class="type">note</span>记录包含了一个<span class="field">linked_person_record_id</span> 字段，内容为
外部记录的 <span class="field">person_record_id</span>
。
这个note的其它字段描述了合并决定的情况：
<span class="field">source_date</span> 表示了这个决定的日期，
<span class="field">text</span> 给出了决定的理由，
而 <span class="field">author_name</span>
命名了人员，电脑或其它作出该决定的实体。
这个规范并不强制要求一个应用是否合并两个记录；一个合并操作应该由一个在寻找类似数据的记录的人类操作员或软件算法来发起。在一个 <span class="type">note</span> 记录里记下该合并会使放弃一个坏的合并决定变得可能，而在<span class="field">author_name</span> 字段记下操作人或程序的名字舍得错误合并的原因有源可寻。
</p><p>
当展示一个 <span class="type">person</span> 记录时,
应用可以在属于那个person记录的notes里面寻找所有非空<span class="field">linked_person_record_id</span>
字段， 或者一个被链接记录的合并视图。
</p><h2 id="changes">9. 相对于前一版规范的改动</h2>
<h3>9.1. 从PFIF 1.1到PFIF 1.2的改动</h3>
<p><span class="type">person</span> 记录增加了4个字段：
<span class="field">sex</span>,
<span class="field">date_of_birth</span>,
<span class="field">age</span>, 和
<span class="field">home_country</span>.
<span class="field">home_zip</span> 字段被<span class="field">home_postal_code</span>字段替换。
要将PFIF 1.1仓库升级的话，
导出原有的 <span class="field">home_zip</span> 字段值到
<span class="field">home_postal_code</span> 字段中；然后对那些<span class="field">home_state</span>指向美国或<span class="field">home_postal_code</span>包含一个美国邮编的记录，将<span class="field">home_country</span> 字段设成
<code>US</code> 。
</p><p><span class="type">note</span> 记录增加了3个字段:
<span class="field">person_record_id</span>,
<span class="field">linked_person_record_id</span>, 和
<span class="field">status</span>.
</p><p>在PFIF XML格式中，
<span class="element">note</span> 元素变成可以在 <span class="element">person</span> 元素以外存在的元素。除了<span class="field">note_record_id</span> 和必须出现在第一位的
<span class="field">person_record_id</span> 字段,
其它的子元素可以是任意顺序。
</p><p>Atom entrys和RSS items转为包含独立的，没有被<span class="element">pfif:pfif</span>元素锁包含的<span class="element">pfif:person</span> 和
<span class="element">pfif:note</span> 元素。
</p><h3>9.2. 从PFIF 1.2 到 PFIF 1.3的改动</h3>