CN101027891A - 用附加信息增强统一资源标识符uri的方法和系统 - Google Patents

Abstract

提供一种用于内容管理系统的唯一命名的方法，该方法包括几个步骤。接收包含相对URI和请求特有信息的第一请求。产生包含长URI的第二请求，该长URI包含相对URI和请求特有信息。发送第二请求。

Description

用附加信息增强统一资源标识符URI的方法和系统

技术领域

本发明一般涉及资源识别，更特别地，涉及用于内容管理系统的唯一命名模式(scheme)的方法和系统。

背景技术

Armonk，New York的国际商用机器公司(IBM)已在商业计算中处于新范例(paradigm)的前沿。由于在过去几十年中网络的重要性增加，因此用户可用资源的数量增加产生了越来越多的利用问题。如果用户不能方便地利用资源，那么它存在并且会在理论上有用的事实不能完全向用户提供实际的益处。

结果，内容管理系统对于方便利用资源的问题利用各种方法。识别模式必须平衡对于方便的资源识别十分重要的两种特性：用户友好和避免不明确性。例如，对资源命名的两种方法是“共用命名”和“摘要命名”。共用名称是用户所熟悉的，但超过较小的名称空间时可能是不明确的。例如，通过给定的名称识别某人会是用户友好的并且在只包含承载给定名称的一个人的名称空间内是明确的，但是，由于会引入不可接受的水平的不明确性，因此该方法在包含承载给定名称的许多人的更大的名称空间中会有问题。

摘要名称一般是用户所不熟悉的，但具有较为明确的优点。例如，通过其全名、出生时间和地点、父母的全名识别某人以相当明确的方式识别他。但是，由于得到的标识符的使用不便的性质，因此这种方法不是用户友好的方法。

统一资源标识符(URI)的系统是摘要命名的例子。URI被用于唯一地识别资源，这些资源的两个例子是文件和对象。情况常常是这样，在有限的名称空间内，由于名称空间随时间改变，因此用户以可能引入不明确性为代价通过使用可改善用户友好性的“相对URI”识别资源。

很清楚，所需要的是用于内容管理系统的命名模式，该命名模式使得能够在变化的名称空间内以用户友好的方式唯一地识别资源。

发明内容

根据第一方面，提供用于内容管理系统的唯一命名的方法，该方法包括几个步骤。接收包含相对URI和请求特有信息的第一请求。产生包含长URI的第二请求，该长URI包含相对URI和请求特有信息。优选发送第二请求。

还提供用于响应包含相对标识符的请求明确识别并提供资源的方法，该方法包括几个步骤。服务器接收包含相对统一资源标识符(URI)和请求特有信息的请求。服务器产生包含相对URI和请求特有信息的长URI。通过服务器将长URI与多个资源相比较。基于比较，通过服务器选择多个资源中的一个，用于响应请求提供。

还提供用于响应包含相对标识符的请求明确识别和提供资源的内容管理系统。系统包含服务器和计算机可读指令。服务器包含计算装置。计算机可读指令可在计算装置上执行，并在被执行时执行包括几个步骤的过程。包含相对URI和消息特有信息的消息被接收。包含相对URI和消息特有信息的长URI被提供。长URI与多个资源相比较，并且多个资源中的一个基于比较被选择。优选地，系统还包括包含多个资源的数据库，其中，数据库在操作上与计算装置的处理器耦合。

还提供用于基于初始资源产生和识别多个明确识别的资源的方法，该方法包括几个步骤。包含相对URI的初始资源由计算装置接收。初始资源被转换成包含MIME类型、用户代理标识符和用户场所(1ocale)的组中的至少一个的至少一个最终资源。URI是至少基于相对URI且至少基于MIME类型、用户代理标识符和用户场所的组中的至少一个为这些至少一个最终资源中的每一个产生的。

附图说明

当结合下面的附图考虑公开的实施例的以下详细说明时，可以获得对本发明的更好的理解，在这些附图中，

图1是表示根据本发明的实施例、将相对统一资源标识符(URI)翻译成长URI的框图；

图2是表示根据本发明的实施例、响应对于用相对URI识别的资源的用户请求提供多个资源中的一个的框图；

图3是表示根据本发明的实施例的使得能够在用户接口层使用相对URI并在整个后端(backend)使用长URI的内容管理系统的框图；以及

图4是表示根据本发明的实施例、基于承载至少相对URI的初始资源产生和识别资源的框图。

具体实施方式

虽然特别参照内容管理系统进行说明，但可以在希望用户友好的唯一命名模式的任何信息技术(IT)系统中实现要求权利的主题。计算领域技术人员将认识到，除了以下描述的计算环境外，公开的实施例还与多种计算环境有关。另外，可以以软件、硬件或软件和硬件的组合实现公开的发明的方法。可以用专用的逻辑实现硬件部分；软件部分可被存储在存储器中并由诸如微处理器、个人计算机(PC)或主机的适当的指令执行系统执行。

在本文件的上下文中，“存储器”或“记录介质”可以为包含、存储、传达、传播或传送供或结合指令执行系统、装置或器件使用的程序和/或数据的任何装置。存储器和记录介质可以是但不限于电、磁、光、电磁、红外或半导体系统、装置或器件。存储器和记录介质还包括但不限于例如：便携式计算机磁盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或闪速存储器)和便携式光盘只读存储器或其它适当的可存储程序和/或数据的介质。

面对不断增加的网络大小和互连性，已开发和实现了内容管理系统以便于网络可用内容的使用。可以通过各种概念框架理解联网，这些概念框架之一是开放系统互连(OSI)参考模型。OSI参考模型提供描述联网技术如何在功能上协调的框架，包括七层，联网技术被分配在这些层之间：

OSI层
		7	应用
6	表示
		5	会话
4	传输
		3	网络
2	数据链路
		1	物理

层1～4可被称为“下层”，并且基本上针对通过网络数据的格式化、编码和传输，即，基于网络移动数据，并且一般用硬件和软件的组合实现。层5～7可被称为“上层”，并且基本上针对与用户交互作用以及实现在网络上运行的应用、协议和服务，并且一般以软件实现。如上面讨论的那样，并且本领域技术人员可以理解，特定的设计考虑可使得在更常使用软件实现的情况下使用硬件实现有利，反之亦然。这些修改和变化会背离本文件中提供的文字说明而仍在所附的权利要求的精神和范围内。

这些层已被划界，以支持概念框架，但实际上这些层在功能上互连。例如，以太网规范与层1和层2有关，TCP/IP协议组中的TCP和IP与层3和层4有关。

本发明的优选实施例针对上层。实际上，上层的分开不象下层的分开那样清楚。例如，TCP/IP协议组的体系结构将层5～7视为单一的“顶层”。其结果是，顶层不向更高的OSI层而向希望利用网络的程序和用户提供服务。换句话说，顶层实现网络用户需要的功能。下层的服务根据需要被利用以支持顶层功能。

例如，考虑在个人计算机上操作的网络浏览器软件。虽然网络浏览器软件传统上被用户称为应用，但它不驻留在OSI应用层。相反，网络浏览器软件利用应用层提供的功能，诸如超文本传输协议(HTTP)。在某种意义上，网络浏览器软件可被称为驻留在“第八”OSI层。

出于许多目的，层5～7没有很好地分开，因此出现概念模糊。因此，有时用如下表所示的另一框架对层5～7划界：

OSI层5～7

功能区	例子
		命名系统	TCP/IP域名称系统
文件和资源共享协议	网络文件系统
		网络配置和管理协议	主机配置协议BOOTP和DHCP
最终用户应用和应用协议	一般文件传输、电子邮件、世界性新闻组网络系统(Usenet)、万维网、交互式协议(诸如Telnet)和管理效用(administration utilities)

本发明的优选实施例特别涉及在上表中给出的第四功能区：最终用户应用和应用协议。在该功能区内，优选实施例特别涉及所建立的供TCP/IP应用寻址因特网资源时使用的通用系统：统一资源标识符(URI)。

由于因特网包括数百万互连的服务器，因此建立URI系统以提高大量可用信息的可用性。各个URI唯一识别客户如何定位和访问特定的资源使得它可被使用。URI启用所谓的“应用层寻址”。这与层2MAC寻址、层3IP寻址、层4端口和套接口寻址和域名系统(DNS)寻址不同。特别地，DNS名称识别与网络连接的特定的实或虚设备。URI基于DNS名称以识别特定的文件、对象或在逻辑上与由DNS名称识别的设备有关的其它资源。实际上，URI由单一的相当简洁的字符串构成，所有信息是指向资源必需的。由于URI是简洁的字符串，因此它们易于被嵌入文件中，由此使得能够方便地嵌入从文件到其外部的任意资源的链接，这些链接至少在理论上是直接或间接可达到的。

每个URI都落入以下两个子范畴之一中：统一资源定位符(URL)和统一资源名称(URN)。URL是规定用于访问目标资源的协议或机制以及目标资源的位置的URI。URL的例子是http://www.ibm.com/us/，它识别由国际商用机器公司提供的网页。该URL将网页的协议或访问机制规定为HTTP，并通过DNS域名“www.ibm.com”和路径“us/”规定网页的位置。

相反，URN是提供资源以唯一名称而不规定资源的访问机制或位置的URI。URN的例子是URN:isbn:0471414638，它识别由Wiley(JohnWiley&Sons公司)以平装本形式在2003年4月4日出版的Kevin Maney的书名为“The Maverick and His Machine：Thomas Watson，Sr.andthe Making of IBM”的书。由此，URI统一地识别该书，但不识别在哪里以及如何可以访问它。

URL和URN均具有限制，但分别提供唯一地识别资源的一种形式的URI。在当前的实践中，大多数URI是遵从标准网络URL语法规则的HTTP URL。因此，为了解释本发明的优选实施例，本文件中的大部分将使用适于网络URL语法规则的例子和术语。但是，本领域技术人员可以理解，其它的URI在所附的权利要求的精神和范围内。

现在转到附图，图1是表示根据本发明的实施例的用于将相对(relative)URI翻译为长URI的过程100的框图。相对URI 102在用户接口层(level)104上被使用。相对URI102被传给URI翻译器106以进行翻译108。URI翻译器106输出识别目标资源111的长URI110，该目标资源111如打算要在用户接口层104上被相对URI102识别的资源。长URI110基于相对URI102以及优选与用户和目标资源111有关的上下文信息112。

作为长URI 110的一部分被包含的上下文信息112优选包含多用途因特网邮件扩充(MIME)类型、用户代理标识符(用户代理ID)和用户场所。除了其它方面以外，用户场所优选包含用户国家和用户语言。

图2是表示根据本发明的实施例的、用于响应对于用相对URI识别的资源的用户请求提供多个资源中的一个的过程114的框图。具有相对URI的用户请求被服务器接收116。相对URI被服务器翻译118成包含相对URI和包含MIME类型、用户代理ID和用户场所的上下文信息的长URI。长URI通过服务器与多个可用资源相比较。基于比较，多个可用资源中的一个被选择122，用于响应用户请求提供。

本文通篇之中，术语“用户代理ID”意味着与访问所考虑的资源有关的用户的计算环境。例如，如果资源是网页，那么用户代理ID可包含用户的网络浏览器软件和计算装置(例如，个人数字助理、个人计算机、打印机等)。这会允许用户用相对URI请求资源并借助相对URI向长URI的后台(behind-the-scenes)翻译被提供用户定制的资源。

例如，用户从服务器请求相对URI http://www.someserver.com。用户的请求包含指示用户在美国并使用读取HTML的网络浏览器的首标信息。因此，服务器将相对URI翻译成长URIhttp://www.someserver.com/text/html/a/us/en/home.html，使得用户将被提供专门为使用读取HTML的网络浏览器的美国用户设计的网页。长URI如下表所示被断开：

表：长URI例子

网络URL	http://www.someserver.com
		MIME类型	text/html
用户代理ID	a
		用户场所	us/en
资源文件名	home.html

在长URI例子表格中，标记“text/html”指示资源的格式适用读取HTML的网络浏览器。标记“a”设计为指示网络浏览器能够处理DHTML和Mozilla 4/x的功能。标记“us”指示用户的国家是美国。标记“en”指示用户的语言是英语。标记“home.html”是附加DNS域名www.someserver.com的类型“/”的请求映射的主页。

如该例子示出的那样，诸如“home”的受到偏好的名称可在许多资源上被使用，这里，各个资源对特定的用户上下文定制，并被上下文敏感的“长URI”在后台识别。

图3是表示根据本发明的实施例的互连网络124的框图，该互连网络124包含使得能够在用户接口层使用相对URI并在整个后端(backend)使用长URI的内容管理系统126。具有相对URI的用户请求128通过因特网130被传输到作为内容管理系统126的一部分的服务器132。服务器132将相对URI翻译成长URI，将长URI与多个可用资源138相比较136，并基于比较136选择140多个可用资源138中的一个用于响应用户请求128提供给用户。

内容管理系统126对用户有效地隐藏公开的唯一命名模式的细节，使得用户能够使用比长URI更加用户友好的相对URI。

图4是表示根据本发明的实施例的用于基于承载至少相对URI的初始资源产生和识别资源的过程142的框图。输入阶段146的初始资源144包含相对URI 148。初始资源144被提供给产生阶段152的资源产生器150。产生阶段152之后是资源产生器150输出一个或更多个最终资源156的目标资源阶段154，每个最终资源具有基于相对URI的长URI和优选与目标资源及其期望的用户相关的上下文信息158。

在初始资源为特别适于描述基本内容(base content)的格式的情况下，这种类型的系统是特别有用的。这种格式的例子是XML。例如，产生了初始资源somecontent.xml。希望初始资源被存储为四个最终资源，每个最终资源具有以下四种格式中的一种不同格式：(1)面向使用英语的美国用户的能够处理DHTML和Mozilla 4/x的功能的网络浏览器用HTML；(2)面向使用日语的日本用户的能够处理DHTML和Mozilla 4/x的功能的网络浏览器用PDF；(3)面向使用英语的美国用户的能够处理DHTML和Mozilla 4/x的功能(除不具有顶部和底部标题(banner)和导航信息外)的网络浏览器用HTML；和(4)面向使用英语的美国用户的XML。诸如图4中说明的过程将somecontent.xml转换成以下四个资源：

(1)/text/html/a/us/en/somecontent.html；

(2)/application/pdf/a/jp/ja/somecontent.paf；

(3)/text/html/fast/us/en/somecontent.html；和

(4)/application/xml/a/us/en/somecontent.html。

该例子的结果是，四个最终资源中的每一个被明确地识别。并且，最终资源被命名和定位，使得可以响应对于“somecontent”的用户请求选择四个资源中的一个用于伴随用户请求基于用户上下文信息提供。

虽然参照本发明的特定实施例示出和说明了本发明，但本领域技术人员可以理解，在不背离本发明的范围的情况下，可以提出形式和细节上的上述和其它变化，包含但不限于附加的、更少的或修改的要素和/或以相同或不同的次序执行的附加的、更少的或修改的块。例如，相对标示符可在用户的计算装置本地上被转换或翻译，然后，包含全标识符的请求被提交给应用层或等同服务。

Claims (15)

1.一种用于内容管理系统的唯一命名的方法，包括以下步骤：

接收包含相对统一资源标识符(URI)和请求特有信息的第一请求；

产生包含长URI的第二请求，该长URI包含所述相对URI和请求特有信息。

2.如权利要求1所述的方法，还包括以下步骤：

发送第二请求。

3.如权利要求1或2所述的方法，其中，第一请求包含：

相对URI；和

包含多用途因特网邮件扩充(MIME)类型、用户代理标识符和用户场所的组中的至少一个的请求特有信息。

4.如权利要求2或3所述的方法，其中，发送的步骤包含以下步骤：

处理第二请求；和

响应第一请求发送包含由长URI识别的资源的响应。

5.如任意前面的权利要求所述的方法，还包括以下步骤：

将长URI与多个资源相比较；和

基于比较的步骤选择多个资源中的一个，用于响应请求进行提供。

6.如权利要求5所述的方法，还包括以下步骤：

响应第一请求发送包含多个资源中的一个的响应。

7.如权利要求6所述的方法，其中，接收的步骤包含通过全时公用网络接收请求的步骤，该请求包含：

相对URI；和

请求特有信息，

以及，发送的步骤包含响应请求通过全时公用网络发送包含多个资源中的一个的步骤。

8.一种用于唯一命名的内容管理系统，包括：

包含计算装置的服务器，该计算装置包含：

处理器；

在操作上与处理器耦合的存储器；

在操作上与处理器耦合的网络接口，

其中，计算装置适于通过网络接口接收包含相对URI和请求特有信息的第一请求；以及

计算装置适于产生包含长URI的第二请求，该长URI包含所述相对URI和请求特有信息。

9.如权利要求8所述的系统，其中，计算装置适于发送第二请求。

10.如权利要求8或9所述的系统，其中，第一请求包含相对URI和包含MIME类型、用户代理标识符和用户场所的组中的至少一个的请求特有信息。

11.如权利要求9或10所述的系统，其中，计算装置适于：

处理第二请求；和

响应第一请求发送包含由长URI识别的资源的响应。

12.如权利要求8～11中的任一项所述的系统，其中，计算装置适于将长URI与多个资源相比较并基于比较选择多个资源中的一个。

13.如权利要求12所述的系统，其中，计算装置适于通过网络接口响应第一请求发送包含多个资源中的一个的响应。

14.如权利要求13所述的系统，其中，计算装置还适于通过全时公用网络接收包含相对URI和请求特有信息的请求，

其中，发送的步骤包含响应请求通过全时公用网络发送包含多个资源中的一个的响应。

15.一种计算机程序，包含适于当所述程序在计算机上运行时执行权利要求1～7中的任一项中的所有步骤的程序代码单元。

Images