Open Archives Initiative
首先要区分的是两个简称，OAIS 和OAI的区别。
OAIS(Open Archival Information System的简称)
OAIS据Peter Hirtle（D-Lib Magazine的副主编）说应该是指由the Consultative Committee for Space Data Systems研究的关于Open Archival Information System的一个ISO参考模型的草案。这个参考模型已经引起了数字图书馆员和档案馆员的极大兴趣。
根据这个草案标准：
一个OAI系统是一个包括人员组织，系统，存档数据的整体，它的责任是保存信息并且为指定的团体提供服务。这个参考模型提供了一个框架给日益增加的对存档概念的理解，给长期的数字信息的保存和访问，以及对描述、比较体系和对目前存在和将来会产生的存档文件的操作。
OAI（Open Archives Initiative）
OAI指的是Open Archives Initiative ，它的目标是，发展和促进在互操作能力方面的系列标准，以方便内容数据的高效分发。OAI的起因是为了加强以学术交流为目的的对电子印刷文档的访问，以及要保证科学数据在将来也可以访问的需求。因为OAI的出现，我们访问使用学术信息的方式将有一个根本性的改变。
“archive”在电子印刷的团体里与“a repository of scholarly papers”同义，继续沿用这个词反映了OAI的起源。
从目前来看，上述的两个简称虽然形似，但其实是两个东西，非常容易混淆。当然让某一个改名可能不太现实，也许一个OAI系统遵循OAIS的参考模型，承诺提供长期，可靠，一致的服务才是对学术团体的真正有利的事情，也是最好的解决方案。
本文中要介绍的主要是The Open Archives Initiative Protocol for Metadata Harvesting
Open Archives Initiative由the Digital Library Federation，和the Coalition for Networked Information提供支持，此外对于Open Archives Initiatives protocols的研究工作还得到了National Science Foundation Grant No. IIS-9817416 和 Defense Advanced Projects Agency Grant No. N66001-98-1-8908 的资助。
首先要说明是OAI的几个概念以及其间的关系：
archive：repositories of scholarly paper 的同义词。
data providers：维护一些repositories（仓储？），并且支持OAI协议来揭示其仓储的内容
service provider：向data providers发出OAI protocol requests并且利用得到的元数据构建具有附加值的服务。
 |
OAI协议的技术体系中，指定了DC作为data providers方必须支持提供的元数据格式。同时支持对多种元数据格式的查询，通过用元数据前缀来说明。
OAI记录有三个部分：
Header
Uniqueindentifer 唯一标识符
Datestamp 仓储中某一个条目的创建、删除或最后修改时间。
Metadata 元数据，规定都必须支持DC，是否支持其他元数据格式由仓储自行决定，可以通过metadata prefix 进行标识。
About 可选部分，内容一般是关于元数据部分的数据，例如使用权限等，这部分的结构协议中不做规定。
OAI协议的请求使用HTTP中的GET或POST方法。请求传递至少一个的参数，形式如：key=vlaue，多个参数时使用‘&’隔开。每个OAI请求都必须包括一个名字为verb=‘OAI方法名’的参数。
GET方法传送的请求用？连接在URL的后面，例如：
http://an.oa.org/OAI-script?
verb=GetRecord&identifier=oai:arXiv:hep-th/9901001&metadataPrefix=oai_dc
这是一个未经过编码的请求，表示使用的OAI方法是GetRecord，要请求得到identifier是oai:arXiv:hep-th/9901001的记录，记录的元数据格式是oai_dc （遵循OAI定义的SCHEMA的DUBLIN CORE）。
POST传送请求时，OAI请求串放在HTTP POST 的body部分，例如：
POST http://an.oa.org/OAI-script HTTP/1.0
Content-Length: 78
Content-Type: application/x-www-form-urlencoded //指定必须使用
verb=GetRecord&identifier=oai%3AarXiv%3Ahep-th%2F9901001&metadataPrefix=oai_dc
这是经过了编码的请求。
对OAI请求的响应也使用HTTP的响应格式，加上适当的头部。每一个OAI请求的响应的content-type都是text/xml，使用UTF-8编码。
所有响应的XML数据都具有如下标记：
1）XML版本声明，编码声明，例如：<?xml version="1.0" encoding="UTF-8" ?>
2）根元素是与要响应的OAI请求中的方法同名，根元素有三个属性，xmlns、xmlns:xsi、xsi:schemaLocation，分别指定了根元素的名字空间、对XML Schema的声明、指定要使用的XML Schema 文件的URL。
3）对于所有的响应，根元素的第一个子元素是responseDate，（格式规范的仓储本地时间），说明了响应发送的时间。
4）对于所有的响应，根元素的第二个子元素是requestURL，内容是请求中的已经编码过的URL（URL中的‘&’要替代成‘&’，以便符合XML的语法规范）
状态码：
OAI协议使用HTTP的状态码来指示请求是否成功，以及错误原因。例如，一个成功的OAI请求，用200，而发生错误的请求则用HTTP 中相应的4**。但是，400对OAI 具有特殊的含义，返回400代表请求的语法错，例如：非法的参数或方法。仓储应该使用HTTP Reason-Phrase提供关于错误的信息，这样对于读者也是很有益处的。
OAI 仓储也会可能支持其他HTTP 状态码，例如用于分流负载的状态码，
302 ：允许仓储临时重定向一个OAI请求到其他仓储，临时仓储的URI在响应中给出。
503 ：不能提供服务，指示一个时间段，在此之后才可以重试。在此其间发来的请求不予响应。
日期和时间
OAI请求：在ListRecords 和 ListIdentifiers 请求中，可选参数from和until类型和记录头中的datestamps一样，使用ISO8601的“完整日期”格式，YYYY-MM-DD
OAI响应：每个响应中都有的responseDate元素，必须是仓储本地的日期加上时间，格式是ISO8601中规定的“完整日期加小时，分，秒”， YYYY-MM-DDThh:mm:ssTZD。例如， 1957-03-20T20:30:00+00:00 （UTC 8:30 PM on March 20th 1957）。
元数据前缀和元数据Schema
在向仓储发送请求时，使用元数据前缀来标识每一种元数据格式，元数据前缀的命名由无空格的字母数字或下划线组成。元数据schema 是一个XML schema文件，可以用来对记录中的元数据的合法性进行检测。
ListMetadataFormats请求可以列出一个仓储支持的所有元数据格式。对ListMetadataFormats请求的响应中包括每种格式的元数据前缀和元数据schema的URL。而这种XML namespace 的 URI是可选部分。
在ListRecords和GetRecord请求中，元数据前缀也可以作为参数，指定返回记录中包含元数据的格式。返回记录中的元数据遵循XML namespace 的规范，因此元数据部分必须包含一个属性‘xmlns’，取值是这种元数据格式的namespace的URL 。
对ListMetadataFormats请求的返回结果中包括了元数据schema的URL 到元数据前缀的对应。
为了保证互操作性，OAI协议要求所有的仓储都支持（不使用限定词），因此协议保留了元数据前缀‘oai_dc’，DC元数据格式的schema在http://www.openarchives.org/OAI/dc.xsd。（见附录7）
流控制
一些OAI请求的返回结果是列表，这样就可能很大，需要分割成一系列的协议请求和响应。分割要遵守以下规则：
当需要分割结果列表时，返回的是一个不完整的列表和一个resumptionToken。请求方为了得到完整的列表，需要继续发送一个或多个带有resumptionToken的请求，这样从这系列的响应就得到一个完整的列表。
细节如下：
1）对于resumptionToken的已经 定义的用途如下：
客户端从仓储接收到含有resumptionToken的响应时，客户端复制这个resumptionToken作为后续的请求的一部分。其他的对resumptionToken的使用都是非法的，仓储将回答一个400错误。
2）在不完整的列表中的任意一个条目都是完整的，例如记录都是完整记录。仅仅是不完整的记录列表。
3）resumptionToken的格式在OAI协议中未做定义。and should be considered opaque by the client.
4）协议不定义不完整的语义，因此，客户端不能假设不完整列表中的条目有什么选择标准，例如是按照时间顺序排列的。
5）某个单独的resumptionToken的生存期在协议中没有规定。可以理解仓储需要根据实际环境来决定一个resumptionToken是否有效，例如对超时的控制等情况。在这种情况下，对请求的响应是状态码400，客户端需要重新初始化请求并且将先前的不完全结果列表丢弃。因为resumptionToken的格式是不透明的，客户端也无法确定它的有效期。
6）在将一个resumptionToken包含在后续的请求中时，客户端需要对它中间含有的特殊字符编码。
在ListRecords响应中对resumptionToken的使用有：
1）ListRecords的响应由一个记录列表组成，如果响应中有resumptionToken，这个记录列表就是不完整的。
2）如果返回的结果列表是不完整的，客户端就应将resumptionToken作为后续的ListRecords请求中的唯一参数。对这个后续请求的响应是这个不完整结果列表的继续部分。客户端可以合并前后的结果集。
3）对后续的请求，响应中也可能包含一个resumptionToken，客户端就要继续将这个resumptionToken放在ListRecords请求中继续发出去，知道返回的结果中不再含有resumptionToken为止，就接收到了所有的结果。
使用流控制结合503状态（延后访问），使得仓储可以调整它提供元数据检索服务的策略。实现OAI协议的团体有可能需要更强大的工具来做服务控制，就不在协议的范围之内了。
请求与响应
每个请求的文档都是按照下列格式：
1）每个小节的标题就是必备的verb参数。
2）简要用法总结。
3）请求中其他的参数，共有三种类型：必备的、可选的、独占的（除了VERB参数，如果有这个参数，就一定是唯一的参数）。
4）响应的格式定义是一个XML schema
5）请求的例外条件，状态码在OAI协议的环境中具有特殊意义，