IIIF 搜索 API 1.0 - 《IIIF官方文档知识库》

翻译者：Yuyan Jiang
原文链接：https://iiif.io/api/search/1.0/#property-definitions

IIIF 搜索 API 1.0
本文件的状态
此版本:1.0.0
最新稳定版本:1.0.0
编辑

目录
o 1.简介
o 1.1.用例
o 1.2.术语
o 2.概述
o 3.搜索
o 3.1.服务说明
o 3.2.请求
o 3.2.1.查询参数
o 3.2.2.示例请求
o 3.3.展示API兼容响应
o 3.3.1.简单列表
o 3.3.2.分页结果
o 3.3.3.目标资源结构

  - [3.4搜索 API特定响应](https://iiif.io/api/search/1.0/#search-api-specific-responses)

o 3.4.1.忽略的参数
o 3.4.2.搜索术语片段
o 3.4.3.搜索术语突出显示
o 3.4.4.多注释命中
o 4.自动完成
o 4.1.服务描述
o 4.2.请求
o 4.2.1.查询参数
o 4.2.2.请求示例
o 4.3.返回结果
o 5.属性定义
o 附录
o A.请求参数要求
o B.版本控制
o C.致谢
o D.更改日志

1.介绍
在IIIF(发音为“Triple-Eye-Eff”) 展示API, 内容通过注释从分布式系统中汇集在一起。这些内容可能包括通常通过图像APIIIIF服务访问的图像, 音频，视频，丰富或纯文本，或任何其他内容。在一个充满活力和动态的系统中，内容可以来自许多来源，并且是丰富、多样和丰富的。在该内容类型列表中，文本资源适合作为知识内容的转录、翻译或编辑，或者作为关于对象的评论、描述、标记或其他注释而被搜索。
该规范展示了在IIIF上下文中执行这些搜索的互操作性机制。规范的范围是在单个IIIF资源中搜索注释内容，例如清单、范围或集合。尽一切努力保持交互尽可能与现有的IIIF模式一致。搜索元数据或其他描述性属性不在此工作范围内。
为了使针对未知内容的搜索更容易, 还提供了自动完成搜索词的相关服务应用于搜索服务中，以确保检索到的术语可以简单地复制到搜索的查询中。
请将反馈发送至 iiif-discuss@googlegroups.com
1.1.用例
能够在演示应用编程接口中搜索注释的用例包括:
o 搜索光学字符识别生成的文本，以查找书籍、报纸或其他主要文本内容中的单词或短语。
o 搜索由众包或学术成果转化提供的转录内容。
o 搜索多个内容流，如翻译或编辑，而不是内容的原始转录，以跳转到对象的适当部分。
o 搜索文本部分，如定义的章节或文章。
o 搜索用户提供了关于资源的评论，作为资源或讨论的发现机制。
o 发现相似的文本部分来比较内容或对象。
可以使用搜索响应构建的用户界面包括在显示中突出显示匹配的单词，提供匹配在对象内发生的位置的热图，以及提供在对象内的点之间跳转的机制。自动完成服务帮助用户识别存在于所选范围内的术语。
1.2.术语
本文档中的关键词“必须”、“不得”、“必需”、“不得”、“应该”、“不应该”、“推荐”、“可以”和“可选”应按照中RFC 2119所述进行解释。
2.概述
IIIF 展示API 向使用人员提供了足够的信息，因此它可以以丰富和可理解的方式向用户呈现图像和其他内容。那些内容资源可以具有与之相关联的文本注释。注释也可以与展示API的结构组件相关联，例如清单本身、序列、范围和层。此外，可以通过对注释进行注释来回复以形成关于评论、转录、编辑或翻译的话题讨论。
注释通常可用于查看注释列表中的应用程序，其中列表中的所有注释都指向同一资源或其一部分。在已知的情况下，这些列表可以直接从清单文档中引用，以允许客户端简单地跟随链接来检索它们。对于固定的、精选的内容，这是发现它们的合适方法，因为注释不会频繁改变，也不会潜在地分布在多个服务器中。注释列表可以包含在图层中，以便将它们分组在一起，例如通过注释的来源，从而允许用户将该分组作为一个整体进行操作。
然而，这对于评论式的注释、众包或分布式转录、对自动光学字符识别转录的校正等不太有用，因为注释可能是不断变化的。此外，能够快速发现单个注释而无需遍历对象的所有视图对于合理的用户体验至关重要。该规范将这一功能添加到IIIF规范套件中。
除了搜索单词或短语的能力之外，用户还会发现建议他们应该搜索哪些术语是有帮助的。这种工具通常被称为自动完成或提前键入，并且在单个对象的上下文中可以提供对语言和内容的洞察。自动完成服务与搜索服务相关联，术语可以作为查询的一部分被输入到该搜索服务中。
3.搜索
搜索服务通常接受包括搜索词或URI的查询，并可以能通过其他属性进一步过滤，包括创建或上次修改注释的日期、注释的动机或创建注释的用户。
3.1.服务描述
展示API中涉及的任何资源都可能有与之关联的搜索服务。资源决定了要搜索的内容的范围。与清单相关联的服务将搜索清单下画布或其他对象上的所有注释，特定范围相关联的服务将仅搜索该范围内的画布，或者画布上的服务将仅搜索该特定画布上的注释。
服务的描述遵循规范中建立的模式链接到服务。描述块必须具有值为“http://iiif.io/api/search/1/context.json”的@context属性，值为“http://iiif.io/api/search/1/search”的profile属性，以及包含可以执行搜索的URI的@id属性。
示例服务描述块:

{
  // ... the resource that the search service is associated with ...
  "service": {
    "@context": "http://iiif.io/api/search/1/context.json",
    "@id": "http://example.org/services/identifier/search",
    "profile": "http://iiif.io/api/search/1/search"
  }
}

3.2.请求
搜索请求是向与特定展示API资源相关的服务发出的。与不同资源相关联的服务的URI必须不同，以允许客户端针对期望的搜索范围使用正确的服务。要执行搜索，客户端必须使用HTTP GET(而不是POST)方式向服务发出请求，并使用查询参数来指定搜索词。
3.2.1.查询参数
除了推荐的q之外，所有其他参数在请求中都是可选的。默认情况下，如果参数为空或未提供，则不限制与该参数搜索相匹配的注释。如果提供了值，但字段不在注释中，则搜索与该注释不匹配。例如，如果注释没有创建者，并且查询指定了用户参数，则注释与查询不匹配。
服务器应该实现q和动机参数，也可以实现其他参数。在请求中接收但未实现的参数必须被忽略，并且应该包含在响应中的层的忽略属性中，如下所示。

参数	定义
q	空间分离的搜索词列表。搜索词可能是单词（在文本机构内搜索）或URIs（用于搜索注释体资源的身份）。多个空间分离术语的语义取决于服务器实现。
motivation	动机参数的空格分隔列表。如果提供了多个动机，如果存在任何动机，注释将匹配搜索。期望值如下。
date	日期范围的空间分离列表。如果创建日期位于任何提供的日期范围内，则注释匹配。日期必须以 ISO8601 格式提供： .日期必须以 UTC 表示，并且必须以基于格式给出。YYYY-MM-DDThh:mm:ssZ/YYYY-MM-DDThh:mm:ssZZ
Use	以空格分隔的URI用户身份列表。如果提供了多个用户，如果有任何用户创建了注释，则注释与搜索匹配。

动机参数的常见值有:

动机	定义
painting	只有带有动机的注释sc:painting
non-painting	除此之外，没有任何动机的注释sc:painting
commenting	带有动机的注释oa:commenting
describing	带有动机的注释oa:describing
tagging	带有动机的注释oa:tagging
linking	带有动机的注释oa:linking

其他动机也是可能的，开放注释规范的完整列表应通过删除”oa：”前缀来获得。其他社区特定动机应包括前缀或使用其全部 URI。
3.2.2.请求示例
该示例请求:

http://example.org/services/manifest/search?q=bird&motivation=painting

会在文字内容中搜索带有“bird”字的注释，有绘画的动机。它将在与服务相关联的资源中搜索注释。
3.3.展示API兼容响应
服务器的响应是一个注释列表，遵循演示API的格式，并具有一些其他功能。这允许已经实施注释列表格式的客户避免进一步实施工作以支持搜索结果。搜索结果以常规IIIF语法的注释形式返回。请注意，注释可以来自多个画布，而不是演示应用编程接口的默认情况，在演示应用编程接口中，所有注释都以单个画布为目标。
3.3.1.简单列表
最简单的响应看起来完全像一个常规注释列表，其中所有匹配的注释都在一个响应中返回。@id的值将与查询中使用的URI相同，但是服务器可能会删除被忽略的查询参数，只要它们在忽略属性中报告。
希望知道匹配注释总数的客户端可以计算resources属性中的注释数量，因为所有匹配都已返回。完整的注释描述必须包含在响应中，即使注释可以通过它们的URIs单独取消引用。

{
  "@context":"http://iiif.io/api/presentation/3/context.json",
  "@id":"http://example.org/service/manifest/search?q=bird&motivation=painting",
  "@type":"sc:AnnotationList",
  "resources": [
    {
      "@id": "http://example.org/identifier/annotation/anno-line",
      "@type": "oa:Annotation",
      "motivation": "sc:painting",
      "resource": {
        "@type": "cnt:ContentAsText",
        "chars": "A bird in the hand is worth two in the bush"
      },
      "on": "http://example.org/identifier/canvas1#xywh=100,100,250,20"
    }
    // Further matching annotations here ...
  ]
}

3.3.2.分页结果
对于长的注释列表，服务器可以选择将响应分成多个部分，通常称为页面。每个页面都是一个注释列表，并且可以引用其他页面，以允许客户端遍历整个集合。这使用了展示API2.1版本中引入的分页功能，但与2.0版本向后兼容。当前响应之后的下一页结果必须在注释列表的下一个属性中引用，上一页应当应该在prev属性中引用。
@id属性中报告的第一个注释列表的URI可能与客户端请求搜索时使用的不同。每页还应该有一个带有整数值的startIndex属性，该属性报告第一个结果在整个结果集中的位置，其中第一个注释的索引为0。例如，如果客户端请求的第一页有10次点击，那么开始索引将为0，第二页的开始索引将为10，这是第11次点击。
所有的页面都在一个层中，它表示匹配注释的整个结果集。图层是每个页面批注列表中的layer属性的值，并记录为具有属性的对象。
图层必须具有@type属性，其值为“sc:Layer”。它应当分别引用具有第一个和最后一个属性的第一个和最后一个注释列表页面的URIs。该层应当有一个total属性，它是查询生成的命中总数，它可能有一个URI作为@id属性的值。
请求示例:

http://example.org/service/manifest/search?q=bird

对第一页注释的响应总共有125个匹配项:

{
  "@context":"http://iiif.io/api/presentation/3/context.json",
  "@id":"http://example.org/service/manifest/search?q=bird&page=1",
  "@type":"sc:AnnotationList",
  "within": {
    "@type": "sc:Layer",
    "total": 125,
    "first": "http://example.org/service/manifest/search?q=bird&page=1",
    "last": "http://example.org/service/identifier/search?q=bird&page=13"
  },
  "next": "http://example.org/service/identifier/search?q=bird&page=2",
  "startIndex": 0,
  "resources": [
    {
      "@id": "http://example.org/identifier/annotation/anno-line",
      "@type": "oa:Annotation",
      "motivation": "sc:painting",
      "resource": {
        "@type": "cnt:ContentAsText",
        "chars": "A bird in the hand is worth two in the bush"
      },
      "on": "http://example.org/identifier/canvas1#xywh=100,100,250,20"
    }
    // Further annotations from the first page here ...
  ]
}

3.3.3.目标资源结构
注释还可以包括对目标(属性中的资源)所在的一个或多个结构的引用。必须给出包含资源的URI和资源类型，并应当包含标签。
这种结构是显式调用的，因为虽然它只使用演示展示API的属性，但它不是一种常见的模式，因此客户端可能并不期望这样。

{
  "@context":"http://iiif.io/api/search/1/context.json",
  "@id":"http://example.org/service/manifest/search?q=bird&motivation=painting",
  "@type":"sc:AnnotationList",
  "resources": [
    {
      "@id": "http://example.org/identifier/annotation/anno-line",
      "@type": "oa:Annotation",
      "motivation": "sc:painting",
      "resource": {
        "@type": "cnt:ContentAsText",
        "chars": "A bird in the hand is worth two in the bush"
      },
      "on": {
        "@id": "http://example.org/identifier/canvas1#xywh=100,100,250,20",
        "within": {
          "@id": "http://example.org/identifier/manifest",
          "type": "sc:Manifest",
          "label": "Example Manifest"
        }
      }
    }
    // Further annotations here ...
  ]
}

3.4搜索API特定响应
可能有一些属性是特定于搜索结果的，而不是一般注释的功能，这些属性对于返回客户端具有价值。此类属性的示例包括匹配内容之前和之后的文本（允许显示结果片段）、匹配文本本身（当应用了案例规范化、阻止或通配符时），以及一组一起完成搜索查询的注释（当短语跨越多个注释时）。
由于这些响应包括特定于搜索的信息，因此@context的值必须是一个数组，其中按顺序包括演示API和搜索API上下文的URI。这允许两个API分别开发，但尽可能保持同步。
为了逐步建立现有解决方案，并为不支持这些功能并保留与演示API兼容性的客户提供优美的退化，搜索API特定信息包含在称为注释列表中的第二个列表中，而不是该层上的属性。注释列表可能具有此属性，服务器可能支持这些功能。
如果支持，命中列表中的每个条目都是一个搜索:命中对象。此类型必须作为@type属性的值包含在内。命中对象引用一个或多个注释，这些注释在列表中作为命中的注释属性值提供附加信息。引用了注释的@id属性的值，因此注释必须有一个URI来支持这个进一步的信息。
基本结构是:

{
  "@context":[
      "http://iiif.io/api/presentation/3/context.json",
      "http://iiif.io/api/search/1/context.json"
  ],
  "@id":"http://example.org/service/manifest/search?q=bird&page=1",
  "@type":"sc:AnnotationList",
  "within": {
    "@type": "sc:Layer"
    // Result set information here ...
  },
  "resources": [
    {
      "@id": "http://example.org/identifier/annotation/anno1",
      "@type": "oa:Annotation"
      // More regular annotation information here ...
    }
    // Further annotations from the first page here ...
  ],
  "hits": [
    {
      "@type": "search:Hit",
      "annotations": [
        "http://example.org/identifier/annotation/anno1"
      ]
      // More search specific information for anno1 here ...
    }
    // Further hits for the first page here ...
  ]
}

3.4.1.忽略的参数
如果服务器忽略了请求中的任何参数，则该层必须存在，并且必须具有忽略的属性，其中该值是被忽略参数的列表。
如果前面例子中的请求是:

http://example.org/service/manifest/search?q=bird&user=http%3A%2F%2Fexample.com%2Fusers%2Fazaroth42

并且在处理请求时忽略了用户参数，那么响应将是:

{
  "@context":[
      "http://iiif.io/api/presentation/3/context.json",
      "http://iiif.io/api/search/1/context.json"
  ],http://example.org/service/manifest/search?q=bird
  "@id":"http://example.org/service/manifest/search?q=bird&page=1",
  "@type":"sc:AnnotationList",
  "within": {
    "@type": "sc:Layer",
    "total": 125,
    "ignored": ["user"]
  },
  "next": "http://example.org/service/identifier/search?q=bird&page=2",
  "startIndex": 0,
  "resources": [
    // Annotations ...
  ]
}

3.4.2.搜索术语片段
命中对象的最简单添加是添加注释中匹配文本之前和之后出现的文本。这允许客户端构建一个片段，其中匹配文本是在周围内容的上下文中提供的，而不是简单地以自身为背景提供的。当服务在画布上具有文本的字级边界时，例如在使用光学字符识别（OCR）生成文本位置时可用时，这是最有用的。
该服务可能会在注释内容（给出）之前添加一定数量的文本，也可以添加在注释内容后出现的具有一定数量文本的属性。例如，在我们的示例句子中搜索查询词“bird”时，当服务器具有完整的单词级坐标时:

http://example.org/service/manifest/search?q=bird

服务器匹配多个“bird”:

{
  "@context":[
      "http://iiif.io/api/presentation/3/context.json",
      "http://iiif.io/api/search/1/context.json"
  ],
  "@id":"http://example.org/service/manifest/search?q=bird",
  "@type":"sc:AnnotationList",
  "resources": [
    {
      "@id": "http://example.org/identifier/annotation/anno-bird",
      "@type": "oa:Annotation",
      "motivation": "sc:painting",
      "resource": {
        "@type": "cnt:ContentAsText",
        "chars": "birds"
      },
      "on": "http://example.org/identifier/canvas1#xywh=200,100,40,20"
    }
    // Further annotations here ...
  ],
  "hits": [
    {
      "@type": "search:Hit",
      "annotations": [
        "http://example.org/identifier/annotation/anno-bird"
      ],
      "before": "There are two ",
      "after": " in the bush"
    }
    // Further hits for the first page here ...
  ]
}

3.4.3.搜索词高亮显示
许多系统没有完整的字级坐标信息，并且仅限于行或段落级别的边界。在这种情况下，客户端能做的最有用的事情是显示整个注释并突出显示其中的点击率。这与以前的使用案例相似，但不同。此处，该词将出现在注释属性的某处，客户端需要使其更加突出。在以前的情况下，该词是注释的全部内容，信息便于在列表中呈现。chars
在这种情况下，客户端需要了解导致服务创建热门的文本，以及有关其在内容中发生位置的足够信息，以便可靠地突出显示它，而不是突出显示非匹配。为此，服务可以通过开放注释对象在注释内容内的匹配术语前后提供文本。TextQuoteSelectors 具有三个属性：记录要查找的确切文本、匹配前的一些文本以及匹配后的一些文本。
这看起来像:

{
  "@type": "oa:TextQuoteSelector",
  "exact": "birds",
  "prefix": "There are two ",
  "suffix": " in the bush"
}

由于多个单词可能与同一个注释中的查询匹配，因此在命中时，多个选择器可能作为选择器属性中的对象给出。例如，如果搜索使用通配符来搜索以“b”开头的所有单词，它将匹配同一个注释两次:

http://example.org/service/manifest/search?q=b*

结果可能是:

{
  "@context":[
      "http://iiif.io/api/presentation/3/context.json",
      "http://iiif.io/api/search/1/context.json"
  ],
  "@id":"http://example.org/service/manifest/search?q=b*&page=1",
  "@type":"sc:AnnotationList",
  "resources": [
    {
      "@id": "http://example.org/identifier/annotation/anno-line",
      "@type": "oa:Annotation",
      "motivation": "sc:painting",
      "resource": {
        "@type": "cnt:ContentAsText",
        "chars": "There are two birds in the bush."
      },
      "on": "http://example.org/identifier/canvas1#xywh=200,100,40,20"
    }
    // Further annotations here ...
  ],
  "hits": [
    {
      "@type": "search:Hit",
      "annotations": [
        "http://example.org/identifier/annotation/anno-line"
      ],
      "selectors": [
        {
          "@type": "oa:TextQuoteSelector",
          "exact": "birds",
          "prefix": "There are two ",
          "suffix": " in the bush"
        },
        {
          "@type": "oa:TextQuoteSelector",
          "exact": "bush",
          "prefix": "two birds in the ",
          "suffix": "."
        }        
      ]
    }
    // Further hits for the first page here ...
  ]
}

3.4.4.多注释命中
鉴于文本部分（如单词、行、段落、页面或任意部分）与向客户端显示该文本的注释之间的对齐灵活性，可能会有多个注释与单个多期限搜索相匹配。这些差异将主要取决于文本和注释的生成方法，对于由 OCR 生成的手动转录文本和文本来说，可能会大不相同。
例如，想象一下，注释是逐行划分的，因为它们是手动转录的方式，并且有两行文本。在这个例子中，第一行是”手里的一只鸟”，第二行是”在灌木丛中有两只鸟”，而搜索的是”手里有”这句话。因此，匹配跨越两个基于行的注释。如果注释处于字级，则所有短语搜索都需要多个注释。
在这种情况下，注释比命中多，因为需要两个或更多的注释来组成一个命中。命中的匹配属性捕获注释中的文本。

{
  "@context":[
      "http://iiif.io/api/presentation/3/context.json",
      "http://iiif.io/api/search/1/context.json"
  ],
  "@id":"http://example.org/service/manifest/search?q=hand+is",
  "@type":"sc:AnnotationList",
  "resources": [
    {
      "@id": "http://example.org/identifier/annotation/anno-bird",
      "@type": "oa:Annotation",
      "motivation": "sc:painting",
      "resource": {
        "@type": "cnt:ContentAsText",
        "chars": "A bird in the hand"
      },
      "on": "http://example.org/identifier/canvas1#xywh=200,100,150,30"
    },
    {
      "@id": "http://example.org/identifier/annotation/anno-are",
      "@type": "oa:Annotation",
      "motivation": "sc:painting",
      "resource": {
        "@type": "cnt:ContentAsText",
        "chars": "is worth two in the bush"
      },
      "on": "http://example.org/identifier/canvas1#xywh=200,140,170,30"
    }
    // Further annotations here ...
  ],
  "hits": [
    {
      "@type": "search:Hit",
      "annotations": [
        "http://example.org/identifier/annotation/anno-bush",
        "http://example.org/identifier/annotation/anno-are"
      ],
      "match": "hand is",
      "before": "A bird in the ",
      "after": " worth two in the bush"
    }
    // Further hits for the first page here ...
  ]
}

4.自动完成
自动完成服务返回可以添加到相关搜索服务的q参数中的术语，给定术语的首个字符。
4.1.服务描述
自动完成服务嵌套在搜索服务中，它为搜索服务提供术语完成。这是为了允许多个搜索服务，每个服务都有自己的自动完成服务。
自动完成服务必须有一个@id属性，其值为服务可以交互的URI，并且必须有一个配置文件属性，其值为”http://iiif.io/api/search/1/autocomplete"，以将其与其他类型的服务区分开来。

{
  // Resource that the services are associated with ...
  "service": {
    "@context": "http://iiif.io/api/search/1/context.json",
    "@id": "http://example.org/services/identifier/search",
    "profile": "http://iiif.io/api/search/1/search",
    "service": {
      "@id": "http://example.org/services/identifier/autocomplete",
      "profile": "http://iiif.io/api/search/1/autocomplete"
    }
  }
}

4.2.请求
该请求与搜索请求非常相似，另外还有一个参数，允许限制对象内的术语发生次数。参数的价值是自动完成服务必须的值，是服务完成的术语的开头字符。例如,“bir”的查询项可能会完成为“bird”、“biro”、“born”和“birth”。
该术语必须被解析为一个完整的字符串，不管其中是否包含空白。例如，“green bir”的查询术语不应该在匹配“green bir”的字段上自动完成，也不应该包含以“bir”开头的内容，而是应该寻找以字符串“green bir”开头的术语。
如果支持的话，其他参数(动机、日期和用户)将响应中的术语集细化为仅来自匹配这些过滤器的注释的术语集。例如，如果给定的动机是“painting”，那么只有来自绘画转录的文本将有助于响应中的术语列表。
4.2.1.查询参数

参数	定义
Min	索引中某个术语出现的最小次数，以便它出现在响应中；如果不存在，默认值为1。对该参数的支持是可选的。

4.2.2.请求示例
请求示例

http://example.org/service/identifier/autocomplete?q=bir&motivation=painting&user=http%3A%2F%2Fexample.com%2Fusers%2Fazaroth42

4.3.反应
响应是一个简单对象的列表(“搜索:术语列表”)，其中包括术语、该术语的搜索链接以及该搜索的匹配数量。列表中提供的术语数量由服务器决定。
服务未处理的参数必须在主“术语列表”对象的忽略属性中返回。该值必须是字符串数组。
术语列表中的对象都是@ type“search:Term”，这可以是显式包含的，但不是必需的。术语对象有许多可能的属性:
o 匹配项作为match属性的值给出，并且必须存在。
o 要执行的搜索的链接是url属性值，并且必须存在。
o 术语的匹配数是count属性的整数值，应该存在。
o 要显示的标签而不是匹配项可以作为label属性值给出，并且可能存在。为了国际化，可能会给出多个标签。
术语应按照字母顺序升序排列，但也允许其他顺序，例如按术语计数降序排列最常见的匹配项。
上面的示例请求可能会生成以下响应:

{
  "@context": "http://iiif.io/api/search/1/context.json",
  "@id": "http://example.org/service/identifier/autocomplete?q=bir&motivation=painting",
  "@type": "search:TermList",
  "ignored": ["user"],
  "terms": [
    {
      "match": "bird",
      "url": "http://example.org/service/identifier/search?motivation=painting&q=bird",
      "count": 15
    },
    {
      "match": "biro",
      "url": "http://example.org/service/identifier/search?motivation=painting&q=biro",
      "count": 3
    },
    {
      "match": "birth",
      "url": "http://example.org/service/identifier/search?motivation=painting&q=birth",
      "count": 9
    },
    {
      "match": "birthday",
      "url": "http://example.org/service/identifier/search?motivation=painting&q=birthday",
      "count": 21
    }
  ]
}

也可以将显示给用户的一个或多个标签与URIs或其他可通过q参数搜索的数据相关联，而不是使用匹配的精确字符串。如果已经发生词干或其他术语规范化，这也是有用的，以便显示原始术语而不是处理过的术语。

{
  "@context": "http://iiif.io/api/search/1/context.json",
  "@id": "http://example.org/service/identifier/autocomplete?q=http%3A%2F%2Fsemtag.example.org%2Ftag%2Fb&motivation=tagging",
  "ignored": ["user"],
  "terms": [
    {
      "match": "http://semtag.example.org/tag/bird",
      "url": "http://example.org/service/identifier/autocomplete?motivation=tagging&q=http%3A%2F%2Fsemtag.example.org%2Ftag%2Fbird",
      "count": 15,
      "label": "bird"
    },
    {
      "match": "http://semtag.example.org/tag/biro",
      "url": "http://example.org/service/identifier/autocomplete?motivation=tagging&q=http%3A%2F%2Fsemtag.example.org%2Ftag%2Fbiro",
      "count": 3,
      "label": "biro"
    }
  ]
}

5.属性定义
after在触发搜索以匹配特定注释的文本之后出现的文本段。该值必须是单个字符串。
n 命中可能具有后属性。
before在触发搜索以匹配特定注释的文本之前出现的文本段。该值必须是单个字符串。
n 命中可能具有之前的属性。
count术语出现的次数。该值必须是正整数。
n 术语应该具有计数属性。
ignored服务器接收到但在处理查询时没有考虑的一组参数。该值必须是字符串数组。
n 术语列表或图层可能具有被忽略的属性，如果服务器忽略了任何查询参数，则必须具有该属性。
match触发搜索以匹配特定注释的文本。该值必须是单个字符串。
n 命中可能具有匹配属性。
n 术语必须具有匹配属性。
附录
A.请求参数要求

参数	请求中需要	搜索中需要	自动完成中需要
q	推荐	推荐	命令的
motivation	自选	推荐	自选
date	自选	自选	自选
uri	自选	自选	自选
min	自选	n/a	自选

B.版本控制
此规范遵循语义版本。有关如何实现的详细信息，请参阅API版本控制说明。
C.承认
这份文件的制作得到了安德鲁·梅隆基金会的慷慨资助。
非常感谢IIIF成员的持续参与、创新想法和反馈。
D.更改日志

日期	描述
2016-05-12	1.0版(失落的夏天)
2015-07-20	版本0.9(旅行生活)