CN101416153B - 实现组织可由硬件/软件接口系统管理的信息单元的数字图象模式的系统和方法 - Google Patents

Abstract

在基于项目的系统中，图象(如JPEG，TIEF，位图等)被处理成核心平台对象(“图象项目”，或更简单的“图象”)，并存在于提供系统中图象的可扩展表示的“图象模式“中-即，图象的特征以及该图象如何关系到系统中其它项目(包括但不限于其它图象)。为此，图象模式定义系统中图象的属性、行为和关系，且模式还强制实施关于图象的规则，如图象必须包含什么专用数据、图象可任选地可包含什么专用数据、特定的图象可如何扩展等。

Description

实现组织可由硬件/软件接口系统管理的信息单元的数字图象模式的系统和方法

引用

本申请要求2003年10月24日提交的序列号为10/692,779(代理案卷号MSFT-2829)的美国专利的优先权，后者又要求2003年8月21日提交的序列号为10/646,632(代理案卷号MSFT-1751)的美国专利的优先权，其题为“SYSTEMSAND METHODS FOR THE IMPLEMENTATION OF A CORE SCHEMA FORPROVIDING A TOP-LEVEL STRUCTURE FOR ORGANIZING UNITS OFINFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACESYSTEM(实现提供组织可由硬件/软件接口系统管理的信息单元的顶层结构的核心模式的系统和方法)”；以及2003年8月21日提交的国际专利号PCT/US03/26144的优先权，这些申请通过引用整体结合于此。

本专利的主题还涉及在下列共同转让的专利中揭示的发明，它们的内容也通过引用结合于此，这些专利是：2003年8月21日提交的美国专利申请号10/647,058(代理案卷号MSFT-1748)，题为“SYSTEMS AND METHODS FORREPRESENTING UNITS OF INFORMATION MANAGEABLE BY AHARDWARE/SOFTWARE INTERFACE SYSTEM BUT INDEPENDENT OFPHYSICAL REPRESENTATION(呈现可由硬件/软件接口系统管理的信息单元而不独立于物理呈现的系统和方法)”；2003年8月21日提交的美国专利申请号10/646,941(代理案卷号MSFT-1749)，题为“SYSTEMS AND METHODS FORSEPARATING UNITS OF INFORMATION MANAGEABLE BY AHARDWARE/SOFTWARE INTERFACE SYSTEM FROM THEIR PHYSICALORANIZATION(将可由硬件/软件接口系统管理的信息单元与其物理组织隔离开来的系统和方法)”；2003年8月21日提交的美国专利申请号10/646,940(代理案卷号MSFT-1750)，提为“SYSTEMS AND METHODS FOR THEIMPLEMENTATION OF A BASE CHEMA FOR ORGANIZAING UNITS OFINFORMATION MANAGEABLE BY HARDWARE/SOFTWARE INTERFACESYSTEM(实现组织可由硬件/软件接口系统管理的信息单元的基础模式的系统和方法)”；2003年8月21日提交的美国专利申请号10/646,645(代理案卷号MSFT-1752)，题为“SYSTEMS AND METHODS FOR REPRESENTINGRELATIONSHIPS BETWEEN UNITS OF INFORMATION MANAGEABLE BY AHARDWARE/SOFTWARE INTERFACE SYSTEM(呈现可由硬件/软件接口系统管理的信息单元之间的关系的系统和方法)”；2003年8月21日提交的美国专利申请号10/646,575(代理案卷号MSFT-2733)，题为“SYSTEMS AND METHODS FORINTERFACING APPLICATION PROGRAMS WITH AN ITEM-BASED STORAGEPLATFORM(将应用程序与基于项目的存储平台接口的系统和方法)”；2003年8月21日提交的美国申请专利10/646,646(代理案卷号MSFT-2734)，题为“STORAGE PLATFORM FOR ORGANIZING，SEARCHING，AND SHARINGDATA(用于组织、搜索、共享数据的存储平台)”；2003年8月21日提交的美国专利申请号10/646,580(代理案卷号MSFT-2735)，题为“SYSTEMS ANDMETHODS FOR DATA MODELING IN AN ITEM-BASED STORAGE PLATFORM(用于在基于项目的存储平台中数据模型化的系统和方法)”；2003年10月24日提交的美国专利申请号10/692,515(代理案卷号MSFT-2844)，题为“SYSTEMSAND METHODS FOR PROVIDING SYNCHRONZATION SERVICES FOR UNITSOF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWAREINTERFACE SYSTEM(对可由硬件/软件接口系统管理的信息单元提供同步服务的系统和方法)”；2003年10月24日提交的美国专利申请号10/692,508(代理案卷号MSFT-2845)，题为“SYSTEMS AND METHODS FOR PROVIDINGRELATIONAL AND HIERARCHICAL SYNCHRONIZATION SERVICE FORUNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWAREINTERFACE SYSTEM(对由硬件/软件接口系统可管理的信息单元提供关系的和分层的同步服务的系统和方法)”；2003年10月24日提交的美国专利申请号10/693,362(代理案卷号MSFT-2846)，题为“SYSTEMS AND METHODS FORTHE IMPLEMENTATION OF A SYNCHRONIZATION SCHEMAS FOR UNITS OFINFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACESYSTEM(对由硬件/软件接口系统可管理的信息单元实现同步模式的系统和方法)”；和2003年10月24日提交的美国专利申请号10/693,574(代理案卷号MSFT-2847)，题为“SYSTEMS AND METHODS FOR EXTENSIONS ANDINHERTANCE FOR UNITS OF INFORMATION MANAGEABLE BY AHARDWARE/SOFTWARE INTERFACE SYSTEM(用于对由硬件/软件接口系统可管理的信息单元扩展和继承的系统和方法)”。

技术领域

本发明一般涉及信息存储和检索领域，尤其涉及用于组织、搜索和共享计算机化系统中的不同类型的数据(特别是图象数据)的活动存储平台。

背景

在最近十年中，单个盘的容量每年增长约百分之70(70％)。摩尔(Moore)法则精确地预测了在过去数年中中央处理单元(CPU)能力的惊人的增长。有线和无线技术已经提供了数量上巨大的连接和带宽。假设当前趋势持续，在数年内一般的膝上计算机将具有约万亿字节(TB)的存储并包含数百万个文件，而5千亿字节(500GB)的驱动器成为常见的。

消费者使用他们的计算机主要用于通信和组织个人信息，不论它们是传统的个人信息管理器(PIM)风格的数据或如数字音乐或照片那样的媒体。数字内容的量和存储原始字节的能力已经大量地增长；然而消费者可用于组织和统一此数据的方法却跟不上步伐。知识工人花费大量时间来管理和共享信息，某些研究估计，知识工人花费15-25％的时间在与无效信息有关的活动上。另外研究估计，典型的知识工人每天约花费2.5小时搜索信息。

开发者与信息技术(IT)部门投资大量的时间与金钱来构建他们自己的用于公用存储抽象的数据存储，以呈现如人、地方、时间和事件等事项目。这不仅导致重复的工作，还形成公用数据的孤岛，没有共同搜索或共享那些数据的机制。仅考虑当今在运行Microsoft Windows操作系统的计算机上有多少地址簿。如电子邮件客户端和个人财务程序那样的许多应用程序保留各自的地址簿，且在每个那样的程序分别维护的地址簿应用程序之间只有很少共享。因而，财务程序(如MicrosoftMoney)不与维护在电子邮件联系人文件夹(如Microsoft Outlook中的联系人文件夹)中的地址共享支付人的地址。确实，许多用户具有多个设备，在这些设备之间和包括到如MSN和AOL等商业服务的手机电话号码的各种附加来源之间应该在逻辑上同步它们的个人数据；然而共享文档的协作大部分是通过将文档附到电子邮件消息来达到的—这是手动的且低效的。

缺乏协作的一个原因是组织计算机系统中的信息的传统方法集中在使用基于文件—文件夹—目录的系统(“文件系统”)，来基于用于存储文件的存储介质的物理组织的抽象将多个文件组织到文件夹的目录分层结构中。在1960年代开发的Multics操作系统被认为是在操作系统级上使用文件、文件夹和目录来管理可存储数据单元的先驱。具体说来，Multics在文件的分层结构中使用符号地址(从而引入文件路径的概念)，其中文件的物理地址对用户(应用程序和最终用户)是不透明的。此文件系统完全不考虑任何单个文件的文件格式，且在文件中及文件之间的关系在操作系统级上被认为是无关的(即，与分层结构中文件的位置不同)。由于Multics的出现，在操作系统级上可存储的数据被组织成文件、文件夹和目录。这些文件一般包括放在由文件系统维护的一特定文件中的文件分层结构本身(“目录”)。此目录进而维护对应于该目录中所有其它文件和那些文件在分层结构(这里指文件夹)中的节点位置的条目的列表。这是本领域中近40年的状态。

然而，虽然提供了驻留在计算机的物理存储系统中的信息的合理表示，但是文件系统是物理存储系统的抽象，因而文件的利用需要在用户处理什么(具有上下文、特征以及与其它单元的关系的单元)和操作系统提供什么(文件、文件夹和目录)之间的间接(解释)层。结果，用户(应用程序和/或最终用户)只好强制把信息单元放入文件系统结构，即使这样做是低效的、不一致的、或不希望的。此外，现有的文件系统关于在各个文件中存储的数据的结构知之甚少，因此，大多数信息在文件中保持封闭，只能被写那些数据的应用程序访问(和可理解)。因此，缺乏信息的模式描述和管理信息的机制，导致形成数据的竖井(silo)，只有很少数据能在各竖井之间共享。例如，许多个人计算机(PC)用户具有5个以上各异的存储，它们包含有关他们在某一层上交互的人的信息—如Outlook联系人、在线账户地址、Windows地址簿、Quicken受款人和即时消息(IM)伙伴列表—因为组织文件向这些PC用户提出重要的挑战。由于大多数现有的文件系统利用嵌套的文件夹隐喻来组织文件和文件夹，因此当文件数量增加时，为维持灵活且有效的组织模式所必需的努力变得十分惊人。在这些情况下，具有单个文件的多重分类是非常有用的；然而使用现有文件系统中的硬和软链接是麻烦且难以维护的。

过去已作了若干不成功的尝试来克服文件系统的缺点。这些以前尝试中的某一些已经涉及使用内容可定址的存储器来提供可以通过内容而不是通过物理地址来访问数据的机制。然而，这些努力被证明是不成功的，因而虽然内容可定址的存储器对由如高速缓存和存储器管理单元等设备的小规模使用被证明是有用的，但对如物理存储介质等设备的大规模使用由于各种原因尚不可能，因此那样的解决方案简直不存在。已作出使用面向对象的数据库(OODB)系统的其它尝试，但是这些尝试虽然带有强烈的数据库的特征，且良好的非文件表示，但在处理文件表示方面并不有效，并不能重现在硬件/软件接口系统级上基于分层结构的文件及文件夹的速度、效率和简单性。诸如试图使用SmallTalk(和其它派生方法)的其它尝试在处理文件和非文件表示方面被证明相当有效，但缺乏有效地组织和利用在各种数据文件之间存在的关系所必需的数据库特征，因此那种系统的整体有效性是不可接受的。使用BeOS(和其它那样操作系统研究)的又一种尝试尽管能够胜任适当地表示文件的同时又提供某些必要的数据库特征，在处理非文件的表示上被证明是不够的，这是传统文件系统同样的核心缺点。

数据库技术是存在类似挑战的另一专业领域。例如，虽然关系型数据库模型已取得很大的商业上的成功，实际上独立软件分销商(ISV)一般运用了关系型数据库软件产品(如Microsoft SQL Server)中可得到的功能一小部分。相反，应用程序与那样产品的大多数交互是以简单的“gets”和“puts”的形式。对此虽然有若干容易明白的原因(如作为平台或数据库的不可知)，一个常被忽视的关键的原因是数据库没有必要提供主要商业应用程序分销商确实需要的精确抽象。例如，虽然真是世界具有如“客户”或“订单”等“项目”的概念(以及订单的嵌入的“行式项目”作为其中的项目和项目本身)，而关系型数据库只在表和行的方面来谈论。结果，虽然应用程序可能希望具有在项目级上的一致性、锁定、安全和/或触发器的方面(只列出一些)，通常数据库只在表/行级上提供这些特征。尽管若每个项目映射到数据库某个表的单个行也能工作得很好，但在带多个行式项目的订单的情况下，存在一个项目实际上要映射到多个表的原因，且在此情况下，单个关系型数据库系统不能确切地提供正确的抽象。因此，应用程序必须在数据库的顶层构建逻辑以提供这些基本抽象。换言之，基本关系模型不提供在其上容易开发高级应用程序的存储数据的足够平台，因为基本关系模型需要在应用程序和存储系统之间的间接层，其中只在某些情况的应用程序中可以看到数据的语义结构。尽管某些数据库分销商正将高级功能构建到他们的产品中(如提供对象关系能力，新的组织模型等)，至今尚没有哪个提供需要的全面解决方案，其中真正的全面解决方案是为有用的域抽象(如“个人”、“位置”、“事件”等)提供有用的数据模型抽象(如“项目”、“扩展”、“关系”等)的解决方案。

考虑在现有数据存储和数据库技术中的上述缺陷，需要一种新的存储平台，它改善了组织、搜索和共享计算机系统中所有类型数据的能力，该存储平台扩展和拓宽了数据平台，超越现有的文件系统和数据库系统，且它被设计成存储所有类型的数据。通过引用结合于此的相关发明满足此要求。

然而，图象(照片、数字图象等)的存储不是标准化的，且不能在各平台和各应用程序之间一般化。虽然应用程序能包括适用于特定图象格式(如JPEG)的API，那样的应用程序的开发者必须知道该格式，包括适合的应用程序接口(API)，并完成与所述格式互操作所必需的转换。本领域中所短缺的是用于计算机系统中所有图象对象的公用模式(或模式组)，而本发明结合通过引用结合于此的相关发明满足此特定的要求。

概述

下面的综述提供了在通过引用结合于此的相关发明(称为“相关发明”)的上下文中描述的本发明的各个方面的综述。此综述不试图提供本发明的所有重要方面的包罗无遗的描述，也不定义本发明的范围。相反，此综述旨在作为对下文的详细描述和附图的引言。

本发明及相关发明一起针对用于组织、搜索和共享数据的存储平台。本发明的存储平台扩展和拓宽了数据存储的概念，超过现有的文件系统和数据库系统，并被设计成存储所有类型的数据，包括结构化的、非结构化的或半结构化的数据。

本发明的存储平台包括在数据库引擎上实现的数据存储。数据库引擎包括带对象关系扩展的关系型数据库引擎。数据存储实现了支持数据的组织、搜索、共享、同步和安全的数据模型。在模式中描述了特定类型的数据，而该平台提供了扩展模式组以定义新的数据类型(主要是由该模式提供的基本类型的子类型)的机制。同步能力便于在用户或系统之间共享数据。提供类似文件系统的能力，它允许数据存储与现有文件系统的互操作，但没有传统文件系统的限制。改变跟踪机制提供跟踪数据存储改变的能力。该存储平台还包括一组应用程序接口，它们使应用程序能访问该存储平台的所有上述能力，并访问在模式中描述的数据。

由数据存储实现的数据模型按照项目、元素和关系定义数据存储的单元。项目是数据存储中可存储的数据单元，并能包括一个或多个元素和关系。元素是包括一个或多个字段(这里也称为属性)的类型的实例。关系是两个项目之间的链接。(如这里所使用的，这些和其它特定术语可被大写化，以区别在附近使用的其它术语；然而实在无意区分大写的术语如“Item(项目)”与不大写的同一术语如“item”，不应假定或隐含这样的区分)。

计算机系统还包括多个项目，其中每个项目构成能由硬件/软件接口系统处理的分立的可存储信息单元；构成所述项目的有组织的结构的多个项目文件夹；以及用于处理多个项目的硬件/软件接口系统，其中每个项目属于至少一个项目文件夹，并可属于一个以上项目文件夹。

项目或某些项目属性值可被动态地计算，而不是从持久存储中导出。换言之，硬件/软件接口系统不要求项目被存储和支持某些操作，如枚举当前的项目组的能力或给定其存储平台的标识符(在描述应用程序接口或API的章节中更充分地描述)来检索项目的能力—例如，项目可以是手机的当前位置或温度传感器上的温度读数。硬件/软件接口系统可处理多个项目，并能进一步包括可由硬件/软件接口系统管理的多个关系互连的项目。

计算机系统的硬件/软件接口系统还包括核心模式，以定义一组被所述硬件/软件接口系统理解并能以预定的和可预测的方式直接处理的核心项目。为处理多个项目，计算机系统将所述项目与多个关系互连，并在硬件/软件接口系统级上管理所述关系。

存储平台的API对每个项目、项目扩展和在存储平台模式组中定义的关系提供数据类。此外，应用程序接口提供一组架构类，它们定义数据类的公用行为组，并与数据类一起提供存储平台API的基本编程模型。存储平台API提供简化的查询模型，使应用程序员能基于数据存储中的诸项目的各种属性，以使应用程序员不必了解底层数据库引擎的查询语言的细节的方式形成查询。存储平台API还收集由应用程序对项目作出的改变，并然后将它们组织到由实现数据存储的数据库引擎(或任何类型的存储引擎)需要的正确更新中。这使应用程序员能对存储器中的项目作出改变，而将数据存储更新的复杂性留给API。

通过其公用的存储基础和模式化的数据，本发明的存储平台使消费者、知识工人及企业能作出更有效的应用程序开发。它提供丰富和可扩展的应用程序接口，不仅使内含在其数据模型中的能力可用，还能包含及扩展现有文件系统和数据库访问方法。

鉴于互相关联的发明(在详细描述的第二节中详细描述)的这一全部结构，本发明特别地针对对计算机系统(在详细描述的第三节中详细描述)中的所有图象对象(图象项目)的公用模式。从本发明的下面详细描述及附图，本发明的其它特征及优点变得十分清楚。

附图的简要描述

上面的综述及本发明的下面详细描述在结合附图阅读时将能更好地理解。为说明本发明的目的，在图中示出本发明的各方面的实施例；然而，本发明不限于揭示的具体的方法和手段。附图中：

图1是表示能结合本发明的诸方面的计算机系统的框图；

图2是示出被划分成三个组件组的计算机系统的框图：硬件组件、硬件/软件接口组件以及应用程序组件；

图2A示出在基于文件的操作系统中对组合在目录中的文件夹中的文件的传统的基于树形的分层结构；

图3是示出数据平台的框图；

图4示出在项目、项目文件夹和类别之间的结构关系；

图5A是示出项目的结构的框图；

图5B是示出图5A的项目的复杂属性类型的框图；

图5C是示出“Location(位置)”项目的框图，其中其复杂类型被进一步描述(明确列出)；

图6A将项目示作在基础模式中找到的项目的子类型；

图6B是示出图6A的子类型项目的框图，其中明确地列出其继承的类型(除了它的直接属性外)；

图7是示出包括其两个顶层类类型-Item(项目)和PropertyBase(属性基础)的基础模式，以及从中导出的另外基础模式的框图；

图8A是示出在核心模式中的项目的框图；

图8B是示出在核心模式中属性类型的框图；

图9是示出项目文件夹、其成员项目以及在项目文件夹及其成员项目之间互连关系的框图；

图10是示出类别(它本身也是项目)、其成员项目以及在类别及其成员项目之间的互连关系的框图；

图11是示出存储平台的数据模型的引用类型分层结构的图示；

图12是示出关系如何被分类的图示；

图13是示出通知机制的图示；

图14是示出两个事务均将新的记录插入同一B树的例子的图示；

图15示出数据改变检测过程；

图16示出示例性目录树；

图17示出将基于目录的文件系统的现有文件夹移动到存储平台数据存储的例子；

图18示出包含文件夹的概念；

图19示出存储平台API的基本体系结构；

图20示意性地示出存储平台API栈的各种组件；

图21A是示例性联系人项目模式的图形表示；

图21B是对图21A的示例性联系人项目模式的元素的图形表示；

图22示出存储平台API的运行库架构；

图23示出“FindAll”操作的执行；

图24示出从存储平台模式生成存储平台API类的过程；

图25示出File(文件)API所基于的模式；

图26是示出用于数据安全目的的访问掩码格式的图示；

图27(部分a，b，c)画出从现有安全区域开拓的新的同等保护的安全区域；

图28是示出项目搜索视图的概念的图示；

图29是示出示例性项目分层结构的图示；

图30A示出作为第一和第二代码段通信的管道的接口“接口1”；

图30B示出的接口包括接口对象I1和I2，它们使系统的第一和第二代码段能通过介质M通信；

图31A示出由接口“接口1”提供的功能如何再分割，以便将该接口的通信转换到多个接口“接口1A”、“接口1B”、“接口1C”；

图31B示出由接口I1提供的功能如何再分割成多个接口I1a、I1b、I1c；

图32A示出无意义的参数precision能被忽略或用任意参数替代的情形；

图32B示出接口被替代接口代替的情况，该替代接口被定义成忽略或添加参数到接口；

图33A示出第一和第二代码段被合并到包含两者的模块的情况；

图33B示出能将接口的部分或全部内嵌地写入另一接口以形成合并的接口的情况；

图34A示出一段或多段中间件如何能转换第一接口的通信以便使它们符合一个或多个不同的接口；

图34B示出如何用接口引入代码段，以从一个接口接收通信，但将功能发送到第二和第三接口；

图35A示出即时编译器(JIT)如何能将通信从一个代码段转换到另一代码段；

图35B示出应用动态重写一个或多个接口的JIT方法来动态分解或更改所述接口；

图36示出图象模式以及(图7的)基础模式及(图8A的)核心模式，以示出在每个模式中各个项目之间的互相关系。

详细描述

目录

  A.示例性计算环境...............................................14

  B.传统的基于文件的存储.........................................17

II.用于组织、搜索和共享数据的WINFS存储平台.......................18

  A.词汇表.......................................................18

  B.存储平台综述.................................................19

  C.数据模型.....................................................20

    1.项目.......................................................21

    2.项目标识...................................................24

    3.项目文件夹和类别...........................................24

    4.模式.......................................................26

      a)基础模式.................................................26

      b)核心模式.................................................26

    5.关系.......................................................28

      a)关系声明.................................................28

      b)持有关系.................................................30

      c)嵌入关系.................................................31

      d)引用关系.................................................31

      e)规则和约束...............................................32

      f)关系的排序...............................................32

    6.可扩展性...................................................36

      a)项目扩展.................................................37

      b)扩展NestedElement类型....................................40

  D.数据库引擎...................................................41

    1.使用UDT的数据存储实现......................................42

    2.项目映射...................................................43

    3.扩展映射...................................................44

    4.嵌套元素映射...............................................44

    5.对象身份...................................................44

    6.SQL对象命名................................................44

    7.列命名.....................................................45

    8.搜索视图...................................................46

      a)项目.....................................................46

        (1)主项目搜索视图........................................46

        (2)分类型的项目搜索视图............................47

      b)项目扩展...........................................47

        (1)主扩展搜索视图..................................47

        (2)分类型的扩展搜索视图............................48

      c)嵌套的元素.........................................48

      d)关系...............................................48

        (1)主关系搜索视图..................................48

        (2)关系实例搜索视图................................49

      e)...................................................50

    9.更新.................................................50

    10.改变跟踪及墓碑......................................50

      a)改变跟踪...........................................50

        (1)“主”搜索视图中的改变跟踪......................51

        (2)“分类型的”搜索视图中的改变跟踪................52

      b)墓碑...............................................52

        (1)项目墓碑........................................52

        (2)扩展墓碑........................................53

        (3)关系墓碑........................................53

        (4)墓碑清除........................................54

    11.助手API和函数.......................................54

      a)函数[System.Storage].GetItem.......................54

      b)函数[System.Storage].GetExtension..................54

      c)函数[System.Storage].GetRelationship...............54

    12.元数据..............................................55

      a)模式元数据.........................................55

      b)实例元数据.........................................55

  E.安全性.................................................55

  F.通知和改变跟踪.........................................55

  G.同步...................................................56

    1.存储平台到存储平台的同步.............................57

      a)同步(Sync)控制应用程序.............................57

      b)模式注释...........................................57

      c)同步配置...........................................58

        (1)共同体文件夹—映射..............................59

        (2)概况............................................60

          (3)时间表.............................................60

        d)冲突处理..............................................61

          (1)冲突检测...........................................61

             (a)基于知识的冲突..................................61

             (b)基于约束的冲突..................................61

          (2)冲突处理...........................................61

             (a)自动冲突分解....................................62

             (b)冲突日志记录....................................62

             (c)冲突审查和分解..................................63

             (d)复制品的会聚性及冲突分解的传播..................63

      2.对非存储平台数据存储的同步..............................63

        a)同步服务..............................................64

          (1)改变枚举...........................................64

          (2)改变应用...........................................65

          (3)冲突分解...........................................65

        b)适配器实现............................................65

      3.安全性..................................................65

      4.可管理性................................................66

    H.传统文件互操作性..........................................66

    I.存储平台API...............................................67

III.图象模式和辅助模式(图象模式组)..............................72

    A.图象模式..................................................72

    B.照片模式..................................................75

    C.分析属性模式..............................................76

IV.结论.........................................................76

I.引言

本发明的主题用细节来描述，以满足法定的要求。然而，该描述本身不试图限制本专利的范围。相反，本发明者设想，要求保护的主题也能以其它方式实施，以结合其它当前和未来的技术包括类似于本说明描述的不同的步骤或步骤的组合。此外，虽然术语“步骤”在这里可用于意味着所采用的方法的不同元素，然而该术语不能被解释为在这里揭示的各步骤之间隐含特定的次序，除非明确地描述了各个步骤的次序。

A.示例性计算环境

本发明的许多实施例可在计算机上执行。图1和下面讨论旨在提供其中实现本发明的合适计算环境的简要描述。虽然不是必需，本发明的诸方面能以诸如由如客户工作站或服务器的计算机上执行的程序模块的计算机可执行指令的一般上下文中描述。一般而言，程序模块包括例程、程序、对象、组件、数据结构等，它们执行特定任务或实现特定抽象数据类型。此外，本发明可用其它计算机系统配置实现，包括手持设备、多处理器系统、基于微处理器的系统或可编程消费者电子设备、网络PC、小型机、大型机等。本发明还能在分布式计算环境中实现，其中任务由通过通信网络链接的远程处理设备完成。在分布式计算环境中，程序模块能位于本地或远程存储器存储设备中。

如图1所示，示例性通用计算系统包括传统的个人计算机20等，它包括处理单元21、系统存储器22和将包括系统存储器的各种系统组件耦合到处理单元21的系统总线23。系统总线23可以是若干种总线结构的任一种，包括存储总线或存储控制器、外围总线、以及使用各种总线体系结构的任一种的局部总线。系统存储器包括只读存储器(ROM)24和随机访问存储器(RAM)25。基本输入/输出系统26(BIOS)包含如在启动时帮助在个人计算机20的诸元件之间传输信息的基本例程，存储在ROM 24中。个人计算机20还可包括读写硬盘(未示出)的硬盘驱动器27、读写可移动磁盘29的磁盘驱动器28、读写如CDROM或其它光介质的可移动光盘29的光盘驱动器30。硬盘驱动器27、磁盘驱动器28和光盘驱动器30分别通过硬盘驱动器接口32、磁盘驱动器接口33和光盘驱动器接口34连接系统总线23。驱动器及其相关的计算机可读介质为个人计算机20提供计算机可读指令、数据结构、程序模块和其它数据的非易失存储。虽然这里描述的示例性环境采用硬盘、可移动磁盘29和可移动光盘31，本专业技术人员理解，在示例性操作环境中也能使用可存储能由计算机访问的数据的其它类型计算机可读介质，如盒式磁带、闪存卡、数字视频盘、Bernoulli盒式磁带、随机存取存储器(RAM)、只读存储器(ROM)等。类似地，示例环境还可包括许多类型的监视设备，如热敏和安全或火警系统，及其它信息来源。

若干程序模块能存储在硬盘、磁盘29、光盘31、ROM 24或RAM 25中，包括操作系统35、一个或多个应用程序36、其它程序模块37和程序数据38。用户能通过如键盘40和定位设备42等输入设备将命令和信息输入到个人计算机20。其它输入设备(未示出)可包括麦克风、操纵杆、游戏垫、圆盘式卫星天线、扫描仪等。这里和其它输入设备常通过耦合到系统总线的串行接口46连接到处理单元21，但也可通过其它接口连接，如并行口、游戏口或通用串行总线(USB)。监视器47或其它类型的显示设备也通过如视频适配器48的接口连接到系统总线23。除监视器47以外，个人计算机通常包括如话筒和打印机等其它外围输出设备(未示出)。图1的示例系统还包括主适配器55、小型计算机系统接口(SCSI)总线56和连接到SCSI总线的外部存储设备62。

个人计算机20可使用到如远程计算机49的一个或多个远程计算机的逻辑连接在网络环境中操作。远程计算机49可以是另一台个人计算机、服务器、路由器、网络PC、对等设备或其它公共网络节点，并通常包括以上对个人计算机20描述的许多或所有元件，虽然在图1中只示出存储器存储设备50。图1中画出的逻辑连接包括局域网(LAN)51和广域网(WAN)52。那样的网络环境常见于办公室、企业范围计算机网络、内联网和因特网。

在LAN网络环境中使用时，个人计算机20通过网络接口或适配器53连接到LAN51。在WAN网络环境中使用时，个人计算机20通常包括调制解调器54或用于通过如因特网等广域网52建立通信的其它装置。内置或外接的调制解调器54通过串行端口接口46连接系统总线23。在网络环境中，相对个人计算机20画出的程序模块或其部分可存储在远程存储器存储设备中。可以理解，示出的网络连接是示例性的，可使用在计算机之间建立通信链路的其它装置。

如图2的框图所示，计算机系统200能被粗略地分成三个组件组：硬件组件202、硬件/软件接口系统组件204、以及应用程序组件206(在这里某些上下文中也称为“用户组件”或“软件组件”)。

回到图1，在计算机系统的各种实施例中，硬件组件202可包括中央处理单元(CPU)21、存储器(ROM 24和RAM 25)、基本输入/输出系统(BIOS)26、以及各种输入/输出(I/O)设备，如键盘40、鼠标42、监视器47、和/或打印机(未示出)等。硬件组件202包括计算机系统200的基本物理基础结构。

应用程序组件206包括各种软件程序，包括但不限于编译器、数据库系统、文件处理程序、商业程序、视频游戏等。应用程序提供计算机资源用于为各种用户(机器、其它计算机系统和/或最终用户)解决问题、提供解决方案和处理数据的手段。

硬件/软件接口系统组件204包括(在某些实施例中可以仅包括)操作系统，在大多数情况后者本身包括外壳和内核。“操作系统”(OS)是启动担当在应用程序和计算机硬件之间的中介的特殊程序。硬件/软件接口系统组件204还可包括虚拟机管理器(VMM)、公用语言运行库(CLR)或其功能等效物、Java虚拟机(JVM)或其功能等效物、或在计算机系统中的操作系统处或操作系统外的其它软件组件。硬件/软件接口系统的目的是提供用户能在其中执行应用程序的环境。任何硬件/软件接口系统的目标是使计算机系统便于使用，以及以有效的方式利用计算机硬件。

硬件/软件接口系统一般在启动时被加载到计算机系统，并随后管理在计算机系统中所有应用程序。应用程序通过经由应用程序接口(API)请求服务来与硬件/软件接口系统交互。某些应用程序使最终用户能通过如命令语言或图形用户界面(GUI)与硬件/软件接口系统交互。

硬件/软件接口系统传统上执行应用程序的各种服务。在多个程序同时运行的多任务硬件/软件接口系统中，硬件/软件接口系统确定哪些应用程序以什么次序运行，以及在切换到另一应用程序之前以供轮流对每个应用程允许多少时间。硬件/软件接口系统还管理在多个应用程序之间内部存储器的共享，并处理来往于如硬盘、打印机和拨号端口等附加的硬件设备的输入和输出。硬件/软件接口系统还将有关操作状态和可能发生的任何错误的消息发送到每个应用程序(在某些情况下到最终用户)。硬件/软件接口系统也能下传(offload)批处理作业(如打印)的管理，使得启动的应用程序能摆脱此工作并重新开始其它处理和/或操作。在能提供并行处理的计算机上，硬件/软件接口系统还管理划分程序，使得它同时在多个处理器上运行。

硬件/软件接口系统外壳(这里简称“外壳”)是到硬件/软件接口系统的交互式最终用户界面。(外壳也称为“命令解释器”，或在一个操作系统中称为“操作系统外壳”)。外壳是可直接由应用程序和/或最终用户访问的硬件/软件接口系统的外层。与外壳相反，内核是直接与硬件组件交互的硬件/软件接口系统的最内层。

虽然可构想本发明的许多实施例尤其适用于计算机化的系统，然而在本说明中不意味着将本发明限于那些实施例。相反，这里使用的术语“计算机系统”旨在包括能存储和处理信息和/或能使用存储的信息控制设备本身的行为或执行的任何和所有设备，而不管那些设备本质上是否为电子的、机械的、逻辑的、或虚拟的。

B.传统的基于文件的存储

在当今大多数计算机系统中，“文件”是可存储信息的单元，它可包括硬件/软件接口系统和应用程序、数据集等。在所有现代硬件/软件接口系统中(Windows，Unix，Linux，MacOS，虚拟机系统等)，文件是能由硬件/软件接口系统处理的基本的分立(可存储和可检索)信息单元。文件组通常被组织成“文件夹”。在MicrosoftWindows、Macintosh OS和其它硬件/软件接口系统中，文件夹是能作为单个信息单元被检索、移动和处理的文件的集合。这些文件夹进而被组织成称为“目录”(在后面详细讨论)的基于树形的分层结构排列。在如Dos、z/OS和大多数基于Unix的操作系统的其它硬件/软件接口系统中，术语“目录”和/或“文件夹”是可交替使用的，早期的Apple计算机系统(如Apple IIe)使用术语“类别”来代替目录；然而在这里使用时所有这些术语被看成是同义语并可交替使用，并旨在还包括对分层信息存储结构及其文件夹和文件组件的所有其它等价术语的引用。

传统上，目录(又名文件夹的目录)是基于树形的分层结构，其中文件被组合成文件夹，文件夹进而按包括目录树的相对节点位置排列。例如，如图2A所示，基于DOS的文件系统的基本文件夹(或“根目录”)212可包括多个文件夹214，其每一个可以还包括另外的文件夹(如特定文件夹的“子文件夹”)216，而这些的每一个又包括另外的文件夹218，直到无限。这些文件夹的每一个可具有一个或多个文件220，虽然在硬件/软件接口系统级上，文件夹中的各个文件除了它们在树形分层结构中的位置外没有什么共同点。不奇怪，将文件组织到文件分层结构的方法间接地反映了用于存储这些文件的典型存储介质(如硬盘、软盘、CD-ROM等)的物理组织。

除上述以外，每个文件夹是对其子文件夹和其目录的容器—即，每个文件夹拥有其子文件夹和文件。例如，当文件夹被硬件/软件接口系统删除时，该文件夹的子文件夹和文件也被删除(在每个子文件夹的情况下还递归地包括它自己的子文件夹和文件)。同样，每个文件一般只由一个文件夹拥有，并且虽然文件能被拷贝且副本位于不同的文件夹，文件的副本本身是不同且独立单元，它与原始文件无直接连接(如对原始文件的改变在硬件/软件接口系统级上不反映到副本文件)。因此在这方面，文件和文件夹在本质上是“物理的”，因为文件夹类似于物理容器来处理，而文件作为这些容器中不同且独立的物理元素来处理。

II.用于组织、搜索和共享数据的WINFS存储平台

本发明结合通过引用结合于此的发明针对用于组织、搜索和共享数据的存储平台。本发明的存储平台扩展和拓宽了数据平台，超越上文讨论的文件系统及数据库系统，并被设计成存储所有类型的数据，包括称为项目的新格式的数据。

A.词汇表

在这里及在权利要求书中使用的术语有下列意义：

·“项目”是能存储硬件/软件接口系统可访问的信息的单元，不象简单文件，它是具有由硬件/软件接口系统外壳展现给最终用户的所有对象共同支持的基本属性集的对象。项目还具对所有项目类型共同支持的属性和关系，包括允许引入新属性和关系的特征(在下面详细讨论)。

·“操作系统”(OS)是扮作应用程序和计算机硬件之间的中介的特殊程序。在大多数情况下，操作系统包括外壳和内核。

·“硬件/软件接口系统”是软件、或硬件及软件的组合，它起着在计算机系统的底层硬件组件和在计算机系统上执行的应用程序之间的接口的作用。硬件/软件接口系统通常包括(在某些实施例中只包括)操作系统。硬件/软件接口系统还能包括虚拟机管理器(VMM)、公用语言运行库(CLR)或其功能等效物，Java虚拟机(JVM)或其功能等效物、或在计算机系统的操作系统处或除操作系统外的其它软件组件。硬件/软件接口系统的目的是提供用户能执行应用程序的环境。任何硬件/软件接口系统的目标是使计算机系统便于使用，并以有效方式利用计算机硬件。

B.存储平台综述

参考图3，存储平台300包括在数据库引擎314上实现的数据存储302。在一个实施例中，数据库引擎包括带有对象关系扩展的关系型数据库引擎。在一个实施例中，关系型数据库引擎314包括Microsoft SQL Server关系型数据库引擎。数据存储302实现支持数据的组织、搜索、共享、同步和安全的数据模型304。在如模式340等模式中描述特定的数据类型，并且存储平台300提供用于采用这些模式并用于扩展这些模式的工具346，这在后面详述。

在数据存储302中实现的改变跟踪机制306提供跟踪数据存储的改变的能力。数据存储302还提供安全能力308和升级/降级能力310，均在后文详述。数据存储302还提供一组应用程序接口312，以向利用该存储平台的其它存储平台组件和应用程序(如应用程序350a，350b和350c)展现数据存储302的能力。本发明的存储平台还包括应用程序接口(API)322，使如应用程序350a，350b，和350c等应用程序能访问存储平台的所有上述功能并能访问在模式中描述的数据。应用程序能结合如OLE OB API324和Microsoft Windows Win 32 API 326等其它API来使用存储平台API 322。

本发明的存储平台300能向应用程序提供各种服务，包括便于在用户或系统之间共享数据的同步服务330。例如，同步服务330允许与具有与数据存储302相同格式的其它数据存储340的互操作，并访问具有其它格式的数据存储342。存储平台300还提供允许数据存储302与如Windows NTFS文件系统318等现有文件系统的互操作的文件系统能力。在至少某些实施例中，存储平台320还能向应用程序提供另外的能力，以允许对数据起作用并允许与其它系统的交互。这些能力可体现在如Info Agent服务334和通知服务332等附加服务328的形式中，以及体现在其它实用程序336的形式中。

在至少某些实施例中，存储平台以计算机系统的硬件/软件接口系统来实施，或形成其完整的一部分。例如而非限制，本发明的存储平台能用操作系统、虚拟机管理器(VMM)、公用语言运行库(CLR)或其功能等效物、或Java虚拟机(JVM)或其功能等效物来实施，或形成其完整的一部分。通过其公用的存储基础和模式化的数据，本发明的存储平台使消费者、知识工人和企业作能够更有效地进行应用程序的开发。它提供了丰富和可扩展的编程表面区域，不仅可得到内含在其数据模型中的能力，还能包括和扩展现有文件系统和数据库访问方法。

在上述描述中及在各种附图中，本发明的存储平台300可称作“WinFs”。然而使用此名字指存储平台仅是为了描述方便，并不试图作出如此限制。

C.数据模型

本发明的存储平台300的数据存储302实现一种数据模型，它支持对驻留在数据存储中的数据的组织、搜索、共享、同步和安全。在本发明的数据模型中，“项目”是存储信息的基本单元。该数据模型提供一种机制，用于声明项目和项目的扩展、用于建立在项目之间的关系、以及用于将项目组织到项目文件夹和类别中，下面将更充分描述。

该数据模型依赖于两个原语机制：类型和关系。类型是提供支配类型的实例的形式的格式的结构。格式被表达成属性的有序组。属性是给定类型的值或一组值的名字。例如，USPostalAddress(美国邮政地址)类型具有属性Street(街道)、City(城市)、Zip(邮编)、State(州)，其中Street、City和State是String类型，而Zip是Int32类型。Street可以是多值(即一组值)，允许地址对Street属性具有一个以上值。系统定义能在其它类型构造中使用的某些原语类型，包括String、Binary、Boolean、Int16、Int32、Int64、Single、Double、Byte、DateTime、Decimal和GUID。可使用任何原语类型(带有下面注释的某些限制)或任何构造的类型来定义类型的属性。例如，Location(位置)类型可定义具有属性Coordinate(座标)和Address(地址)，其中Address属性是上述类型USPostalAddress。属性也可以是必需的或可任选的。

关系可被声明并表示两个类型的实例集之间的映射。例如，可以有在Person(个人)类型和Location类型之间声明的关系，称为LivesAt(生活在)，它确定什么人生活在什么位置。关系具有名和两个端点，即源端点和目标端点。关系也可具有属性的有序集。源端点及目标端点均具有名和类型。例如，LivesAt关系具有称为类型Person的Occupant(居民)的源和称为类型Location的Dwelling(住房)的目标，且此外具有属性StartDate(起始日期)和EndDate(终止日期)，表示该居民生活在该住房的时间段。注意，随时间推移，个人能生活在多个住房，且住房可有多个居民，所以放置StartDate和EndDate信息的最可能的地方是在关系本身处。

关系定义了在由作为端点类型给出的类型约束的实例之间的映射。例如LivesAt关系不能是其中Automobile(汽车)是Occupant(居民)的关系，因为Automobile不是Person。

数据模型允许定义类型间的子类型—超类型关系。也称为基本类型关系的子类型—超类系型关系以如下方式定义，若类型A是类型B的基本类型，则必须是B的每个实例也是A的实例的情况。另一种表达的方法是符合B的每个实例必须符合A。例如，若A具有String类型的属性Name(名字)，而B具有Int16类型的属性Age(年龄)，则得出，B的任何实例必须兼有Name和Age。类型的分层结构可被设想成带有在根上的单个超类型的树。根的分枝提供第一级子类型，该级分枝提供第二级子类型，如此等等，直到本身不再具有任何子类型的叶端(leaf-most)子类型。树不限于统一深度，但不能包含任何回路。给定的类型可具有零个或许多子类型和零个或一个超类型。给定实例可最多符合一个类型以及该类型的超类型。换言之，对树中任一级处给定的实例，该实例最多可符合该级上的一个子类型。如果一类型的实例必须也是该类型的子类型的实例，则该类型可说成是抽象。

1.项目

项目是可存储的信息的单元，不象简单的文件，它是具有由存储平台向最终用户或应用程序展现的所有对象共同支持的基本属性集的对象。项目也具有所有项目类型共同支持的属性和关系，包括如下所述允许引入新的属性和关系的特征。

项目是公用操作的对象，如拷贝、删除、移动、打开、打印、备份、恢复、复制等。项目是能被存储和检索的单元，且由存储平台处理的可存储信息的所有形式作为项目、项目的属性、或项目之间的关系存在，其每个在下面更详细讨论。

项目旨在表示显示的且容易理解的数据单元，如联系人(Contacts)、人(People)、服务(Services)、位置(Locations)、(各种类型的)文档(Documents)等。图5A是示出项目的结构的框图。该项目的不合格的名是“Location”。该项目的合格名是“Core.Location”，它表明，此项目结构被定义成Core(核心)模式中的特定类型的项目(Core模式在下面详细讨论)。

Location项目具有多个属性，包括EAddress(电子邮件地址)、MetropolitanRegion(都市地区)、Neighborhood(街坊)、和PostalAddress(邮政地址)。每个项目的特定类型属性紧跟属性名地表示，并用冒号(“：”)与属性名分开。在类型名的右边，对该属性类型允许的值的数量在方括号(“[]”)之间表示，其中冒号(“：”)右边的星号(“*”)表示未规定的和/或无限制的数量(“许多”)。冒号右边的“1”表明最多一个值。冒号左边的零(“0”)表明该属性是可任选的(可以完全没有值)。冒号左边的“1”表明必须至少有一个值(该属性是必须的)。Neighborhood和MetropolitanRegin均是“nvarchar”类型(或等效类型)，它是预定义的数据类型或“简单类型”(这里用缺少大写来表示)。然而EAddress和PostalAddress分别是类型EAddress和PostalAddress的已定义类型或“复杂类型”(这里用大写标记)的属性。复杂类型是从一个或多个简单数据类型和/或从其它复杂类型导出的类型。一个项目的属性的复杂类型还构成”嵌套元素“，因为复杂类型的细节嵌套入直接项目中以定义其属性，而属于这些复杂类型的信息用具有这些属性的项目来维持(在该项目的边界内，如后面讨论)。类型的这些概念是众知的，且容易被本专业技术人员理解。

图5B是示出复杂属性类型PostalAddress和EAddress的框图。PostalAddress属性类型定义，属性类型PostalAddress的项目可期望有零个或一个City(城市)值、零个或一个Country Code(国家代码)值、零个或一个MailStop(国家代码)值、和任何数量(零到许多)PostalAddress类型等等。以此方式，定义了一项目中的特定属性的数据的形状。EAddress属性类型如所示类似地定义。虽然这里在本申请中可任选地使用，表示在Location项目中复杂类型的另一方法是用其中列出的每个复杂类型的各个属性得出该项目。图5C是示出Location项目的框图，在其中进一步描述其复杂类型。然而应该理解，在此图5C中Location项目的另一种表示恰是对图5A中示出的同一个项目。本发明的存储平台还允许子分类(subtyping)，从而一个属性类能是另一个的子类型(其中一个属性类继承另一个父属性类型的属性)。

类似于但不同于属性及它们的属性类型，项目继承性地表示其自己的Item(项目)类型，它也是子分类的主题。换言之，本发明的若干实施例中的存储平台允许一个项目是另一个项目的子类型(从而一个项目继承另一个父项目的属性)。此外，对本发明的各种实施例，每个项目是“Item”项目类型的子类型，后者是在基础模式中找到的第一和基本的项目类型(基础模式也在后面详细讨论)。图6A示出一项目(在此实例中为Location项目)为在基础模式中找到的Item项目类型的子类型。在此图中，箭头表示Location项目(如所有其它项目)是Item项目类型的子类型。作为从中导出所有其它项目的基本项目的Item项目类型具有若干如ItemId的重要属性和各种时间标记，从而定义了操作系统中所有项目的标准属性。在本图中，Item项目类型的这些属性被Location所继承，并从而成为Location的属性。

表示从Item项目类型继承的Location项目中属性的另一种方法是用来自其中列出的父项目的每个属性类型的各个属性得出Location。图6B是示出Location项目的框图，其中除了其直接属性外描述其继承的类型。应注意和理解，此项目是图5A中示出的同一项目，虽然在本图中，Location用所有其属性示出，包括直接属性(在本图及图5A中示出)和继承属性(在本图中示出但未在图5A中示出)(而在图5A中，通过用箭头示出Location项目是Item项目类型的子类型来引用这些属性)。

项目是独立的对象，因而若删除一项目，也删除项目的所有直接和继承的属性。类似地，当检索一项目时，检索的是该项目及其所有直接和继承的属性(包括属于其复杂属性类型的信息)。本发明的某些实施例可使人们能在检索特定项目时请求属性的子集；然而对许多那样的实施例默认的是在检索时向项目提供所有其直接和继承的属性。此外，项目的属性也能通过添加新的属性到该项目的类型的现有属性而加以扩展。这些“扩展”其后是该项目的真实属性，且该项目类型的子类型可自动地包括扩展属性。

项目的“边界”由其属性(包括复杂属性类型、扩展等)来表示。项目的边界也表示在项目上执行的操作的限制，包括拷贝、删除、移动、创建等。例如在本发明的若干实施例中，当拷贝一项目时，在该项目边界之内的所有内容也被拷贝。对每个项目，边界包括下列：

·项目的项目类型，且若该项目是另一项目的子类型(如在所有项目从基础模式的单个项目和项目类型导出的本发明的若干实施例的情况下)，是任何适用的子类型信息(即属于父项目类型的信息)。若要拷贝的原始项目是另一项目的子类型，该副本也能是该相同项目的子类型。

·项目的复杂类型属性和扩展(如果有的话)。若原始项目具有复杂类型(原来的或扩展的)的属性，副本也能具有相同的复杂类型。

·在“所有权关系”上的项目的记录，即，本项目(“拥有项目”)拥有什么其它项目(“目录项目”)的项目拥有列表。这特别关系到下面充分讨论的项目文件夹和下面说到的所有项目必须至少属于一个项目文件夹的规则。此外，关于嵌入项目(下列更充分讨论)，一个嵌入项目被认为是其中嵌入如拷贝、删除等操作的项目的一部分。

2.项目标识

在全局项目空间中用ItemID唯一地标识项目。Base.Item类型定义了存储该项目身份的类型GUID的字段ItemID。一项目必须在数据存储中准确只有一个身份。

项目引用是包含定位和标识项目的信息的数据结构。在该数据模型中，定义名为ItemReference的抽象类型，从中导出所有项目引用类型。ItemReference(项目引用)类型定义了名为Resolve(解析)的虚拟方法。Resolve方法解析ItemReference并返回一项目。此方法被ItemReference的具体子类型所覆盖，后者实现给定一引用时检索项目的功能。调用Resolve方法作为存储平台API 322的一部分。

ItemIDReference(项目ID引用)是ItemReference的子类型。它定义了Locator(定位器)和ItemID字段。Locator字段命名(即标识)项目的域。它由能将Locator的值解析到项目域的定位器解析方法来处理。ItemID字段是ItemID类型。

ItemPathReference(项目路径引用)是定义Locator和Path(路径)字段的ItemReference的特殊化。Locator字段标识一项目域。它由能将Locator的值解析到项目域的定位器解析方法来处理。Path字段包含以由Locator提供的项目域为根的存储平台名字空间中的(相对)路径。

不能在集合运算中使用此类引用。引用一般必须通过路径解析过程来解析。存储平台API 322的Resolve方法提供此功能。

上面讨论的引用形式通过图11示出的引用类型分层结构表示。从这些类型继承的另外引用类型能在模式中定义。它们能在关系声明中用作目标字段的类型。

3.项目文件夹和类别

如下面将更充分讨论的，项目组能组织成称为项目文件夹(不要与文件的文件夹混淆)的特殊项目。然而不象大多数文件系统，一个项目可属于多个项目文件夹，使得当一个项目在一个项目文件夹中被访问和修订时，此修订的项目随后能直接从另一项目文件夹访问。实质上，虽然对一个项目的访问可从不同的项目文件夹发生，事实上真正访问的是同一个项目。然而，一个项目文件夹不必拥有其所有成员项目，或简单地结合其它文件夹共同拥有项目，使得一个项目文件夹的删除不必要导致项目的删除。然而在本发明的若干实施例中，一个项目必须至少属于一个项目文件夹，使得如果特定项目的唯一文件夹被删除，则对某些实施例，该项目被自动被删除，或在另外实施例中，该项目自动地成为默认项目文件夹的成员(“TrashCan(垃圾箱)”文件夹在概念上类似于在各种基于文件和文件夹的系统中使用的类似名字文件夹。)

如下面更充分讨论的，项目也可属于基于共同描述的特征的类别，特征如：(a)项目类型(或类型)，(b)特定的直接或继承的属性(或属性)，或(c)对应于项目属性的特定值(或值)。例如，包括个人联系人信息的特定属性的项目可自动属于联系人(Contact)类别，具有联系人信息属性的任何项目看来也自动属于此类别。同样，具有“New York City(纽约市)”值的位置属性的任何项目可自动属于纽约市类别。

类别在概念上不同于项目文件夹之处在于，项目文件夹可包括互相无关的项目(即无共同的描述的特征)，而在类别中的每个项目具有对该类别描述的共同类型、属性或值(“共同性”)，正是这个共同性形成对它与该类别中其它项目或那些项目之间的关系的基础。此外，虽然在特定文件夹中的项目的成员资格基于该项目的任何特定方面不是强制的，然而对某些实施例，具有在分类上与一类别相关的共同性的所有项目在硬件/软件接口系统级上可自动地成为该类别的成员。概念上，类别也能看作虚拟项目文件夹，其成员资格基于特定查询(如在数据库的上下文中)的结果，而满足此查询的条件(由类别的共同性确定)的项目应构成该类别的成员资格。

图4示出在项目、项目文件夹和类别之间的结构关系。多个项目402、404、406、408、410、412、414、418和420是各个项目文件夹422、424、426、428和430的成员。某些项目属于一个以上项目文件夹，如项目402属于项目文件夹422和424。某些项目，如项目402、404、406、408、410和412也是一个或多个类别432、434和436的成员，而其它项目，如项目44，416，418和420可以不属于任何类别(虽然这大部分不象在某些实施例中，其中具有任何属性自动暗示类别中的成员资格，因此在那样实施例中为了不是任何类别的成员，项目应完全地无特征)。与文件夹的分层结构相反，类别和项目文件夹均有更像如所示的有向图的结构。在任何情况下，项目、项目文件夹和类别都是项目(尽管是不同的项目类型)。

与文件、文件夹和目录相反，本发明的项目、项目文件夹和类别的特征在本质上不是“物理的”，因为它们不具有物理容器的概念上的等价性，因而项目可存在于一个以上那样的位置。项目存在于一个以上项目文件位置以及被组织成类别的能力提供了在硬件/软件接口级上增强和丰富程度的数据处理及存储结构能力，超越了在本领域中当前可得到的能力。

4.模式

a)基础模式

为了提供创建和使用项目的通用基础，本发明的存储平台的各实施例包括建立用于创建和组织项目及属性的概念性框架的基础(Base)模式。基础模式定义了某些特定类型的项目和属性，以及从中进一步导出子类型的这些特定基本类型的特征。使用此基础模式使程序员能在概念上将项目(及其各自的类型)与属性(及其各自的类型)加以区别。此外，基础模式列出所有项目可拥有的基本属性集，因为所有项目(及其对应的项目类型)是从基础模式的此基本项目(及其对应的项目类型)导出。

如图7所示，对于本发明的若干实施例，基础模式定义三个顶层类型：Item(项目)、Extension(扩展)和PropertyBase(属性基础)。如图所示，通过此基本“Item”项目类型的属性定义了项目类型。相反，顶层属性类型“PropertyBase”没有预定义的属性，仅是一个锚位(anchor)，从中导出所有其它属性，并通过它所有导出的属性类型互相联系(共同从单个属性类型导出)。Extension类型属性定义该扩展扩展了哪个项目，并定义将一个扩展与另一个项目相区别的标识，因为一个项目可具有多个扩展。

ItemFolder(项目文件夹)是Item项目类型的子类型，除了从Item继承的属性外，它表征用于建立到其成员(如果有的话)的关系，尽管Identitykey(身份关键字)和Property(属性)均是PropertyBase的子类型。CategoryRef(目录引用)进而是IdentityKey的子类型。

b)核心模式

本发明的存储平台的各种实施例还包括为顶层项目类型结构提供概念框架的核心(Core)模式。图8A是示出核心模式中的项目的框图，而图8B是示出核心模式中属性类型的框图。在带不同扩展名(*.com、*.exe、*.bat、*.sys等)的文件和在基于文件和文件夹系统中其它准则之间作出的区分是类似于核心模式的功能。在基于项目的硬件/软件接口系统中，核心模式定义了一组核心项目类型，它们直接(按项目类型)或间接地(按项目子类型)将所有项目特征化成基于项目的硬件/软件接口系统理解并能以预定或可预计的方式直接处理的一个或多个核心模式项目类型。预定的项目类型反映了在基于项目的硬件/软件接口系统中最常用的项目，且因此通过理解这些包括核心模式的预定项目类型的基于项目的硬件/软件接口系统获取有效性级别。

在某些实施例中，核心模式是不可扩展的，即，没有另外的类型可直接从基础模式中的项目类型子分类，除非作为核心模式的一部分的特定的预定导出的项目类型。通过禁止对核心模式的扩展(即，通过禁止向核心模式添加新的项目)，存储平台托管核心模式项目类型的使用，因为每个后续的项目类型必须是核心模式项目类型的子类型。此结构允许在保持具有一组预定的核心项目类型的益处的同时在定义另外项目类型时有合理程度的灵活性。

参考图8A，对本发明的各种实施例，由核心模式支持的特定项目类型可包括下列的一个或多个：

·Category(类别)：此项目类型(及从中导出的子类型)的项目代表在基于项目的硬件/软件接口系统中的有效类别。

·Commodity(物品)：作为值的可标识事物的项目。

·Device(设备)：具有支持信息处理能力的逻辑结构的项目。

·Document(文档)：具有不能由基于项目的硬件/软件接口系统解释而相反由对应于文档类型的应用程序解释的内容的项目。

·Event(事件)：记录环境中某些发生事件的项目。

·Location(位置)：代表物理位置(如地理位置)的项目。

·Message(消息)：在两个或更多主体(下面定义)之间通信的项目。

·Principal(主体)：具有除ItemId之外的至少一个肯定可验证身份(如，个人、组织、组、家庭、作者、服务等的标识)的项目。

·Statement(语句)：具有关于环境的特定信息的项目，包括但不限于：政策、预订、凭证等。

类似地参考图8B，由核心模式支持的特定属性类型可包括下列的一个或多个：

·Certificate(证书)(从基础模式中的基本PropertyBase类型导出)

·PrincipalIdentityKey(主体身份关键字)(从基础模式中的IdentityKey类型导出)

·PostalAddress(邮政地址)(从基础模式中Property类型导出)

·RichText(多信息文本)(从基础模式中Property类型导出)

·EAddress(电子邮件地质)(从基础模式中Property类型导出)

·IdentitySecnrityPackage(身份安全包)(从基础模式中Relationship类型导出)

·RoleOccupancy(居民角色)(从基础模式中Relationship类型导出)

·BasicPresence(基础存在)(从基础模式中Relationship类型导出)

这些项目和属性按在图8A和图8B中列出的各自属性进一步描述。

5.关系

关系是二元关系，其中一个项目被指定为源，另一个被指定为目标。源项目和目标项目通过关系相联系。源项目一般控制关系的生命周期。即，当源项目被删除，项目之间的关系也被删除。

关系被分类成：包含(Containment)和引用(Reference)关系。包含关系控制目标项目的生命周期，而引用关系不提供任何生命周期管理语义。图12示出关系分类的方式。

包含关系又被分类成持有(Holding)和嵌入(Embedding)关系。当对一个项目的所有持有关系被移除，该项目被删除。持有关系通过引用计数机制控制目标。嵌入关系能够对复合项目建模，并能被看作排他的持有关系。一个项目能是一个或多个持有关系的目标；但一个项目只能是一个嵌入关系的目标。作为嵌入关系的目标的项目不能是任一其它持有或嵌入关系的目标。

引用关系不控制目标项目的生命周期。它们可以是摇摆不定的—目标项目可以不存在。引用关系能用于在全局项目名字空间的任何处(即，包括远程数据存储)建模对项目的引用。

获得一项目不自动取得某关系，应用程序必须明确地请求项目的关系。此外，修改关系不修改源或目标项目；类似地，添加关系不影响源/目标项目。

a)关系声明

显式的关系类型用下列元素定义；

·在Name(名字)属性中指定关系名

·下列之一的关系类型：持有、嵌入、引用。这是在Type(类型)属性中指定的。

·源和目标端点。每个端点指定所引用项目的名和类型。

·源端点字段一般是ItemID(项目ID)类型(未声明)，而必须引用在与关系实例同一数据存储中的项目。

·对持有和嵌入关系，目标端点字段必须是ItemIDReference(项目ID引用)类型，且它必须引用在与关系实例相同存储中的项目。对引用关系，目标端点能是任何ItemReference(项目引用)类型，并能引用在其它存储平台数据存储中的项目。

·能可任选地声明标量或PropertyBase(属性基础)类型的一个或多个字段。这些字段能包含与该关系相关联的数据。

·关系实例被存储在全局关系表中。

·每个关系实例唯一地由组合(源ItemID、关系ID)标识。对所有源自给定项目的关系，在给定的源ItemID中关系ID是唯一的，而不管它们的类型。

源项目是关系的拥有者。而被指定为拥有者的项目控制关系的生命周期，关系本身和与它们相关的项目分开。存储平台API 322提供用于展现与项目相关联的关系的机制。

这里是一个关系声明的例子。

<Relationship Name＝″Employment″BaseType＝″Reference″>

       <Source Name＝″Employee″ItemType＝″Contact.Person″/>

       <Target Name＝″Employer″ItemType＝″Contact.Organization″

           ReferenceType＝″ItemIDReference″/>

       <Property Name＝″StartDate″Type＝″the storage

       platformTypes.DateTime″/>

       <Property Name＝″EndDate″Type＝″the storage

       platformTypes.DateTime″/>

       <Property Name＝″Office″Type＝″the storage

       platformTypes.DateTime″/>

</Relationship>

这是引用关系的例子。若由源引用所引用的个人项目不存在，则不能创建该关系。而且若该个人项目被删除，在个人和组织之间的关系实例也被删除。然而若组织项目被删除，关系不被删除，而它是摇摆不定的。

b)持有关系

持有关系用于基于目标项目的生命周期管理来对引用计数建模。

一个项目可以是用于对项目的零个或多个关系的源端点。不是嵌入项目的项目可以是在一个或多个持有关系中的目标项目。

目标端点引用类型必须是ItemIDReference，且它必须引用在与关系实例相同的存储中的项目。

持有关系实施目标端点的生命周期管理。持有关系实例和作为目标的项目的创建是原子操作。可以创建将同一项目作为目标的另外的持有关系实例。当具有给定项目作为目标端点的最后一个持有关系实例被删除时，该目标项目也被删除。

在关系声明中指定的端点项目的类型一般在创建该关系的实例时强制。在关系建立之后端点项目的类型不能改变。

持有关系在形成项目的名字空间中起着关键作用。它们包含“Name(名字)”属性，它定义目标项目相对于源项目的名字。对所有源自给定项目的持有关系，相对名字是唯一的。从根项目开始到给定项目的相对名字的有序类表形成该项目的全名。

持有关系形成一有向非循环图(DAG)。在创建持有关系时，系统确保不产生回路，从而确保项目的名字空间形成DAG。

虽然持有关系控制目标项目的生命周期，它不控制目标端点项目的操作的一致性。目标项目在操作上独立于通过持有关系拥有它的项目。在作为持有关系的源的项目上的拷贝、移动、备份和其它操作不影响作为同一关系的目标的项目—例如，备份文件夹项目不自动地备份该文件夹中所有项目(FolderMember(文件夹成员)关系中的目标)。

下面是持有关系的例子：

<Relationship Name＝″FolderMembers″BaseType＝″Holding”>

       <Source Name＝″Folder″ItemType＝″Base.Folder″/>

       <Target Name＝″Item″ItemType＝″Base.Item″

           ReferenceType＝″ItemIDReference″/>

</Relationship>

FolderMember关系使文件夹的概念成为项目的类属集合。

c)嵌入关系

嵌入关系将目标项目的生命周期的排外控制的概念模型化。它们允许合成项目的概念。

嵌入关系实例和作为目标的项目的创建是原子操作。一个项目能是零个或多个嵌入关系的源。然而一个项目能是一个且仅是一个嵌入关系的目标。作为嵌入关系的目标的项目不能是持有关系的目标。

目标端点引用类型必须是ItemIDReference，且它必须引用在与关系实例相同数据存储中的项目。

在关系声明中指定的端点项目的类型一般在创建该关系的实例时强制。在关系建立之后端点的类型不能改变。

嵌入关系控制该目标端点的操作一致性。例如，串行化项目的操作可包括串行化所有源自该项目及所有其目标的所有嵌入关系；拷贝一项目也拷贝所有它的嵌入项目。

下面是示例声明：

<Relationship Name＝″ArchiveMembers″BaseType＝″Embedding”>

             <Source Name＝″Archive″ItemType＝″Zip.Archive″/>

             <Target Name＝″Member″ItemType＝″Base.Item″

                 ReferenceType＝″ItemIDReference″/>

             <Property Name＝″ZipSize″Type＝″the storage

             platformTypes.bigint″/>

             <Property Name＝″SizeReduction″Type＝″the storage

             platformTypes.float″/>

</Relationship>

d)引用关系

引用关系不控制它引用的项目的生命周期。尤其是，引用关系不保证目标的存在，也不保证目标的类型如关系声明中指定的那样。这意味着引用关系能是摇摆不定的。而且引用关系能引用在其它数据存储中的项目。引用关系能看作类似于网页上的链接的概念。

下面是引用关系说明的例子：

<Relationship Name＝″DocumentAuthor″BaseType＝″Reference″>

       <Sourc ItemType＝″Document″

       ItemType＝″Base.Document″/>

       <Target ItemType＝″Author″ItemType＝″Base.Author″

           ReferenceType＝″ItemIDReference″/>

       <Property Type＝″Role″Type＝″Core.CategoryRef″/>

        <Property Type＝″DisplayName″Type＝″the storage

        platformTypes.nvarchar(256)″/>

</Relationship>

在目标的端点允许任何引用类型。参与引用关系的项目可以是任何项目类型。

引用关系用于对项目之间的大多数非生命周期管理关系建模。因为不强制目标的存在，引用关系便于对松散耦合的关系建模。引用关系能用于在其它存储，包括在其它计算机上的存储中的目标项目。

e)规则和约束

下列附加规则和约束应用于关系：

·一个项目必须是(仅一个嵌入关系)或(一个或多个持有关系)的目标。一个例外是根项目。一个项目能是零个或多个引用关系的目标。

·作为嵌入关系目标的项目不能是持有关系的源。它能是引用关系的源。

·一个项目若是从文件升级，则不能是持有关系的源。它能是嵌入关系和引用关系的源。

·一个从文件升级的项目不能是嵌入关系的目标。

f)关系的排序

在一至少个实施例中，本发明的存储平台支持关系的排序。通过在基本关系定义中名为“Order(排序)”的属性完成排序。在Order字段中无唯一性约束。不保证带有同一“Order”属性值的关系的次序，然而保证，它们能排序在带较低“Order”值的关系之后并在带较高“Order”字段值的关系之前。

应用程序通过在在组合(SourceItem ID，RelationshipID，Order)上排序得到默认次序的关系。源自给定项目的所有关系实例被排序成单个集合，而不管在集合中关系的类型。然而这保证，给定类型(如，FolderMembers(文件夹成员))的所有关系是给定项目的关系集合的已排序子集。

用于处理关系的数据存储API 312实现一组支持关系的排序的操作。引入下列术语帮助解释那些操作：

·RelFirst是有序集合中带次序值OrdFirst的第一个关系；

·RelLast是有序集合带次序值OrdLast的最后一个关系；

·RelX是集合中带次序值OrdX的给定关系；

·RelPrev是集合中最接近于RelX的带小于OrdX的次序值OrdPrev的关系；以及

·RelNext是集合中最接近于RelX的带大于OrdX的次序值OrdNext的关系。

操作包括但不限于：

·InsertBeforeFirst(SourceItemID，Relationship)插入关系作为集合中的第一个关系。新关系的“Order”属性的值可小于OrdFirst。

·InsertAfterLast(SourceItemID，Relationship)插入关系作为集合中的最后一个关系。新关系的“Order”属性的值可大于OrdLast。

·InsertAt(SourceItemID，ord，Relationship)插入带有对“Order”属性指定的值的关系。

·InsertBefore(SourceItemID，ord，Relationship)在带有给定次序值的关系之前插入该关系。新的关系可被分配“Order”值，它在OrdPrev和ord之间，但不包括这两个值。

·InsertAfter(SourceItemID，ord，Relationship)在带有给定次序值的关系之后插入该关系。新的关系可被分配“Order”值，它在ord和OrdNext之间，但不包括这两个值。

·MoveBefore(SourceItemID，ord，Relationship)将带给定关系ID的关系移动到带指定“Order”值的关系之前。关系可被分配新的“Order”值，它在OrdPrev和ord之间，但不包括这两个值。

·MoveAfter(SourceItemID，ord，Relationship)将带给定关系ID的关系移动到带指定“Order”值的关系之后。该关系可被分配新的次序值，它在ord和OrdNext之间，但不包括这两个值。

如前提到，每个项目必须是项目文件夹的成员。按照关系，每个项目必须与一项目文件夹有一关系。在本发明的若干实施例中，某些关系由在诸项目之间存在的关系表示。

如对本发明的各实施例的实现，关系提供一有向的二元关系，它由一个项目(源)延伸到另一项目(目标)。关系由源项目(延伸它的项目)拥有，因此若源被移除则关系被移除(如在源项目被删除时关系被删除)。此外在某些情况下，关系可共享(共同拥有的)目标项目的拥有权，且那样的拥有权仅可反映在关系的IsOwned(被拥有)属性(或其等效属性)中(如图7对关系属性类型所示)。在这些实施例中，创建一新的IsOwned关系自动递增该目标上的引用计数，而删除那样的关系可递减该目标项目上的引用计数。对这些特定实施例，若项目具有大于0的引用计数，则继续存在，若项目计数达到0则自动删除。再一次，项目文件夹是具有(或能具有)与其它项目的一组关系的项目，这些其它项目包括项目文件夹的成员资格。关系的其它实际实现是可能的，并由本发明构想来实现这里描述的功能。

不管实际的实现如何，关系是从一个对象到另一对象的可选择的连接。一个项目属于一个以上项目文件夹以及一个或多个类别，而不论这些项目、文件夹和类别是公有的或私有的能力是由给予基于项目的结构中的存在(或缺乏)的意义所确定的。这些逻辑关系是分配给一组关系的意义，而不论其专门用来实现这里所述功能的物理实现如何。逻辑关系是在项目及其文件夹或类别之间建立的(或相反)，因为本质上项目文件夹和类别的每一个都是特定类型的项目。因此，能象其它项目一样地对项目文件夹和类别起作用(拷贝、添加到电子邮件消息中、嵌入文档等等，而无限制)，而项目文件夹和类别能象其它项目一样使用相同的机制串行化和解串行化(导入和导出)。(例如在XML中，所有项目可具有串行化的格式，且此格同等地应用于项目文件夹、类别和项目)。

代表项目及其项目文件夹之间的关系的上述关系在逻辑上能从项目延伸到项目文件夹、从项目文件夹延伸到项目、或两者。逻辑上从一项目延伸到项目文件夹的关系表明该项目文件夹对于该项目是公有的，并与该项目共享其成员资格信息；相反，缺乏从项目到项目文件夹的逻辑关系表明该项目文件夹对该项目是私有的，且不与该项目共享其成员资格信息。类似地，逻辑上从项目文件夹延伸到项目的关系表明该项目是公有的，并可与该项目文件夹共享，而缺乏从项目文件夹延伸到项目的逻辑关系表明该项目是私有的且不能共享。因此，当向其它系统导出项目文件夹时，它是“公有”的项目，它在新的环境中共享，且当项目搜索其项目文件夹寻找其它可共享的项目时，它是“公有”的项目文件夹，它向该项目提供关于属于它的可共享项目的信息。

图9是示出项目文件夹(它本身也是项目)、其成员项目、和项目文件夹及其成员项目之间互联关系的框图。项目文件夹900具有多个项目902、904和906作为其成员。项目文件夹900具有从它本身到项目902的关系912，它表明项目902是公有的，且能与项目文件夹900、其成员904和906、和任何可访问项目文件夹900的任何其它项目文件夹、类别、或项目(未示出)共享。然而从项目902到项目文件夹项目900没有关系，这表明项目文件夹900对项目902是私有的，且不与项目902共享其成员资格信息。另一方面，项目904确实具有从它本身到项目文件夹900的关系924，这表明项目文件夹900是公有的，且与项目904共享其成员资格信息。然而没有从项目文件夹900到项目904的关系，这表明项目904是私有的，且不与项目文件夹900、其另外的成员902、906、及可访问项目文件夹900的任何其它项目文件夹、类别、或项目(未示出)共享。与其到项目902和904的关系(或没有这些关系)相反，项目文件夹900具有从其本身到项目906的关系916，且项目906具有回到项目文件夹900的关系926，一起表明项目906是公有的，且能对文件夹900、其成员902和904、和可访问项目文件夹900的任何其它项目文件夹、类别、或项目(未示出)共享，且项目文件夹900是公有的，并与项目906共享其成员资格信息。

如前讨论，在项目文件夹中的项目不需要共享共同性，因为项目文件夹未被“描述”。另一方面，类别由对所有其成员项目共同的共同性描述。因此，类别的成员资格固有地限于具有所描述的共同性的项目，且在某些实施例中，满足类别的描述的所有项目自动地成为该类别的成员。因此，尽管项目文件夹允许由其成员资格来表示不重要的类型结构，类别基于定义的共同性来允许成员资格。

当然，类别描述本质上是逻辑的，因而类别可通过类型、属性和/或值的任何逻辑表示来描述。例如，对一类别的逻辑表示可以是其成员资格，以包括具有两个属性之一或两者的项目。若这些对类别描述的属性是“A”和“B”，则该类别的成员资格可包括具有属性A而没有B的项目、具有属性B而没有A的项目、及兼有属性A和B的项目。通过逻辑运算符“OR(或)”来描述属性的逻辑表示，其中由类别描述成员组是具有属性A OR B的项目。如本领域的技术人员所理解的，也能使用类似的逻辑运算符(包括但不限于单独的“AND(和)”“XOR(异或)”和“NOT(非)”或其组合)来描述类别。

尽管在项目文件夹(未描述)和类别(已描述)之间有区别，但在本发明的许多实施例中，原则上到项目的类别关系及到类别的项目关系以上面对项目文件夹和项目的同样方法揭示。

图10是示出一类别(其本身也是项目)、其成员项目、类别及其成员项目之间的互联关系的框图。类别1000具有多个项目1002、1004和1006作为成员，所有这些都共享由类别1000描述的共同的属性、值和类型1008(共同性描述1008’)的某个组合。类别1000具有从其本身到项目1002的关系，它表明项目1002是公有的，且能与类别1000、其成员1004和1006、以及可访问类别1000的任何其它类别、项目文件夹、或项目(未示出)共享。然而，没有从项目1002到类别1000的关系，这表明类别1000对项目1002是私有的，且不与项目1002共享成员资格信息。另一方面，项目1004的确具有从其本身到类别1000的关系1024，这表明类别1000是公有的，且与项目1004共享其成员资格信息。然而，不存在从类别1000延伸到项目1004的关系，这表明项目1004是私有的，且不能与类别1000、它的其它成员1002和1006、以及可访问类别1000的任何其它类别、项目文件夹、或项目(未示出)共享。与它与项目1002和1004的关系(或没有此关系)相反，类别1000具有从其本身到项目1006的关系1016，且项目1006具有回到类别1000的关系1026，这一起表明项目1006是公有的，且能与类别1000、其项目成员1002和1004、以及可访问类别1000的任何其它类别、项目文件夹、或项目(未示出)共享，且类别1000是公有的，且与项目1006共享其成员资格信息。

最后，由于类别和项目文件夹本身是项目，且项目可以互相关系，类别可关系到项目文件夹，反之亦然，且在某些另外实施例中，类别、项目文件夹和项目可分别关系到其它类别、项目文件夹和项目。然而在各种实施例中，项目文件夹结构和/或类别结构在硬件/软件接口系统级上禁止包含回路。当项目文件夹和类别结构类似于有向图时，禁止回路的实施例类似于有向非循环图(DAG)，根据图论领域的数学定义，DAG是其中没有路径在同一顶点开始与终止的有向图。

6.可扩展性

如上所述，本存储平台旨在提供初始模式组340。然而，至少在某些实施例中，该存储平台还允许包括独立软件分销商(ISV)等顾客创建新的模式344(即新的项目和嵌套的元素类型)。本节讨论通过扩展在初始模式组340中定义的项目类型和嵌套的元素类型(或简称“元素”类型)着眼于创建该模式的机制。

较佳地，项目和嵌套元素类型的初始组的扩展如下约束：

·允许ISV引入新的项目类型，即子类型Base.Item；

·允许ISV引入新的嵌套元素类型，即子类型Base.NestedElement；

·允许ISV引入新的扩展，即子类型Base.NestedElement；但

·ISV不能子分类由存储平台的初始模式组340定义的任何类型(项目、嵌入元素、或扩展类型)。

由于由存储平台的初始模式组定义的项目类型或嵌入元素类型可能不精确地匹配ISV应用程序的需要，必须允许ISV定制该类型。这就考虑了扩展的概念。扩展是强类型的实例，但是(a)它们不能独立存在，以及(b)它们必须附属于项目或嵌套元素。

除了解决对模式可扩展性的需要之外，扩展还旨在解决“多分类”问题。在某些实施例中，因为存储平台可能不支持多继承性或重叠子类型，应用程序可以使用扩展作为模型化重叠类型实例(如文档既是合法文档又是安全文档)的方法。

a)项目扩展

为提供项目的可扩展性，数据模型还定义名为Base.Extension的抽象类型。这是扩展类型的分层结构的根类型。应用程序可以子分类Base.Extension，以创建特定的扩展类型。

在基础模式中如下定义Base.Extension类型：

<Type Name＝″Base.Extension″IsAbstract＝″True″>

   <Propety Name＝″ItemID″

           Type＝″the storage platformTypes.uniqueidentified″

           Nullable＝″false″

           MultiValued＝″false″/>

   <Property Name＝″ExtensionID″

           Type＝″the storage platformTypes.uniqueidentified″

              Nullable＝″false″

              MultiValued＝″false″/>

</Type>

ItemID字段包含与该扩展关联的项目的ItemID。带此ItemID的项目必须存在。若带给定ItemID的项目不存在，则不能创建扩展。当项目被删除，带同一ItemID的所有扩展被删除。二元组(ItemID，ExtensionID)唯一地标识了扩展实例。

扩展类型的结构类似于项目类型的结构：

·扩展类型具有字段；

·字段可以是原语或嵌套元素类型；以及

·扩展类型可被子分类。

下列限制应用于扩展类型

·扩展不能是关系的源和目标；

·扩展类型实例不能独立于项目存在；以及

·扩展类型不能用作在存储平台类型定义中的字段类型

对能与给定的项目类型关联的扩展的类型没有约束。任何扩展类型允许扩展任何项目类型。当多个扩展实例被附加到一个项目，它们在结构和行为上彼此独立。

扩展实例被分别存储并从项目访问。所有扩展类型实例可从全局扩展视图访问。能组成一有效的查询，它将返回给定类型的扩展的所有实例，而不管它们关联什么类型的项目。存储平台API提供可存储、检索和修改项目扩展的编程模型。

扩展类型可是使用存储平台的单个继承模型来子分类的类型。从一个扩展类型导出创建新的扩展类型。一个扩展的结构或行为不能覆盖或替代项目类型分层结构的结构或行为。类似于项目类型，扩展类型实例能通过与该扩展类型关联的视图直接访问。扩展的ItemID表明，它们属于哪个项目，并能用于从全局项目视图检索对应的项目对象。为操作一致性的目的，扩展被考虑成项目的一部分。拷贝/移动、备份/恢复和存储平台定义的其它常用操作可以在作为项目的一部分的扩展上操作。

考虑下述例子。在Windows类型组中定义Contact(联系人)类型。

<Type Name＝″Contact″BaseType＝“Base.Item″>

   <Property Name＝″Name″

              Type＝″String″

              Nullable＝″false″

              MultiValued＝″false″/>

   <Property Name＝″Address″

              Type＝″Address″

              Nullable＝″true″

              MultiValued＝″false″/>

</Type>

CRM(客户关系管理)应用程序开发者喜欢将CRM应用程序扩展附加到存储在存储平台中的联系人。应用程序开发者定义包含应用程序能处理的附加数据结构的CRM扩展。

<Type Name＝″CRMExtension″BaseType＝″Base.Extension″>

   <Property Name＝″CustomerID″

                    Type＝″String″

              Nullable＝″false″

              MultiValued＝″false″/>

</Type>

HR应用程序开发者希望也将附加数据附加到联系人。此数据独立于CRM应用程序数据。应用程序开发者还可创建—扩展

<Type Name=″HRExtension″EBase Type=″Base.Extension″>

   <Property Name=″EmployeeID″

              Type=″String″

              Nullable=″false″

              MultiValued=″false″/>

</Type>

CRMExtension和HRExtension是能附加到联系人项目的两个独立扩展。它们能彼此独立地创建和访问。

在上述例子中，CRMExtension类型的字段和方法不能覆盖联系人分层结构的字段和方法。应注意，CRMExtension类型的实例能被附加到不同于联系人的项目类型。

在检索联系人项目时，不自动地检索它的项目扩展。给定联系人项目，可通过查询全局扩展视图以寻找带同一ItemID的扩展来访问其有关的项目扩展。

可通过CRMExtension类型视图来访问系统中所有的CRMExtension扩展，而不论它们属于什么项目。一个项目的所有项目扩展共享同一项目id。在上述例子中，联系人项目实例和附加的CRMExtension和HRExtension实例共享同一ItemID。

下面的表总结了在Item(项目)、Extension(扩展)和NestedElement(嵌套元素)类型之间的相似性和差别：

项目、项目扩展与嵌套元素

b)扩展NestedElement类型

嵌套元素类型不用与项目类型相同的机制扩展。嵌套元素的扩展用与嵌套元素类型字段相同的机制存储和访问。

数据模型定义了名为Element(元素)的嵌套元素类型的根。

<Type Name＝″Element″

      IsAbstract＝″True″>

       <Property Name＝″ElementID″

               Type＝″the storage platformTypes.uniqueidentifier″

               Nullable＝″false″

               MultiValued＝″false″/>

</Type>

NestedElement类型从此类型继承。NestedElement元素类型另外定义—字段，它是多组元素。

<Type Name＝″NestedElement″BaseType＝″Base.Element″

   IsAbstract＝″True″>

       <Property Name＝″Extensions″

               Type＝″Base.Element″

               Nullable＝″false″

               MultiValued＝″true″/>

</Type>

NestedElement扩展在下面方面不同于项目扩展：

·嵌套元素扩展不是扩展类型。它们不属于以Base.Extension类型为根的扩展类型分层结构。

·嵌套元素扩展与该项目的其它字段一起存储，且不是全局可访问的—不能组成检索给定扩展类型的所有实例的查询。

·象存储其它嵌套元素(或项目)一样地存储这些扩展。象其它的嵌套组，NestedElement扩展被存在UDT中。它们可通过嵌套元素类型的Extension(扩展)字段来访问。

·用于访问多值属性的集合接口也用于在类型扩展组上的访问和迭代。下面的表总结和比较Item扩展和NestedElement扩展。

项目扩展与Nested Element扩展

D.数据库引擎

如上提到，数据存储在数据库引擎上实现。在本实施例中，数据库引擎包括诸如Microsoft SQL Server引擎等实现SQL查询语言、带有对象关系扩展的关系数据库引擎。本节按照本实施例，描述数据存储实现的数据模型到关系存储的映射，在逻辑API上提供由存储平台的客户机使用的信息。然而可以理解，当采用不同的数据库引擎时可采用不同的映射。确实，除了在关系型数据库引擎上实现存储平台概念数据模型之外，也可在其它类型数据库上实现，如面向对象和XML数据库。

面向对象(OO)数据库系统为编程语言对象(如C++、Java)提供持续性和事务。“项目”的存储平台概念可很好地映射到面向对象系统中的对象，虽然嵌入的集合必须添加给对象。类似继承性和嵌套元素类型等其它存储平台类型概念也映射到面向对象类型的系统。面向对象系统通常已经支持对象身份；因此，项目身份可被映射到对象身份。项目的行为(操作)很好地映射到对象方法。然而，面向对象的系统通常缺乏组织能力并在搜索方面很差。而且，面向对象的系统不提供对非结构化和半结构化数据的支持。为支持这里描述的完全存储平台数据模型，象关系、文件夹和扩展等概念需要添加到对象数据模型。此外，需要实现如升级、同步、通知和安全性等机制。

类似于面向对象的系统，基于XSD(XML模式定义)的XML数据库支持基于单继承类型的系统。本发明的项目类型系统可映射到XSD类型模型。XSD也不提供对行为的支持。项目的XSD必须增添项目的行为。XML数据库处理单个XSD文档并缺乏组织和拓宽搜索能力。如面向对象数据库那样，为支持这里描述的数据模型，如关系和文件夹等其它概念需要被结合到该XML数据库；而且需要实现如同步、通知和安全性等机制。

关于下面小节，提供少量图示以便于一般的信息揭示：图13是示出通知机制的图示。图14是示出两个事务均将新记录插入同一B树的例子的图示。图15示出数据改变检测过程。图16示出示例性目录树。图17示出其中基于目录的文件系统的现有文件夹被移动到存储平台数据存储中。

1.使用UDT的数据存储实现

在本实施例中，在一个实施例中包括Microsoft SQL Server引擎的关系型数据库引擎314支持内建的标量类型。内建的标量类型是“原生(native)”且“简单”的。它们是原生的意义是，用户不能定义他们自己的类型；它们是简单的意义是，用户不能封装复杂的结构。用户定义的类型(下文称为UDT)通过使用户能通过定义复杂的结构化类型来扩展类型系统，提供了一种用于超过或超越原生的标量类型系统的类型可扩展性的机制。一旦由用户定义，UDT能用于可以使用内建标量类型的类型系统中的任何地方。

按本发明的一个方面，存储平台模式被映射到数据库引擎存储中的UDT类。数据存储项目被映射到从Base.Item类型导出的UDT类。类似于项目，扩展也能映射到UDT类并使用继承。根扩展类型是Base.Extension，从它导出所有扩展类型。

UDT是CLR类，它具有状态(即数据字段)和行为(即例程)。使用任何受管语言(c#、VB.NET等)定义UDT。UDT方法和操作符能在T-SQL中针对该类型的实例调用。UDT能是：行中列的类型、T-SQL中例程的参数的类型、或在T-SQL中变量的类型。

存储平台模式到UDT类的映射在高级别上完全是直接的。一般而言，存储平台模式被映射到CLR名字空间。存储平台类型被映射到CLR类。CLR类的继承镜象了存储平台类型的继承，且存储平台属性被映射到CLR类属性。

2.项目映射

为了希望项目能够被全局地搜索，并在本实施例的关系型数据中支持继承以及类型可替代性，对在数据库存储中的项目存储的一种可能的实现是在带有类型Base.Item的列的单个表中存储所有项目。使用类型可替代性，能存储所有类型的项目，且可按使用Yukon的“is of(类型)”的操作符的项目类型的子类型来过滤搜索。

然而，由于在本实施例中牵涉到与这一方法相关联的额外开销，由顶级类型将各项目划分，使得每个类型“家族”的项目存储到单独的表中。在此划分模式中，对每个直接从Base.Item继承的项目类型创建一个表。如上所述，继承下面这些的类型使用类型的可替代性存储在合适的类型家族表中。只有从Base.Item的第一级继承被专门地处理。

使用一“阴影”表存储所有项目的全局可搜索属性的副本。此表可由存储平台API的Update()方法维护，通过此方法作出所有数据的改变。不象类型家族表，此全局项目表只包含该项目的顶级标量属性，而不是全UDT项目对象。全局项目表允许通过展现ItemID和TypeID(类型ID)导航到存储在类型家族表中的项目对象。ItemID通常唯一地标识数据存储中的项目。可使用这里未予描述的元数据将TypeID映射到类型名和包含该项目的视图。由于通过其ItemID寻找项目在全局项目表的上下文及其它情况下都是常用操作，因此给定了项目的ItemId，提供GetItem()函数来检索项目对象。

为便于访问和尽可能地隐藏实现的细节，项目的所有查询可以对照在上述项目的表上构建的视图进行。具体说来，对每个项目类型针对合适类型的家族表创建视图。这些类型视图可选择相关联的类型，包括子类型的所有项目。为方便起见，除了UDT对象，视图能对包括继承字段的该类型的所有顶级域展现列。

3.扩展映射

扩展非常类似于项目，且具有某些相同要求。如支持继承性的另一根类型，扩展受到存储中许多同样的考虑和折衷比较。为此，对扩展应用类似的类型家族映射，而不是单个表方法。当然，在其它实施例中，可使用单个表方法。在本实施例中，扩展通过ItemID仅与一个项目关联，并包含在项目的上下文中唯一的ExtensionID。如同项目一样，给定包括ItemID和ExtensionID对的身份，可提供一函数用于检索扩展。类似于项目类型视图，对每个扩展类型可创建视图。

4.嵌套元素映射

嵌套元素是可嵌入到项目、扩展、关系、或其它嵌套元素以形成深嵌套结构的类型。类似于项目和扩展，嵌套元素作为UDT实现，但它们存储在项目和扩展中。因此，嵌套元素没有超越它们的项目和扩展容器的映射的存储映射。换言之，在系统中没有直接存储NestedElement类型的实例的表，且没有专门用于嵌套元素的视图。

5.对象身份

在数据模型中的每一实体，即每个项目、扩展和关系具有唯一的关键字值。一个项目由其ItemId唯一地标识。扩展由合成关键字(ItemId，ExtensionId)唯一地标识。关系由合成关键字(ItemId，RelationId)标识。ItemId，ExtensionId和RelationshipId均是GUID值。

6.SQL对象命名

在数据存储中创建的所有对象可存储在从存储平台模式名字导出的SQL模式名字中。例如，存储平台基础模式(常称“基础”)可产生在“[System.Storage]”SQL模式中的类型，如“[System.Storage].Item”。产生的名字可用限定词加前缀以消除命名的冲突。在合适处可使用惊叹号(！)作为名字的每个逻辑部分的分割符。下面表概括了在数据存储用于对象的命名习惯。与用于访问数据存储中的实例的修饰的命名习惯一起列出每个模式元素(项目、扩展、关系和视图)。

对象	名字修饰	描述	例子
				主项目搜索视图	Master！Item	在当前项目域中提供项目的综述	[System.Storage].[Master！Item]
分类型的项目搜索视图	ItemType	提供来自项目和任何父类型的所有属性数据	[AcmeCorp.Doc].[OfficeDoc]
				主扩展搜索视图	Master！Extension	提供在当前项目域中所有扩展的综述	[System.Storage].[Master！Extension]
分类型的扩展搜索视图	Extension！extensionType	对扩展提供所有属性数据	[AcmeCorp.Doc].[Extension！SlickyNote]

对象	名字修饰	描述	例子
				主关系视图	Master！Relationship	提供在当前项目域中所有关系的综述	[System.Storage].[Master！Relationship]
关系视图	Relationship！relationshipName	提供所有与给定的关系相关联的数据	[AcmeCorp.Doc].[Relationship！AuthorsFromDocument]
				视图	View！viewName	基于模式视图定义提供列/类型	[AcmeCorp.Doc].[View！DocumentTitles]

7.列命名

当映射任一对象模型到存储时，由于与应用程序对象一起存储的附加信息，有可能发生命名冲突。为避免命名冲突，所有非类型的特定列(不直接映射到类型声明中的命名的属性的列)用下划线字符(_)加前缀。在本实施例中，下划线字符(_)不允许作为任何标识符属性的开始字符。此外，为统一在CLR和数据存储之间的命名，存储平台类型或模式元素的所有属性(关系等)应具有大写的第一字符。

8.搜索视图

由存储平台提供视图，用于搜索存储的内容。对每个项目和扩展类型提供SQL视图。此外，提供视图以支持关系和视图(由数据模型定义)。所有SQL视图和在存储平台中的底层表是只读的。下面将更充分描述，使用存储平台API的Update()方法可存储或改变数据。

在存储平台模式中直接定义的每个视图(由模式设计者定义，而非由存储平台自动地生成)可由命名的SQL视图[<schema-name>].[View！<view-name>]访问。例如，在模式“AcmePublisher.Books”中名为“BookSales”的视图可使用名字“[AcmePublisher.Books].[View！BookSales]来访问。因为视图的输出格式在每一视图的基础上是自定义的(由定义视图的那一方提供的任意查询确定的)，列基于模式视图定义被直接映射。

存储平台数据存储中的所有SQL搜索视图使用列的下述排序习惯：

·如ItemId、ElementId、RelationshipId等的视图结果的逻辑“关键字”列

·如TypeId等关于结果类型的元数据信息。

·改变如CreateVersion(创建版本)、UpdateVersion(更新版本)等跟踪列

·类型专用的列(声明的类型的属性)

·类型专用的视图(家族视图)也包含返回对象的对象列

每个类型家族的成员可使用一系列项目视图来搜索，在数据存储中每个项目类型有一个视图。图28是示出项目搜索视图的概念的图示。

a)项目

每个项目搜索视图对特定类型或其子类型的项目的每个实例包含一行。例如，文档的视图能返回Document(文档)、LegalDocument(合法文档)和ReviewDocument(审阅文档)的实例。给定此例，能如图29那样概念化项目视图。

(1)主项目搜索视图

存储平台数据存储的每个实例定义称为主项目视图(Master Item View)的特殊项目视图。此视图提供关于数据存储中每个项目的综述信息。视图对每个项目类型属性提供一列，其中一列描述项目的类型，若干列用于提供改变跟踪和同步信息。在数据存储中使用名字“[System.Storage].[Master！Item]”来标识主项目视图。

列	类型	描述
			ItemId	ItemId	该项目的存储平台身份
_TypeId	TypeId	该项目的TypeId-标识该项目的确切类型并能用于使用元数据类别来检索关于类型的信息
			RootItemId	ItemId	控制此项目的生命周期的第一个非嵌入先辈的ItemId
<全局改变跟踪>	…	全局改变跟踪信息
			<项目属性>	n/a	对每个项目类型属性有一列

(2)分类型的项目搜索视图

每个项目类型也具有搜索视图。类似于根项目视图，此视图还提供通过“_Item”列对项目对象的访问。在数据存储中使用名字[schemaName].[itemTypeName]标识每个分类型的项目搜索视图。例如[AcmeCorp.Dod].[OfficeDoc]。

列	类型	描述
			ItemId	ItemId	该项目的存储平台身份
<类型改变跟踪>	…	类型改变跟踪信息
			<父属性>	<属性专用>	对每个父属性有一列
<项目属性>	<属性专用>	对此类型的每个排他属性有一列
			Item	项目的CLR类型	CLR对象一声明的项目的类型

b)项目扩展

WinFs存储中的所有项目扩展也可使用搜索视图来访问。

(1)主扩展搜索视图

数据存储的每个实例定义一称为主扩展视图(Master Extension View)的特殊扩展视图。此视图提供关于数据存储中每个扩展的综述信息。该视图对每个扩展属性有一列，其中一列描述扩展的类型，而若干列用于提供改变跟踪和同步信息。使用名字“[System.Storage].[Master！Extension]”在数据存储中标识主扩展视图。

列	类型	描述
			ItemId	ItemId	与此扩展关联的项目的存储平台身份
ExtensionId	ExtensionId(GUID)	此扩展实例的id
			_TypeId	TypeId	该扩展的TypeId-标识该扩展的确切类型，并能用于使用元数据类别来检索关于该扩展的信息
<全局改变跟踪>	…	全局改变跟踪信息
			<扩展属性>	<属性专用>	对每个扩展类型属性有一列

(2)分类型的扩展搜索视图

每个扩展类型还具有搜索视图。类似于主扩展视图，此视图还提供通过_Extension列对项目对象的访问。在数据存储中使用名字[SchemaName].[Extension！extensionTypeName]标识每个分类型的扩展搜索视图。例如[AcmeCorp.Doc].[Extension！OfficeDocExt]。

列	类型	描述
			ItemId	ItemId	与此扩展关联的项目的存储平台身份
ExtensionId	ExtensionId(GUID)	此扩展实例的Id
			<类型改变跟踪>	…	类型改变跟踪信息
<父属性>	<属性专用>	对每个父属性有一列
			<扩展属性>	<属性专用>	对每个此类型的排他属性有一列
_Extension	扩展实例的CLR类型	CLR对象—声明的扩展的类型

c)嵌套的元素

所有嵌套的元素存储在项目、扩展或关系实例之中。因此，它们能通过查询合适的项目、扩展或关系搜索视图来访问。

d)关系

如上讨论，关系形成在存储平台数据存储中各项目之间链接的基本单元。

(1)主关系搜索视图

每个数据存储提供—主关系视图。此视图提供关于数据存储中所有关系实例的信息。在数据存储中使用名字“[System.Storage].[Master！Relationship]”来标识主关系视图。

列	类型	描述
			ItemId	ItemId	源端点的身份(ItemId)
RelationshipId	RelationshipId(GUID)	该关系实例的id
			_RelTypeId	RelationshiPTypeId	该关系的RelTypeId—使用元数据类别来标识该关系实例的类型
<全局改变跟踪>	…	全局改变跟踪信息
			TargetItemReference	ItemReference	目标端点的身份
_Relationship	Relationship	对此实例的Relationship对象的实例

(2)关系实例搜索视图

每个声明的关系也有返回该特定关系的所有实例的搜索视图。类似于主关系视图，此视图对该关系数据的每个属性提供命名的列。在数据存储中使用名字[schemaName].[Relationship！relationshipName]来标识每个关系实例搜索视图。例如[AcmeCorp.Doc].[Relationship！DocumentAuthor]。

列	类型	描述
			ItemId	ItemId	源端点的身份(ItemId)
RelationshipId	RelationshipId(GUID)	该关系实例的id
			<类型改变跟踪>	…	类型改变跟踪信息
TargetItemReference	ItemReference	目标端点的身份
			<源名>	ItemId	源端点身份的命名属性(ItemId的别名)
<目标名>	ItemReference或导出的类	目标端点身份的命名属性(TargetItemReference的别名和模型(cast))
			<关系属性>	<属性专用>	对每个关系定义的属性有一列

列	类型	描述
			_Relationship	关系实例的CLR类型	CLR对象—声明关系的类型

e)

9.更新

存储平台数据存储中所有视图是只读的。为创建数据模型元素(项目、扩展或关系)的新实例，或更新现有的实例，必须使用存储平台API的ProcessOperation或ProcessUpdategram方法。ProcessOperation方法是单个存储的过程，它是由消费细化拟执行的动作的“操作”的数据存储定义的。ProcessUpdategram方法是存储的过程，它采取称为“更新元素(updategram)”的一组有序的操作，它们共同细化拟执行的一组动作。

操作格式是可扩展的，并提供在模式元素上的各种操作。某些公用操作包括：

1.项目操作：

a.CreateItem(在嵌入或持有关系的上下文中创建一新的项目)

b.UpdateItem(更新一现有的项目)

2.关系操作：

a.CreateRelationship(创建引用或持有关系的实例)

b.UpdateRelationship(更新一关系实例)

c.DeleteRelationship(移除一关系实例)

3.扩展操作

a.CreateExtension(添加一扩展到现有的项目)

b.UpdateExtension(更新一现有的扩展)

c.DeleteExtension(删除一扩展)

10.改变跟踪及墓碑

如下面更充分讨论，由数据存储提供改变跟踪和墓碑服务。本节提供在数据存储中展现的改变跟踪信息的概述

a)改变跟踪

由数据存储提供的每个搜索视图包含用于提供改变跟踪信息的列；那些列对所有项目、扩展和关系视图是公用的。由模式设计者明确地定义的存储平台模式视图不自动地提供改变跟踪信息—该信息是通过在其上构建视图本身的搜索视图来间接提供的。

对数据存储中的每个元素，可从两个地方得到改变跟踪信息：“主”元素视图和“分类型的”元素视图。例如，可从主项目视图“[System.Storage].[Master！Item]”和分类型的项目视图[AcmeCorp.Document].[Document]中得到关于AcmeCorp.Document.Document项目类型的改变跟踪信息。

(1)“主”搜索视图中的改变跟踪

主搜索视图中的改变跟踪信息提供关于元素的创建和更新版本的信息、关于哪个同步伙伴创建该元素的信息、关于哪个同步伙伴最后一次更新该元素的信息、以及来自每个伙伴的用于创建和更新的版本号。用伙伴关键字来标识同步关系中的伙伴(下面描述)。类型[System.Storge.Store].ChangeTrackingInfo的名为_ChangeTrackingInfo的单个UDT对象包含所有这些信息。在System.Storage模式中定义类型。在项目、扩展和关系的所有全局搜索视图中可得到_ChangeTrackingInfo。_ChangeTrackingInfo的类型定义是：

<Type Name＝″ChangeTrackingInfo″BaseType＝″Base.NestedElement″>

 <FieldProperty Name＝″CreationLocalTS″      Type＝″SqlTypes.SqlInt64″

 Nullable＝″False″/>

 <FieldProperty Name＝″CreatingPartnerKey″      Type＝″SqlTypes.SqlInt32″

  Nullable＝″False″/>

 <FieldProperty Name＝″CreatingPartnerTS″       Type＝″SqlTypes.SqlInt64″

  Nullable＝″False″/>

 <FieldProperty Name＝″LastUpdateLocalTS″       Type＝″SqlTypes.SqlInt64″

  Nullable＝″False″/>

 <FieldProperty Name＝″LastUpdatingPartnerKey″  Type＝″SqlTypes.SqlInt32″

  Nullable＝″False″/>

 <FieldProperty Name＝″LastUpdatingPartnerTS″   Type＝″SqlTypes.SqlInt64″

  Nullable＝″False″/>

</Type>

这些属性包含下述信息：

列	描述
		_CreationLocalTS	本地机器的创建时间标记
_CreatingPartnerKey	创建此实体的伙伴的PartnerKey。若实体是本地创建的，这是本地机器的PartnerKey
		_CreatingPartnerTS	在对应于_CreatingPartnerKey的伙伴处创建此实体的时间的时间标记
_LastUpdateLocalTS	对应于本地机器的更新时间的本地时间标记
		_LastUpdatePartnerKey	最后一次更新此实体的伙伴的PartnerKey。若对该实体的最后一次更新在本地完成，则这是本地机器的PartnerKey。

列	描述
		_LastUpdatePartnerTS	在对应于_LastUpdatingPartnerKey的伙伴处更新此实体的时间的时间标记。

(2)“分类型的”搜索视图中的改变跟踪

除了提供与全局搜索视图相同信息外，每个分类型的搜索视图提供记录在同步拓扑中每个元素的同步状态的附加信息。

列	类型	描述
			<全局改变跟踪>	…	来自全局改变跟踪的信息
_ChangeUnitVersions	MultiSet<改变单元版本>	特定元素中的改变单元的版本号的描述
			_ElementSyncMetadata	ElementSyncMetadata	关于只对同步运行库感兴趣的项目的附加版本无关元数据
_VersionSyncMetadata	VersionSyncMetadata	关于只对同步运行库感兴趣的版本的附加版本专用元数据

b)墓碑

数据存储为项目、扩展和关系提供墓碑信息。墓碑视图提供一个地方中有关活动和墓碑实体两者(项目、扩展和关系)的信息。项目和扩展墓碑视图不提对对应对象的访问，而关系墓碑视图提供对关系对象的访问(在墓碑关系的情况下关系对象为空)。

(1)项目墓碑

通过视图[System.Storage].[Tombstone！item]从系统检索项目墓碑。

列	类型	描述
			ItemId	ItemId	项目的身份
_TypeID	TypeId	项目的类型
			<项目属性>	…	对所有项目定义的属性
_RootItemId	ItemId	包含此项目的第一个非嵌入项目的ItemId
			_ChangeTrackingInfo	ChangeTrackingInfo类型的CLR实例	此项目的改变跟踪信息

列	类型	描述
			_IsDeleted	BIT	这是标志，0是活动项目，1是墓碑项目
_DeletionWallclock	UTCDATETIME	按删除项目的伙伴的UTC墙钟日期时间，若该项目是活动的，它为空

(2)扩展墓碑

使用视图[System.Storage].[Tombstone！Extension]从系统检索扩展墓碑。扩展改变跟踪信息类似于为项目提供的添加了ExtensionId属性的信息。

列	类型	描述
			ItemId	ItemId	拥有该扩展的项目的身份
ExtensionId	ExtensionId	该扩展的ExtensionId
			_TypeID	TypeId	该扩展的类型
_ChangeTrackingInfo	ChangeTrackingInfo类型的CLR实例	此扩展的改变跟踪信息
			_IsDeleted	BIT	这是标志，0是活动项目，而1是墓碑扩展
_DeletionWallclock	UTCDATETIME	按删除该扩展的伙伴的UTC墙钟日期间。若该扩展是活动的，它为空

(3)关系墓碑

通过视图[System.Storage].[Tombstone！Relationship]从系统检索关系墓碑。关系墓碑信息类似于对扩展提供的信息。然而，在关系实例的目标ItemRef上提供附加信息。此外，还选择关系对象。

列	类型	描述
			ItemId	ItemId	拥有该关系的项目的身份(关系的源端点的身份)
RelationshipId	RelationshipId	该关系的RelationshipId
			_TypeID	TypeId	关系的类型

列	类型	描述
			_ChangeTrackingInfo	ChangeTrackingInfo类型的CLR实例	此关系的改变跟踪信息
_IsDeleted	BIT	这是标志，0是活动项目，而1是墓碑扩展
			_DeletionWallclock	UTCDATETIME	按删除该关系的伙伴的UTC墙钟日期时间。若该关系是活动的，它为空
_Relationship	关系的CLR实例	这是活动关系的关系对象，对墓碑的关系它为空
			TargetItemReference	ItemReference	目标端点的身份

(4)墓碑清除

为防止墓碑信息无限制地增长，数据存储提供墓碑清除任务。此任务确定什么时候可以舍弃墓碑信息。该任务计算本地创建/更新版本的界限，并随后通过舍弃所有更早的墓碑版而截断墓碑信息。

11.助手API和函数

基础映射还提供若干助手函数。提供这些函数以帮助在该数据模型上的公用操作。

a)函数[System.Storage].GetItem

//给定ItemId返回一项目对象

Item Getltem(ItemId ItemId)

b)函数[System.Storage].GetExtension

//给定ItemId和ExtensionId返回一扩展对象

Extension GetExtension(ItemId ItemId，ExtensionId ExtensionId)

c)函数[System.Storage].GetRelationship

//给定ItemId和RelationshipId返回—关系对象

Relationship GetRelationship(ItemId ItemId，Relationshipld Relationshipld)

12.元数据

有两类在存储中表示的元数据：实例元数据(项目的类型等)，和类型元数据。

a)模式元数据

模式元数据作为来自元模式的项目类型的实例存储在数据存储中。

b)实例元数据

应用程序使用实例元数据来查询项目的类型，并寻找与项目相关联的扩展。给定项目的ItemId，应用程序可查询全局项目视图，以返回该项目的类型，并使用此值来查询Meta.Type视图以返回关于该项目的声明的类型的信息。例如，

//对给定的项目实例返回元数据项目对象

SELECT m._Item AS metadatalnfoObj

FROM[System.Storage].[Item]i INNER JOIN[Meta].[Type]m ON i._Typeld＝m.ItemId

WHERE i.ItemId＝@ItemId

E.安全性

一般而言，所有可保护的对象使用图26中所示的访问掩码格式来安排访问权限。在此格式中，低16位用于对象专用的的访问权限，接着7位用于应用于大多数对象类型的标准访问权限，高4位用于指定类属访问权限，每个对象类型将其映射到一组标准且对象专用的权限。ACCESS_SYSTEM_SECURITY位对应于访问对象的SACL的权限。

在图26的访问掩码结构中，项目专用的权限被放置在对象专用权限段(低16位)。由于在本实施例中，存储平台向管理员安全性展现两组API：Win32和存储平台API，为促进存储平台对象专用权限的设计，必须考虑文件系统对象专用的权限。

在通过引用结合于此的有关专利中充分描述了用于本发明的存储平台的安全模型。在这点上，图27(部分a、b和c)画出按安全模型的一实施例，作为从现有安全区域开拓出的新的等同地保护的安全区域。

F.通知和改变跟踪

按本发明的另一方面，存储平台提供允许应用程序跟踪数据改变的通知能力。此特征主要供保持易失状态或执行数据改变事件上的业务逻辑的应用程序使用。应用程序注册在项目、项目扩展及项目关系上的通知。在提交了数据改变通知被异步地传送。应用程序可按项目、扩展和关系类型以及操作类型来过滤通知。

按一个实施例，存储平台API 322为通知提供两类接口。第一，应用程序注册由对项目、项目扩展和项目关系的改变触发的简单数据改变事件。第二，应用程序创建“监视程序”对象来监视项目、项目扩展和项目之间关系的组。在系统失败或系统离线超过预定时间之后，可保存和重新创建监视程序对象的状态。单个通知可反映多个更新。

关于此功能的附加细节能在通过引用结合于此的有关专利中找到。

G.同步

按本发明的另一方面，存储平台提供同步服务330，它(I)允许存储平台的多个实例(每个有自己的数据存储302)按一组灵活的规则来同步它们的内容的各部分，以及(ii)为第三方提供基础结构以将本发明的存储平台的数据存储与实现专有协议的其它数据源同步。

存储平台到存储平台的同步在一组参与的复制品之间发生。例如参考图3，希望在多半是在不同的计算机系统上运行的存储平台的另一实例的控制下提供在存储平台300的数据存储302和另一远程数据存储338之间的同步。该组的总的成员资格不必在任何给定时间被任何给定复制品知道。

不同的复制可以独立地(即并发地)作出改变。将同步过程定义成使每个复制品知道由其它复制品作出的改变。此同步能力本质上是多主的(multi-master)。

本发明的同步能力允许各复制品：

·确定另一复制品知道什么改变；

·请求关于此复制品不知道的改变的信息；

·传输关于其它复制品不知道的改变的信息；

·确定两个改变何时互相冲突；

·本地应用改变；

·传输冲突分解到其它复制品以确保会聚性；以及

·基于对冲突分解指定的政策分解冲突。

1.存储平台到存储平台的同步

本发明的存储平台的同步服务300的基本应用是同步存储平台(每个带有它自己的数据存储)的多个实例。同步服务在存储平台模式级上操作(而不是在数据库引擎314的底层表中)。因此，例如“范围(Scope)”用于定义下面讨论的同步组。

同步服务按“纯改变(net change)”的原则操作。不是记录和发送各个操作(如事务复制)，同步服务而是发送这些操作的最终结果，因此常将多个操作的结果合并成单个最终结果。

同步服务通常不考虑事务边界。换言之，若在单个事务中对存储平台数据存储作出两个改变，不保证这些改变原子地应用到所有其它复制品上—可以示出一个改变而不示出其它改变。此原则的例外是，若在同一事务中对同一项目作出两个改变，则这些改变保证被原子地发送和应用到其它复制。因此，项目是同步服务的一致性单元。

a)同步(Sync)控制应用程序

任一应用程序可连接到同步服务并启动sync(同步)操作。那样的应用程序提供执行同步(见下面同步概况)所需的所有参数。那样的应用程序在这里被称为同步控制应用程序(SCA)。

在同步两个存储平台实例时，在一侧由SCA启动同步。该SCA通知本地同步服务与远程伙伴同步。在另一侧，同步服务通过由来自发起机器的同步服务发出的消息唤醒。它基于在目标机器上存在的持久配置信息(见下文的映射)作出响应。同步服务能按时间表或响应于事件运行。在这些情况下，实现时间表的同步服务成为SCA。

为启用同步，需要采取两个步骤。首先，模式设计者必须用合适的同步语义注释存储平台模式(如下文所述的指定改变单元)。其次，同步必须在具有参与同步的存储平台的实例的所有机器上正确地配置(如下所述)。

b)模式注释

同步服务的基本概念是改变单元(Change Unit)的概念。改变单元是由存储平台个别地跟踪的最小的模式片段。对每个改变单元，同步服务能确定自从最后一次同步以来它是被改变还是未被改变。

指定模式中的改变单元达到若干目的。首先，它确定了在线的同步服务如何罗嗦。当在改变单元内作出改变时，整个改变单元被发送到其它复制品，因为同步服务不知道改变单元的哪部分被改变。其次，它确定了冲突检测的粒度。当对同一改变单元作出两个并发的改变(这些术语在后继章节中详细定义)，同步服务引起冲突；另一方面，若对不同改变单元作出并发改变，则无冲突发生，且改变被自动地合并。第三，它严重地影响了由系统保持的元数据的量。对每个改变单元保持许多同步服务元数据；因此，使改变单元更小会增加同步的额外开销。

定义改变单元需要找出正确的折衷。为此，同步服务允许模式设计者参与此过程。

在一个实施例中，同步服务不支持大于一个元素的改变单元。然而，它支持让模式设计者指定比一个元素更小的改变单元的能力—即将一个元素的多个属性组合到单独的改变单元中。在该实施例中，这是使用下述句法实现的：

<Type Name＝″Appointment″MajorVersion＝″1″MinorVersion＝″0″ExtendsType＝″Base.Item″

        ExtendsVersion＝″1″>

 <Field Name＝″MeetingStatus″Type＝″the storage platformTypes.uniqueidentifier Nullable＝″False″/>

 <Fileld Name＝″OrganizerName″Type＝″the storage platformTypes.nvarchar(512)″Nullable＝″False″/>

 <Filed Name＝″OrganizerEmail″Type＝″the storage platformTypes.nvarchar(512)″

   TypeMajorVersion＝″1″                     MultiValued＝″True″/>

 … 

 <ChangeUnit Name＝″CU_Status″>

   <Field Name＝″MeetingStatus″/>

 </ChangeUnit>

 <ChangeUnit Name＝″CU_Organizer″/>

   <Field Name＝″OrganizerName″/>

   <Field Name＝″OrganizerEmail″/>

 </ChangeUnit>

 …

</Type>

c)同步配置

希望保持它们数据的某些部分同步的一组存储平台伙伴被称为同步共同体。虽然共同体的成员希望保持同步，它们不需要以完全相同的方式表示数据；换言之，同步伙伴可转换他们正在同步的数据。

在对等情况下，让对等方对所有它们的伙伴维持转换映射是不现实的。取代地，同步服务采取定义“共同体文件夹”的方法。共同体文件夹是代表所有共同体成员正在与之同步的假设的“共享文件夹”的抽象。

此概念最好用一例子说明。若Joe希望保持他的若干计算机的My Documents(我的文档)文件夹同步，Joe定义一共同体文件夹，如称为JoeDocuments。随后在每台计算机上，Joe在假设的JoeDocuments文件夹和本地My Documents文件夹之间配置一映射。从这点出发，当Joe的计算机彼此同步时，它们借助JoeDocuments中的文档而不是它们的本地项目来交谈。以此方法，所有Joe的计算机互相理解，而不必知道其它人是谁—共同体文件夹成为同步共同体的通用语。

配置同步服务包括三个步骤：(1)定义在本地文件夹和共同体文件夹之间的映射；(2)定义确定哪个得到同步的同步概况(如与谁同步，以及哪个子集应当被发送、哪个被接收)；以及(3)定义不同的同步概况应当运行的时间表，或手动运行它们。

(1)共同体文件夹—映射

共同体文件夹映射作为XML配置文件被存储在个别机器上。每个映射具有以下模式：

/mappings/communityFolder

此元素命名映射的共同体文件夹。名字遵循文件夹的句法规则。

/mappings/localFolder

此元素命名映射所转换到的本地文件夹。此名字遵循文件夹的句法规则。为了映射有效，文件夹必须已存在。此文件夹中的项目被看作对每一此映射的同步。

/mappings/transformations

此元素定义如何将项目从共同体文件夹转换到本地文件夹以及如何反向转换。若缺少或为空，不执行转换。具体说来，这意味着无ID被映射。此配置主要用于创建文件夹的高速缓存。

/mappings/transformations/mapIDs

此元素请求新生成的本地ID被赋予所有从共同体文件夹映射的项目，而不是重新使用共同体ID。同步运行库维护ID映射，以来回转换项目。

/mappings/transformations/localRoot

此元素请求共同体文件夹中的所有根项目作为指定根的子项目。

/mappings/runAs

此元素控制，在谁的授权下处理针对此映射的请求。若不存在，则假设发送者。

/mappings/runAs/sender

存在此元素表明，对此映射的消息发送者必须是人格化的，且在他的凭证下处理请求。

(2)概况

同步概况是分离同步所需的总的参数组。由SCA将其提供给同步运行库以启动同步。存储平台到存储平台的同步的同步概况包含以下信息：

·本地文件夹，用作改变的源和目标；

·与之同步的远程文件夹名—此文件夹必须通过如上定义的映射从远程伙伴发布；

·方向—同步服务支持只发送、只接收以及发送—接收同步；

·本地过滤器—选择发送什么本地信息到远程伙伴。表示成本地文件夹上的存储平台查询；

·远程过滤器—选择从远程伙伴接收什么远程信息—表示成共同体文件夹上的存储平台查询；

·转换—定义如何在项目和本地格式间转换；

·本地安全性—指定是在远程端点(人格化)的许可下应用从远程端点检索的改变，还是用户在本地启动同步；以及

·冲突分解政策—指定冲突是否应被拒绝、记入日志或自动分解—在后一种情况下，指定使用哪个冲突分解器以及它的配置参数。

同步服务提供允许简单构建同步概况的运行时CLR类。概况可被串行化成XML文件或从XML文件串行化，以便容易存储(常与时间表一起)。然而，在存储平台中没有存储所有概况的标准地方；欢迎SCA在不必永久保持的点上构建概况。注意，不需要具有本地映射来启动同步。能在概况中指定所有同步信息。然而为响应于由远程方启动的同步请求，需要映射。

(3)时间表

在一个实施例中，同步服务不提供它自己的调度基础结构。相反，它依赖于另一组件来完成此任务—在Microsoft Windows操作系统中可得到的WindowsScheduler。同步服务包括命令行实用程序，它担当SCA并基于保存在XML文件中的同步概况触发同步。该实用程序使得按时间表或者响应于如用户登录或登出等事件来配置Windows Scheduler变得非常容易。

d)冲突处理

同步服务中的冲突处理被划分成三个阶段：(1)发生在改变应用时的冲突检测—此步骤判断是否可安全地应用改变；(2)自动冲突分解并记入日志—在此步骤(发生在紧接着冲突检测之后)资讯自动冲突分解器，以查看冲突是否能被分解—若不能，可任选地将冲突记入日志；以及(3)冲突检查与分解—若某些冲突已被记入日志，且发生在同步会话之外，则采取此步骤—此时，被记入日志的冲突能被分解并从日志中移除。

(1)冲突检测

在本实施例中，同步服务检测两类冲突：基于知识和基于约束的。

(a)基于知识的冲突

当两个复制对同一改变单元作出独立的改变时，发生基于知识的冲突。两个改变若是它们在互相不知道的情况作出的，则称为独立的-换言之，第一个的版本不被第二个的知识所覆盖，反之亦然。同步服务基于上述复制品的知识自动检测所有那些冲突。

将冲突想成在改变单元的版本历史中的分叉有时是有益的。若在改变单元的生命中不发生冲突，其版本历史是简单的链—每个发生在前一个之后。在基于知识的冲突的情况下，两个改变并行发生，导致链分裂，成为版本树。

(b)基于约束的冲突

存在独立的改变在一起应用时破坏完整性约束的情况。例如，在同一目录中用同样的名字创建一个文件的两个复制品能导致发生那样的冲突。

基于约束的冲突牵涉到两个独立的改变(就象基于知识的冲突)，但它们不影响同一改变单元。相反，它们影响不同的改变单元，但在它们之间存在约束。

同步服务检测在改变应用时的约束破坏，并自动引起基于约束的冲突。分解基于约束的冲突通常需要自定义代码，它以不破坏约束的方式修改那些改变；同步服务不提供这样做的通用机制。

(2)冲突处理

在检测到冲突时，同步服务可采取三个动作之一(由同步概况中的同步启动者选择)：(1)拒绝该改变，将其返回到发送者；(2)将冲突记入到冲突日志；或(3)自动分解冲突。

若改变被拒绝，同步服务如同该改变没有到达该复制品那样地运作。否定确认被发回到发起者。此分解政策主要在无领导的复制品(如文件服务器)上有用，在那里将冲突记入日志是不可行的。相反，那些复制品通过拒绝它们来强迫其它复制品处理那些冲突。

同步启动者在它们的同步概况中配置冲突分解。同步服务支持在单个概况中以下列方式组合多个冲突分解器—首先通过指定冲突分解器的列表，一个接着一个地尝试分解，直到其中一个成功；第二，通过将冲突分解器与冲突类型相关联，如引导更新—更新基于知识的冲突到一个分解器，但所有其它冲突记入日志。

(a)自动冲突分解

同步服务提供若干默认的冲突分解器。其列表包括：

·本地赢：若与本地存储的数据冲突，则不予处理进入的改变；

·远程赢：若与进入的改变冲突，则不予处理本地数据；

·最后写赢：基于改变的时间标记挑选每个改变单元的本地赢或远程赢(注意，同步服务一般不依赖于时钟值；此冲突分解器是该规则的唯一例外)；

·确定的：以保证在所有复制品上相同，但在其它情况下无意义的方式挑选赢者—同步服务的一个实施例使用伙伴ID的字典式比较来实现此特征。

此外，ISV能实现并安装它们自己的冲突分解器。自定义冲突分解器可接受配置参数；那些参数必须由SCA在同步概况中的冲突分解段中指定

在冲突分解器处理冲突时，它向运行库返回需要执行的操作(替代冲突改变)的列表。然后同步服务应用这些操作，其具有正确地调整的远程指示，以包括冲突处理器所考虑的所有内容。

在应用分解的同时可能检测到另外冲突。在那样情况下，新的冲突必须在原先处理重新开始之前被分解。

将冲突考虑成项目的版本历史中的分枝时，冲突分解可看成合并—组合两个分枝以形成单个点。因此，冲突分解将版本历史转到DAG。

(b)冲突日志记录

一种非常特定类型的冲突分解器是冲突日志记录器。同步服务将冲突记入日志作为ConflictRecord(冲突记录)的项目。这些记录反过来与冲突中的项目有关(除非项目本身已被删除)。每个冲突记录包括：导致冲突的进入的改变；冲突的类型；更新—更新、更新—删除、删除—更新、插入—插入或约束；以及进入的改变的版本和发送它的复制品的知识。记入日志的冲突可用于下面所述的检查和分解。

(c)冲突审查和分解

同步服务对应用程序提供API，以检查冲突日志并建议其中的冲突分解。该API允许应用程序枚举所有冲突，或与给定项目有关的冲突。还允许那些应用程序以下列三种方法之一分解记入日志的冲突：(1)远程赢—接受记入日志的改变并覆写冲突的本地改变；(2)本地赢—忽略记入日志的改变的冲突部分；以及(3)建议新的改变—其中，应用程序提议一合并，以它的观点，该合并分解冲突。一旦由应用程序分解了冲突，同步服务将它们从日志中移除。

(d)复制品的会聚性及冲突分解的传播

在复杂同步的情况下，在多个复制品中能检测到同一冲突。若发生此情况，发生若干事情：(1)在一个复制品上能分解冲突，并将分解送到其它复制品；(2)冲突在两个复制品上被自动分解；以及(3)在两个复制品上手动分解冲突(通过分解检查API)。

为保证会聚性，同步服务将冲突分解转发到其它复制品。当分解冲突的改变到达复制品时，同步服务自动地在日志中寻找由此更新分解的任何冲突，并消除它们。在此情况下，一个复制品上的冲突分解被绑定到所有其它复制品。

若不同的复制品对同一冲突选择了不同的赢者，则同步服务应用绑定冲突分解的原则，并自动地挑选两个分解中一个胜过另一个。以确定性的方式挑选赢者以保证在所有时刻都产生同样的结果(一个实施例使用复制品ID字典式比较)。

若不同复制对同一冲突建议不同的“新改变”，则同步服务将此新冲突处理成特殊冲突，并使用冲突日志记录器来防止它传播到其它复制品。那样情况常在手动冲突分解时发生。

2.对非存储平台数据存储的同步

按本发明的存储平台的另一方面，存储平台提供ISV用于实现同步适配器的体系结构，同步适配器使存储平台能与如Microsoft Exchange、AD、Hotmail等传统系统同步。同步适配器得益于由下述同步服务提供的许多同步服务。

不管其名称如何，同步适配器不需要作为某个存储平台体系结构的插件来实现。在需要时，“同步适配器”能简单地是利用同步服务运行库接口来获得如改变枚举和应用等服务的任何应用程序。

为了使其他人能更容易地配置和运行到给定背端(backend)的同步，鼓励同步适配器的编写者展现标准同步适配器接口，它在给定上述的同步概况时运行同步。概况提供配置信息给适配器，某些适配器传送到同步运行库以控制运行库服务(如，要同步的文件夹)。

a)同步服务

同步服务向适配器编写者提供若干同步服务。在本节余下部分，方便地将存储平台在其上做同步的机器称为“客户机”，而适配器正与其对话的非存储平台背端称为“服务器”。

(1)改变枚举

基于由同步服务维持的改变跟踪数据，改变枚举允许同步适配器容易地枚举自从最后一次与该伙伴试图作出同步以来对数据存储文件夹发生的改变。

基于“锚位(anchor)”的概念来枚举改变—这是表示有关最后一次同步的信息的不透明的结构。如以前章节所述，锚位采取存储平台知识的形式。利用改变枚举服务的同步适配器落入两大类别：使用“存储的锚位”的适配器和使用“提供的锚位”的适配器。

区别基于关于最后一次同步的信息存储在哪里—在客户机上或在服务器上。适配器常常容易地存储此信息在客户机上—背端往往不能容易地存储此信息。另一方面，若多个客户机与同一背端同步，则将此信息存储在客户机上是低效且在某些情况下是不正确的—这使一个客户机不知道其它客户机已推到服务器的改变。若适配器希望使用服务器存储的锚位，则适配器需要在改变枚举时将其送回到存储平台。

为了让存储平台维护锚位(用于本地或远程存储)，存储平台需要知道成功地应用在服务器上的改变。这些且只有这些改变能包括在锚位中。在改变枚举期间，同步适配器使用确认(Acknowledgement)接口，以报告哪个改变已被成功地应用。在同步结束时，使用提供的锚位的适配器必须读出新锚位(它集合所有成功应用的改变)并将其发送到它们的背端。

各适配器常常需要存储适配器专用数据以及插入到存储平台数据存储中的各项目。该数据存储的常见例子是远程ID和远程版本(时间标记)。同步服务提供用于存储此数据的机制，而改变枚举提供接收此额外数据以及要返回的改变的机制。在大多数情况下，这消除了适配器重新查询数据库的需求。

(2)改变应用

改变应用允许同步适配器将从它们的背端接收的改变应用到本地存储平台。期望适配器将改变转换到存储平台模式。图24示出从存储平台模式生成存储平台API类的过程。

改变应用的主要功能是自动检测冲突。如在存储平台到存储平台同步的情况下，冲突被定义成在互相不知道时作出的两个重叠的改变。当适配器使用改变应用时，它们必须指定对其执行冲突检测的锚位。若检测到未被适配器的知识覆盖的重叠的本地改变，则改变应用引起冲突。类似于改变枚举，适配器可使用存储的或提供的锚位。改变应用支持适配器专用元数据的有效存储。那样的数据可由适配器将其附加到要应用的改变上，且可被同步服务存储。数据可在下次改变枚举时返回。

(3)冲突分解

上述冲突分解机制(记入日志和自动分解选项)也对同步适配器可用。在应用改变时，同步适配器能指定用于冲突分解的政策。若指定了，冲突可被传递到指定的冲突处理程序并予以分解(若可能)。冲突也能被记入日志。当试图将本地改变应用到背端时，适配器有可能检测冲突。在那样情况下，适配器仍可以将冲突传递到同步运行库，以按政策分解。此外，同步适配器可请求任何由同步服务检测的冲突发回给它们以便处理。在背端能存储或分解冲突的情况这特别方便。

b)适配器实现

虽然某些“适配器”简单地是利用运行库接口的应用程序，然而鼓励适配器实现标准的适配器接口。这些接口允许同步控制应用程序：请求适配器按给定的同步概况执行同步；取消正进行的同步；以及接收关于正进行同步的进展报告(完成百分比)。

3.安全性

同步服务努力将尽可能少的同步引入到由存储平台实现的安全模式。不是去定义对同步新的权限，而是使用现有的权限。具体地，

·能读数据存储项目的任何人可枚举对那个项目的改变；

·能写到数据存储项目的任何人可应用改变到该项目；以及

·能扩展数据存储项目的任何人可将同步元数据与该项目关联。

同步服务不维护安全授权信息。当在复制品A由用户U作出改变，且将其转发到复制品B时，该改变最初在A处(由U)作出的事实丢失了。若B将此改变转发到复制品C，则这是在B的授权而不是在A的授权下完成的。这就导致下述限制：若不信任一个复制品对一个项目作出它自己的改变，它不能转发由其它复制品作出的改变。

在启动同步服务时，由同步控制应用程序完成。同步服务人格化SCA的身份，并在该身份下完成所有操作(本地的和远程的)。作为说明，观察到用户U不能使本地同步服务从远程存储平台检索对用户U不具有读访问的项目的改变。

4.可管理性

监视复制品的分布式共同体是复杂的问题。同步服务可使用“扫描(sweep)”算法来收集和分发关于该复制品的状态的信息。扫描算法的属性确保关于所有所配置的复制品的信息最终被收集，且检测到该失败(无响应)的复制品。

在每个复制品上可得到共同体范围的监视信息。可在任意选取的复制品上运行监视工具，以检查此监视信息并作出管理决策。在受影响的复制品上必须直接作出配置改变。

H.传统文件互操作性

如上提到，至少在某些实施例中，本发明的存储平台旨在被实施为计算机系统的硬件/软件接口系统的整体部分。例如，本发明的存储平台可被实施为如Microsoft Windows家族操作系统的整体部分。在这方面，存储平台API成为操作系统API的一部分，应用程序通过它与操作系统交互。因此，存储平台成为装置，应用程序通过它将信息存到操作系统上，且从而基于项目的存储平台的数据模型替代了这一操作系统的传统文件系统。例如，当在Microsoft Windows家族操作系统中实施时，存储平台可替代在该操作系统中实现的NTFS文件系统。当前，应用程序通过由Windows家族操作系统展现的Win32 API来访问NTFS文件系统的服务。

然而，应认识到，完全用本发明的存储平台替代NTFS文件系统需要重新编码现有的基于Win32的应用程序，且那样的重新编码可能是不合需要的，因此本发明的存储平台提供与如NTFS等现有文件系统的某种互操作性是有益的。从而，在本发明的一个实施例中，存储平台使依赖于Win32编程模型的应用程序能同时访问存储平台的数据存储以及传统的NTFS文件系统的数据存储的内容。为此，存储平台使用作为Win32命名习惯的超集(superset)的命名习惯以便于容易的互操作性。此外，存储平台支持通过Win32 API访问存储在存储平台卷中的文件和目录。

关于此功能的另外细节能在通过引用结合于此的有关专利中找到。

I.存储平台API

存储平台包括-API，它使应用程序能访问上面讨论的存储平台的特征和能力，并访问存储在数据存储中的项目。本节描述本发明的存储平台的存储平台API的一个实施例。关于此功能的细节能在通过引用结合于此的有关专利中找到，为方便起见在下面总结此信息的某一些。

参考图18，包含文件夹是一个项目，它包含与其它项目的持有关系，且与通常概念的文件系统文件夹等价。每个项目“包含”在至少一个包含文件夹中。

图19示出按本实施例的存储平台API的基本体系结构。存储平台API使用SQL客户机1900与本地数据存储302对话，并还使用SQL客户机1900与远程数存储(如数据存储340)对话。本地存储还可使用DQP(分布式查询处理器)或通过上述的存储平台同步服务(“Sync”)与远程数据存储340对话。存储平台API322还担当数据存储通知的桥接器API，将应用程序的下标传送到通知引擎，并如上所述将通知路由到应用程序(如应用程序350a、350b或350c)。在一个实施例中，存储平台API 322还定义受限制的“提供者”体系结构，使得它能访问MicrosoftExchange和AD中的数据。

图20示意性地表示存储平台API的各种组件。存储平台AP包括下列组件：(1)数据类2002，它代表存储平台元素和项目类型；(2)运行库架构2004，它管理对象的持久性并提供支持类2006；以及(3)工具2008，它用于从存储平台模式生成CLR类。

从给定模式得出的类的分层结构直接反应了该模式中类型的分层结构。作为例子，考虑在如图21A和图21B中所示的联系人模式中定义的项目类型。

图22示出操作中的运行库架构。运行库架构如下操作：

1.应用程序350a、350b或350c绑定到存储平台的项目。

2.架构2004创建对应于绑定项目的ItemContext对象2202，并将其返回给应用程序。

3.应用程序提交在此ItemContext(项目上下文)上的Find(寻找)，以得到项目的集合；返回的集合在概念上是对象图2204(由于关系)。

4.应用程序改变、删除和插入数据。

5.应用程序通过调用Update()方法保存改变。

图23示出“FindAll(寻找所有)”操作的执行。

图24示出从存储平台模式生成存储平台API类的过程。

图25示出文件API所基于的模式。存储平台API包括处理文件对象的名字空间。该名字空间被称为System.Storage.Files。System.Storage.Files中的类的数据成员直接反映了存储在存储平台存储中的信息；此信息是从文件系统对象的“升级”或使用Win32 API本机地创建。System.Storage.Files名字空间具有两个类：FileItem(文件项目)和DirectoryItem(目录项目)。这些类的成员及其方法可通过审阅图25中的模式图来预测。FileItem和DirectoryItem是从存储平台API只读的。为修改它们，必须使用System.IO中的Win32 API或类。

对于API，编程接口(或简称之为接口)可以被视为用于令代码的一个或多个片断能与由代码的一个或多个其它片断提供的功能进行通信或对其进行访问的任一机制、过程、协议。或者，编程接口可以被视为能够通信地耦合至其它计算机的一个或多个机制、方法、函数调用、模块等的系统的组件的一个或多个机制、方法、函数调用、模块、对象等。上述语句中的术语“代码片断”意在包括代码的一个或多个指令或代码行，并包括，如，代码模块、对象、子例程、函数等等，无论应用的术语是什么、或代码片断是否被单独编译、或代码片断是否被提供为源码、中间码或对象代码、代码片断是否在运行时系统或进程中使用、或它们是否位于同一或不同机器上或跨多个机器分布、或由代码片断表示的功能是否完全由软件、完全由硬件或硬件和软件的组合来实现。

概念上，编程接口可以被一般地察看，如图30A或图30B所示的。图30A示出了接口“接口1”为管道，第一和第二代码片断通过该管道进行通信。图30B示出了接口包括接口对象I1和I2(可以是或不是第一和第二代码片断的部分)，它们令系统的第一和第二代码片断能通过介质M进行通信。在图30B中，可以认为接口对象I1和I2为同一系统的单独接口，并且也可以认为对象I1和I2加上介质M构成了接口。尽管图30A和30B示出了双向流程以及该流程的每一侧上的接口，某些实现可仅具有一个方向上的信息流(或如下所述没有信息流)，或仅具有一侧的接口对象。作为示例而非局限，诸如应用编程或程序接口(API)、入口点、方法、函数、子例程、远程过程调用和组件对象模型(COM)接口等术语包含在编程接口的定义之内。

这类编程接口的方面可包括第一代码片断向第二代码片断发送信息的方法(其中，“信息”以其最广泛的意义使用，并包括数据、命令、请求等等)；第二代码片断接收信息的方法；以及该信息的结构、序列、语法、组织、模式、定时和内容。在这一点上，只要信息以接口所定义的方式传输，底层传输介质本身可以对接口的操作不重要，无论该介质是有线还是无线，或两者的组合。在某些情况下，在常规意义上，当一个代码片断仅访问由第二代码片断执行的功能时，信息可不在一个或两个方向上传输，因为信息传输可以是或者通过另一机制(如，信息被放置在与代码片断之间的信息流分离的缓存、文件等中)或者不存在。这些方面的任一个或所有可以在给定的情况下重要，如，取决于代码片断是否是松耦合或紧耦合配置的系统的一部分，并且因此该列表应当被认为是说明性的而非限制。

编程接口的这一概念对本领域的技术人员是已知的，并且可以阅读上述本发明的详细描述而清楚这一概念。然而，有其它方法来实现编程接口，并且除非明显地排除，这些方法也由所附权利要求书包含在内。这些其它方法看似比图30A和30B的视图更精密或复杂，但是它们仍执行类似的功能来完成同一整体结果。现在简要描述编程接口的某些说明性替换实现。

分解：可以通过将通信分裂成多个离散通信来间接地实现从一个代码片断到另一个的通信。这在图31A和31B中示意性地描述。如图所示，可以按照功能的可分组来描述某些接口。由此，可以分解图30A和30B的接口功能来达到相同的结果，如同可以在数学上提供24，或2乘2乘3乘2一样。因此，如图31A所示，可以细分由接口“接口1”提供的功能以将该接口的通信变换成多个接口“接口1A”、“接口1B”、“接口1C”等，而达到相同的结果。如图31B所示，由接口I1提供的函数可以被细分成多个接口I1a、I1b、I1c等，而达到相同的结果。类似地，从第一代码片断接收信息的第二代码片断的接口I2可以被分解成多个接口I2a、I2b、I2c等。当分解时，包括在第一代码片断中的接口的数量不需要匹配包括在第二代码片断中的接口的数量。在图31A或31B的任一情况下，接口“接口1”和I1的功能性精神分别与图30A和30B的保持相同。接口的分解也可遵从联合、通信和其它数学性质，使得分解较难识别。例如，命令操作可以是不重要的，并且因此由接口完成的功能可以在达到该接口之前由另一段代码或接口较好地完成，或者由系统的单独组件执行。此外，编程领域的普通技术人员可以理解有各种方式来作出不同的函数调用而达到相同的结果。

重定义：在某些情况下，可能忽略、添加或重定义编程接口的某些方面(如参数)，而仍达到预期的结果。这在图32A和32B中示出。例如，假定图30A的接口“接口1”包括函数调用Square(input，precision，output)(平方)，它包括三个参数，input(输入)、precision(精度)和output(输出)，并且由第一代码片断向第二代码片断发布。如果中间参数precision在给定的情形下无关紧要，如图32A所示，它也可以被忽略或甚至由meaningless(无意义)(在这一情况下)参数来替换。也可以添加无关紧要的additional(另外)参数。在任一情况下，只要在输入由第二代码片断平方之后返回输出，就可以达到square(平方)的功能。Precision也有可能对计算系统的某一下游或其它部分是极有意义的参数；然而，一旦认识到precision对计算平方这一有限目的不是必需的，它可以被替换或忽略。例如，不是传递一个有效的pricision值，而是在不对结果产生不利影响的情况下传递诸如出生日期等无意义的值。类似地，如图32B所示，接口I1由接口I1′替换，它被重新定义来忽略或向接口添加参数。接口I2可类似地被重定义为接口I2′，它被重定义来忽略不必要的参数，或可在别处处理的参数。此处的要点是在某些情况下，编程接口可包括对某一目的而言所不需要的方面，诸如参数，因此可以忽略或重定义它们，或在别处处理它们用于其它目的。

内嵌代码：合并两个单独的代码模块的一些或全部功能也是可行的，使得它们之间的“接口”改变形式。例如，图30A和30B的功能可以被分别转化到图33A和33B的功能。在图33A中，图30A的先前的第一和第二代码片断被合并成包含两者的模块。在这一情况下，该代码片断仍可以彼此通信，但是该接口可以适用于更适合单个模块的形式。由此，例如，正式的调用(Call)和返回(Return)语句将不再必需，但是依照接口“接口1”的类似的处理或响应仍是有效的。类似地，如图33B所示，图30B的部分(或所有)接口I2可以内嵌地写入接口I1来形成接口I1″。如图所示，接口I2被划分成I2a和I2b，并且接口部分I2a内嵌在接口I1中书写代码来形成接口I1″。对于具体的示例，考虑图30B的接口1执行函数调用square(input，output)，它由接口I2接收，在由第二代码片断处理传递到input的值(对其求平方)之后，它被使用output传递回已求平方的结果。在这一情况下，由第二代码片断执行的处理(对input求平方)可以由第一代码片断在不调用该接口的情况下执行。

脱离：可以通过将通信分裂成多个离散的通信来间接地完成从一个代码片断到另一个的通信。这在图34A和34B中示意性地描述。如图34A所示，提供了中间件的一个或多个片断(脱离接口(Divorce Interface)，因为它们从原始的接口脱离的功能和/或接口函数)，以转化第一接口“接口1”上的通信，使得它们符合不同的接口，在本情况下为“接口2A”、“接口2B”和“接口2C”。这可以在这样一种情况中完成，例如，依照“接口1”协议设计应用的已安装基础与如操作系统进行通信，但是然后改变该操作系统来使用不同的接口，在本情况下为接口“接口2A”、“接口2B”和“接口2C”。要点是改变了由第二代码片断使用的原始接口，使得它不再与第一代码片断所使用的接口兼容，因此使用中介来令旧接口和新接口兼容。类似地，如图34B所示，可以使用脱离接口DI1引入第三代码片断以从接口I1接收信息，并使用脱离接口DI2引入第三代码片断以向例如接口I2a和I2b发送接口功能，重新设计接口I2a和I2b以使用DI2，但是提供相同的功能性结果。类似地，DI1和DI2可共同工作以将图30B的接口I1和I2的功能转换成一新操作系统，而提供相同或类似的功能性结果。

重写：再一种可能的变化是动态地重写代码，使用别的东西来替换接口的功能，而仍达到相同的总体结果。例如，可以有一种系统，其中，向执行环境(如由.Net框架提供的环境、Java运行时环境或其它类似的运行时刻类型环境)中的及时(Just-in-Time)(JIT)编译器或解释器提供了中间语言(如Microsoft IL、JavaByteCode等)中呈现的代码片断。可以书写JIT编译器以动态地将通信从第一代码片断转化到第二代码片断，即，令它们符合第二代码片断(原始或不同的第二代码片断)所需要的不同接口。这在图35A和35B中有描述。如图35A中所看见的，这一方式类似于上述的脱离情形。它可以在这样一种情况下完成，例如，依照“接口1”协议设计应用的已安装基础操作系统进行通信，然后改变该操作系统以使用不同的接口。JIT编译器可以用于令已安装基础应用的空中通信符合操作系统的新接口。如图35B所描述的，可以应用这一动态重写接口的方法以进行动态分解，或者改变接口。

应当注意，上述通过替换实施例实现与接口相同或相似的结果的情形也可以以各种方式串行、并行或与其它干预代码组合。由此，上文呈现的替换实施例并非相互穷尽，并且可以被混合、匹配和组合以产生与图30A和30B中所呈现的一般情形相同或等效的情形。也应当注意，如同大多数编程构造，本发明可能未描述达到与接口相同或相似的功能的其它类似的方式，但是它们仍由本发明的精神和范围来表示，即，应当注意，它至少部分地是由作为接口的值的基础的接口表示的功能或由其启用的有利结果。

III.图象模式和辅助模式(图象模式组)

在这里揭示的本发明的各个实施例中，图象(如JPEG、TIEF、位图等)被处理成核心平台对象(“图象项目”或更简单地“图象”)，且本发明包括“图象(Image)模式”以提供系统中图象的可扩展的表示—即，图象的特征和该图象如何与系统中的其它项目(包括但不限于其它图象)相关。为此，图象模式对系统中的图象定义属性、行为和关系，且模式还强制实行关于图象的规则，如，图像必须包含什么专用数据、图像能可任选地包含哪些专用数据、特定图象如何扩展，等等。图象模式包括表示不同类型图象所必须的类型信息，包括用于表示图象的文件格式的属性(包括GIF、TIEF、JPEG以及其它已知图象对象类型)以及表示图象的语义内容的属性。本发明的各实施例的图象模式是构建所有图象相关功能的基础。

除图象模式外，这里还提供并讨论对“照片(Photo)”、“分析属性(AnalysisProperties)”、“位置(Location)”项目的相关辅助模式(总称为“图象模式组”)，且本发明的某些实施例包括这些辅助模式的一个或多个。照片模式是照片对象(“照片项目”或简单的“照片”)的可扩展的表示，其中照片项目类型是图象项目类型的子类型。分析属性模式(AP模式)是照片项目的分析属性(AP)的可扩展的表示，它启用对照片的先进的比较功能，如自动面部识别、图象的相似性等。位置模式是照片项目的物理(地理)位置属性的可扩展的表示。

图36A和图36B示出本发明的各实施例的图象模式(项目及属性)，以及从基础模式(图7)和核心模式(图8A和图8B)选择的元素，以示出在每个模式之间的互相关系(为方便起见，在图示中省略各个属性)。

A.图象模式

如前讨论，图象模式包括表示不同类型的图象项目所必须的项目、属性和关系。这包括用于表示特定图象类型(GIF、TIEF、JPEG等)的本机文件格式，以及表示图象的语义内容的属性。为此，对任何图象项目，项目类型是由所有图象共享的基础项目类型，且是如图36示出的Core.Document项目类型(即在“核心(Core)”模式中的“文档(Document)”类型)的直接扩展。(Core.Document类型是图8A示出的核心模式的一部分。)图象类型包含一般描述图象的字段，且它可应用到所有图象，而不论其格式。图象模式的基本项目类型是Image(图像)类型，下面是Image类型的某些字段：

属性名	描述
		Rating	此图片的等级。这能表示消费者等级、父母等级等。
SizeX	图象的宽度象素。
		SizeY	图象的高度象素。
BitDepth	每个象素的位深度(1、8、16、24等)。
		ColorSpace	此图片的色彩空间的名字，例如“sRGB”。
ColorSpaceVersion	此图片的色彩空间的版本，如“1.2”。
		TimesPrinted	此图象已被打印的次数。此字段由应用程序维护。
RegionOfInterest	图象中感兴趣区域的集合。例如带面部或重要陆标的的矩形。
		History	此图象的历史。应用过哪一过滤器？将它用电子邮件发给谁？何时打印过它？
DigitalNegativeID	此字段对同一图象的所有副本是相同的。若图象的副本被编辑，用户决定他是希望保持它相同，还是认为此版本是新的数字底片。
		OtherVersions	到同一图片的其它版本的链接的集合。下层版本、较小的版本等。这应是嵌入的关系。若一图象改变，则所有子图象也应考虑由应用程序改变。若图象被删除—所有其子图象被WinFs删除。
MetadataLifecycle	控制元数据生命周期的变量。

图象模式还包括附加属性(嵌套元素)，它从Base.PropertyBase如下地扩展：

·“Region”：Region属性代表图象中的区域，并包括下列字段：

属性名	描述
		Left	区域的象素座标
Top	区域的象素座标
		Right	区域的象素座标
Bottom	区域的象素座标

·“RegionOfInterest”：此属性表示在图象中特别感兴趣的信息，并包括下列字段：

属性名	描述
		Person	在此感兴趣的域中表示的人的列表。若该区域包含人以外的某些事物(陆标等)，则此字段为空。
Region	在图象中感兴趣的区域的集合。例如带面部或重要陆标的矩形。若空，则矩形是未知的(用于捕捉在图片中的人而不必知道他们在何处)。
		Confidence	在此特定匹配中的置信度，由元数据提供者返回。

此外，图象模式还可包括在图象项目和其它项目之间如图36A所示的一系列关系，如下所示：

·“PersonReference”：图象可具有到联系人或主体项目(图8A的Core.Principal)的一个或多个PersonRefernce链接，以表明在特定照片中的人，并包括下列字段：

属性名	描述
		Displayname	显示引用的人的名。该字段在链接本身摇摆不定的情况特别有用，但即使链接没有摇摆不定，此字段可用于表明在此特定图象中如何精确地引用在链接的联系人中的人。

·“EventReference”：图象也可具有到事件项目(图8A中的Core.Event)的EventReference链接，以表明对特别照片的事件，并包括下列字段：

属性名	描述
		Displayname	显示引用的事件的名字。此字段在链接本身摇摆不定时特别有用，但即使链接未摇摆不定，此字段可用于表明在此特定图象中此事件如何精确地被引用。

·“LocationReference”：图象也可具有到位置项目(图8A的Core.Location)的LocationReference链接，以表明特定照片的位置，并包括下列字段：

属性名

描述

Latitude	拍摄此图片的位置的纬度。这常常可从数码相机得到。
		Longitude	拍摄此图片的位置的经度。这常常可从数码相机得到。
Altitude	拍摄此图片的位置的高度。这常常可从数据相机得到。
		Heading	拍摄此图片的位置的方向(相机朝的方向)。这常常可从数码相机得到。
LocationName	拍摄此图片的位置的名称。虽然这可能是自由形式字符串，建议将其分解成代表位置的有意思的子字符串。例如“Seattle(西雅图)”、“Washingtion(华盛顿)”、“USA(美国)”可被设置为此多值字段的三个单独的实例。

B.照片模式

照片模式是图象模式的辅助模式，它应用于实际上是某种类型照片的图象。对任何照片项目，照片类型代表一组描述照片的属性，而不论图象格式，且照片类型扩展如在图36中所示的Image.Image类型(即，在“图象”模式中的“Image”类型)。下面是照片类型的某些字段：

属性名	描述
		DateTaken	拍摄图片的日期。此字段可从EXIF信息中得到或手动设置。
DateAquired	在从如数码相机或扫描仪等设备取图片时的日期。
		AcquisitionSessionID	获取会话的唯一ID。例如，若我同一卷胶卷扫描若干照片，则此ID对同一卷的所有照片将相同。
Orientation	指定图象方向的字段。该语义与EXIF标签(1-8号)相同。需要更多信息请见<u>http://jpeqclub.org/exif orientation.html</u>。空意味着未知。纵向/横向方向可以从此标签及SizeX/SizeY确定性地计算。
		Location	拍摄图片的位置
Event	此图象有关的事件。例“Birthday(生日)”“Christmas(圣诞节)”
		CameraMake	用于拍照片的相机制造商的名称。例“Canon”。
CameraModel	用于拍照片的相机型号名。例：“S50”。

属性名	描述
		ExposureTime	以秒表示的快门速度(曝光时间)(或更通常是几分之一
	秒)。
		Aperture	用于作出曝光的光圈设置。
IsoSpeed	等价于ISO感光率的胶卷速度。
		Flash	闪光灯亮？0＝无闪光灯，1＝闪光灯亮。空意味着不知道闪光灯是否亮。
RedEyeUsed	使用红眼模式？0＝否。1＝是。空意味着不知道。这对高级查询有用。例如，若使用红眼，这看来是肖像。
		ExposureMode	曝光方式。允许下列5个值：Auto(自动)、Shutter priority(快门优先级)、Aperture priority(光圈优先级)、ISO priority(ISO优先级)、Manual(手动)。
SubjectDistance	由相机测得对象的距离。距离按米计。

C.分析属性模式

对数字照片，借助分析应用程序可在照片上计算一组属性。然而，计算和重计算这些属性是很花费时间和处理器资源的。此外，这些字段是应用程序专用的，其它应用程序可能不理解这些字段的内部格式。

对照片项目，在由这些应用程序使用之前可替代地计算标准的分析属性组，并以对照片项目类型的扩展的形式将其添加到照片项目。分析属性模式(AP模式)正是通过提供AP扩展的AP类型这样做的，而AP扩展本身如图7所示也是基础模式的Base.Extension扩展类型的扩展。AP类型扩展包括下列字段：

属性名	描述
		ColorHistogram	用于相似性检测的彩色直方图数据。
GrayHistogram	用于相似性检测的灰度直方图数据。
		SimilarityIndex	用于相似性检测的图象纹理数据

IV.结论

如前说明，本发明是针对用于组织、搜索和共享数据的存储平台。本发明的存储平台扩展和拓宽了数据存储的概念，超越现有的文件系统和数据库系统，并被设计成存储所有类型的数据，包括结构化的、非结构化的或半结构化的数据，如关系型(表式)数据、XML以及被称为项目的新数据形式。通过其共同的存储基础和模式化的数据，本发明的存储平台使消费者、知识工人和企业能更有效地进行应用程序的开发。它提供丰富且可扩展的应用编程接口，它不仅可用在其数据模型中内在的能力，还可包含和扩展现有文件系统和数据库访问方法。可以理解，对上述实施例可作出改变而不偏离这里广泛的发明性概念。因而，本发明不限于揭示的特定实施例，而旨在覆盖由权利要求定义的本发明的精神和范围内的所有修改。

从上述明白，本发明的各种系统、方法和方面的所有或部分能以程序代码的方式(如指令)来实施。程序码可存储在如磁、电、或光存储介质等计算机可读介质上，包括但不于：软盘、CD-ROM、CD-RW、DVD-ROM、DVD-RAM、磁带、闪存、硬盘驱动器或任何其它机器可读介质，其中当由如计算机、服务器等机器加载并执行程序代码时，该机器成为实施本发明的装置。本发明也可在通过某种传输介质发送的程序代码的形式中实施，传输介质如电线或电缆、光缆、包括因特网和内联网的网络或通过任何其它形式的传输，其中当由如计算机的机器接收、加载和执行程序代码时，该机器变成用于实施本发明的装置。当在通用处理器上实现时，程序代码组合处理器以提供类似于专用逻辑线路操作的唯一的装置。

Claims (15)

1.一种用于处理多个项目的方法，所述多个项目包括属于一图象并具有硬件/软件接口系统能理解的属性的分立信息单元，所述方法包括：

建立一图像模式，以定义至少一个图象项目及至少一个图象属性；

扩展至少一个图象项目来定义照片模式，所述照片模式定义能从中导出在所述硬件/软件接口系统中处理的照片项目的基本项目类型，所述基本项目类型用于定义包含所述照片项目中的一个的感兴趣区域属性的属性，所述感兴趣区域属性包括用于标识所述照片项目中的一个的第一区域内的至少一个人的字段；

在所述照片项目和属于所述照片项目中的一个内的至少一个人的项目之间建立链接。

2.如权利要求1所述的方法，其特征在于，所述基本项目类型还包括下列属性组中的至少一个属性：拍摄所述照片的日期；获得照片的所述日期；所述照片的获得会话的唯一标识；方向；位置；事件；相机的制造商；相机的型号；曝光时间；光圈；ISO速度；对所述照片是否使用闪光灯的指示；对所述照片是否是用红眼模式的指示；曝光模式；以及所述照片的目标距离。

3.如权利要求1所述的方法，其特征在于，所述感兴趣区域属性还包括用于标识所述照片项目中的一个的第二区域内的至少一个感兴趣区域的字段。

4.如权利要求3所述的方法，其特征在于，所述感兴趣区域属性还包括置信度字段。

5.一种用于处理多个项目的系统，所述项目包括属于图象并具有硬件/软件接口系统可理解的属性的分立信息单元，所述系统包括：

用于建立一图象模式，以定义至少一个图象项目和至少一个图象属性的装置；

用于扩展至少一个图象项目来定义照片模式的装置，所述照片模式定义能从中导出在所述硬件/软件接口系统中处理的照片项目的基本项目类型，所述基本项目类型用于定义包含所述照片项目中的一个的感兴趣区域属性的属性，所述感兴趣区域属性包括用于标识所述照片项目中的一个的第一区域内的至少一个人的字段，以及用于标识所述照片项目中的一个的第二区域内的至少一个感兴趣区域的第二字段；

用于在所述照片项目中的一个和属于在该照片项目中的至少一个人的项目之间建立链接的装置。

6.如权利要求5所述的系统，其特征在于，所述图象模式中的至少一个属性是所述图象的区域属性，所述区域属性包括所述区域的左、上、右、下座标的字段。

7.如权利要求5所述的系统，其特征在于，所述照片项目中的一个的感兴趣区域属性还包括置信度字段。

8.如权利要求5所述的系统，其特征在于，所述硬件/软件接口系统包括一分析属性模式，它定义所照片项目中的一个的至少一个分析属性(AP)。

9.如权利要求8所述的系统，其特征在于，所述至少一个AP包括下列属性组中的至少一个：彩色直方图；灰度直方图；以及相似性指数。

10.如权利要求5所述的系统，其特征在于，所述基本项目类型还包括下列属性组中的至少一个属性：拍摄所述照片的日期；获得照片的所述日期；所述照片的获得会话的唯一标识；方向；位置；事件；相机的制造商；相机的型号；曝光时间；光圈；ISO速度；对所述照片是否使用闪光灯的指示；对所述照片是否是用红眼模式的指示；曝光模式；以及所述照片的目标距离。

11.一种硬件/软件接口系统处理多个项目的方法，所述项目包括属于具有所述硬件/软件接口系统可理解的属性的图象的分立信息单元，所述方法包括：

建立一图象模式，以定义至少一个图象项目和至少一个图象属性；

在所述图象模式中建立一项目作为组成基本项目类型的基本项目，从中导出在硬件/软件接口系统中处理的所有其它的图象项目；以及

在由基本项目定义的照片数字图象项目和属于在所述照片数字图象项目的区域中表示的至少一个人的项目之间建立链接。

12.如权利要求11所述的方法，其特征在于，还包括，为了表示拍摄所述照片数字图象项目所在的地理位置，建立所述数字图象项目和对应于所述地理位置的位置项目之间的链接，使得能基于所述位置项目来查询所述数字图象项目。

13.如权利要求12所述的方法，其特征在于，还包括，为了表示拍摄照片数字图象项目所在的地理位置，在所述链接上设置对应于所述地理位置的位置属性。

14.如权利要求11所述的方法，其特征在于，还包括，为了表示在所述照片数字图象项目中表示的至少一个事件，在所述照片数字图象项目和属于所述事件的项目之间建立链接，使得能基于属于所述事件的项目查询所述照片数字图象项目。

15.如权利要求11所述的方法，其特征在于，还包括建立从第一数字图象项目到第二数字图象项目的链接，所述第二数字图像项目是(a)能从其导出所述第一数字图象项目的父数字图象项目，或者是(b)从所述第一数字图象项目导出的子数字图象项目。

Images