怎样解引标识了现实世界对象或抽象概念的URI

1 解引后得到的是什么?

前文所述,“对这些URI进行解引的时候,可以得到的是被另一个URI所标识的对于该现实世界对象或抽象概念的网络文档。”

因为直接解引标识现实世界对象的URI也是不可行的。

使用不同的URI来标识现实世界对象和描述这些对象的网络文档,使得在网络上对这个现实世界对象和描述这个对象的网络文档的声明可以被分别创建,两者之间的区分是至关重要的。

2 HTTP的内容协商机制

内容协商的基本理念是:

  1. HTTP客户端每一次发送请求时,在其HTTP头信息(header)中表明客户端所倾向的文档类型(HTML或RDF)。
  2. 服务器能够检查这些头信息并且选择一个合适的响应:
    a.如果头信息表明客户端倾向于HTML,那么服务器响应为发送一个HTML文档。
    b.如果客户端倾向于RDF,那么服务器将发送给客户端一个RDF文档。

3 303 URI和hash URI两种不同的实现策略

 

3.1 303 URI

303 URI的策略简括如下:

当客户端对一个标识了现实世界对象的303 URI发出解引请求时,服务器发送给客户端一个“303 see other”HTTP响应代码,并且提供一个描述了这个现实世界对象的网络文档的URI。这也叫做303重定(303 redirect)向。客户端解引服务器提供的这个新URI,获取一个描述了这个现实世界对象的网络文档。

具体来说,包含四个步骤:

  1. 客户端对于一个标识了现实世界对象或抽象概念的URI执行一个HTTP GET请求。如果客户端是一个关联数据应用并且倾向于一个资源的RDF/XML表达,它将在发送HTTP GET请求时一并发送一个“Accept:application/rdf+xml”头信息;客户端是HTML浏览器时,则会发送一个“Accept:text/html”头信息。
  2. 服务器使用HTTP"303 see other"响应代码响应客户端,并且发送给客户端一个采用HTTP GET请求中客户端所倾向的格式描述了这个现实世界对象或抽象概念的网络文档的URI。
  3. 然后客户端开始对这个服务器返回的新URI执行一个新HTTP GET请求。
  4. 服务器发送给客户端一个“200 ok”HTTP响应代码,并发送给客户端这个网络文档。

303 URI示例:

3.2 hash URI

URI可以包含一个特殊的片段(fragment),这个部分用一个hash符号#(片段标识符)从URI的基部中分隔出来,这是hash URI策略的重要基础。

当客户端请求检索一个hash URI时,HTTP协议要求一个片段(fragment)能够在向服务器请求URI之前就从服务器上剥离出来。

具体来说,

  1. 客户端将URI中的片段标识符连同用其所分隔出来的片段一起去掉,然后对这个去掉了特殊片段的URI发起HTTP GET请求,并发送一个客户端倾向的文档类型的头信息。
  2. 服务器发送给客户端一个符合要求的描述文档,并且这个文档中包含了对hash URI所标识了的现实世界对象的描述信息。

hash URI示例如下:

3.3 两种策略的缺点

对于303 URI策略的普遍批评是,它需要两次HTTP请求才能检索到对于现实世界对象的一个描述。

一个包含了hash的URI不能被直接的检索,因此不一定标识了一个网络文档,这使得这样的URI能够被用来标识现实世界对象和抽象概念,而不造成任何模棱两可。

3.4 两种策略的不同用途

在非常大的数据集中,通常采用303 URI来标识资源。如DBpedia

在较小的RDF词汇中,通常采用hash URI来标识术语。

参考文献:

Leo Sauermann and Richard Cyganiak. Cool uris for the semantic web - w3c interest group note. http://www.w3.org/TR/cooluris/, 2008.

Leave a Reply

Your email address will not be published. Required fields are marked *