Cool URIs for the Semantic Web学习笔记
【Cool URIs for the Semantic Web】
Technical Report: http://www.w3.org/TR/2008/NOTE-cooluris-20080331/
要解决什么问题？
在语义网中表示RDF数据也是使用URI表示的，怎样和表示HTML数据的URI进行区分？比如一个单独的RDF/XML文档和一个HTML文档。这篇技术报告就是为了解决这个问题。
解决方案：303 URI和hash URI，它们各有优缺点，具体采用哪个要视情况而定。
通过使用RDFa等技术可以将元标记嵌入到HTML、微格式（microformats）和其它支持GRDDL机制的文档中。这样，可以通过解析返回的HTML文档得到RDF数据。
Hash URIs – 针对非文档资源，这些URI包含一个片段，即使用一个hash符号#分开URI的特殊部分。
e.g. http://www.example.com/about#exampleinc
Example Inc., the company
http://www.example.com/about#bob
Bob, the person
http://www.example.com/about#alice
Alice, the person
http://www.example.com/about
RDF document describing Example Inc., Bob, and Alice
在上例中，这个URI可以提供一个包含所述资源描述的RDF文档，通过这个原始的hash URI可以识别出这些资源。下图展示了不进行内容判断的hash URI方案:
或者，使用内容判断将这个URI重定向到一个HTML文档或RDF表示。到底返回什么，取决于客户端的偏好和服务器设置。Content-Location头应该指明这个hash URI到底指向HTML文档的一部分还是RDF文档的一部分。下图展示了进行了内容判断的hash URI方案:
使用303 URI指向一个通用的文档
303是一个重定向状态码，服务器能给出表示所请求的资源的文档位置。
e.g. http://www.example.com/id/exampleinc
Example Inc., the company
http://www.example.com/id/bob
Bob, the person
http://www.example.com/id/alice
Alice, the person
服务器需要配置成：对上面这些URI请求，返回303状态码和包含了描述所请求资源的文档的URI的Location HTTP头。比如，将http://www.example.com/id/alice重定向到http://www.example.com/doc/alice。
之后，进行内容判断，再由服务器决定返回HTML格式还是RDF格式的文档。当RDF和HTML以不同的形式表示相同内容时，就应该使用这一步。
优点：客户端可以对这个一般的文档添加书签或做更深入的工作。用户若有一个支持RDF的客户端，可以对文档添加书签，然后使用Email把它发给其它用户或设备，而这些用户或设备通过解析它进而得到HTML或RDF形式的内容。
使用303 URI指向不同文档
当RDF和HTML描述的资源区别很大的时候，上面提到的（使用303 URI指向一个通用的文档）就不适合了，它们不是相同文档的两个版本，而是完全不同的两个文档。下图显示了不同文档的303 URI方案的重定向：
每个RDF文档都会包含使用原始URI描述相关资源的语句。
在303和Hash之间进行选择
Hash的优点：reducing the number of necessary HTTP round-trips, which in turn reduces access latency. A family of URIs can share the same non-hash part. The descriptions of http://www.example.com/about#exampleinc, http://www.example.com/about#alice, and http://www.example.com/about#bob are retrieved with a single request to http://www.example.com/about.
Hash的缺点：A client interested only in #product123 will inadvertently load the data for all other resources as well, because they are in the same file. 303 URIs, on the other hand, are very flexible because the redirection target can be configured separately for each resource. There could be one describing document for each resource, or one large document for all of them, or any combination in between. It is also possible to change the policy later on.
当使用在ontology中使用303 URIs时，网络延迟会显著影响客户端的性能。大量的重定向会导致很高的响应时间。一个通过303查找一组术语的客户端可能会使用大量的请求，尽管第一个请求已经包含了需要知道的一切。
当使用303方案访问大规模数据集时，客户端可能会使用很多请求而导致要下载所有的数据，我们建议额外提供SPARQL节点或类似的服务，来回答向服务器提交的复杂查询，而不是直接让客户端通过HTTP下载很大的数据集。
303和Hash可以结合使用，从而允许一个大型数据库被分成多个部分，并有一个非文档资源标识符。相关例子：
http://www.example.com/bob#this
Bob, the person with a combined URI.
任何片段的标识符都是有效的，上面URI中的this是一个建议，你可能想把它复制到你的实现中。
结论：
Hash URI适合比较小而稳定且能同时演变（evolve together）的资源集，理想的案例是RDF Schema词汇集和OWL本体，它们的术语常常一起使用，而且这些术语的数量在未来也不太可能超出控制。
没有内容判断的Hash URI能够通过仅仅将静态RDF文件上传至Web服务器便能实现，不需要任何服务器设置。但这样会因为快捷但不恰当地获取已发布的RDF而使得它们很流行（原文 This makes them popular for quick-and-dirty RDF publication.）。
URIs of the bob#this form can be used for large sets of data that are, or may grow, beyond the point where it is practical to serve all related resources in a single document. 303 URIs may also be used for such data sets, making neater-looking URIs, but with an impact on run-time performance and server load.
If in doubt, follow your nose.
Cool URIs
最好的资源标示符，不仅仅为人和机器提供描述，而且被设计成具有简单性、稳定性和易管理性，就如同Time Berners-Lee在《Cool URIs don’t change》和W3C Team在《Common HTTP Implementation Problems》中提到的。
简单性：简短、易记的URI
稳定性：设计一个URI表示特定资源时，应考虑它能保留的尽可能的久，比如十年二十年，而且还要去掉URI中类似.php和.aspx之类的后缀，因为你以后可能要更换技术。
易管理性：使用你能管理的方式发布URIs，一个比较好的实践是，在URI路径中包含当前的年份，这样你在更改URI-schema时用不着更改以前的URIs。将所有的303 URIs保存在专门的子域名中，e.g. http://id.example.com/alice，这样会使日后迁移URI处理子系统时变得容易。
Linking
所有和真实世界中对象（资源标识符，RDF文档URL和HTML文档URL）相联系的URI都应该彼此明确的连接在一起，以帮助信息顾客 理解它们的关系。比如，在303 URI方案中，有3个关于Alice的URI：
http://www.example.com/id/alice
Identifier for Alice, the person
http://www.example.com/people/alice
Alice's homepage
http://www.example.com/data/alice
RDF document with description of Alice
其中两个是Web文档URI，以http://www.example.com/data/alice 定位的RDF文档可能包含这些语句（使用N3表示）：
<http://www.example.com/id/alice>
foaf:page <http://www.example.com/people/alice>;
rdfs:isDefinedBy <http://www.example.com/data/alice>;
a foaf:Person;
foaf:name "Alice";
foaf:mbox <mailto:alice@example.com>;
...
foaf:page连向一个HTML文档，使得一个支持RDF的客户端能够找到供人阅读的资源，同时，通过将页面指向它的主题，定义了关于HTML文档的有用的元数据。rdfs:isDefinedBy指向包含RDF描述的文档，从而允许RDF浏览器从当前文档列出的各类辅助资源中识别出主要的。我们使用rdfs:isDefinedBy而不是rdfs:seeAlso，因为/data/alice的内容是可靠的。在http://www.example.com/people/alice的HTML文档应该在它的header部分包含一个指向相应RDF文档的<link>元素：
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
<head>
<title>Alice's Homepage</title>
<link rel="alternate" type="application/rdf+xml"
title="RDF Representation"
href="http://www.example.com/data/alice" />
</head> ...
这允许支持RDF的Web客户端发现RDF信息。If the RDF data is about the Web page, rather than an expression of the information in it, then we recommend using rel="meta" instead of rel="alternate".
客户端也可以从HTTP头信息中直接推导出类似的链接信息：that a thing is described by a Web document which can be found at the end of a 303 redirect; that the Content-Location resource is a content-specific version of the generic document, and more. Ontologies for these relations are not discussed here.
下图指出了RDF和HTML文档如何是3个URIs彼此相互联系：
实现内容判断
《Best Practice Recipes for Publishing RDF Vocabularies》中讨论的基本都是RDF词汇，但是里面的观点同样适用于其它通过静态文件发布的小型RDF数据集。由于混合模式的客户端能处理HTML和RDF，比如带Tabulator扩展的Firefox，在实践中内容判断有点困难。
这些浏览器通过在Accept头使用q（quality）值consume both RDF and HTML，以声明它们的能力：
Accept: application/rdf+xml;q=0.7, text/html
上例说明，浏览器以q=0.7的参数处理RDF，而以q=1.0（默认值）的参数处理HTML。这意味着浏览器在处理HTML时比RDF有轻微的优先权。现在，客户端中HTML的优先权并不意味着每个服务器都应该发送HTML：
l If the HTML variant is a simple low-quality rendering of the RDF, like a property-value table or a list of triples, then the server should send the RDF, unless the client has a very strong preference for HTML.
l If HTML and RDF variant contain the same information, and both are of high quality, then the server should treat both variants with equal preference, and leave the choice to the client's preferences.
l If the RDF variant is only a part of the information offered in the HTML, or is scraped from the HTML, then the server should probably send the HTML, unless the client has a strong preference for RDF.
有些算法用来选择一个最佳的匹配，比如，Apache服务器可以配置成为服务器端的q指定相对值，对于某个特定的客户端，计算q_html(server)*q_html(client)和q_rdf(server)*q_rdf，取较大者。
内容判断相当复杂，但是对于同时支持HTML和RDF的客户端选择哪个作为最佳类型而言，却是一个很有效的方法。
Examples from the Web
ECS Southampton
http://id.ecs.soton.ac.uk/person/1650
URI for Wendy Hall, the person
http://www.ecs.soton.ac.uk/people/wh
HTML page about Wendy Hall
http://rdf.ecs.soton.ac.uk/person/1650
RDF about Wendy Hall
D2R Server – 开源
http://www4.wiwiss.fu-berlin.de/dblp/resource/person/315759
URI for Chris Bizer, the person
http://www4.wiwiss.fu-berlin.de/dblp/page/person/315759
HTML page about Chris Bizer
The RDF document for Chris Bizer is a SPARQL query result from the server's SPARQL endpoint: http://www4.wiwiss.fu-berlin.de/dblp/sparql?query=
DESCRIBE+/%3Chttp/%3A/%2F/%2Fwww4.wiwiss.fu-berlin.de
/%2Fdblp/%2Fresource/%2Fperson/%2F315759/%3E
The SPARQL query encoded in this URI is: DESCRIBE <http://www4.wiwiss.fu-berlin.de/dblp/resource/person/315759>
Semantic MediaWiki–开源
an open-source Semantic wiki engine. Authors can use special wiki syntax to put semantic attributes and relationships into wiki articles. For each article, the software generates a 303 URI that identifies the article's topic, and serves RDF descriptions generated from the attributes and relationships. Semantic MediaWiki drives the OntoWorld wiki. It has an article about the city of Karlsruhe:
http://ontoworld.org/wiki/Karlsruhe
the article, an HTML document
http://ontoworld.org/wiki/_Karlsruhe
the city of Karlsruhe
http://ontoworld.org/wiki/Special:ExportRDF/Karlsruhe
RDF description of Karlsruhe
其它的资源命名建议
New URI Schemes
HTTP URIs已经用来识别Web资源和Web文档了，我们应该设计一下新的URI Scheme来识别其它资源吗？e.g. info scheme用来识别基于LCCN号码的书籍，如info:lccn/2002022641
这里有一些新URI scheme的例子，更详细的列表参见Thompson和Orchard的《URNs, Namespaces and Registries》。
Magnet 基于Hash值，能使得Web站点和本地运行的工具集（如文件管理器）得到完美整合。它的URI像这样：magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C
Info: URI scheme 被建议用来标识与现有公共命名空间有联系的信息资产，比如面向LCCN号码的URI (info:lccn/2002022641)和the Dewey decimal system (info:ddc/22/eng//004.678)。
Tag URIs 通过使用域名和日期生成无冲突的URI，即使日后更换了所有人，URI也不会引起歧义。如tag:hawke.org,2001-06-05:Taiko。
XRI defines a scheme and resolution protocol for abstract identifiers. The idea is to use URIs that contain wildcards, to adapt to changes of organizations, servers, etc.
Examples are @Jones.and.Company/(+phone.number) or xri://northgate.library.example.com/(urn:isbn:0-395-36341-1).
Reference by Description
此方案通过完全去除URIs从根本上解决了URI问题：不再使用URI声明资源，而是使用匿名节点，描述时带上信息从而允许我们找到正确的那个。如，一个人可以用名字、出生日期和社会安全号码SSN来描述。这些信息应该足够有效以唯一的确定一个人。
一个流行的做法是使用人的Email作为唯一识别信息，FOAF中的foaf:mbox属性就是为了这个目的。在OWL中，这类属性成为Inverse Functional Property(IFP)。当一个代理遇到同一Email的两个资源，它能推理出这两个资源针对的都是同一个人，可以当作一个来处理。
但是如何在Web上使用这个方法？如何让代理下载关于某个资源的更多的数据？有一个很好的实践实现了这个目的：不仅仅提供资源的IFP（如人的Email地址），还要使用rdfs:seeAlso属性指向网上包含更多信息的RDF文档。
结论
语义网上的资源名应该满足两点要求：能够使用标准Web技术获取关于这个资源的描述；命名方案不应混淆things和描述things的文档。前面论述的303 URIs和Hash URIs两种方案均满足这两点要求。第二点要求促进了对协调多个URIs的需求。
贴图：见原文……