-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathPFIF的常见问题和实现指引.html
259 lines (219 loc) · 15.4 KB
/
PFIF的常见问题和实现指引.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
<html dir="ltr"><head><link rel="stylesheet" href="http://zesty.ca/pfif/style.css" />
<title>PFIF常见问题和实现指南</title>
</head>
<body dir="ltr">
<div class="title">
<h1>PFIF常见问题和实现指南</h1>
</div>
<p>本文档英文原版由Ka-Ping Yee维护, 中文译文由利 嘉豪主要翻译和维护，特别鸣谢胡 千里。
可以通过邮箱ping<img src="http://zesty.ca/64.gif" />zesty.ca联系Ka-Ping, 通过lijiahao90 at gmail联系嘉豪。
<p>许多问题都可以通过查看<a href="http://zesty.ca/pfif/1.1">PFIF说明书</a>
和<a href="http://zesty.ca/pfif/1.1/pfif-1.1-example.xml">PFIF文档示例</a>找到答案。
<div class="toc">
<ul>
<li><a href="http://zesty.ca/pfif/faq.html#life-cycle">
</a><a href="http://zesty.ca/pfif/faq.html#life-cycle">一个PFIF记录的生命周期是什么？</a>
<li><a href="http://zesty.ca/pfif/faq.html#home-repository">
</a><a href="http://zesty.ca/pfif/faq.html#home-repository">什么是源仓库(home repository)</a>
<li><a href="http://zesty.ca/pfif/faq.html#changing-fields">
</a><a href="http://zesty.ca/pfif/faq.html#changing-fields">当一个记录被一个应用传递到另一个应用时，哪些字段发生了改变？</a>
<li><a href="http://zesty.ca/pfif/faq.html#dates">
</a><a href="http://zesty.ca/pfif/faq.html#dates"> <span class="field">entry_date</span>
</a><a href="http://zesty.ca/pfif/faq.html#dates">和<span class="field">source_date</span>有什么区别?</a>
<li><a href="http://zesty.ca/pfif/faq.html#source-fields">
</a><a href="http://zesty.ca/pfif/faq.html#source-fields">字段<span class="field">source_name</span>, <span class="field">source_date</span>, 以及<span class="field">source_url</span> 都代表了什么？</a>
<li><a href="http://zesty.ca/pfif/faq.html#output-format">
</a><a href="http://zesty.ca/pfif/faq.html#output-format">我应该生成PFIF文档，Atom feed，还是RSS feed作为输出？</a>
<li><a href="http://zesty.ca/pfif/faq.html#input-format">
</a><a href="http://zesty.ca/pfif/faq.html#input-format">我应该接受PFIF文档，Atom feed，还是RSS feed作为输入？
</a>
<li><a href="http://zesty.ca/pfif/faq.html#other-fields">
</a><a href="http://zesty.ca/pfif/faq.html#other-fields">对于其他数据库中包含的，但在PFIF格式中不存在的字段该如何处理？</a>
<li><a href="http://zesty.ca/pfif/faq.html#multiple-records">
</a><a href="http://zesty.ca/pfif/faq.html#multiple-records">我的应用程序应如何处理对于同一个人的多条记录？</a>
<li><a href="http://zesty.ca/pfif/faq.html#schema-location">
</a><a href="http://zesty.ca/pfif/faq.html#schema-location"><code>xmlns:xsi</code>
</a><a href="http://zesty.ca/pfif/faq.html#schema-location">和<code>xsi:schemaLocation</code>属性是拿来干什么的？</a>
<li><a href="http://zesty.ca/pfif/faq.html#spec-validation">
</a><a href="http://zesty.ca/pfif/faq.html#spec-validation">为什么规范文档无法通过W3C验证？</a>
</li></li></li></li></li></li></li></li></li></li></li></ul>
</div>
<h3 id="life-cycle">
一个PFIF记录的生命周期是什么？</h3>
<p>
下面的图表描述了一条PFIF记录被创建，之后传播到其他仓库（repository）中的生命周期。
<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>
<p>
一个PFIF 仓库可以包含 <em>原始记录</em>
和<em>克隆记录</em>.
原始记录是存储于其源仓库（home repository）的记录；复制记录则属于其他仓库。
<h3 id="home-repository">
什么是源仓库</h3>
<p>
每条记录都属于一个 <em>源仓库</em>,
也就是这个计算机记录初次创建时所在的仓库。（即上图中第2阶段）。
虽然记录可以被分发和复制到其他数据库，
主仓库仍然保留对该记录的权威性。
<p>
<span class="field">person_record_id</span>
和<span class="field">note_record_id</span>
以一个域名加"/"组成。
该域名标识了记录的源仓库。
<h3 id="changing-fields">
在一个记录被一个应用程序传递到另一个应用程序之时，哪些字段发生了改变？</h3>
<p> <strong>唯一</strong> 发生了改变的域
就是 <span class="field">entry_date</span> 域,
它表明了记录进入接收应用程序的时间。
<strong>任何其它字段都不变</strong>.
记录存储到一个仓库中之后，
记录中没有任何内容会发生变化，连<span class="field">entry_date</span>字段也不例外。
<p>PFIF 基于"post-only" 原则。
一条记录初次存储成PFIF格式之后，
它只是从一个地方复制到另一个地方，内容不发生改变。
<h3 id="dates">
<span class="field">entry_date</span>
和<span class="field">source_date</span>有什么区别?</h3>
<p><span class="field">source_date</span> 是记录的“真实”日期：
即原始记录创建的日期。
<p><span class="field">entry_date</span>则是
记录的该特定副本被存储的日期。
<span class="field">entry_date</span>应当由接收仓库自动填充；
任何人在都没有必要在输入数据时手动输入 <span class="field">entry_date</span>。
<p>一条记录的所有拷贝副本都有和原始记录相同的<span class="field">source_date</span>。
一条记录的所有副本很可能拥有不同的 <span class="field">entry_date</span>值。
<p>这两个字段对
<span class="type">person</span> 和 <span class="type">note</span> 记录都适用。
<p>(Katrina People Finder 项目<a href="http://www.ethanzuckerman.com/entryform.html">项目格式</a>中，标为 "Entry Date" 和"Note Entry Date"的字段，与PFIF格式中的 <span class="field">source_date</span> 字段,
而不是 <span class="field">entry_date</span> 字段对应。
用户应该从不需要输入 <span class="field">entry_date</span> 字段。)
<p><span class="field">entry_date</span>字段存在的目的是为了使递进式更新(incremental updates)变得可能
如果你想每天都镜像一个远程PFIF仓库的所有记录到自己的数据库，那么你不需要每天都请求dump整个
远程数据库。你只需要请求所有 <span class="field">entry_date</span>
大于你上一次接收的最高 <span class="field">entry_date</span> 的记录.
<p>
历史笔记：是的，这些字段的名称有点让人混淆。
如果你在好奇为什么他们会被选择作为字段的名称，这就需要回到上面图标忠从2b到3到4的流程，也就是当初Katrina People Finer项目将其注意力集中在的地方。当人们将数据从非PFIF仓库转移到PFIF仓库的过程中，这些名称就变得有意义了：<span class="field">source_date</span> 是该记录在非PFIF的源头仓库中的日期， 而<span class="field">entry_date</span> 是人们将该记录输入到PFIF仓库中的日期。我们保留了这些名字的兼容性，虽然他们在一般情况下显得不是那么有意义。你只要记住 <span class="field">source_date</span> 是一个固定的日期是 <span class="field">entry_date</span> 自动生成的到达日期。
<h3 id="source-fields">
<span class="field">source_name</span>, <span class="field">source_date</span>, 以及<span class="field">source_url</span> 字段都代表了什么？</h3>
<p>这些字段将 (PFIF 或非PFIF) 记录在其 <strong>源仓库</strong>标识出来.
<span class="field">source_name</span> 是源仓库的名字;
<span class="field">source_date</span> 是该记录在源仓库中被创建的日期;
<span class="field">source_url</span> 是链接到源仓库中该记录的URL地址。
<p>这些字段在该记录被第一次转成PFIF时被设定，而且不再改变。
<h3 id="output-format">
我应该生成PFIF文档，Atom feed，还是RSS feed作为输出？</h3>
<p>
总是优先考虑 PFIF XML 文档格式.
无论怎样你的应用都会需要支持这个格式。
如果你在写一个将PFIF XML直接格式化的程序，要记住，在字段中你需要将 "&" 替换成 "&amp;" ；将
"<" 替换成 "&lt;"。.
<p>
将PFIF嵌入到Atom feed仅当你需要跟一个Atom feed阅读器保持兼容。
或者将PFIF嵌入到RSS feed里仅当你需要跟一个RSS feed阅读器保持兼容。
Atom和RSS feed格式的规范只是为了跟其它同步软件(syndication softwares)保持兼容，以使得PFIF数据可以通过现存的同步信息渠道。(syndication channels.)
<p>
对于其它用途，保持使用PFIF XML格式。 除非你依赖于其它Atom或RSS软件来传递你的PFIF, 否则没有任何理由做多余的工作将其嵌入Atom或RSS。
<h3 id="input-format">
我应该接受PFIF文档，Atom feed，还是RSS feed作为输入？
</h3>
<p>
PFIF-aware 应用应该扫描这个文档以找到 <code class="element">pfif:person</code> 元素同时忽略其它所有元素。这对与三种格式都适用。
<p>
如果你在使用一个XML解析库，你需要向你的XML解析库请求获得所有 <code class="element">pfif:person</code> 元素。
如果你在字符串匹配时使用正则表达式，你应该搜索 <code>"<pfif:person"</code>
来找到每个<span class="element">person</span> 元素的起始位置,
然后从每个 <span class="element">person</span> 元素的起始位置开始搜索
<code>"</pfif:person"</code> 以找到该元素的结束位置。
<h3 id="other-fields">
对于其他数据库中包含的，但在PFIF格式中不存在的字段该如何处理？</h3>
<p>
如果该字段是关于失踪人员的不会发生改变的信息，那么将它放在 <span class="type">person</span> 记录的<span class="field">other</span> 字段中。
规范中（specification）提到:
<blockquote>
短字段应该跟字段名称，冒号和字段值在同一行。
长字段应该让字段名称和冒号单独一行，内容在下一行缩进。
<p>
当一个记录通过机器从其它格式被转换为PFIF时，字段 "automated-pfif-author" 应该被包含且用来命名该生成PFIF的程序。将记录从一个PFIF仓库中输出时，不添加"automated-pfif-author" 字段。
<p>
一个以自由文本形式存在的对人的描述也可以与字段名称 "description"一起被放到这里。
例如，一个从非PFIF格式挖出记录的程序可以生成一个像这样的 <span class="field">other</span> 字段：
<pre> description:
Dark hair, in her late thirties.
Also goes by the names "Kate" or "Katie".
automated-pfif-author: ScrapeMatic 0.5</pre>
从其它应用输入的数据字段名称也可以域名和"/"开头。比如，如果一个生日日期从ICRC记录输入，那么它可能看起来像这样
For example, if a birthdate is imported from an ICRC record,
it might look like this:
<pre>icrc.org/birthdate: 1976-02-26</pre>
</p></p></blockquote>
<p>
如果数据的字段随着时间改变， 将它变为一个note。 暂时我们没有任何对于note的特定格式。
用你自己判断将它格式化成文本；如果你喜欢的话， 可以使用与<span class="field">other</span> 字段相同的格式。
<h3 id="multiple-records">
我的应用程序应如何处理对于同一个人的多条记录？</h3>
<p>
哪怕当一个应用确定了多个 <span class="type">person</span> 记录指向的其实是同一个人，
它也不应该尝试去就地合并这些记录。
实际上, 它应该保留所有收到的记录，同时呈现一个他们的合并版本。保留原始记录会保持记录的可信度，使得应用可以在未来处理来自于原始来源的相同记录。
<p>
<a href="http://zesty.ca/pfif/1.1#database">这份规范的数据库模型部分</a>
提出了一种可能的方式，使得基于关系型数据库应用可以跟踪指向同一个person的多个记录。
<h3 id="schema-location">
<code>xmlns:xsi</code>
<code>xsi:schemaLocation</code> 属性是拿来干什么的?</h3>
<p>
这些属性不是PFIF规范所必需的，但是它们有助于校验工具来校验XML文档。
例如
Altova 的 <a href="http://www.altova.com/products_ide.html">XML Spy</a>,
一个XML的编辑器和校验器, 能识别这些属性，从而利用它们来参照PFIF XML模型来校验一个PFIF文档
and can use them to validate a PFIF document against the PFIF XML Schema.
<p>
这个<a href="http://zesty.ca/pfif/1.1/pfif-1.1-example.xml">PFIF文档范例</a>
展示了如何使用这些属性来告诉PFIF文档的阅读器在哪里能找文档的XML模型。
其中 <code>xmlns:xsi</code> 属性标识了一个XML模型实例的命名空间。而 <code>xsi:schemaLocation</code> 则将PFIF命名空间URI映射到ML模型文档的URL地址。
<h3 id="spec-validation">
为什么规范文档无法通过W3C验证？</h3>
<p>
在<a href="http://zesty.ca/pfif/1.1">http://zesty.ca/pfif/1.1</a>上的规范文档包括了来自于RDDL 2.0的属性(RDDL 2.0是一个被提出用来指向一个XML模型的格式）。这些属性的存在是为了使读取PFIF文档的程序可以沿着命名空间URL地址找到http://zesty.ca/pfif/1.1,
获取文档，以及在 <a href="http://zesty.ca/pfif/1.1">http://zesty.ca/pfif/1.1/pfif-1.1.xsd</a> 找到XML 模型文档的链接。如果一个XML处理器支持RDDL,
那么只需要指定命名空间，而不需要其它属性来帮助找到模型。
<p>
RDDL 属性 are properly qualified in an "rddl" namespace. <a href="http://validator.w3.org/">W3C 校验器</a> 不知道怎么样处理命名空间，但从其它方面来说，这个规范文档是一个合法的XHTML 1.0 Strict文档.
</p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></p></body></html>