專利名稱：：實現組織可由硬件/軟件接口系統管理的信息單元的數字圖象模式的系統和方法
技術領域：
：本發明一般涉及信息存儲和檢索領域，尤其涉及用于組織、搜索和共享計算機化系統中的不同類型的數據(特別是圖象數據)的活動存儲平臺。背景在最近十年中，單個盤的容量每年增長約百分之70(70%)。摩爾(Moore)法則精確地預測了在過去數年中中央處理單元(CPU)能力的驚人的增長。有線和無線技術已經提供了數量上巨大的連接和帶寬。假設當前趨勢持續，在數年內一般的膝上計算機將具有約萬億字節(TB)的存儲并包含數百萬個文件，而5千億字節(500GB)的驅動器成為常見的。消費者使用他們的計算機主要用于通信和組織個人信息，不論它們是傳統的個人信息管理器(PIM)風格的數據或如數字音樂或照片那樣的媒體。數字內容的量和存儲原始字節的能力已經大量地增長;然而消費者可用于組織和統一此數據的方法卻跟不上步伐。知識工人花費大量時間來管理和共享信息，某些研究估計，知識工人花費15—25%的時間在與無效信息有關的活動上。另外研究估計，典型的知識工人每天約花費2.5小時搜索信息。開發者與信息技術(IT)部門投資大量的時間與金錢來構建他們自己的用于公用存儲抽象的數據存儲，以呈現如人、地方、時間和事件等事項目。這不僅導致重復的工作，還形成公用數據的孤島，沒有共同搜索或共享那些數據的機制。僅考慮當今在運行MicrosoftWindows操作系統的計算機上有多少地址簿。如電子郵件客戶端和個人財務程序那樣的許多應用程序保留各自的地址簿，且在每個那樣的程序分別維護的地址簿應用程序之間只有很少共享。因而，財務程序(如MicrosoftMoney)不與維護在電子郵件聯系人文件夾(如MicrosoftOutlook中的聯系人文件夾)中的地址共享支付人的地址。確實，許多用戶具有多個設備，在這些設備之間和包括到如MSN和AOL等商業服務的手機電話號碼的各種附加來源之間應該在邏輯上同步它們的個人數據；然而共享文檔的協作大部分是通過將文檔附到電子郵件消息來達到的一這是手動的且低效的。缺乏協作的一個原因是組織計算機系統中的信息的傳統方法集中在使用基于文件一文件夾一目錄的系統("文件系統")，來基于用于存儲文件的存儲介質的物理組織的抽象將多個文件組織到文件夾的目錄分層結構中。在1960年代開發的Multics操作系統被認為是在操作系統級上使用文件、文件夾和目錄來管理可存儲數據單元的先驅。具體說來，Multics在文件的分層結構中使用符號地址(從而引入文件路徑的概念)，其中文件的物理地址對用戶(應用程序和最終用戶)是不透明的。此文件系統完全不考慮任何單個文件的文件格式，且在文件中及文件之間的關系在操作系統級上被認為是無關的(即，與分層結構中文件的位置不同)。由于Multics的出現，在操作系統級上可存儲的數據被組織成文件、文件夾和目錄。這些文件一般包括放在由文件系統維護的一特定文件中的文件分層結構本身("目錄")。此目錄進而維護對應于該目錄中所有其它文件和那些文件在分層結構(這里指文件夾)中的節點位置的條目的列表。這是本領域中近40年的狀態。然而，雖然提供了駐留在計算機的物理存儲系統中的信息的合理表示，但是文件系統是物理存儲系統的抽象，因而文件的利用需要在用戶處理什么(具有上下文、特征以及與其它單元的關系的單元)和操作系統提供什么(文件、文件夾和目錄)之間的間接(解釋)層。結果，用戶(應用程序和/或最終用戶)只好強制把信息單元放入文件系統結構，即使這樣做是低效的、不一致的、或不希望的。此外，現有的文件系統關于在各個文件中存儲的數據的結構知之甚少，因此，大多數信息在文件中保持封閉，只能被寫那些數據的應用程序訪問(和可理解)。因此，缺乏信息的模式描述和管理信息的機制，導致形成數據的豎井(silo)，只有很少數據能在各豎井之間共享。例如，許多個人計算機(PC)用戶具有5個以上各異的存儲，它們包含有關他們在某一層上交互的人的信息一如Outlook聯系人、在線賬戶地址、Windows地址簿、Quicken受款人和即時消息(IM)伙伴列表一因為組織文件向這些PC用戶提出重要的挑戰。由于大多數現有的文件系統利用嵌套的文件夾隱喻來組織文件和文件夾，因此當文件數量增加時，為維持靈活且有效的組織模式所必需的努力變得十分驚人。在這些情況下，具有單個文件的多重分類是非常有用的；然而使用現有文件系統中的硬和軟鏈接是麻煩且難以維護的。過去已作了若干不成功的嘗試來克服文件系統的缺點。這些以前嘗試中的某一些已經涉及使用內容可定址的存儲器來提供可以通過內容而不是通過物理地址來訪問數據的機制。然而，這些努力被證明是不成功的，因而雖然內容可定址的存儲器對由如高速緩存和存儲器管理單元等設備的小規模使用被證明是有用的，但對如物理存儲介質等設備的大規模使用由于各種原因尚不可能，因此那樣的解決方案簡直不存在。己作出使用面向對象的數據庫(OODB)系統的其它嘗試，但是這些嘗試雖然帶有強烈的數據庫的特征，且良好的非文件表示，但在處理文件表示方面并不有效，并不能重現在硬件/軟件接口系統級上基于分層結構的文件及文件夾的速度、效率和簡單性。諸如試圖使用SmallTalk(和其它派生方法)的其它嘗試在處理文件和非文件表示方面被證明相當有效，但缺乏有效地組織和利用在各種數據文件之間存在的關系所必需的數據庫特征，因此那種系統的整體有效性是不可接受的。使用BeOS(和其它那樣操作系統研究)的又一種嘗試盡管能夠勝任適當地表示文件的同時又提供某些必要的數據庫特征，在處理非文件的表示上被證明是不夠的，這是傳統文件系統同樣的核心缺點。數據庫技術是存在類似挑戰的另一專業領域。例如，雖然關系型數據庫模型已取得很大的商業上的成功，實際上獨立軟件分銷商(ISV)—般運用了關系型數據庫軟件產品(如MicrosoftSQLServer)中可得到的功能一小部分。相反，應用程序與那樣產品的大多數交互是以簡單的"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和12，它們使系統的第一和第二代碼段能通過介質M通信；圖31A示出由接口"接口1"提供的功能如何再分割，以便將該接口的通信轉換到多個接口"接口1A"、"接口1B"、"接口1C";圖31B示出由接口Il提供的功能如何再分割成多個接口Ila、Ilb、Ilc;圖32A示出無意義的參數precision能被忽略或用任意參數替代的情形；圖32B示出接口被替代接口代替的情況，該替代接口被定義成忽略或添加參數到接口；圖33A示出第一和第二代碼段被合并到包含兩者的模塊的情況；圖33B示出能將接口的部分或全部內嵌地寫入另一接口以形成合并的接口的情況；圖34A示出一段或多段中間件如何能轉換第一接口的通信以便使它們符合一個或多個不同的接口；圖34B示出如何用接口引入代碼段，以從一個接口接收通信，但將功能發送到第二和第三接口；圖35A示出即時編譯器(JIT)如何能將通信從一個代碼段轉換到另一代碼段；圖35B示出應用動態重寫一個或多個接口的JIT方法來動態分解或更改所述接口；圖36示出圖象模式以及(圖7的)基礎模式及(圖8A的)核心模式，以示出在每個模式中各個項目之間的互相關系。詳細描述目錄A.示例性計算環境................................................................................14B.傳統的基于文件的存儲....................................................................17II.用于組織、搜索和共享數據的WINFS存儲平臺..................................18A*詞匯表...............................................................................................18B.存儲平臺綜述....................................................................................19C.數據模型...........................................................................................201*卵.............................................................................................212.項目標識......................................................................................243.項目文件夾和類別.......................................................................244.賊.............................................................................................26a)基礎模式................................................................................26b)核心模式................................................................................265.縣.............................................................................................28a)關系聲明................................................................................28b)持有關系................................................................................30c)嵌入關系................................................................................31d)引用關系................................................................................31e)規則和約束............................................................................32f)關系的排序............................................................................326.可擴展性......................................................................................36a)項目擴展................................................................................37b)擴展NestedElement類型......................................................40D.數據庫引擎.......................................................................................411.使用UDT的數據存儲實現.........................................................422.項目映射......................................................................................433.擴展映射......................................................................................444.嵌套元素映射..............................................................................445.對象身份......................................................................................446.SQL對象命名..............................................................................447.列命名..........................................................................................458.搜索視圖......................................................................................46a)項目.......................................................................................46(1)主項目搜索視圖.........................................................46(2)分類型的項目搜索視圖.............................................47b)項目擴展................................................................................47(1)主擴展搜索視圖.........................................................47(2)分類型的擴展搜索視圖.............................................48c)嵌套的元素............................................................................48d)關系.......................................................................................48(1)主關系搜索視圖.........................................................48(2)關系實例搜索視圖.....................................................49e)..................................................................................................509*M.............................................................................................5010.改變跟蹤及墓碑.........................................................................50a)改變跟蹤..................................................................................50(1)"主"搜索視圖中的改變跟蹤..................................51(2)"分類型的"搜索視圖中的改變跟蹤.......................52b)M.......................................................................................52(1)項目墓碑....................................................................52(2)擴展墓碑....................................................................53(3)關系墓碑....................................................................53(4)墓碑清除....................................................................5411.助手API和函數........................................................................54a)函數[System.Storage].Getltem...............................................54b)函數[System.Stomge].GetExtension.......................................54c)函數[System.Storage].GetRelationship...................................5412.元數據........................................................................................55a)模式元數據............................................................................55b)實例元數據............................................................................55E.安全性...............................................................................................55F.通知和改變跟蹤................................................................................55醇..................................................................................................561.存儲平臺到存儲平臺的同步........................................................57a)同步(Sync)控制應用程序.................................................57b)模式注釋................................................................................57c)同步配置................................................................................58(1)共同體文件夾一映射.................................................59(2)概況...........................................................................60(3)時間表........................................................................60d)沖突處理................................................................................61(1)沖突檢測....................................................................61(a)基于知識的沖突...................................................61(b)基于約束的沖突...................................................61(2)沖突處理....................................................................61(a)自動沖突分解......................................................62(b)沖突日志記錄......................................................62(c)沖突審查和分解...................................................63(d)復制品的會聚性及沖突分解的傳播....................632.對非存儲平臺數據存儲的同步....................................................63a)同步服務..................................................................................64(1)改變枚舉....................................................................64(2)改變應用....................................................................65(3)沖突分解....................................................................65b)適配器實現............................................................................653.安全性..........................................................................................654.可管理性......................................................................................66H.傳統文件互操作性............................................................................66I.存儲平臺API.....................................................................................67III.圖象模式和輔助模式(圖象模式組)..................................................72A.圖象模式...........................................................................................72B.照片模式...........................................................................................75C.分析屬性模式....................................................................................76IV*賤.......................................................................................................76I.引言本發明的主題用細節來描述，以滿足法定的要求。然而，該描述本身不試圖限制本專利的范圍。相反，本發明者設想，要求保護的主題也能以其它方式實施，以結合其它當前和未來的技術包括類似于本說明描述的不同的步驟或步驟的組合。此外，雖然術語"步驟"在這里可用于意味著所采用的方法的不同元素，然而該術語不能被解釋為在這里揭示的各步驟之間隱含特定的次序，除非明確地描述了各個步驟的次序。A.示例性計算環境本發明的許多實施例可在計算機上執行。圖1和下面討論旨在提供其中實現本發明的合適計算環境的簡要描述。雖然不是必需，本發明的諸方面能以諸如由如客戶工作站或服務器的計算機上執行的程序模塊的計算機可執行指令的一般上下文中描述。一般而言，程序模塊包括例程、程序、對象、組件、數據結構等，它們執行特定任務或實現特定抽象數據類型。此外，本發明可用其它計算機系統配置實現，包括手持設備、多處理器系統、基于微處理器的系統或可編程消費者電子設備、網絡PC、小型機、大型機等。本發明還能在分布式計算環境中實現，其中任務由通過通信網絡鏈接的遠程處理設備完成。在分布式計算環境中，程序模塊能位于本地或遠程存儲器存儲設備中。如圖1所示，示例性通用計算系統包括傳統的個人計算機20等，它包括處理單元21、系統存儲器22和將包括系統存儲器的各種系統組件耦合到處理單元21的系統總線23。系統總線23可以是若千種總線結構的任一種，包括存儲總線或存儲控制器、外圍總線、以及使用各種總線體系結構的任一種的局部總線。系統存儲器包括只讀存儲器(ROM)24和隨機訪問存儲器(RAM)25。基本輸入/輸出系統26(BIOS)包含如在啟動時幫助在個人計算機20的諸元件之間傳輸信息的基本例程，存儲在ROM24中。個人計算機20還可包括讀寫硬盤(未示出)的硬盤驅動器27、讀寫可移動磁盤29的磁盤驅動器28、讀寫如CDROM或其它光介質的可移動光盤29的光盤驅動器30。硬盤驅動器27、磁盤驅動器28和光盤驅動器30分別通過硬盤驅動器接口32、磁盤驅動器接口33和光盤驅動器接口34連接系統總線23。驅動器及其相關的計算機可讀介質為個人計算機20提供計算機可讀指令、數據結構、程序模塊和其它數據的非易失存儲。雖然這里描述的示例性環境采用硬盤、可移動磁盤29和可移動光盤31，本專業技術人員理解，在示例性操作環境中也能使用可存儲能由計算機訪問的數據的其它類型計算機可讀介質，如盒式磁帶、閃存卡、數字視頻盤、Bernoulli盒式磁帶、隨機存取存儲器(RAM)、只讀存儲器(ROM)等。類似地，示例環境還可包括許多類型的監視設備，如熱敏和安全或火警系統，及其它信息來源。若干程序模塊能存儲在硬盤、磁盤29、光盤31、ROM24或RAM25中，包括操作系統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、存儲器(ROM24和RAM25)、基本輸入/輸出系統(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、MacintoshOS和其它硬件/軟件接口系統中，文件夾是能作為單個信息單元被檢索、移動和處理的文件的集合。這些文件夾進而被組織成稱為"目錄"(在后面詳細討論)的基于樹形的分層結構排列。在如Dos、z/OS和大多數基于Unix的操作系統的其它硬件/軟件接口系統中，術語"目錄"和域"文件夾"是可交替使用的，早期的Apple計算機系統(如AppleIIe)使用術語"類別"來代替目錄；然而在這里使用時所有這些術語被看成是同義語并可交替使用，并旨在還包括對分層信息存儲結構及其文件夾和文件組件的所有其它等價術語的引用。傳統上，目錄(又名文件夾的目錄)是基于樹形的分層結構，其中文件被組合成文件夾，文件夾進而按包括目錄樹的相對節點位置排列。例如，如圖2A所示，基于DOS的文件系統的基本文件夾(或"根目錄")212可包括多個文件夾214，其每一個可以還包括另外的文件夾(如特定文件夾的"子文件夾")216，而這些的每一個又包括另外的文件夾218，直到無限。這些文件夾的每一個可具有一個或多個文件220，雖然在硬件/軟件接口系統級上，文件夾中的各個文件除了它們在樹形分層結構中的位置外沒有什么共同點。不奇怪，將文件組織到文件分層結構的方法間接地反映了用于存儲這些文件的典型存儲介質(如硬盤、軟盤、CD-ROM等)的物理組織。除上述以外，每個文件夾是對其子文件夾和其目錄的容器一即，每個文件夾擁有其子文件夾和文件。例如，當文件夾被硬件/軟件接口系統刪除時，該文件夾的子文件夾和文件也被刪除(在每個子文件夾的情況下還遞歸地包括它自己的子文件夾和文件)。同樣，每個文件一般只由一個文件夾擁有，并且雖然文件能被拷貝且副本位于不同的文件夾，文件的副本本身是不同且獨立單元，它與原始文件無直接連接(如對原始文件的改變在硬件/軟件接口系統級上不反映到副本文件)。因此在這方面，文件和文件夾在本質上是"物理的"，因為文件夾類似于物理容器來處理，而文件作為這些容器中不同且獨立的物理元素來處理。II.用于組織、搜索和共享數據的WINFS存儲平臺本發明結合通過引用結合于此的發明針對用于組織、搜索和共享數據的存儲平臺。本發明的存儲平臺擴展和拓寬了數據平臺，超越上文討論的文件系統及數據庫系統，并被設計成存儲所有類型的數據，包括稱為項目的新格式的數據。A.詞匯表在這里及在權利要求書中使用的術語有下列意義"項目"是能存儲硬件/軟件接口系統可訪問的信息的單元，不象簡單文件，它是具有由硬件/軟件接口系統外殼展現給最終用戶的所有對象共同支持的基本屬性集的對象。項目還具對所有項目類型共同支持的屬性和關系，包括允許引入新屬性和關系的特征(在下面詳細討論)。"操作系統"(OS)是扮作應用程序和計算機硬件之間的中介的特殊程序。在大多數情況下，操作系統包括外殼和內核。"硬件/軟件接口系統"是軟件、或硬件及軟件的組合，它起著在計算機系統的底層硬件組件和在計算機系統上執行的應用程序之間的接口的作用。硬件/軟件接口系統通常包括(在某些實施例中只包括)操作系統。硬件/軟件接口系統還能包括虛擬機管理器(VMM)、公用語言運行庫(CLR)或其功能等效物，Java虛擬機(JVM)或其功能等效物、或在計算機系統的操作系統處或除操作系統外的其它軟件組件。硬件/軟件接口系統的目的是提供用戶能執行應用程序的環境。任何硬件/軟件接口系統的目標是使計算機系統便于使用，并以有效方式利用計算機硬件。B.存儲平臺綜述參考圖3，存儲平臺300包括在數據庫引擎314上實現的數據存儲302。在一個實施例中，數據庫引擎包括帶有對象關系擴展的關系型數據庫引擎。在一個實施例中，關系型數據庫引擎314包括MicrosoftSQLServer關系型數據庫引擎。數據存儲302實現支持數據的組織、搜索、共享、同步和安全的數據模型304。在如模式340等模式中描述特定的數據類型，并且存儲平臺300提供用于采用這些模式并用于擴展這些模式的工具346，這在后面詳述。在數據存儲302中實現的改變跟蹤機制306提供跟蹤數據存儲的改變的能力。數據存儲302還提供安全能力308和升級/降級能力310，均在后文詳述。數據存儲302還提供一組應用程序接口312，以向利用該存儲平臺的其它存儲平臺組件和應用程序(如應用程序350a，350b和350c)展現數據存儲302的能力。本發明的存儲平臺還包括應用程序接口(API)322，使如應用程序350a，350b，和350c等應用程序能訪問存儲平臺的所有上述功能并能訪問在模式中描述的數據。應用程序能結合如OLEOBAPI324和MicrosoftWindowsWin32API326等其它API來使用存儲平臺API322。本發明的存儲平臺300能向應用程序提供各種服務，包括便于在用戶或系統之間共享數據的同步服務330。例如，同步服務330允許與具有與數據存儲302相同格式的其它數據存儲340的互操作，并訪問具有其它格式的數據存儲342。存儲平臺300還提供允許數據存儲302與如WindowsNTFS文件系統318等現有文件系統的互操作的文件系統能力。在至少某些實施例中，存儲平臺320還能向應用程序提供另外的能力，以允許對數據起作用并允許與其它系統的交互。這些能力可體現在如InfoAgent服務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、Intl6、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具有Intl6類型的屬性Age(年齡)，則得出，B的任何實例必須兼有Name和Age。類型的分層結構可被設想成帶有在根上的單個超類型的樹。根的分枝提供第一級子類型，該級分枝提供第二級子類型，如此等等，直到本身不再具有任何子類型的葉端(leaf-most)子類型。樹不限于統一深度，但不能包含任何回路。給定的類型可具有零個或許多子類型和零個或一個超類型。給定實例可最多符合一個類型以及該類型的超類型。換言之，對樹中任一級處給定的實例，該實例最多可符合該級上的一個子類型。如果一類型的實例必須也是該類型的子類型的實例，則該類型可說成是抽象。1.項目項目是可存儲的信息的單元，不象簡單的文件，它是具有由存儲平臺向最終用戶或應用程序展現的所有對象共同支持的基本屬性集的對象。項目也具有所有項目類型共同支持的屬性和關系，包括如下所述允許引入新的屬性和關系的特征。項目是公用操作的對象，如拷貝、刪除、移動、打開、打印、備份、恢復、復制等。項目是能被存儲和檢索的單元，且由存儲平臺處理的可存儲信息的所有形式作為項目、項目的屬性、或項目之間的關系存在，其每個在下面更詳細討論。項目旨在表示顯示的且容易理解的數據單元，如聯系人(Contacts)、人(People)、服務(Services)、位置(Locations)、(各種類型的)文檔(Documents)等。圖5A是示出項目的結構的框圖。該項目的不合格的名是"Location"。該項目的合格名是"Core丄ocation"，它表明，此項目結構被定義成Core(核心)模式中的特定類型的項目(Core模式在下面詳細討論)。Location項目具有多個屬性，包括EAddress(電子郵件地址)、MetropolitanRegion(都市地區)、Neighborhood(街坊)、和PostalAddress(郵政地址)。每個項目的特定類型屬性緊跟屬性名地表示，并用冒號(":")與屬性名分開。在類型名的右邊，對該屬性類型允許的值的數量在方括號("[]")之間表示，其中冒號(":")右邊的星號("*")表示未規定的和/或無限制的數量("許多")。冒號右邊的"1"表明最多一個值。冒號左邊的零("0")表明該屬性是可任選的(可以完全沒有值)。冒號左邊的"1"表明必須至少有一個值(該屬性是必須的)。Neighborhood和MetropolitanRegin均是"nvarchar"類型(或等效類型)，它是預定義的數據類型或"簡單類型"(這里用缺少大寫來表示)。然而EAddress和PostalAddress分別是類型EAddress和PostalAddress的已定義類型或"復雜類型"(這里用大寫標記)的屬性。復雜類型是從一個或多個簡單數據類型和/或從其它復雜類型導出的類型。一個項目的屬性的復雜類型還構成"嵌套元素"，因為復雜類型的細節嵌套入直接項目中以定義其屬性，而屬于這些復雜類型的信息用具有這些屬性的項目來維持(在該項目的邊界內，如后面討論)。類型的這些概念是眾知的，且容易被本專業技術人員理解。圖5B是示出復雜屬性類型PostalAddress和EAddress的框圖。PostalAddress屬性類型定義，屬性類型PostalAddress的項目可期望有零個或一個City(城市)值、零個或一個CountryCode(國家代碼)值、零個或一個MailStop(國家代碼)值、和任何數量(零到許多)PostalAddress類型等等。以此方式，定義了一項目中的特定屬性的數據的形狀。EAddress屬性類型如所示類似地定義。雖然這里在本申請中可任選地使用，表示在Location項目中復雜類型的另一方法是用其中列出的每個復雜類型的各個屬性得出該項目。圖5C是示出Location項目的框圖，在其中進一步描述其復雜類型。然而應該理解，在此圖5C中Location項目的另一種表示恰是對圖5A中示出的同一個項目。本發明的存儲平臺還允許子分類(subtyping)，從而一個屬性類能是另一個的子類型(其中一個屬性類繼承另一個父屬性類型的屬性)。類似于但不同于屬性及它們的屬性類型，項目繼承性地表示其自己的Item(項目)類型，它也是子分類的主題。換言之，本發明的若干實施例中的存儲平臺允許一個項目是另一個項目的子類型(從而一個項目繼承另一個父項目的屬性)。此外，對本發明的各種實施例，每個項目是"Item"項目類型的子類型，后者是在基礎模式中找到的第一和基本的項目類型(基礎模式也在后面詳細討論)。圖6A示出一項目(在此實例中為Location項目)為在基礎模式中找到的Item項目類型的子類型。在此圖中，箭頭表示Location項目(如所有其它項目)是Item項目類型的子類型。作為從中導出所有其它項目的基本項目的Item項目類型具有若干如Itemld的重要屬性和各種時間標記，從而定義了操作系統中所有項目的標準屬性。在本圖中，Item項目類型的這些屬性被Location所繼承，并從而成為Location的屬性。表示從Item項目類型繼承的Location項目中屬性的另一種方法是用來自其中列出的父項目的每個屬性類型的各個屬性得出Location。圖6B是示出Location項目的框圖，其中除了其直接屬性外描述其繼承的類型。應注意和理解，此項目是圖5A中示出的同一項目，雖然在本圖中，Location用所有其屬性示出，包括直接屬性(在本圖及圖5A中示出)和繼承屬性(在本圖中示出但未在圖5A中示出)(而在圖5A中，通過用箭頭示出Location項目是Item項目類型的子類型來引用這些屬性)。項目是獨立的對象，因而若刪除一項目，也刪除項目的所有直接和繼承的屬性。類似地，當檢索一項目時，檢索的是該項目及其所有直接和繼承的屬性(包括屬于其復雜屬性類型的信息)。本發明的某些實施例可使人們能在檢索特定項目時請求屬性的子集;然而對許多那樣的實施例默認的是在檢索時向項目提供所有其直接和繼承的屬性。此外，項目的屬性也能通過添加新的屬性到該項目的類型的現有屬性而加以擴展。這些"擴展"其后是該項目的真實屬性，且該項目類型的子類型可自動地包括擴展屬性。項目的"邊界"由其屬性(包括復雜屬性類型、擴展等)來表示。項目的邊界也表示在項目上執行的操作的限制，包括拷貝、刪除、移動、創建等。例如在本發明的若干實施例中，當拷貝一項目時，在該項目邊界之內的所有內容也被拷貝。對每個項目，邊界包括下列項目的項目類型，且若該項目是另一項目的子類型(如在所有項目從基礎模式的單個項目和項目類型導出的本發明的若干實施例的情況下)，是任何適用的子類型信息(即屬于父項目類型的信息)。若要拷貝的原始項目是另一項目的子類型，該副本也能是該相同項目的子類型。項目的復雜類型屬性和擴展(如果有的話)。若原始項目具有復雜類型(原來的或擴展的)的屬性，副本也能具有相同的復雜類型。在"所有權關系"上的項目的記錄，S卩，本項目("擁有項目")擁有什么其它項目("目錄項目")的項目擁有列表。這特別關系到下面充分討論的項目文件夾和下面說到的所有項目必須至少屬于一個項目文件夾的規則。此外，關于嵌入項目(下列更充分討論)，一個嵌入項目被認為是其中嵌入如拷貝、刪除等操作的項目的一部分。2.項目標識在全局項目空間中用ItemID唯一地標識項目。Base.Item類型定義了存儲該項目身份的類型GUID的字段ItemID。一項目必須在數據存儲中準確只有一個身份。項目引用是包含定位和標識項目的信息的數據結構。在該數據模型中，定義名為ItemReference的抽象類型，從中導出所有項目引用類型。ItemReference(項目引用)類型定義了名為Resolve(解析)的虛擬方法。Resolve方法解析ItemReference并返回一項目。此方法被ItemReference的具體子類型所覆蓋，后者實現給定一引用時檢索項目的功能。調用Resolve方法作為存儲平臺API322的一部分。ItemIDReference(項目ID引用)是ItemReference的子類型。它定義了Locator(定位器)和ItemID字段。Locator字段命名(即標識)項目的域。它由能將Locator的值解析到項目域的定位器解析方法來處理。ItemID字段是ItemID類型。ItemPathReference(項目路徑引用)是定義Locator和Path(路徑)字段的ItemReference的特殊化。Locator字段標識一項目域。它由能將Locator的值解析到項目域的定位器解析方法來處理。Path字段包含以由Locator提供的項目域為根的存儲平臺名字空間中的(相對)路徑。不能在集合運算中使用此類引用。引用一般必須通過路徑解析過程來解析。存儲平臺API322的Resolve方法提供此功能。上面討論的引用形式通過圖11示出的引用類型分層結構表示。從這些類型繼承的另外引用類型能在模式中定義。它們能在關系聲明中用作目標字段的類型。3.項目文件夾和類別如下面將更充分討論的，項目組能組織成稱為項目文件夾(不要與文件的文件夾混淆)的特殊項目。然而不象大多數文件系統，一個項目可屬于多個項目文件夾，使得當一個項目在一個項目文件夾中被訪問和修訂時，此修訂的項目隨后能直接從另一項目文件夾訪問。實質上，雖然對一個項目的訪問可從不同的項目文件夾發生，事實上真正訪問的是同一個項目。然而，一個項目文件夾不必擁有其所有成員項目，或簡單地結合其它文件夾共同擁有項目，使得一個項目文件夾的刪除不必要導致項目的刪除。然而在本發明的若干實施例中，一個項目必須至少屬于一個項目文件夾，使得如果特定項目的唯一文件夾被刪除，則對某些實施例，該項目被自動被刪除，或在另外實施例中，該項目自動地成為默認項目文件夾的成員("TrashCan(垃圾箱)"文件夾在概念上類似于在各種基于文件和文件夾的系統中使用的類似名字文件夾。)如下面更充分討論的，項目也可屬于基于共同描述的特征的類別，特征如(a)項目類型(或類型)，(b)特定的直接或繼承的屬性(或屬性)，或(c)對應于項目屬性的特定值(或值)。例如，包括個人聯系人信息的特定屬性的項目可自動屬于聯系人(Contact)類別，具有聯系人信息屬性的任何項目看來也自動屬于此類別。同樣，具有"NewYorkCity(紐約市)"值的位置屬性的任何項目可自動屬于紐約市類別。類別在概念上不同于項目文件夾之處在于，項目文件夾可包括互相無關的項目(即無共同的描述的特征)，而在類別中的每個項目具有對該類別描述的共同類型、屬性或值("共同性")，正是這個共同性形成對它與該類別中其它項目或那些項目之間的關系的基礎。此外，雖然在特定文件夾中的項目的成員資格基于該項目的任何特定方面不是強制的，然而對某些實施例，具有在分類上與一類別相關的共同性的所有項目在硬件/軟件接口系統級上可自動地成為該類別的成員。概念上，類別也能看作虛擬項目文件夾，其成員資格基于特定查詢(如在數據庫的上下文中)的結果，而滿足此查詢的條件(由類別的共同性確定)的項目應構成該類別的成員資格。圖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(目錄弓l用)進而是IdentityKey的子類型。b)核心模式本發明的存儲平臺的各種實施例還包括為頂層項目類型結構提供概念框架的核心(Core)模式。圖8A是示出核心模式中的項目的框圖，而圖8B是示出核心模式中屬性類型的框圖。在帶不同擴展名(*.com、*.exe、*.bat、氣sys等)的文件和在基于文件和文件夾系統中其它準則之間作出的區分是類似于核心模式的功能。在基于項目的硬件/軟件接口系統中，核心模式定義了一組核心項目類型，它們直接(按項目類型)或間接地(按項目子類型)將所有項目特征化成基于項目的硬件/軟件接口系統理解并能以預定或可預計的方式直接處理的一個或多個核心模式項目類型。預定的項目類型反映了在基于項目的硬件/軟件接口系統中最常用的項目，且因此通過理解這些包括核心模式的預定項目類型的基于項目的硬件/軟件接口系統獲取有效性級別。在某些實施例中，核心模式是不可擴展的，即，沒有另外的類型可直接從基礎模式中的項目類型子分類，除非作為核心模式的一部分的特定的預定導出的項目類型。通過禁止對核心模式的擴展(即，通過禁止向核心模式添加新的項目)，存儲平臺托管核心模式項目類型的使用，因為每個后續的項目類型必須是核心模式項目類型的子類型。此結構允許在保持具有一組預定的核心項目類型的益處的同時在定義另外項目類型時有合理程度的靈活性。參考圖8A，對本發明的各種實施例，由核心模式支持的特定項目類型可包括下列的一個或多個Category(類別)此項目類型(及從中導出的子類型)的項目代表在基于項目的硬件/軟件接口系統中的有效類別。Commodity(物品)作為值的可標識事物的項目。Device(設備)具有支持信息處理能力的邏輯結構的項目。Document(文檔)具有不能由基于項目的硬件/軟件接口系統解釋而相反由對應于文檔類型的應用程序解釋的內容的項目。Event(事件)記錄環境中某些發生事件的項目。Location(位置)代表物理位置(如地理位置)的項目。Message(消息)在兩個或更多主體(下面定義)之間通信的項目。PrincipaK主體)具有除Itemld之外的至少一個肯定可驗證身份(如，個人、組織、組、家庭、作者、服務等的標識)的項目。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(名字)屬性中指定關系名下列之一的關系類型持有、嵌入、弓l用。這是在Type(類型)屬性中指定的。源和目標端點。每個端點指定所引用項目的名和類型。源端點字段一般是ItemID(項目ID)類型(未聲明)，而必須引用在與關系實例同一數據存儲中的項目。對持有和嵌入關系，目標端點字段必須是ItemIDReference(項目ID引用)類型，且它必須引用在與關系實例相同存儲中的項目。對引用關系，目標端點能是任何ItemReference(項目引用)類型，并能引用在其它存儲平臺數據存儲中的項目。能可任選地聲明標量或PropertyBase(屬性基礎)類型的一個或多個字段。這些字段能包含與該關系相關聯的數據。關系實例被存儲在全局關系表中。每個關系實例唯一地由組合(源ItemID、關系ID)標識。對所有源自給定項目的關系，在給定的源ItemID中關系ID是唯一的，而不管它們的類型。源項目是關系的擁有者。而被指定為擁有者的項目控制關系的生命周期，關系本身和與它們相關的項目分開。存儲平臺API322提供用于展現與項目相關聯的關系的機制。這里是一個關系聲明的例子。<RdationshipName="Employment"BaseType="Reference"><SourceName="Employee"ItemType="Contact.Person，V><TargetName="Employer"ItemType-"ContactOrganization"ReferenceType="ItemIDReference"/><PropertyName="StartDate，，Type="thestorageplatformTypes.DateTime"/>〈PropertyName="EndDate"Type=，，thestorageplatformTypes.DateTime"/>〈PropertyName="Office"Type="thestorageplatformTypes.DateTime"/></Relationship>這是引用關系的例子。若由源引用所引用的個人項目不存在，則不能創建該關系。而且若該個人項目被刪除，在個人和組織之間的關系實例也被刪除。然而若組織項目被刪除，關系不被刪除，而它是搖擺不定的。b)持有關系持有關系用于基于目標項目的生命周期管理來對引用計數建模。一個項目可以是用于對項目的零個或多個關系的源端點。不是嵌入項目的項目可以是在一個或多個持有關系中的目標項目。目標端點引用類型必須是ItemIDReference，且它必須引用在與關系實例相同的存儲中的項目。持有關系實施目標端點的生命周期管理。持有關系實例和作為目標的項目的創建是原子操作。可以創建將同一項目作為目標的另外的持有關系實例。當具有給定項目作為目標端點的最后一個持有關系實例被刪除時，該目標項目也被刪除。在關系聲明中指定的端點項目的類型一般在創建該關系的實例時強制。在關系建立之后端點項目的類型不能改變。持有關系在形成項目的名字空間中起著關鍵作用。它們包含"Name(名字)"屬性，它定義目標項目相對于源項目的名字。對所有源自給定項目的持有關系，相對名字是唯一的。從根項目開始到給定項目的相對名字的有序類表形成該項目的全名。持有關系形成一有向非循環圖(DAG)。在創建持有關系時，系統確保不產生回路，從而確保項目的名字空間形成DAG。雖然持有關系控制目標項目的生命周期，它不控制目標端點項目的操作的一致性。目標項目在操作上獨立于通過持有關系擁有它的項目。在作為持有關系的源的項目上的拷貝、移動、備份和其它操作不影響作為同一關系的目標的項目一例如，備份文件夾項目不自動地備份該文件夾中所有項目(FolderMember(文件夾成員)關系中的目標)。下面是持有關系的例子(RelationshipName=，，FolderMembers"BaseType=，，Holding，，><SourceName=，，Folder"ItemType="Base.Folder7>〈TargetName="Item"ItemType="Base.Item，，ReferenceType="ItemIDReference"/></Rdationship>FolderMember關系使文件夾的概念成為項目的類屬集合。C)嵌入關系嵌入關系將目標項目的生命周期的排外控制的概念模型化。它們允許合成項目的概念。嵌入關系實例和作為目標的項目的創建是原子操作。一個項目能是零個或多個嵌入關系的源。然而一個項目能是一個且僅是一個嵌入關系的目標。作為嵌入關系的目標的項目不能是持有關系的目標。目標端點引用類型必須是ItemIDReference，且它必須引用在與關系實例相同數據存儲中的項目。在關系聲明中指定的端點項目的類型一般在創建該關系的實例時強制。在關系建立之后端點的類型不能改變。嵌入關系控制該目標端點的操作一致性。例如，串行化項目的操作可包括串行化所有源自該項目及所有其目標的所有嵌入關系；拷貝一項目也拷貝所有它的嵌入項目。下面是示例聲明(RelationshipName=，，ArchiveMembers"BaseType-，，Embedding">〈SourceName="Archive"ItemType="Zip,Archive"/><TargetName="Member"ItemType="Base'Item，，ReferenceType="ItemIDReference"/><PropertyName-"ZipSize"Type="thestorageplatformTypes.bigint"/>〈PropertyName="SizeReduction"Type=，，thestorageplatformTypes.float"/></Relationship>d)引用關系引用關系不控制它引用的項目的生命周期。尤其是，引用關系不保證目標的存在，也不保證目標的類型如關系聲明中指定的那樣。這意味著引用關系能是搖擺不定的。而且引用關系能引用在其它數據存儲中的項目。引用關系能看作類似于網頁上的鏈接的概念。下面是引用關系說明的例子(RelationshipName="DocumentAuthor"BaseType-"Reference"><SourcItemType-"Document"ItemType="Base.Document7><TargetItemType-"Author"ItemType="Base.Author"ReferenceType="ItemIDReference"/><PropertyType="Role"Type="Core.CategoryRef，/>〈PropertyType-"DisplayName"Type-"thestorageplatformTypes.nvarchar(256)"/></Relationship>在目標的端點允許任何引用類型。參與引用關系的項目可以是任何項目類型。引用關系用于對項目之間的大多數非生命周期管理關系建模。因為不強制目標的存在，引用關系便于對松散耦合的關系建模。引用關系能用于在其它存儲，包括在其它計算機上的存儲中的目標項目。e)規則和約束下列附加規則和約束應用于關系一個項目必須是(僅一個嵌入關系)或(一個或多個持有關系)的目標。一個例外是根項目。一個項目能是零個或多個引用關系的目標。作為嵌入關系目標的項目不能是持有關系的源。它能是引用關系的源。一個項目若是從文件升級，則不能是持有關系的源。它能是嵌入關系和引用關系的源。一個從文件升級的項目不能是嵌入關系的目標。f)關系的排序在一至少個實施例中，本發明的存儲平臺支持關系的排序。通過在基本關系定義中名為"Order(排序)"的屬性完成排序。在Order字段中無唯一性約束。不保證帶有同一"Order"屬性值的關系的次序，然而保證，它們能排序在帶較低"Order"值的關系之后并在帶較高"Order"字段值的關系之前。應用程序通過在在組合(SourceItemID，RelationshipID,Order)上排序得到默認次序的關系。源自給定項目的所有關系實例被排序成單個集合，而不管在集合中關系的類型。然而這保證，給定類型(如，FolderMembers(文件夾成員))的所有關系是給定項目的關系集合的已排序子集。用于處理關系的數據存儲API312實現一組支持關系的排序的操作。引入下列術語幫助解釋那些操作-RelFirst是有序集合中帶次序值OrdFirst的第一個關系；RdLast是有序集合帶次序值OrdLast的最后一個關系；RdX是集合中帶次序值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之間，但不包括這兩個值。如前提到，每個項目必須是項目文f^夾的成員。按照關系，每個項目必須與一項目文件夾有一關系。在本發明的若干實施例中，某些關系由在諸項目之間存在的關系表示。如對本發明的各實施例的實現，關系提供一有向的二元關系，它由一個項目(源)延伸到另一項目(目標)。關系由源項目(延伸它的項目)擁有，因此若源被移除則關系被移除(如在源項目被刪除時關系被刪除)。此外在某些情況下，關系可共享(共同擁有的)目標項目的擁有權，且那樣的擁有權僅可反映在關系的IsOwned(被擁有)屬性(或其等效屬性)中(如圖7對關系屬性類型所示)。在這些實施例中，創建一新的IsOwned關系自動遞增該目標上的引用計數，而刪除那樣的關系可遞減該目標項目上的引用計數。對這些特定實施例，若項目具有大于0的引用計數，則繼續存在，若項目計數達到O則自動刪除。再一次，項目文件夾是具有(或能具有)與其它項目的一組關系的項目，這些其它項目包括項目文件夾的成員資格。關系的其它實際實現是可能的，并由本發明構想來實現這里描述的功能。不管實際的實現如何，關系是從一個對象到另一對象的可選擇的連接。一個項目屬于一個以上項目文件夾以及一個或多個類別，而不論這些項目、文件夾和類別是公有的或私有的能力是由給予基于項目的結構中的存在(或缺乏)的意義所確定的。這些邏輯關系是分配給一組關系的意義，而不論其專門用來實現這里所述功能的物理實現如何。邏輯關系是在項目及其文件夾或類別之間建立的(或相反)，因為本質上項目文件夾和類別的每一個都是特定類型的項目。因此，能象其它項目一樣地對項目文件夾和類別起作用(拷貝、添加到電子郵件消息中、嵌入文檔等等，而無限制)，而項目文件夾和類別能象其它項目一樣使用相同的機制串行化和解串行化(導入和導出)。(例如在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是私有的，且不與項目文件夾卯O、其另外的成員卯2、906、及可訪問項目文件夾900的任何其它項目文件夾、類另!J、或項目(未示出)共享。與其到項目902和904的關系(或沒有這些關系)相反，項目文件夾900具有從其本身到項目906的關系916，且項目906具有回到項目文件夾900的關系926，一起表明項目906是公有的，且能對文件夾卯0、其成員卯2和904、和可訪問項目文件夾900的任何其它項目文件夾、類別、或項目(未示出)共享，且項目文件夾900是公有的，并與項目906共享其成員資格信息。如前討論，在項目文件夾中的項目不需要共享共同性，因為項目文件夾未被"描述"。另一方面，類別由對所有其成員項目共同的共同性描述。因此，類別的成員資格固有地限于具有所描述的共同性的項目，且在某些實施例中，滿足類別的描述的所有項目自動地成為該類別的成員。因此，盡管項目文件夾允許由其成員資格來表示不重要的類型結構，類別基于定義的共同性來允許成員資格。當然，類別描述本質上是邏輯的，因而類別可通過類型、屬性和/或值的任何邏輯表示來描述。例如，對一類別的邏輯表示可以是其成員資格，以包括具有兩個屬性之一或兩者的項目。若這些對類別描述的屬性是"A"和"B"，則該類別的成員資格可包括具有屬性A而沒有B的項目、具有屬性B而沒有A的項目、及兼有屬性A和B的項目。通過邏輯運算符"OR(或)"來描述屬性的邏輯表示，其中由類別描述成員組是具有屬性AORB的項目。如本領域的技術人員所理解的，也能使用類似的邏輯運算符(包括但不限于單獨的"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的關系(或沒有此關系)相反，類別IOOO具有從其本身到項目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類型<TypeName-"Base.Extension"lsAbstract="Tme"><PropetyName-"ltemlD"Type-"thestorageplatformTypes.uniqueidentified"Nullable-"false"MultiValued="false7><PropertyName="ExtensionlD"Type="thestorageplatformTypes.uniqueidentified"Nullable-"false"MultiValued="false7></Type>ItemID字段包含與該擴展關聯的項目的ItemlD。帶此ItemID的項目必須存在。若帶給定ItemID的項目不存在，則不能創建擴展。當項目被刪除，帶同一ItemID的所有擴展被刪除。二元組(ItemID，ExtensionID)唯一地標識了擴展實例。擴展類型的結構類似于項目類型的結構擴展類型具有字段；字段可以是原語或嵌套元素類型；以及擴展類型可被子分類。下列限制應用于擴展類型擴展不能是關系的源和目標；擴展類型實例不能獨立于項目存在；以及擴展類型不能用作在存儲平臺類型定義中的字段類型對能與給定的項目類型關聯的擴展的類型沒有約束。任何擴展類型允許擴展任何項目類型。當多個擴展實例被附加到一個項目，它們在結構和行為上彼此獨立。擴展實例被分別存儲并從項目訪問。所有擴展類型實例可從全局擴展視圖訪問。能組成一有效的查詢，它將返回給定類型的擴展的所有實例，而不管它們關聯什么類型的項目。存儲平臺API提供可存儲、檢索和修改項目擴展的編程模型。擴展類型可是使用存儲平臺的單個繼承模型來子分類的類型。從一個擴展類型導出創建新的擴展類型。一個擴展的結構或行為不能覆蓋或替代項目類型分層結構的結構或行為。類似于項目類型，擴展類型實例能通過與該擴展類型關聯的視圖直接訪問。擴展的ItemID表明，它們屬于哪個項目，并能用于從全局項目視圖檢索對應的項目對象。為操作一致性的目的，擴展被考慮成項目的一部分。拷貝/移動、備份/恢復和存儲平臺定義的其它常用操作可以在作為項目的一部分的擴展上操作。考慮下述例子。在Windows類型組中定義Contact(聯系人)類型。<TypeName="Contact"BaseType="Base.Item"><PropertyName="Name"Type="String"Nullable-"false"MultiValued="false7>^PropertyName="Address"Type="Address"Nullable-"true"MultiV3lued="false7></Type>CRM(客戶關系管理)應用程序幵發者喜歡將CRM應用程序擴展附加到存儲在存儲平臺中的聯系人。應用程序開發者定義包含應用程序能處理的附加數據結構的CRM擴展。<TypeName-"CRMExtension"BaseType="Base.Extension">■^PropertyName="CustomerlD"Type="String"Nullal^le="false"MultiVslued="f3lse7></Type>HR應用程序開發者希望也將附加數據附加到聯系人。此數據獨立于CRM應用程序數據。應用程序開發者還可創建一擴展<TypeName-"HRExtension"EBaseType-"Base,Extension"><PropertyName="EmployeelD"Type="String"Nullable-"false"MultiValued="false7></Type>CRMExtension和HRExtension是能附加到聯系人項目的兩個獨立擴展。它們能彼此獨立地創建和訪問。在上述例子中，CRMExtension類型的字段和方法不能覆蓋聯系人分層結構的字段和方法。應注意，CRMExtension類型的實例能被附加到不同于聯系人的項目類型。在檢索聯系人項目時，不自動地檢索它的項目擴展。給定聯系人項目，可通過查詢全局擴展視圖以尋找帶同一ItemID的擴展來訪問其有關的項目擴展。可通過CRMExtension類型視圖來訪問系統中所有的CRMExtension擴展，而不論它們屬于什么項目。一個項目的所有項目擴展共享同一項目id。在上述例子中，聯系人項目實例和附加的CRMExtension和HRExtension實例共享同一ItemID。下面的表總結了在Item(項目)、Extension(擴展)和Neste犯lement(嵌套元素)類型之間的相似性和差別項目、項目擴展與嵌套元素<table>tableseeoriginaldocumentpage44</column></row><table>關系語義能具有與項目的關與項目擴展無關系與嵌套元素無關系系與項目的能通過持有嵌入和通常只能通過擴展通過字段來與項目關聯軟關系與其它項目來相關。擴展語義類相關。嵌套元素是項相關似于嵌入項目語義目的一部分b)擴展NestedElement類型嵌套元素類型不用與項目類型相同的機制擴展。嵌套元素的擴展用與嵌套元素類型字段相同的機制存儲和訪問。數據模型定義了名為Element(元素)的嵌套元素類型的根。<TypeName="Element"lsAbstract="True"><PropertyName-"ElementlD"Type="thestorageplatformTypes.uniqueidentifier"Null3ble="f3lse"MultiValued="false"/></Type>NestedElement類型從此類型繼承。NestedElement元素類型另外定義一字段，它是多組元素。<TypeName="NestedElement"BaseType="Base.Element"lsAbstract='True"><PropertyName="Extensions"Type="Base.Element"Nullable-"false"MultiValued="true7></Type>NestedElement擴展在下面方面不同于項目擴展-嵌套元素擴展不是擴展類型。它們不屬于以Base.Extension類型為根的擴展類型分層結構。嵌套元素擴展與該項目的其它字段一起存儲，且不是全局可訪問的一不能組成檢索給定擴展類型的所有實例的査詢。象存儲其它嵌套元素(或項目)一樣地存儲這些擴展。象其它的嵌套組，NestedElement擴展被存在UDT中。它們可通過嵌套元素類型的Extension(擴展)字段來訪問。<table>tableseeoriginaldocumentpage46</column></row><table>如上提到，數據存儲在數據庫引擎上實現。在本實施例中，數據庫引擎包括諸如MicrosoftSQLServer引擎等實現SQL査詢語言、帶有對象關系擴展的關系數據庫引擎。本節按照本實施例，描述數據存儲實現的數據模型到關系存儲的映射，在邏輯API上提供由存儲平臺的客戶機使用的信息。然而可以理解，當采用不同的數據庫引擎時可采用不同的映射。確實，除了在關系型數據庫引擎上實現存儲平臺概念數據模型之外，也可在其它類型數據庫上實現，如面向對象和XML數據庫。面向對象(00)數據庫系統為編程語言對象(如C++、Java)提供持續性和事務。"項目"的存儲平臺概念可很好地映射到面向對象系統中的對象，雖然嵌入的集合必須添加給對象。類似繼承性和嵌套元素類型等其它存儲平臺類型概念也映射到面向對象類型的系統。面向對象系統通常已經支持對象身份；因此，項目身份可被映射到對象身份。項目的行為(操作)很好地映射到對象方法。然而，面向對象的系統通常缺乏組織能力并在搜索方面很差。而且，面向對象的系統不提供對非結構化和半結構化數據的支持。為支持這里描述的完全存儲平臺數據模型，象關系、文件夾和擴展等概念需要添加到對象數據模型。此外，需要實現如升級、同步、通知和安全性等機制。類似于面向對象的系統，基于XSD(XML模式定義)的XML數據庫支持基于單繼承類型的系統。本發明的項目類型系統可映射到XSD類型模型。XSD也不提供對行為的支持。項目的XSD必須增添項目的行為。XML數據庫處理單個XSD文檔并缺乏組織和拓寬搜索能力。如面向對象數據庫那樣，為支持這里描述的數據模型，如關系和文件夾等其它概念需要被結合到該XML數據庫；而且需要實現如同步、通知和安全性等機制。關于下面小節，提供少量圖示以便于一般的信息揭示圖13是示出通知機制的圖示。圖14是示出兩個事務均將新記錄插入同一B樹的例子的圖示。圖15示出數據改變檢測過程。圖16示出示例性目錄樹。圖17示出其中基于目錄的文件系統的現有文件夾被移動到存儲平臺數據存儲中。1.使用UDT的數據存儲實現在本實施例中，在一個實施例中包括MicrosoftSQLServer引擎的關系型數據庫引擎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的"isof(類型)"的操作符的項目類型的子類型來過濾搜索。然而，由于在本實施例中牽涉到與這一方法相關聯的額外開銷，由頂級類型將各項目劃分，使得每個類型"家族"的項目存儲到單獨的表中。在此劃分模式中，對每個直接從Base.Item繼承的項目類型創建一個表。如上所述，繼承下面這些的類型使用類型的可替代性存儲在合適的類型家族表中。只有從Base.Item的第一級繼承被專門地處理。使用一"陰影"表存儲所有項目的全局可搜索屬性的副本。此表可由存儲平臺API的Update()方法維護，通過此方法作出所有數據的改變。不象類型家族表，此全局項目表只包含該項目的頂級標量屬性，而不是全UDT項目對象。全局項目表允許通過展現ItemID和TypeID(類型ID)導航到存儲在類型家族表中的項目對象。ItemlD通常唯一地標識數據存儲中的項目。可使用這里未予描述的元數據將TypeID映射到類型名和包含該項目的視圖。由于通過其ItemID尋找項目在全局項目表的上下文及其它情況下都是常用操作，因此給定了項目的Itemld，提供GetltemO函數來檢索項目對象。為便于訪問和盡可能地隱藏實現的細節，項目的所有查詢可以對照在上述項目的表上構建的視圖進行。具體說來，對每個項目類型針對合適類型的家族表創建視圖。這些類型視圖可選擇相關聯的類型，包括子類型的所有項目。為方便起見，除了UDT對象，視圖能對包括繼承字段的該類型的所有頂級域展現列。3.擴展映射擴展非常類似于項目，且具有某些相同要求。如支持繼承性的另一根類型，擴展受到存儲中許多同樣的考慮和折衷比較。為此，對擴展應用類似的類型家族映射，而不是單個表方法。當然，在其它實施例中，可使用單個表方法。在本實施例中，擴展通過ItemID僅與一個項目關聯，并包含在項目的上下文中唯一的ExtensionID。如同項目一樣，給定包括ItemID和ExtensionID對的身份，可提供一函數用于檢索擴展。類似于項目類型視圖，對每個擴展類型可創建視圖。4.嵌套元素映射嵌套元素是可嵌入到項目、擴展、關系、或其它嵌套元素以形成深嵌套結構的類型。類似于項目和擴展，嵌套元素作為UDT實現，但它們存儲在項目和擴展中。因此，嵌套元素沒有超越它們的項目和擴展容器的映射的存儲映射。換言之，在系統中沒有直接存儲NestedElement類型的實例的表，且沒有專門用于嵌套元素的視圖。5.對象身份在數據模型中的每一實體，即每個項目、擴展和關系具有唯一的關鍵字值。一個項目由其Itemld唯一地標識。擴展由合成關鍵字(Itemld，Extensionld)唯一地標識。關系由合成關鍵字(Itemld,Relationld)標識。Itemld，Extensionld和Relationshipld均是GUID值。6.SQL對象命名在數據存儲中創建的所有對象可存儲在從存儲平臺模式名字導出的SQL模式名字中。例如，存儲平臺基礎模式(常稱"基礎")可產生在"[System.Storage]"SQL模式中的類型，如"[System.Stomge].Item"。產生的名字可用限定詞加前綴以消除命名的沖突。在合適處可使用驚嘆號(！)作為名字的每個邏輯部分的分割符。下面表概括了在數據存儲用于對象的命名習慣。與用于訪問數據存儲中的實例的修飾的命名習慣一起列出每個模式元素(項目、擴展、關系和視圖)。<table>tableseeoriginaldocumentpage50</column></row><table>7.列命名當映射任一對象模型到存儲時，由于與應用程序對象一起存儲的附加信息，有可能發生命名沖突。為避免命名沖突，所有非類型的特定列(不直接映射到類型聲明中的命名的屬性的列)用下劃線字符(_)加前綴。在本實施例中，下劃線字符(_)不允許作為任何標識符屬性的開始字符。此外，為統一在CLR和數據存儲之間的命名，存儲平臺類型或模式元素的所有屬性(關系等)應具有大寫的第一字符。8.搜索視圖由存儲平臺提供視圖，用于搜索存儲的內容。對每個項目和擴展類型提供SQL視圖。此外，提供視圖以支持關系和視圖(由數據模型定義)。所有SQL視圖和在存儲平臺中的底層表是只讀的。下面將更充分描述，使用存儲平臺API的Update0方法可存儲或改變數據。在存儲平臺模式中直接定義的每個視圖(由模式設計者定義，而非由存儲平臺自動地生成)可由命名的SQL視圖[〈schema-name〉].[View!〈view-name〉]訪問。例如，在模式"AcmePublisher.Books"中名為"BookSales"的視圖可使用名字"[AcmePublisher.Books].[View舊ookSales]來訪問。因為視圖的輸出格式在每一視圖的基礎上是自定義的(由定義視圖的那一方提供的任意查詢確定的)，列基于模式視圖定義被直接映射。存儲平臺數據存儲中的所有SQL搜索視圖使用列的下述排序習慣如ltemld、Elementld、Relationship^等的視圖結果的邏輯"關鍵字"歹U如Typeld等關于結果類型的元數據信息。改變如CreateVersion(創建版本)、UpdateVersion(更新版本)等跟蹤列類型專用的列(聲明的類型的屬性)類型專用的視圖(家族視圖)也包含返回對象的對象列每個類型家族的成員可使用一系列項目視圖來搜索，在數據存儲中每個項目類型有一個視圖。圖28是示出項目搜索視圖的概念的圖示。a)項目每個項目搜索視圖對特定類型或其子類型的項目的每個實例包含一行。例如，文檔的視圖能返回Document(文檔)、LegalDocument(合法文檔)和ReviewDocument(審閱文檔)的實例。給定此例，能如圖29那樣概念化項目視圖。(1)主項目搜索視圖存儲平臺數據存儲的每個實例定義稱為主項目視圖(MasterItemView)的特殊項目視圖。此視圖提供關于數據存儲中每個項目的綜述信息。視圖對每個項目類型屬性提供一列，其中一列描述項目的類型，若干列用于提供改變跟蹤和同步信息。在數據存儲中使用名字"[System.Storage].[Master!Item]"來標識主項目視圖。<table>tableseeoriginaldocumentpage52</column></row><table>每個項目類型也具有搜索視圖。類似于根項目視圖，此視圖還提供通過"Jtem"列對項目對象的訪問。在數據存儲中使用名字[schemaName].[itemTypeName]標識每個分類型的項目搜索視圖。例如[AcmeCorp.Dod].[OfficeDoc]。<table>tableseeoriginaldocumentpage52</column></row><table>WinFs存儲中的所有項目擴展也可使用搜索視圖來訪問。(1)主擴展搜索視圖數據存儲的每個實例定義一稱為主擴展視圖(MasterExtensionView)的特殊擴展視圖。此視圖提供關于數據存儲中每個擴展的綜述信息。該視圖對每個擴展屬性有一列，其中一列描述擴展的類型，而若干列用于提供改變跟蹤和同步信息。使用名字"[System.Storage].[Master!Extension]"在數據存儲中標識主擴展視圖。<table>tableseeoriginaldocumentpage52</column></row><table><table>tableseeoriginaldocumentpage53</column></row><table>(2)分類型的擴展搜索視圖每個擴展類型還具有搜索視圖。類似于主擴展視圖，此視圖還提供通過—Extension列對項目對象的訪問。在數據存儲中使用名字[SehemaName〗,[Extension!extensionTypeName]標識每個分類型的擴展搜索視圖。例如[AcmeCorp.Doc].[Extension!OfficeDocExt]。<table>tableseeoriginaldocumentpage53</column></row><table>所有嵌套的元素存儲在項目、擴展或關系實例之中。因此，它們能通過查詢合適的項目、擴展或關系搜索視圖來訪問。d)關系如上討論，關系形成在存儲平臺數據存儲中各項目之間鏈接的基本單元。(1)主關系搜索視圖每個數據存儲提供一主關系視圖。此視圖提供關于數據存儲中所有關系實例的信息。在數據存儲中使用名字"[System.Storage].[Master!Relationship]"來標識主關系視圖。<table>tableseeoriginaldocumentpage54</column></row><table>e)9.更新存儲平臺數據存儲中所有視圖是只讀的。為創建數據模型元素(項目、擴展或關系)的新實例，或更新現有的實例，必須使用存儲平臺API的ProcessOperation或ProcessUpdategram方法。ProcessOperation方法是單個存儲的過程，它是由消費細化擬執行的動作的"操作"的數據存儲定義的。ProcessUpdategram方法是存儲的過程，它采取稱為"更新元素(updategram)"的一組有序的操作，它們共同細化擬執行的一組動作。操作格式是可擴展的，并提供在模式元素上的各種操作。某些公用操作包括1.項目操作a.Createltem(在嵌入或持有關系的上下文中創建一新的項目)b.Updateltem(更新一現有的項目)2.關系操作a.CreateRelationship(創建引用或持有關系的實例)b.UpdateRelationship(更新一關系實例)c.DeleteRelationship(移除一關系實例)3.擴展操作a.CreateExtension(添加一擴展到現有的項目)b.UpdateExtension(更新一現有的擴展)c.DeleteExtension(刪除一擴展)10.改變跟蹤及墓碑如下面更充分討論，由數據存儲提供改變跟蹤和墓碑服務。本節提供在數據存儲中展現的改變跟蹤信息的概述a)改變跟蹤由數據存儲提供的每個搜索視圖包含用于提供改變跟蹤信息的列；那些列對所有項目、擴展和關系視圖是公用的。由模式設計者明確地定義的存儲平臺模式視圖不自動地提供改變跟蹤信息一該信息是通過在其上構建視圖本身的搜索視圖來間接提供的。對數據存儲中的每個元素，可從兩個地方得到改變跟蹤信息"主"元素視圖和"分類型的"元素視圖。例如，可從主項目視圖"[System.Storage].[Master!Item]"和分類型的項目視圖[AcmeCorp.Document].[Document]中得至lj關于AcmeCorp.Document.Document項目類型的改變跟蹤信息。(1)"主"搜索視圖中的改變跟蹤主搜索視圖中的改變跟蹤信息提供關于元素的創建和更新版本的信息、關于哪個同步伙伴創建該元素的信息、關于哪個同步伙伴最后一次更新該元素的信息、以及來自每個伙伴的用于創建和更新的版本號。用伙伴關鍵字來標識同步關系中的伙伴(下面描述)。類型[System.Storge.Store].ChangeTrackinglnfo的名為—ChangeTrackinglnfo的單個UDT對象包含所有這些信息。在System.Storage模式中定義類型。在項目、擴展和關系的所有全局搜索視圖中可得到—ChangeTrackinglnfo。—ChangeTrackinglnfo的類型定義是<TypeName-"ChangeT:i:ackinglnfo"BaseType="Base.NestedElement"><FieldPropertyUame-"C:i:eationliOcalTS"Type="SqlTypesSqllnt64"Nullable="False"/><FieldPropertyName="CreatingPairtne:rKey"Type="SqlTypes.Sqllnt32"Nullable="False"/><FieldPrope:rtyName="C:reatingPartnerTS"Type-"SqlTypes.Sqllnt64"Nullable="False"/><FieldPropertyName-"LastUpdateIjOcalTS"Type="SqlTypes.Sqllnt64"Nullable="False"/><FieldPropertyName=":LastUpdatingPartiie:i:Key"Type="SqlTypesSqllnt32"Nullable-"False"/><FieldPrope:i:tyName="IjastUpdatingPartne:i:TS"Type-"SqlTypesSqllnt64"Nullable="False"/></Type>這些屬性包含下述信息:<table>tableseeoriginaldocumentpage56</column></row><table><table>tableseeoriginaldocumentpage57</column></row><table>(2)"分類型的"搜索視圖中的改變跟蹤除了提供與全局搜索視圖相同信息外，每個分類型的搜索視圖提供記錄在同步拓撲中每個元素的同步狀態的附加信息。<table>tableseeoriginaldocumentpage57</column></row><table>b)墓碑數據存儲為項目、擴展和關系提供墓碑信息。墓碑視圖提供一個地方中有關活動和墓碑實體兩者(項目、擴展和關系)的信息。項目和擴展墓碑視圖不提對對應對象的訪問，而關系墓碑視圖提供對關系對象的訪問(在墓碑關系的情況下關系對象為空)。(1)項目墓碑通過視圖[System.Storage].[Tombstone!item]從系統檢索項目墓碑。<table>tableseeoriginaldocumentpage57</column></row><table><table>tableseeoriginaldocumentpage58</column></row><table>(2)擴展墓碑使用視圖[System.Storage].[Tombstone!Extension]從系統檢索擴展墓碑。擴展改變跟蹤信息類似于為項目提供的添加了Extensionld屬性的信息。<table>tableseeoriginaldocumentpage58</column></row><table>(3)關系墓碑通過視圖[System.Storage].[Tombstone!Relationship]從系統檢索關系墓碑。關系墓碑信息類似于對擴展提供的信息。然而，在關系實例的目標ItemRef上提供附加信息。此外，還選擇關系對象。<table>tableseeoriginaldocumentpage58</column></row><table><table>tableseeoriginaldocumentpage59</column></row><table>(4)墓碑清除為防止墓碑信息無限制地增長，數據存儲提供墓碑清除任務。此任務確定什么時候可以舍棄墓碑信息。該任務計算本地創建/更新版本的界限，并隨后通過舍棄所有更早的墓碑版而截斷墓碑信息。11.助手API和函數基礎映射還提供若干助手函數。提供這些函數以幫助在該數據模型上的公用操作。a)函數System.Storage.Getltem〃給定Itemld返回一項目對象ItemGetltem(ItemldItemld)b)函數[System.Storage].GetExtension〃給定Itemld和Extensionld返回一擴展對象ExtensionGetExtension(ItemldItemld,ExtensionldExtensionld)c)函數[System.Storage].GetRelationship〃給定Itemld和Relationshipld返回—關系對象RelationshipGetRelationship(ItemldItemld,RelationshipldRelationshipld)12.元數據有兩類在存儲中表示的元數據實例元數據(項目的類型等)，和類型元數據。a)模式元數據模式元數據作為來自元模式的項目類型的實例存儲在數據存儲中。b)實例元數據應用程序使用實例元數據來查詢項目的類型，并尋找與項目相關聯的擴展。給定項目的Itemld，應用程序可查詢全局項目視圖，以返回該項目的類型，并使用此值來査詢Meta.Type視圖以返回關于該項目的聲明的類型的信息。例如，〃對給定的項目實例返回元數據項目對象SELECTm,_ltemASmetadatalnfoObjFROM[Syst"im.Storagej.ltemiINNERJOIN[Meta].[TypemONi.一Typeld=m.ltemldWHEREi.ltemld=@ltemldE.安全性一般而言，所有可保護的對象使用圖26中所示的訪問掩碼格式來安排訪問權限。在此格式中，低16位用于對象專用的的訪問權限，接著7位用于應用于大多數對象類型的標準訪問權限，高4位用于指定類屬訪問權限，每個對象類型將其映射到一組標準且對象專用的權限。ACCESS—SYSTEM—SECURITY位對應于訪問對象的SACL的權限。在圖26的訪問掩碼結構中，項目專用的權限被放置在對象專用權限段(低16位)。由于在本實施例中，存儲平臺向管理員安全性展現兩組API:Win32和存儲平臺API，為促進存儲平臺對象專用權限的設計，必須考慮文件系統對象專用的權限。在通過引用結合于此的有關專利中充分描述了用于本發明的存儲平臺的安全模型。在這點上，圖27(部分a、b和c)畫出按安全模型的一實施例，作為從現有安全區域開拓出的新的等同地保護的安全區域。F.通知和改變跟蹤按本發明的另一方面，存儲平臺提供允許應用程序跟蹤數據改變的通知能力。此特征主要供保持易失狀態或執行數據改變事件上的業務邏輯的應用程序使用。應用程序注冊在項目、項目擴展及項目關系上的通知。在提交了數據改變通知被異步地傳送。應用程序可按項目、擴展和關系類型以及操作類型來過濾通知。按一個實施例，存儲平臺API322為通知提供兩類接口。第一，應用程序注冊由對項目、項目擴展和項目關系的改變觸發的簡單數據改變事件。第二，應用程序創建"監視程序"對象來監視項目、項目擴展和項目之間關系的組。在系統失敗或系統離線超過預定時間之后，可保存和重新創建監視程序對象的狀態。單個通知可反映多個更新。關于此功能的附加細節能在通過引用結合于此的有關專利中找到。G.同步按本發明的另一方面，存儲平臺提供同步服務330，它(I)允許存儲平臺的多個實例(每個有自己的數據存儲302)按一組靈活的規則來同步它們的內容的各部分，以及(ii)為第三方提供基礎結構以將本發明的存儲平臺的數據存儲與實現專有協議的其它數據源同步。存儲平臺到存儲平臺的同步在一組參與的復制品之間發生。例如參考圖3，希望在多半是在不同的計算機系統上運行的存儲平臺的另一實例的控制下提供在存儲平臺300的數據存儲302和另一遠程數據存儲338之間的同步。該組的總的成員資格不必在任何給定時間被任何給定復制品知道。不同的復制可以獨立地(即并發地)作出改變。將同步過程定義成使每個復制品知道由其它復制品作出的改變。此同步能力本質上是多主的(multi-master)。本發明的同步能力允許各復制品確定另一復制品知道什么改變；請求關于此復制品不知道的改變的信息；傳輸關于其它復制品不知道的改變的信息；確定兩個改變何時互相沖突；本地應用改變；傳輸沖突分解到其它復制品以確保會聚性；以及基于對沖突分解指定的政策分解沖突。1.存儲平臺到存儲平臺的同步本發明的存儲平臺的同步服務300的基本應用是同步存儲平臺(每個帶有它自己的數據存儲)的多個實例。同步服務在存儲平臺模式級上操作(而不是在數據庫引擎314的底層表中)。因此，例如"范圍(Scope)"用于定義下面討論的同步組。同步服務按"純改變(netchange)"的原則操作。不是記錄和發送各個操作(如事務復制)，同步服務而是發送這些操作的最終結果，因此常將多個操作的結果合并成單個最終結果。同步服務通常不考慮事務邊界。換言之，若在單個事務中對存儲平臺數據存儲作出兩個改變，不保證這些改變原子地應用到所有其它復制品上一可以示出一個改變而不示出其它改變。此原則的例外是，若在同一事務中對同一項目作出兩個改變，則這些改變保證被原子地發送和應用到其它復制。因此，項目是同步服務的一致性單元。a)同步(Sync)控制應用程序任一應用程序可連接到同步服務并啟動sync(同步)操作。那樣的應用程序提供執行同步(見下面同步概況)所需的所有參數。那樣的應用程序在這里被稱為同步控制應用程序(SCA)。在同步兩個存儲平臺實例時，在一側由SCA啟動同步。該SCA通知本地同步服務與遠程伙伴同步。在另一側，同步服務通過由來自發起機器的同步服務發出的消息喚醒。它基于在目標機器上存在的持久配置信息(見下文的映射)作出響應。同步服務能按時間表或響應于事件運行。在這些情況下，實現時間表的同步服務成為SCA。為啟用同步，需要采取兩個步驟。首先，模式設計者必須用合適的同步語義注釋存儲平臺模式(如下文所述的指定改變單元)。其次，同步必須在具有參與同步的存儲平臺的實例的所有機器上正確地配置(如下所述)。b)模式注釋同步服務的基本概念是改變單元(ChangeUnit)的概念。改變單元是由存儲平臺個別地跟蹤的最小的模式片段。對每個改變單元，同步服務能確定自從最后一次同步以來它是被改變還是未被改變。指定模式中的改變單元達到若干目的。首先，它確定了在線的同步服務如何羅嗦。當在改變單元內作出改變時，整個改變單元被發送到其它復制品，因為同步服務不知道改變單元的哪部分被改變。其次，它確定了沖突檢測的粒度。當對同一改變單元作出兩個并發的改變(這些術語在后繼章節中詳細定義)，同步服務引起沖突；另一方面，若對不同改變單元作出并發改變，則無沖突發生，且改變被自動地合并。第三，它嚴重地影響了由系統保持的元數據的量。對每個改變單元保持許多同步服務元數據；因此，使改變單元更小會增加同步的額外開銷。定義改變單元需要找出正確的折衷。為此，同步服務允許模式設計者參與此過程。在一個實施例中，同步服務不支持大于一個元素的改變單元。然而，它支持讓模式設計者指定比一個元素更小的改變單元的能力一即將一個元素的多個屬性組合到單獨的改變單元中。在該實施例中，這是使用下述句法實現的<TypeName="Appointment"MajorVersion-'T'MinorVersion-"O"ExtendsType-"Base.ltem"ExtendsVersion-"1"><FieldName="MeetingStatus"Type="thestorageplatformTypes.uniqueidentifierNullable="False"/><FileldName="OrganizerName"Type="thestorageplatformTypes.nvarchar(512)"Nullable="False7><FiledName-"OrganizerEmail"Type="thestorageplatformTypes.nvarchar(512)"TypeMajorVersion-'T'Multi^alued="True7><ChangeUnitName-"CU_Status"><FieldName-"MeetingStatus"/></ChangeUnit><ChangeUnitName="CU_Organizer"/><FieldName-"OrganizerName"/><FieldName-"OrganizerEmai卩'/></ChangeUnit></Type>c)同步配置希望保持它們數據的某些部分同步的一組存儲平臺伙伴被稱為同步共同體。雖然共同體的成員希望保持同步，它們不需要以完全相同的方式表示數據;換言之，同步伙伴可轉換他們正在同步的數據。在對等情況下，讓對等方對所有它們的伙伴維持轉換映射是不現實的。取代地，同步服務采取定義"共同體文件夾"的方法。共同體文件夾是代表所有共同體成員正在與之同步的假設的"共享文件夾"的抽象。此概念最好用一例子說明。若Joe希望保持他的若干計算機的MyDocuments(我的文檔)文件夾同步，Joe定義一共同體文件夾，如稱為JoeDocuments。隨后在每臺計算機上，Joe在假設的JoeDocuments文件夾和本地MyDocuments文件夾之間配置一映射。從這點出發，當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)時間表在一個實施例中，同步服務不提供它自己的調度基礎結構。相反，它依賴于另一組件來完成此任務一在MicrosoftWindows操作系統中可得到的WindowsScheduler。同步服務包括命令行實用程序，它擔當SCA并基于保存在XML文件中的同步概況觸發同步。該實用程序使得按時間表或者響應于如用戶登錄或登出等事件來配置WindowsScheduler變得非常容易。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)復制品的會聚性及沖突分解的傳播在復雜同步的情況下，在多個復制品中能檢測到同一沖突。若發生此情況，發生若干事情(l)在一個復制品上能分解沖突，并將分解送到其它復制品；(2)沖突在兩個復制品上被自動分解；以及(3)在兩個復制品上手動分解沖突(通過分解檢查API)。為保證會聚性，同步服務將沖突分解轉發到其它復制品。當分解沖突的改變到達復制品時，同步服務自動地在日志中尋找由此更新分解的任何沖突，并消除它們。在此情況下，一個復制品上的沖突分解被綁定到所有其它復制品。若不同的復制品對同一沖突選擇了不同的贏者，則同步服務應用綁定沖突分解的原則，并自動地挑選兩個分解中一個勝過另一個。以確定性的方式挑選贏者以保證在所有時刻都產生同樣的結果(一個實施例使用復制品ID字典式比較)。若不同復制對同一沖突建議不同的"新改變"，則同步服務將此新沖突處理成特殊沖突，并使用沖突日志記錄器來防止它傳播到其它復制品。那樣情況常在手動沖突分解時發生。2.對非存儲平臺數據存儲的同步按本發明的存儲平臺的另一方面，存儲平臺提供ISV用于實現同步適配器的體系結構，同步適配器使存儲平臺能與如MicrosoftExchange、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.傳統文件互操作性如上提到，至少在某些實施例中，本發明的存儲平臺旨在被實施為計算機系統的硬件/軟件接口系統的整體部分。例如，本發明的存儲平臺可被實施為如MicrosoftWindows家族操作系統的整體部分。在這方面，存儲平臺API成為操作系統API的一部分，應用程序通過它與操作系統交互。因此，存儲平臺成為裝置，應用程序通過它將信息存到操作系統上，且從而基于項目的存儲平臺的數據模型替代了這一操作系統的傳統文件系統。例如，當在MicrosoftWindows家族操作系統中實施時，存儲平臺可替代在該操作系統中實現的NTFS文件系統。當前，應用程序通過由Windows家族操作系統展現的Win32API來訪問NTFS文件系統的服務。然而，應認識到，完全用本發明的存儲平臺替代NTFS文件系統需要重新編碼現有的基于Win32的應用程序，且那樣的重新編碼可能是不合需要的，因此本發明的存儲平臺提供與如NTFS等現有文件系統的某種互操作性是有益的。從而，在本發明的一個實施例中，存儲平臺使依賴于Win32編程模型的應用程序能同時訪問存儲平臺的數據存儲以及傳統的NTFS文件系統的數據存儲的內容。為此，存儲平臺使用作為Win32命名習慣的超集(superset)的命名習慣以便于容易的互操作性。此外，存儲平臺支持通過Win32API訪問存儲在存儲平臺巻中的文件和目錄。關于此功能的另外細節能在通過引用結合于此的有關專利中找到。I.存儲平臺API存儲平臺包括一API，它使應用程序能訪問上面討論的存儲平臺的特征和能力，并訪問存儲在數據存儲中的項目。本節描述本發明的存儲平臺的存儲平臺API的一個實施例。關于此功能的細節能在通過引用結合于此的有關專利中找到，為方便起見在下面總結此信息的某一些。參考圖18，包含文件夾是一個項目，它包含與其它項目的持有關系，且與通常概念的文件系統文件夾等價。每個項目"包含"在至少一個包含文件夾中。圖19示出按本實施例的存儲平臺API的基本體系結構。存儲平臺API使用SQL客戶機1900與本地數據存儲302對話，并還使用SQL客戶機l卯0與遠程數存儲(如數據存儲340)對話。本地存儲還可使用DQP(分布式査詢處理器)或通過上述的存儲平臺同步服務("Sync")與遠程數據存儲340對話。存儲平臺API322還擔當數據存儲通知的橋接器API，將應用程序的下標傳送到通知引擎，并如上所述將通知路由到應用程序(如應用程序350a、350b或350c)。在一個實施例中，存儲平臺API322還定義受限制的"提供者"體系結構，使得它能訪問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中的類的數據成員直接反映了存儲在存儲平臺存儲中的信息；此信息是從文件系統對象的"升級"或使用Win32API本機地創建。System.Storage.Files名字空間具有兩個類Fileltem(文件項目)和Directoryltem(目錄項目)。這些類的成員及其方法可通過審閱圖25中的模式圖來預測。Fileltem和Directoryltem是從存儲平臺API只讀的。為修改它們，必須使用System.IO中的Win32API或類。對于API，編程接口(或簡稱之為接口)可以被視為用于令代碼的一個或多個片斷能與由代碼的一個或多個其它片斷提供的功能進行通信或對其進行訪問的任一機制、過程、協議。或者，編程接口可以被視為能夠通信地耦合至其它計算機的一個或多個機制、方法、函數調用、模塊等的系統的組件的一個或多個機制、方法、函數調用、模塊、對象等。上述語句中的術語"代碼片斷"意在包括代碼的一個或多個指令或代碼行，并包括，如，代碼模塊、對象、子例程、函數等等，無論應用的術語是什么、或代碼片斷是否被單獨編譯、或代碼片斷是否被提供為源碼、中間碼或對象代碼、代碼片斷是否在運行時系統或進程中使用、或它們是否位于同一或不同機器上或跨多個機器分布、或由代碼片斷表示的功能是否完全由軟件、完全由硬件或硬件和軟件的組合來實現。概念上，編程接口可以被一般地察看，如圖30A或圖30B所示的。圖30A示出了接口"接口1"為管道，第一和第二代碼片斷通過該管道進行通信。圖30B示出了接口包括接口對象Il和12(可以是或不是第一和第二代碼片斷的部分)，它們令系統的第一和第二代碼片斷能通過介質M進行通信。在圖30B中，可以認為接口對象II和12為同一系統的單獨接口，并且也可以認為對象II和12加上介質M構成了接口。盡管圖30A和30B示出了雙向流程以及該流程的每一側上的接口，某些實現可僅具有一個方向上的信息流(或如下所述沒有信息流)，或僅具有一側的接口對象。作為示例而非局限，諸如應用編程或程序接口(API)、入口點、方法、函數、子例程、遠程過程調用和組件對象模型(COM)接口等術語包含在編程接口的定義之內。這類編程接口的方面可包括第一代碼片斷向第二代碼片斷發送信息的方法(其中，"信息"以其最廣泛的意義使用，并包括數據、命令、請求等等)；第二代碼片斷接收信息的方法；以及該信息的結構、序列、語法、組織、模式、定時和內容。在這一點上，只要信息以接口所定義的方式傳輸，底層傳輸介質本身可以對接口的操作不重要，無論該介質是有線還是無線，或兩者的組合。在某些情況下，在常規意義上，當一個代碼片斷僅訪問由第二代碼片斷執行的功能時，信息可不在一個或兩個方向上傳輸，因為信息傳輸可以是或者通過另一機制(如，信息被放置在與代碼片斷之間的信息流分離的緩存、文件等中)或者不存在。這些方面的任一個或所有可以在給定的情況下重要，如，取決于代碼片斷是否是松耦合或緊耦合配置的系統的一部分，并且因此該列表應當被認為是說明性的而非限制。編程接口的這一概念對本領域的技術人員是己知的，并且可以閱讀上述本發明的詳細描述而清楚這一概念。然而，有其它方法來實現編程接口，并且除非明顯地排除，這些方法也由所附權利要求書包含在內。這些其它方法看似比圖30A和30B的視圖更精密或復雜，但是它們仍執行類似的功能來完成同一整體結果。現在簡要描述編程接口的某些說明性替換實現。分解:可以通過將通信分裂成多個離散通信來間接地實現從一個代碼片斷到另一個的通信。這在圖31A和31B中示意性地描述。如圖所示，可以按照功能的可分組來描述某些接口。由此，可以分解圖30A和30B的接口功能來達到相同的結果，如同可以在數學上提供24，或2乘2乘3乘2—樣。因此，如圖31A所示，可以細分由接口"接口l"提供的功能以將該接口的通信變換成多個接口"接口1A"、"接口1B"、"接口1C"等，而達到相同的結果。如圖31B所示，由接口II提供的函數可以被細分成多個接口Ila、Ilb、Ilc等，而達到相同的結果。類似地，從第一代碼片斷接收信息的第二代碼片斷的接口12可以被分解成多個接口12a、12b、12c等。當分解時，包括在第一代碼片斷中的接口的數量不需要匹配包括在第二代碼片斷中的接口的數量。在圖31A或31B的任一情況下，接口"接口1"和II的功能性精神分別與圖30A和30B的保持相同。接口的分解也可遵從聯合、通信和其它數學性質，使得分解較難識別。例如，命令操作可以是不重要的，并且因此由接口完成的功能可以在達到該接口之前由另一段代碼或接口較好地完成，或者由系統的單獨組件執行。此外，編程領域的普通技術人員可以理解有各種方式來作出不同的函數調用而達到相同的結果。重定義:在某些情況下，可能忽略、添加或重定義編程接口的某些方面(如參數)，而仍達到預期的結果。這在圖32A和32B中示出。例如，假定圖30A的接口"接口1"包括函數調用^Mflre^pwAFec/w'o",o"0W(平方)，它包括三個參數，z'";w/(輸入)、；rec/w'o"(精度)和ow0wf(輸出)，并且由第一代碼片斷向第二代碼片斷發布。如果中間參數;^c/^"在給定的情形下無關緊要，如圖32A所示，它也可以被忽略或甚至由meam'"g/ew(無意義)(在這一情況下)參數來替換。也可以添加無關緊要的^toY/o"a/(另外)參數。在任一情況下，只要在輸入由第二代碼片斷平方之后返回輸出，就可以達到square(平方)的功能。iVec&fo"也有可能對計算系統的某一下游或其它部分是極有意義的參數；然而，一旦認識到;wc/^w對計算平方這一有限目的不是必需的，它可以被替換或忽略。例如，不是傳遞一個有效的pn'c/w'ow值，而是在不對結果產生不利影響的情況下傳遞諸如出生日期等無意義的值。類似地，如圖32B所示，接口Il由接口I1'替換，它被重新定義來忽略或向接口添加參數。接口I2可類似地被重定義為接口I2'，它被重定義來忽略不必要的參數，或可在別處處理的參數。此處的要點是在某些情況下，編程接口可包括對某一目的而言所不需要的方面，諸如參數，因此可以忽略或重定義它們，或在別處處理它們用于其它目的。內嵌代碼:合并兩個單獨的代碼模塊的一些或全部功能也是可行的，使得它們之間的"接口"改變形式。例如，圖30A和30B的功能可以被分別轉化到圖33A和33B的功能。在圖33A中，圖30A的先前的第一和第二代碼片斷被合并成包含兩者的模塊。在這一情況下，該代碼片斷仍可以彼此通信，但是該接口可以適用于更適合單個模塊的形式。由此，例如，正式的調用(Call)和返回(Return)語句將不再必需，但是依照接口"接口1"的類似的處理或響應仍是有效的。類似地，如圖33B所示，圖30B的部分(或所有)接口12可以內嵌地寫入接口II來形成接口ir。如圖所示，接口12被劃分成I2a和I2b，并且接口部分I2a內嵌在接口II中書寫代碼來形成接口n"。對于具體的示例，考慮圖30B的接口l執行函數調用W"wef^/7W,ow0w(;，它由接口I2接收，在由第二代碼片斷處理傳遞到/";W的值(對其求平方)之后，它被使用oW;7W傳遞回已求平方的結果。在這一情況下，由第二代碼片斷執行的處理(對/甲"f求平方)可以由第一代碼片斷在不調用該接口的情況下執行。脫離:可以通過將通信分裂成多個離散的通信來間接地完成從一個代碼片斷到另一個的通信。這在圖34A和34B中示意性地描述。如圖34A所示，提供了中間件的一個或多個片斷(脫離接口(DivorceInterface)，因為它們從原始的接口脫離的功能和/或接口函數)，以轉化第一接口"接口1"上的通信，使得它們符合不同的接口，在本情況下為"接口2A"、"接口2B"和"接口2C"。這可以在這樣一種情況中完成，例如，依照"接口1"協議設計應用的已安裝基礎與如操作系統進行通信，但是然后改變該操作系統來使用不同的接口，在本情況下為接口"接口2A"、"接口2B"和"接口2C"。要點是改變了由第二代碼片斷使用的原始接口，使得它不再與第一代碼片斷所使用的接口兼容，因此使用中介來令舊接口和新接口兼容。類似地，如圖34B所示，可以使用脫離接口DI1引入第三代碼片斷以從接口II接收信息，并使用脫離接口DI2引入第三代碼片斷以向例如接口I2a和12b發送接口功能，重新設計接口I2a和I2b以使用DI2，但是提供相同的功能性結果。類似地，DI1和DI2可共同工作以將圖30B的接口II和12的功能轉換成一新操作系統，而提供相同或類似的功能性結果。重寫:再一種可能的變化是動態地重寫代碼，使用別的東西來替換接口的功能，而仍達到相同的總體結果。例如，可以有一種系統，其中，向執行環境(如由.Net框架提供的環境、Java運行時環境或其它類似的運行時刻類型環境)中的及時(Just-in-Time)(JIT)編譯器或解釋器提供了中間語言(如MicrosoftIL、JavaByteCode等)中呈現的代碼片斷。可以書寫JIT編譯器以動態地將通信從第一代碼片斷轉化到第二代碼片斷，即，令它們符合第二代碼片斷(原始或不同的第二代碼片斷)所需要的不同接口。這在圖35A和35B中有描述。如圖35A中所看見的，這一方式類似于上述的脫離情形。它可以在這樣一種情況下完成，例如，依照"接口l"協議設計應用的已安裝基礎操作系統進行通信，然后改變該操作系統以使用不同的接口。JIT編譯器可以用于令已安裝基礎應用的空中通信符合操作系統的新接口。如圖35B所描述的，可以應用這一動態重寫接口的方法以進行動態分解，或者改變接口。應當注意，上述通過替換實施例實現與接口相同或相似的結果的情形也可以以各種方式串行、并行或與其它干預代碼組合。由此，上文呈現的替換實施例并非相互窮盡，并且可以被混合、匹配和組合以產生與圖30A和30B中所呈現的一般情形相同或等效的情形。也應當注意，如同大多數編程構造，本發明可能未描述達到與接口相同或相似的功能的其它類似的方式，但是它們仍由本發明的精神和范圍來表示，S卩，應當注意，它至少部分地是由作為接口的值的基礎的接口表示的功能或由其啟用的有利結果。III.圖象模式和輔助模式(圖象模式組)在這里揭示的本發明的各個實施例中，圖象(如JPEG、TIEF、位圖等)被處理成核心平臺對象("圖象項目"或更簡單地"圖象")，且本發明包括"圖象(Image)模式"以提供系統中圖象的可擴展的表示一即，圖象的特征和該圖象如何與系統中的其它項目(包括但不限于其它圖象)相關。為此，圖象模式對系統中的圖象定義屬性、行為和關系，且模式還強制實行關于圖象的規則，如，圖像必須包含什么專用數據、圖像能可任選地包含哪些專用數據、特定圖象如何擴展，等等。圖象模式包括表示不同類型圖象所必須的類型信息，包括用于表示圖象的文件格式的屬性(包括GIF、TIEF、JPEG以及其它已知圖象對象類型)以及表示圖象的語義內容的屬性。本發明的各實施例的圖象模式是構建所有圖象相關功能的基礎。除圖象模式外，這里還提供并討論對"照片(Photo)"、"分析屬性(AnalysisProperties)"、"位置(Location)"項目的相關輔助模式(總稱為"圖象模式組")，且本發明的某些實施例包括這些輔助模式的一個或多個。照片模式是照片對象("照片項目"或簡單的"照片")的可擴展的表示，其中照片項目類型是圖象項目類型的子類型。分析屬性模式(AP模式)是照片項目的分析屬性(AP)的可擴展的表示，它啟用對照片的先進的比較功能，如自動面部識別、圖象的相似性等。位置模式是照片項目的物理(地理)位置屬性的可擴展的表示。圖36A和圖36B示出本發明的各實施例的圖象模式(項目及屬性)，以及從基礎模式(圖7)和核心模式(圖8A和圖8B)選擇的元素，以示出在每個模式之間的互相關系(為方便起見，在圖示中省略各個屬性)。A.圖象模式如前討論，圖象模式包括表示不同類型的圖象項目所必須的項目、屬性和關系。這包括用于表示特定圖象類型(GIF、T正F、JPEG等)的本機文件格式，以及表示圖象的語義內容的屬性。為此，對任何圖象項目，項目類型是由所有圖象共享的基礎項目類型，且是如圖36示出的Core.Document項目類型(即在"核心(Core)"模式中的"文檔(Document)"類型)的直接擴展。(Core.Document類型是圖8A示出的核心模式的一部分。)圖象類型包含一般描述圖象的字段，且它可應用到所有圖象，而不論其格式。圖象模式的基本項目類型是Image(圖像)類型，下面是Image類型的某些字段:_<table>tableseeoriginaldocumentpage78</column></row><table>圖象模式還包括附加屬性(嵌套元素)，它從Base.PropertyBase如下地擴展:"Region":Region屬性代表圖象中的區域，并包括下列字段<table>tableseeoriginaldocumentpage78</column></row><table><table>tableseeoriginaldocumentpage79</column></row><table><table>tableseeoriginaldocumentpage80</column></row><table>秒)。Aperture用于作出曝光的光圈設置。IsoSpeed等價于ISO感光率的膠巻速度。Flash閃光燈亮？0=無閃光燈，1=閃光燈亮。空意味著不知道閃光燈是否亮。RedEyeUsed使用紅眼模式？0=否。1=是。空意味著不知道。這對高級査詢有用。例如，若使用紅眼，這看來是肖像。ExposureMod6曝光方式。允許下列5個值Auto(自動)、Shutterpriority(快門優先級)、Aperturepriority(光圈優先級)、ISOpriority(ISO優先級)、Manual(手動)。SubjectDistance由相機測得對象的距離。距離按米計。c.分析屬性模式對數字照片，借助分析應用程序可在照片上計算一組屬性。然而，計算和重計算這些屬性是很花費時間和處理器資源的。此外，這些字段是應用程序專用的，其它應用程序可能不理解這些字段的內部格式。對照片項目，在由這些應用程序使用之前可替代地計算標準的分析屬性組，并以對照片項目類型的擴展的形式將其添加到照片項目。分析屬性模式(AP模式)正是通過提供AP擴展的AP類型這樣做的，而AP擴展本身如圖7所示也是基礎模式的Base.Extension擴展類型的擴展。AP類型擴展包括下列字段屬性名描述ColorHistogram用于相似性檢測的彩色直方圖數據。GrayHistogram用于相似性檢測的灰度直方圖數據。Similaritylndex用于相似性檢測的圖象紋理數據IV.結論如前說明，本發明是針對用于組織、搜索和共享數據的存儲平臺。本發明的存儲平臺擴展和拓寬了數據存儲的概念，超越現有的文件系統和數據庫系統，并被設計成存儲所有類型的數據，包括結構化的、非結構化的或半結構化的數據，如關系型(表式)數據、XML以及被稱為項目的新數據形式。通過其共同的存儲基礎和模式化的數據，本發明的存儲平臺使消費者、知識工人和企業能更有效地進行應用程序的開發。它提供豐富且可擴展的應用編程接口，它不僅可用在其數據模型中內在的能力，還可包含和擴展現有文件系統和數據庫訪問方法。可以理解，對上述實施例可作出改變而不偏離這里廣泛的發明性概念。因而，本發明不限于揭示的特定實施例，而旨在覆蓋由權利要求定義的本發明的精神和范圍內的所有修改。從上述明白，本發明的各種系統、方法和方面的所有或部分能以程序代碼的方式(如指令)來實施。程序碼可存儲在如磁、電、或光存儲介質等計算機可讀介質上，包括但不于軟盤、CD-ROM、CD-RW、DVD-ROM、DVD-RAM、磁帶、閃存、硬盤驅動器或任何其它機器可讀介質，其中當由如計算機、服務器等機器加載并執行程序代碼時，該機器成為實施本發明的裝置。本發明也可在通過某種傳輸介質發送的程序代碼的形式中實施，傳輸介質如電線或電纜、光纜、包括因特網和內聯網的網絡或通過任何其它形式的傳輸，其中當由如計算機的機器接收、加載和執行程序代碼時，該機器變成用于實施本發明的裝置。當在通用處理器上實現時，程序代碼組合處理器以提供類似于專用邏輯線路操作的唯一的裝置。權利要求1.一種帶有用于計算機系統的硬件/軟件接口系統的計算機可讀指令的計算機可讀介質，其中，所述硬件/軟件接口系統處理屬于一圖象并具有所述硬件/軟件接口系統能理解的屬性的多個分立的信息單元(“項目”)。2.如權利要求1所述的計算機可讀介質，其特征在于，所述硬件/軟件接口系統包括定義至少一個圖象項目及至少一個圖象屬性的圖象模式。3.如權利要求2所述的計算機可讀介質，其特征在于，所述圖象模式中的至少一個項目是組成基本項目類型的基本項目，從中導出在所述硬件/軟件接口系統中處理的所有其他圖象項目。4.如權利要求3所述的計算機可讀介質，其特征在于，所述基本圖象項目類型包括下列屬性組中的至少一個屬性等級；大小，其中大小包括圖象的寬或高的象素；圖象的位深度；色彩空間；色彩空間的版本；所述圖象的打印次數；所述圖象中感興趣的區域；屬于所述圖象的歷史；數字底片標識；到同一圖象的其它版本的鏈接的集合；以及圖象的元數據生命周期。5.如權利要求2所述的計算機可讀介質，其特征在于，所述圖象模式中的至少一個屬性是所述圖象的區域屬性，所述區域屬性包括所述區域的左、上、右、下座標的字段。6.如權利要求5所述的計算機可讀介質，其特征在于，所述圖象模式中的至少一個屬性是對所述圖象的感興趣的區域的屬性，所述感興趣的區域的屬性包括區域的字段。7.如權利要求6所述的計算機可讀介質，其特征在于，所述圖象的所述感興趣的區域的屬性還包括主體(如個人)的字段。8.如權利要求6所述的計算機可讀介質，其特征在于，所述圖象的所述感興趣的區域的屬性還包括置信度的字段。9.如權利要求2所述的計算機可讀介質，其特征在于，所述圖象項目具有與主體項目(如個人)的關系(如鏈接)。10.如權利要求2所述的計算機可讀介質，其特征在于，所述圖象具有與事件項目的關系(如鏈接)。11.如權利要求2所述的計算機可讀介質，其特征在于，所述圖象項目具有與位置項目的關系(如鏈接)。12.如權利要求3所述的計算機可讀介質，其特征在于，所述硬件/軟件接口系統包括定義至少一個照片項目和至少一個照片屬性的照片模式，且其中，所述照片項目類型是圖象項目類型的擴展。13.如權利要求12所述的計算機可讀介質，其特征在于，所述照片模式中的至少一個項目是組成基本項目類型的基本項目，從中導出在所述硬件/軟件接口系統中處理所有其它照片項目。14.如權利要求13所述的計算機可讀介質，其特征在于，所述基本照片項目類型包括下列屬性組中的至少一個屬性拍攝所述照片的日期；獲得照片的所述曰期；所述照片的獲得會話的唯一標識；方向；位置；事件；相機的制造商；相機的型號；曝光時間；光圈；ISO速度；對所述照片是否使用閃光燈的指示；對所述照片是否是用紅眼模式的指示；曝光模式；以及所述照片的目標距離。15.如權利要求3所述的計算機可讀介質，其特征在于，所述硬件/軟件接口系統包括一分析屬性模式，它定義照片項目的至少一個分析屬性(AP)和至少一個AP屬性，且其中，所述照片項目類型是圖象項目類型的擴展。16.如權利要求15所述的計算機可讀介質，其特征在于，所述AP包括下列屬性組中的至少一個屬性彩色直方圖；灰度直方圖；以及相似性指數。17.—種用于處理屬于圖象并具有硬件/軟件接口系統可理解的屬性的多個分立的單元("項目")的系統，所述方法包括一圖象模式，它定義至少一個圖象項目和至少一個圖象屬性，其中，所述圖象模式中的所述圖象項目是組成基本項目類型的基本項目，從中導出在硬件/軟件接口系統中處理的所有其它圖象項目。18.如權利要求17所述的系統，其特征在于，所述基本圖象項目類型包括下列屬性組中的至少一個屬性等級；大小，其中，大小包括圖象的寬和高的象素；圖象的位深度；色彩空間；色彩空間的版本；所述圖象的打印次數；所述圖象中感興趣的區域；屬于所述圖象的歷史；數字底片標識；到同一圖象的其它版本的鏈接的集合；以及圖象的元數據生命周期。19.如權利要求17所述的系統，其特征在于，所述圖象模式中的至少一個屬性是所述圖象的區域屬性，所述區域屬性包括所述區域的左、上、右、下座標的字段。20.如權利要求17所述的系統，其特征在于，所述圖象模式中的至少一個屬性是所述圖象的感興趣的區域的屬性，所述感興趣的區域的屬性包括區域的字段。21.如權利要求17所述的系統，其特征在于，所述圖象的感興趣的區域的屬性還包括主體(如個人)的字段。22.如權利要求17所述的系統，其特征在于，所述圖象的感興趣的區域的屬性還包括置信度的字段。23.如權利要求17所述的系統，其特征在于，所述圖象項目具有與主體項目(如個人)的關系(如鏈接)。24.如權利要求17所述的系統，其特征在于，所述圖象項目具有與事件項目的關系(如鏈接)。25.如權利要求17所述的系統，其特征在于，所述圖象項目具有與位置項目的關系(如鏈接)。26.如權利要求17所述的系統，其特征在于，所述硬件/軟件接口系統包括一照片模式，它定義至少一個照片項目和至少一個照片屬性，并其中，所述照片項目類型是圖象項目類型的擴展。27.如權利要求17所述的系統，其特征在于，所述照片模式中的至少一個項目是組成基本項目類型的基本項目，從中導出在所述硬件/軟件接口系統中處理的所有其它照片項目。28.如權利要求27所述的系統，其特征在于，所述基本照片項目類型包括下列屬性組中的至少一個屬性拍攝所述照片的日期；獲得所述照片的日期；所述照片的獲得會話的唯一標識；方向；位置；事件；相機的制造商；相機的型號；曝光時間；光圈；ISO速度；對所述照片是否使用閃光燈的指示；對所述照片是否使用紅眼模式的指示；曝光模式；以及所述照片的目標距離。29.如權利要求27所述的系統，其特征在于，所述硬件/軟件接口系統包括一分析屬性模式，它定義照片項目的至少一個分析屬性(AP)和至少一個AP屬性，且其中，所述照片項目類型是圖象類型的擴展。30.如權利要求29所述的系統，其特征在于，所述AP包括下列屬性組中的至少一個屬性彩色直方圖；灰度直方圖；以及相似性指數。31.—種硬件/軟件接口系統處理屬于具有所述硬件/軟件接口系統可理解的屬性的圖象的多個分立的信息單元("圖象項目")的方法，所述方法包括建立一圖象模式，以定義至少一個圖象項目和至少一個圖象屬性；以及在所述圖象模式中建立一項目作為組成基本項目類型的基本項目，從中導出在硬件/軟件接口系統中處理的所有其它的圖象項目。32.如權利要求31所述的方法，其特征在于，所述基本圖象項目類型包括下列屬性組中的至少一個屬性等級；大小，其中，大小包括圖象的寬和高的象素；圖象的位深度；色彩空間；色彩空間的版本；所述圖象的打印次數；所述圖象中感興趣的區域；屬于所述圖象的歷史；數字底片標識；到同一圖象的其它版本的鏈接的集合；以及圖象的元數據生命周期。33.如權利要求31所述的方法，其特征在于，所述圖象模式中至少一個屬性是所述圖象的區域屬性，所述區域屬性包括所述區域的左、上、右、下座標的字段。34.如權利要求33所述的方法，其特征在于，所述圖象模式中的至少一個屬性是所述圖象的感興趣的區域的屬性，所述感興趣的區域的屬性包括區域的字段、主體(如個人)的字段、或置信度的字段。35.如權利要求31所述的方法，其特征在于，所述圖象項目具有與主體項目(如個人)、與事件項目、或與位置項目的關系(鏈接)。36.如權利要求31所述的方法，其特征在于，還包括，為了表示在拍攝照片數字圖象項目(照片)處的幾何位置，建立所述照片和對應于所述幾何位置的位置項目(位置)之間的關系(位置關系)，使得能基于所述位置查詢所述照片。37.如權利要求36所述的方法，其特征在于，還包括，為表示在拍攝照片數字圖象項目(照片)處的幾何位置，在所述位置關系上設置對應于所述幾何位置的位置屬性(LocProp)。38.如權利要求31所述的方法，其特征在于，還包括，為表示照片數字圖象項目(照片)中的至少一個人，建立所述照片和屬于所述個人的項目(聯系人)之間的關系，使得能基于所述聯系人査詢所述照片。39.如權利要求31所述的方法，其特征在于，還包括，為表示在照片數字圖象項目(照片)中表示的至少一個事件，建立所述照片和屬于所述事件的項目(事件)之間的關系，使得能基于所述事件査詢所述照片。40.如權利要求31所述的方法，其特征在于，還包括建立從第一數字圖象項目(圖像)到第二圖象的關系，所述第二圖像是(a)從其導出所述第一圖象的父圖象，或(b)從所述第一圖象導出的子圖象。全文摘要在基于項目的系統中，圖象(如JPEG，TIEF，位圖等)被處理成核心平臺對象(“圖象項目”，或更簡單的“圖象”)，并存在于提供系統中圖象的可擴展表示的“圖象模式“中-即，圖象的特征以及該圖象如何關系到系統中其它項目(包括但不限于其它圖象)。為此，圖象模式定義系統中圖象的屬性、行為和關系，且模式還強制實施關于圖象的規則，如圖象必須包含什么專用數據、圖象可任選地可包含什么專用數據、特定的圖象可如何擴展等。文檔編號G06F7/00GK101416153SQ200480001501公開日2009年4月22日申請日期2004年7月29日優先權日2003年8月21日發明者A·瓦斯齊羅,B·P·吉布森,C·A·埃文斯,J·C·普拉特,J·P·湯普森,N·H·巴盧,P·S·赫爾亞,S·C·格蘭納,S·E·達特申請人:微軟公司