JP4901472B2 - System and method for implementation of a digital image schema that organizes units of information manageable by a hardware / software interface system - Google Patents
System and method for implementation of a digital image schema that organizes units of information manageable by a hardware / software interface system Download PDFInfo
- Publication number
- JP4901472B2 JP4901472B2 JP2006523867A JP2006523867A JP4901472B2 JP 4901472 B2 JP4901472 B2 JP 4901472B2 JP 2006523867 A JP2006523867 A JP 2006523867A JP 2006523867 A JP2006523867 A JP 2006523867A JP 4901472 B2 JP4901472 B2 JP 4901472B2
- Authority
- JP
- Japan
- Prior art keywords
- item
- items
- type
- relationship
- schema
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/50—Information retrieval; Database structures therefor; File system structures therefor of still image data
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/284—Relational databases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F7/00—Methods or arrangements for processing data by operating upon the order or content of the data handled
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Software Systems (AREA)
- Human Computer Interaction (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Processing Or Creating Images (AREA)
Description
本発明は一般に、情報の格納と取出しの分野に関し、より詳細には、コンピュータ化されたシステムにおけるさまざまなタイプのデータ、特にイメージ・データを編成、検索、および共有するためのアクティブなストレージ・プラットフォームに関する。 The present invention relates generally to the field of information storage and retrieval, and more particularly to an active storage platform for organizing, retrieving and sharing various types of data, particularly image data, in a computerized system. About.
本出願は、２００３年１０月２４日に出願した米国特許出願第１０／６９２，７７９号（整理番号ＭＳＦＴ−２８２９）の優先権を主張し、全体として参照により本明細書に組み込まれている「SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A CORE SCHEMA FOR PROVIDING A TOP-LEVEL STRUCTURE FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM」という名称の２００３年８月２１日に出願した米国特許出願第１０／６４６，６３２号（整理番号ＭＳＦＴ−１７５１）、および２００３年８月２１日に出願した国際出願第ＰＣＴ／ＵＳ０３／２６１４４号の利益を主張するものである。 This application claims priority to US patent application Ser. No. 10 / 692,779 (Docket MSFT-2829) filed Oct. 24, 2003, which is incorporated herein by reference in its entirety. US Patent Application No. 10/646, filed on August 21, 2003, entitled SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A CORE SCHEMA FOR PROVIDING A TOP-LEVEL STRUCTURE FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM , 632 (reference number MSFT-1751), and international application No. PCT / US03 / 26144 filed on August 21, 2003.
本出願はさらに、以下の本願の譲受人に譲渡された出願において開示された発明にその主題によって関連しており、その内容も参照により本明細書に組み込まれている。２００３年８月２１日に出願した「SYSTEMS AND METHODS FOR REPRESENTING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM BUT INDEPENDENT OF PHYSICAL REPRESENTATION」という名称の米国特許出願第１０／６４７，０５８号（整理番号ＭＳＦＴ １７４８）、２００３年８月２１日に出願した「SYSTEMS AND METHODS FOR SEPARATING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM FROM THEIR PHYSICAL ORGANIZATION」という名称の米国特許出願第１０／６４６，９４１号（整理番号ＭＳＦＴ−１７４９）、２００３年８月２１日に出願した「SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A BASE SCHEMA FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM」という名称の米国特許出願第１０／６４６，９４０号（整理番号ＭＳＦＴ−１７５０）、２００３年８月２１日に出願した「SYSTEMS AND METHOD FOR REPRESENTING RELATIONSHIPS BETWEEN UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM」という名称の米国特許出願第１０／６４６，６４５号（整理番号ＭＳＦＴ−１７５２）、２００３年８月２１日に出願した「SYSTEMS AND METHODS FOR INTERFACING APPLICATION PROGRAMS WITH AN ITEM-BASED STORAGE PLATFORM」という名称の米国特許出願第１０／６４６，５７５号（整理番号ＭＳＦＴ−２７３３）、２００３年８月２１日に出願した「STORAGE PLATFORM FOR ORGANIZING, SEARCHING, AND SHARING DATA」という名称の米国特許出願第１０／６４６，６４６号（整理番号ＭＳＦＴ−２７３４）、２００３年８月２１日に出願した「SYSTEMS AND METHODS FOR DATA MODELING IN AN ITEM-BASED STORAGE PLATFORM」という名称の米国特許出願第１０／６４６，５８０号（整理番号ＭＳＦＴ−２７３５）、２００３年１０月２４日に出願した「SYSTEMS AND METHODS FOR PROVIDING SYNCHRONIZATION SERVICES FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM」という名称の米国特許出願第１０／６９２，５１５号（整理番号ＭＳＦＴ−２８４４）、２００３年１０月２４日に出願した「SYSTEMS AND METHODS FOR PROVIDING RELATIONAL AND HIERARCHICAL SYNCHRONIZATION SERVICES FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM」という名称の米国特許出願第１０／６９２，５０８号（整理番号ＭＳＦＴ−２８４５）、２００３年１０月２４日に出願した「SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A SYNCHRONIZATION SCHEMAS FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM」という名称の米国特許出願第１０／６９３，３６２号（整理番号ＭＳＦＴ−２８４６）、および２００３年１０月２４日に出願した「SYSTEMS AND METHODS FOR EXTENSIONS AND INHERITANCE FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM」という名称の米国特許出願第１０／６９３，５７４号（整理番号ＭＳＦＴ−２８４７）。 This application is further related by subject matter to the invention disclosed in the following assignee application, the contents of which are also incorporated herein by reference. No. 10 / 647,058 (reference number MSFT 1748) entitled “SYSTEMS AND METHODS FOR REPRESENTING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM BUT INDEPENDENT OF PHYSICAL REPRESENTATION” filed on August 21, 2003 ), US Patent Application No. 10 / 646,941 entitled “SYSTEMS AND METHODS FOR SEPARATING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM FROM THEIR PHYSICAL ORGANIZATION” filed on August 21, 2003 (reference number MSFT) -1749), US Patent Application No. 10 / 646,940 entitled “SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A BASE SCHEMA FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM” filed on August 21, 2003. (Reference number MSFT-1750), "SYST" filed on August 21, 2003 US Patent Application No. 10 / 646,645 (reference number MSFT-1752) entitled “EMS AND METHOD FOR REPRESENTING RELATIONSHIPS BETWEEN UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM”, filed on August 21, 2003, US Patent Application No. 10 / 646,575 (reference number MSFT-2733) named “SYSTEMS AND METHODS FOR INTERFACING APPLICATION PROGRAMS WITH AN ITEM-BASED STORAGE PLATFORM”, “STORAGE PLATFORM FOR ORGANIZING” filed on August 21, 2003 , SEARCHING, AND SHARING DATA ”, US patent application Ser. No. 10 / 646,646 (reference number MSFT-2734),“ SYSTEMS AND METHODS FOR DATA MODELING IN AN ITEM-BASED STORAGE ”filed on August 21, 2003. US Patent Application No. 10 / 646,580 entitled "Platform" (reference number MSFT-2735), 2003 US Patent Application No. 10 / 692,515 (reference number MSFT-2844), entitled “SYSTEMS AND METHODS FOR PROVIDING SYNCHRONIZATION SERVICES FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM”, filed on 24th of October, 2003 US Patent Application No. 10 / 692,508 (reference number MSFT-) named “SYSTEMS AND METHODS FOR PROVIDING RELATIONAL AND HIERARCHICAL SYNCHRONIZATION SERVICES FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM” filed on October 24 2845), US Patent Application No. 10 / 693,362, filed October 24, 2003, entitled "SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A SYNCHRONIZATION SCHEMAS FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM" Application number MSFT-2846), filed October 24, 2003 No. 10 / 693,574 (reference number MSFT-2847) named “SYSTEMS AND METHODS FOR EXTENSIONS AND INHERITANCE FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM”.
個々のディスク容量は、過去１０年間にわたり毎年約７０パーセント増大している。ムーアの法則は、数年にわたって生じてきた中央演算処理装置（ＣＰＵ）の驚異的進歩を正確に予測していた。有線およびワイヤレスの技術（Wired and wireless technologies ）は、驚異的な接続性と帯域幅をもたらしてきた。現在の傾向がこのまま続くと仮定すれば、数年のうちには平均的なラップトップ・コンピュータがほぼ１テラバイト（ＴＢ）のストレージを装備して数百万のファイルを収容するようになり、５００ギガバイト（ＧＢ）のドライブが普及することであろう。 Individual disk capacity has increased by about 70 percent annually over the past decade. Moore's Law accurately predicted the tremendous advancement of central processing units (CPUs) that had occurred over the years. Wired and wireless technologies have provided tremendous connectivity and bandwidth. Assuming current trends will continue, in the coming years, the average laptop computer will be equipped with nearly 1 terabyte (TB) of storage to accommodate millions of files, 500 gigabytes ( GB) drives will spread.
消費者は、従来のパーソナル・インフォメーション・マネージャ（ＰＩＭ）スタイルのデータであろうとデジタル音楽やデジタル写真などの媒体であろうと、主に通信と個人情報の編成のために、コンピュータを使用する。デジタル・コンテンツの量、および未加工・バイト（raw bytes）を格納する機能は、すさまじい成長を遂げた。しかし、このデータを編成し一元管理するために消費者が利用できる方法は、後れをとっている（追随していない）。知識労働者は、情報の管理および共有に膨大な時間を費やしており、ある調査によれば、知識労働者はその時間の１５〜２５％を非生産的な情報関連の業務に費やしていると推定されている。また、一般的な知識労働者が情報の検索に１日当たり約２．５時間を費やしていると推定する調査もある。 Consumers use computers, primarily for communication and organizing personal information, whether traditional Personal Information Manager (PIM) style data or media such as digital music or digital photos. The amount of digital content and the ability to store raw bytes has grown tremendously. However, the methods available to consumers to organize and centralize this data are behind (not following). Knowledge workers spend a great deal of time managing and sharing information, and according to one study, knowledge workers spend 15-25% of their time on unproductive information-related work It is estimated. There are also studies that estimate that general knowledge workers spend about 2.5 hours per day searching for information.
開発者および情報テクノロジー（ＩＴ）部門は、人、場所、時間、イベントなどの事項を表す共通のストレージ抽象化のための独自のデータ・ストアの構築にかなりの時間および資金を投資している。これは、重複した作業になるばかりでなく、データを共通に検索したりまたは共有したりするためのメカニズムを備えていない共通データの孤島も作り出してしまう。Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）オペレーティング・システムを稼動しているコンピュータ上に、現在どれほど多くのアドレス帳が存在できるかを考えてみる。電子メール・クライアントおよび資産管理プログラムなど多くのアプリケーションはここのアドレス帳を保持しており、そのような各プログラムが個別に保持しているアドレス帳データはアプリケーション間でほとんど共有されていない。したがって、（Microsoft Moneyのような）資産管理プログラムは、（Microsoft Outlookにあるような）電子メールの連絡先フォルダに保持されるアドレスと支払い先のアドレスを共有しない。実際に、多くのユーザが複数の装置を所有しており、論理的にはそれらの間で、さらに携帯電話からＭＳＮおよびＡＯＬなど商業サービスを含む多種多様な追加ソースにわたって個人データの同期をとる必要がある。それにもかかわらず、共有ドキュメントのコラボレーションは、大部分が電子メール・メッセージにドキュメントを添付することにより、つまり手作業で非効率的に行われている。 Developers and information technology (IT) departments have invested considerable time and money in building their own data stores for common storage abstractions that represent matters such as people, places, time, events, and so on. This not only results in duplicate work, but also creates an island of common data that does not have a mechanism for searching or sharing data in common. Consider how many address books can currently exist on a computer running the Microsoft Windows operating system. Many applications, such as e-mail clients and asset management programs, hold the address book here, and the address book data that each such program holds individually is rarely shared between applications. Therefore, asset management programs (such as Microsoft Money) do not share addresses held in email contact folders (such as in Microsoft Outlook) and payee addresses. In fact, many users own multiple devices and logically need to synchronize their personal data across a wide variety of additional sources, including mobile services from mobile phones to MSN and AOL, etc. There is. Nevertheless, shared document collaboration is largely done inefficiently by attaching the document to an email message, that is, manually.
このコラボレーションが欠けている１つの原因は、コンピュータ・システムにおいて情報を編成する従来型のアプローチが、ファイル・フォルダおよびディレクトリ・ベースのシステム（「ファイル・システム」）の使用に重点を置いてきたことである。これは、複数のファイルを、ファイルを格納するために使用される記憶媒体の物理編成の抽象化に基づいてフォルダのディレクトリ階層に複数のファイルを編成するものである。１９６０年代に開発されたＭｕｌｔｉｃｓオペレーティング・システムは、ファイル、フォルダ、ディレクトリを使用してオペレーティング・システム・レベルで格納可能なデータの単位を管理することを開拓したと信じられている。特に、Ｍｕｌｔｉｃｓでは、ファイルの物理アドレスがユーザ（アプリケーションおよびエンド・ユーザ）に透過的ではなかったファイルの階層内にシンボリック・アドレスを使用した（これによりファイル・パスの概念を導入した）。このファイル・システムは個々のファイルのファイル形式（file format）に完全に無関心であり、ファイル間のリレーションシップはオペレーティング・システム・レベル（つまり、階層内のファイルの場所以外）では無関係であると見なされていた。Ｍｕｌｔｉｃｓの出現以来、格納可能なデータは、オペレーティング・システム・レベルでファイル、フォルダおよびディレクトリに編成されてきた。これらのファイルは一般に、ファイル・システムによって保持される特殊ファイルに組み込まれたファイル階層自体（「ディレクトリ」）を含んでいる。このディレクトリが、ディレクトリ内の他のすべてのファイルに対応するエントリのリストと、階層内のそのようなファイルのノード上の場所（本明細書においてフォルダと呼ぶ）を保持する。以上のような状態が、ほぼ４０年間にわたるこの分野の状態であった。 One reason for this lack of collaboration is that traditional approaches to organizing information in computer systems have focused on the use of file folders and directory-based systems (“file systems”). It is. This organizes a plurality of files into a directory hierarchy of folders based on an abstraction of the physical organization of the storage medium used to store the files. The Multics operating system developed in the 1960s is believed to have pioneered managing units of data that can be stored at the operating system level using files, folders, and directories. In particular, Multics used symbolic addresses in the hierarchy of files where the file's physical address was not transparent to users (applications and end users) (thus introducing the concept of file paths). This file system is completely indifferent to the file format of individual files, and the relationships between the files are considered irrelevant at the operating system level (ie, other than the location of the file in the hierarchy). It was made. Since the advent of Multics, storable data has been organized into files, folders and directories at the operating system level. These files typically include the file hierarchy itself (“directory”) embedded in a special file maintained by the file system. This directory maintains a list of entries corresponding to all other files in the directory and the location on the node of such files in the hierarchy (referred to herein as a folder). The above situation has been in this field for almost 40 years.
しかし、コンピュータの物理ストレージ・システムに収められた情報の合理的な表現を提供し、ファイル・システムが、その物理ストレージ・システムの抽象化である限り、それゆえ、ファイルの利用には、ユーザが操作するもの（コンテクスト、機能、および他の単位とのリレーションシップを備える単位）とオペレーティング・システムが提供するもの（ファイル、フォルダ、およびディレクトリ）との間であるレベルの本筋からはずれた処理（a level of indirection）（判断（(interpretation））が必要となる。必然的に、ユーザ（アプリケーションおよび／またはエンド・ユーザ）は、たとえそうすることが非効率であり、整合性に欠ける、あるいは望ましくない場合であっても、選択の余地がなく、情報の単位をファイル・システム構造に押し込まざるを得なかった。さらに、既存のファイル・システムは個々のファイルに格納されているデータの構造についてほとんど識別することがない。このために、ほとんどの情報は、その作成元のアプリケーションにしかアクセス（および理解）することができないファイル内に閉じこめられたままである。したがって、こうした情報の概略的な記述と情報管理のメカニズムの不足により、個々のサイロ（貯蔵庫）間でほとんどデータが共有されないデータのサイロの作成につながっている。たとえば、多くのパーソナル・コンピュータ（ＰＣ）ユーザは、ある程度やり取りする相手に関する情報を収めた５つ以上の別個の格納場所、たとえば、Ｏｕｔｌｏｏｋ Ｃｏｎｔａｃｔｓ、オンライン・アカウント・アドレス、Ｗｉｎｄｏｗｓ（登録商標）Ａｄｄｒｅｓｓ Ｂｏｏｋ、Ｑｕｉｃｋｅｎ Ｐａｙｅｅｓ、およびインスタント・メッセージング（ＩＭ）仲間リストなど、を持っている。その理由は、こうしたＰＣユーザにとってファイルを整理することは重大な課題となるからである。ほとんどの既存のファイル・システムはファイルおよびフォルダの整理にネストされたフォルダのメタファーを使用するので、ファイルの数が増加するにつれて、柔軟かつ効率的な編成スキーマを維持するために必要な取り組みはまさに試練となってしまう。そのような状況において、単一ファイルについて複数の分類を備えることは非常に有用であろう。ただし、既存のファイル・システムでハードまたはソフト・リンクを使用することは煩わしく、保守も困難になる。 However, as long as it provides a reasonable representation of the information contained in a computer's physical storage system and the file system is an abstraction of that physical storage system, the use of the file is An off-level process (a that has context, function, and units that have relationships with other units) and what the operating system provides (files, folders, and directories) (a level of indirection (necessary (interpretation) is necessary. By necessity, users (applications and / or end users) are inefficient to do so, inconsistent or undesirable In some cases, there is no choice and pushes the unit of information into the file system structure. In addition, existing file systems rarely identify the structure of the data stored in individual files, so most of the information is in the application that created it. It remains confined in a file that can only be accessed (and understood), so there is little data sharing between individual silos due to the lack of a general description of this information and the mechanism of information management. For example, many personal computer (PC) users have more than five separate storage locations containing information about whom they interact to some extent, such as Outlook Contacts, online account Address, Windows ( (Registered trademark) Address Book, Quick Payes, and Instant Messaging (IM) buddy list, etc. Organizing files is a major challenge for these PC users. Because existing file systems use nested folder metaphors for file and folder organization, as the number of files increases, the effort required to maintain a flexible and efficient organization scheme is just a challenge. In such a situation, it would be very useful to have multiple classifications for a single file, but using a hard or soft link with an existing file system would be cumbersome and maintainable. It becomes difficult.
過去において、ファイル・システムの欠点に対処する試みがいくつか失敗に終わっている。こうしたこれまでの試みの中には、連想記憶装置（content addressable memory ）」を使用して、物理アドレスによってではなくコンテンツによってデータにアクセスできるようなメカニズムを提供するものも含まれていた。しかし、こうした取り組みは不成功に終わった。しかし一方、連想記憶装置はキャッシュおよびメモリ管理装置などの装置による小規模な利用に有効であることが判明したが、物理記憶媒体のような装置の大規模な利用は種々の理由からまだ可能ではなく、したがって、そのような解決策が単に存在していない。オブジェクト指向データベース（ＯＯＤＢ）システムを使用する他の試みも行われたが、こうした試みは、強力なデータベース特性と優れた非ファイル表現にもかかわらず、ファイル表現の処理には効果的ではなく、速度、効率、およびハードウェア／ソフトウェア・インターフェース・システム・レベルにおけるファイルおよびフォルダ・ベースの階層構造の簡易さを再現することはできなかった。ＳｍａｌｌＴａｌｋ（および他の派生）を使用しようと試みたものなど、他の取り組みは、ファイルおよび非ファイル表現を処理する上では非常に効果的であると判明したが、各種データ・ファイル間に存在するリレーションシップを効果的に編成して利用するために必要なデータベース機能が不十分であった。そのため、そのようなシステムの全体的効率は許容できないものであった。さらに、ＢｅＯＳ（および他のそのようなオペレーティング・システムの研究）を使用する別の試みも、一部の必要なデータベース機能を提供しながら十分にファイルを表現できるにもかかわらず、非ファイル表現の処理には不十分である（従来のファイル・システムの同様の中心的な短所）ことが判明した。 In the past, several attempts to address the shortcomings of file systems have failed. Some of these previous attempts included using a content addressable memory to provide a mechanism that allows data to be accessed by content rather than by physical address. However, these efforts were unsuccessful. However, while associative storage devices have proved effective for small-scale use by devices such as caches and memory management devices, large-scale use of devices such as physical storage media is still not possible for various reasons. Therefore, no such solution simply exists. Other attempts to use an object-oriented database (OODB) system have also been made, but these attempts are not effective in processing file representations, despite their powerful database characteristics and good non-file representations, and speed. , Efficiency, and simplicity of file and folder based hierarchies at the hardware / software interface system level could not be reproduced. Other efforts, such as those attempting to use SmallTalk (and other derivations), have proven very effective in handling file and non-file representations, but exist between various data files Insufficient database functions were required to effectively organize and use relationships. Therefore, the overall efficiency of such a system was unacceptable. In addition, another attempt to use BeOS (and other such operating system research) is also able to represent non-file representations even though it can adequately represent files while providing some necessary database functionality. It turns out to be inadequate for processing (similar core disadvantage of traditional file systems).
データベース・テクノロジは、同様の挑戦課題が存在するもう１つの技術分野である。たとえば、リレーショナル・データベース・モデルは巨大な商業的成功を収めてきたが、実際には、独立系ソフトウェア・ベンダ（ＩＳＶ）が一般に実施している、リレーショナル・データベース・ソフトウェア製品（Microsoft SQL Serverなど）に使用可能な機能はほんの一部である。と言うよりも、そのような製品とのほとんどのアプリケーションのやりとりは、簡単な「得る（gets）」および「入れる（puts）」の形態をとる。これには、プラットフォームまたはデータベースについて明確な見解がないなど、多くの簡単に明らかになる理由があるけれども、注目されないことになる多くの重要な理由の一つは、主要なビジネス・アプリケーション・ベンダが実際に必要とする厳密な抽象化を必ずしも提供しなくてもよいという点があげられる。たとえば、現実世界は「顧客」または「注文」（注文内のアイテムおよび注文のアイテムとしての注文に組み込まれた「line items（品目名）」と共に）のような「アイテム」の概念を備えているが、リレーショナル・データベースはテーブルおよび行（rows）の観点から論じるのみである。したがって、アプリケーションに、アイテム・レベルで（２〜３の例をあげると）整合性、ロッキング、セキュリティ、および／またはトリガの諸相（aspect）を備えたいとしても、一般にデータベースがこれらの機能（features）をテーブル／行（rows）レベルでのみ提供する。これは、各アイテムがデータベース内の一部のテーブルの単一行（rows）にマップされる場合は良好に機能するかもしれないが、複数の品目名のある注文の場合には、アイテムが実際に複数のテーブルにマップされなければならず、その場合には、簡単なリレーショナル・データベース・システムは正しい抽象化を提供しない。したがって、アプリケーションは、データベースの上部に論理を構築して、これらの基本抽象化を提供する必要がある。すなわち、基本リレーショナル・モデルは、より上位レベルのアプリケーションを容易に開発できる、データのストレージのための、十分なプラットフォームを提供しない。というのは基本リレーショナル・モデルがアプリケーションおよびストレージ・システムとの間に、あるレベルの本筋からはずれた処理（a level of indirection）を必要とするからである。ここでは、データの意味構造は、特定の事例におけるアプリケーション内で見えるだけである。いくつかのデータベースベンダは、オブジェクト・リレーショナル機能、新しい組織モデルなどを提供する自社製品により高レベルの機能性を組み込んでいるが、いずれも、まだ、必要な一種の包括的解決策を提供するには至っていない。ここで真に包括的な解決策とは、有用なドメイン抽象化（「Ｐｅｒｓｏｎｓ」、「Ｌｏｃａｔｉｏｎｓ」、「Ｅｖｅｎｔｓ」など）に有用なデータ・モデル抽象化（「Ｉｔｅｍｓ」、「Ｅｘｔｅｎｓｉｏｎｓ」、「Ｒｅｌａｔｉｏｎｓｈｉｐｓ」など）を提供するものである。 Database technology is another area of technology with similar challenges. For example, the relational database model has been a huge commercial success, but in fact, relational database software products (such as Microsoft SQL Server) commonly practiced by independent software vendors (ISVs). Only a few functions are available. Rather, most application interactions with such products take the form of simple “gets” and “puts”. There are many easy reasons for this, such as lack of a clear view of the platform or database, but one of the many important reasons that will not be noticed is that major business application vendors The exact abstraction actually required is not necessarily provided. For example, the real world has the concept of “items” such as “customers” or “orders” (with “line items” embedded in the items in the order and the items in the order) But relational databases only discuss in terms of tables and rows. Thus, even if an application wants to have integrity, locking, security, and / or trigger aspects at the item level (to name a few examples), the database generally has these features. Only at the table / rows level. This may work well if each item is mapped to a single row in some table in the database, but in the case of an order with multiple item names, the item is actually It must be mapped to multiple tables, in which case a simple relational database system does not provide the correct abstraction. Therefore, applications need to build logic on top of the database to provide these basic abstractions. That is, the basic relational model does not provide a sufficient platform for the storage of data that can easily develop higher level applications. This is because the basic relational model requires a level of indirection between the application and the storage system. Here, the semantic structure of the data is only visible within the application in the specific case. Some database vendors incorporate higher levels of functionality with their products that provide object-relational capabilities, new organizational models, etc., but all still offer the kind of comprehensive solution they need. Has not reached. A truly comprehensive solution here is a data model abstraction ("Items", "Extensions", "Relationships") useful for useful domain abstractions ("Persons", "Locations", "Events", etc.). Etc.).
既存のデータ・ストレージとデータベース・テクノロジにおける前述の不備を考慮すると、コンピュータ・システムのすべてのタイプのデータを編成、検索、共有する改良された能力を提供する新しいストレージ・プラットフォーム、すなわち、データ・プラットフォームを既存のファイル・システムおよびデータベース・システムを超えたデータ・プラットフォームに拡張して広げるストレージ・プラットフォームであり、あらゆるタイプのデータの格納装置となるように設計されたストレージ・プラットフォームの必要性が存在する。先に参照により本明細書に組み込まれている関連発明は、この必要性を満たす。 Considering the aforementioned deficiencies in existing data storage and database technologies, a new storage platform that provides an improved ability to organize, search and share all types of data in computer systems, ie data platform Is a storage platform that extends and extends the data platform beyond existing file and database systems, and there is a need for a storage platform designed to be the storage device for all types of data . The related invention previously incorporated herein by reference fulfills this need.
しかし、イメージ（写真、デジタル画像など）のストレージは標準化されておらず、プラットフォームおよびアプリケーションにわたって汎用化されていない。アプリケーションは、特定の画像フォーマット（ＪＰＥＧなど）に合わせて調整されたＡＰＩを含むことができるが、そのようなアプリケーションの開発者は、フォーマットを認識し、調整されたアプリケーション・プログラミング・インターフェース（ＡＰＩ）を含め、さらに前記フォーマットと相互運用するために必要なあらゆる変換を行う必要がある。当技術分野において不足しているのは、コンピュータ・システムのすべての画像オブジェクトに対する共通のスキーマ（あるいはスキーマのセット）であり、本発明は、先に参照により本明細書に組み込まれている関連発明と共に、この特定の必要性を満たす。 However, the storage of images (photos, digital images, etc.) is not standardized and is not generalized across platforms and applications. An application can include an API tailored to a specific image format (such as JPEG), but the developer of such an application is aware of the format and is tailored to an application programming interface (API). And any other conversions necessary to interoperate with the format must be performed. What is deficient in the art is a common schema (or set of schemas) for all image objects in a computer system, and the present invention is related invention previously incorporated herein by reference. Along with this particular need.
以下では、先に本明細書（「関連発明」）に参照により組み込まれている関連発明との関連で説明されている本発明のさまざまな態様の概要を述べる。本概要は、本発明の重要な態様のすべてを包括的に説明するものではなく、また本発明の範囲を定義するものでもない。むしろ、本概要は、詳細な説明およびそれに付随する図への導入部としての役割を果たすことを目的としている。 The following outlines various aspects of the present invention that have been described above in relation to related inventions previously incorporated herein by reference ("related inventions"). This summary is not an exhaustive description of all important aspects of the invention and does not define the scope of the invention. Rather, this summary is intended to serve as an introduction to the detailed description and the accompanying figures.
本発明および関連発明は全体として、データを編成し（organizing）、検索し（searching）、共有する（sharing）ためのストレージ・プラットフォームを対象としている。本発明のストレージ・プラットフォームは、既存のファイル・システムおよびデータベース・システムを超えてデータ・ストレージの概念を拡張して広げ、構造化、非構造化、または半構造化データを含むあらゆるタイプのデータの格納装置（store）となるように設計される。 The present invention and related inventions are generally directed to a storage platform for organizing, searching, and sharing data. The storage platform of the present invention extends and extends the concept of data storage beyond existing file systems and database systems, and supports any type of data including structured, unstructured, or semi-structured data. Designed to be a store.
本発明のストレージ・プラットフォームは、データベース・エンジン上に実装されたデータ・ストアを備えている。データベース・エンジンは、オブジェクト・リレーショナル拡張（relational extensions）を備えるリレーショナル・データベース・エンジンを備えている。データ・ストアは、データの編成、検索、共有、同期化、およびセキュリティをサポートするデータ・モデルを実装する。データの特定のタイプについてはスキーマ内に記述され、プラットフォームは、新しいデータのタイプを定義するようにスキーマのセットを拡張するメカニズムを提供する（原則的に基本タイプのサブタイプはスキーマごとに提供する）。同期化機能により、ユーザまたはシステム間のデータの共有が容易になる。既存のファイル・システムとのデータ・ストアの相互運用を、そのような従来型のファイル・システムの制限を受けることなく、可能にするファイル・システムと同様の機能が提供される。変更追跡メカニズムは、データ・ストアへの変更を追跡する機能を提供する。ストレージ・プラットフォームは、アプリケーションがストレージ・プラットフォームの前述のすべての機能にアクセスできるようにし、スキーマに記述されているデータにアクセスできるようにする一連のアプリケーションプログラム・インターフェースをさらに備えている。 The storage platform of the present invention comprises a data store implemented on a database engine. The database engine includes a relational database engine with object-relational extensions. The data store implements a data model that supports data organization, retrieval, sharing, synchronization, and security. Specific types of data are described in the schema, and the platform provides a mechanism to extend the set of schemas to define new data types (in principle, subtypes of basic types are provided for each schema) ). The synchronization function facilitates sharing of data between users or systems. A function similar to a file system is provided that allows data store interoperability with existing file systems without the limitations of such conventional file systems. The change tracking mechanism provides the ability to track changes to the data store. The storage platform further comprises a set of application program interfaces that allow applications to access all of the aforementioned functions of the storage platform and to access the data described in the schema.
データ・ストアによって実装されるデータ・モデルは、アイテム（items）、要素（elements）、およびリレーションシップ（relationships）の観点からデータ・ストレージの単位（units of data storage）を定義する。アイテムは、データ・ストア内に格納可能なデータの単位であり、１つまたは複数の要素およびリレーションシップを備えることができる。要素は、１つまたは複数のフィールド（本明細書においてプロパティとも呼ぶ）を備えるタイプのインスタンスである。リレーションシップは２つのアイテムの間のリンクである。（本明細書において使用されているように、これらの特定の用語は近接して使用される他の用語と分けるために最初を大文字表記（翻訳上では原語表記する場合がある）にすることがある。ただし、大文字表記の用語（たとえば「Ｉｔｅｍ」）と大文字表記しない同じ用語（たとえば「ｉｔｅｍ」（翻訳上では、日本語表記の「アイテム」））とを区別する意図はなく、そのような区別が推定されたり、または暗示されたりされるべきではない。）
コンピュータ・システムは、各アイテムをハードウェア／ソフトウェア・インターフェース・システムにより操作することができる個々の格納可能な情報の単位を構成する複数のアイテムと、前記アイテムの組織構造（organizational structure）を構成する複数のアイテム・フォルダと、各アイテムが少なくとも１つのアイテム・フォルダに属し、且つ複数のアイテム・フォルダに属すことが可能な態様で、複数のアイテムを操作するハードウェア／ソフトウェア・インターフェース・システムと、を備えている。
The data model implemented by the data store defines units of data storage in terms of items, elements, and relationships. An item is a unit of data that can be stored in a data store and can comprise one or more elements and relationships. An element is an instance of a type that comprises one or more fields (also referred to herein as properties). A relationship is a link between two items. (As used herein, these specific terms may be capitalized first (may be translated in the original language) to separate them from other terms used in close proximity. However, there is no intention to distinguish between capitalized terms (eg, “Item”) and non-capitalized terms (eg, “item” (in translation, “item”)) The distinction should not be estimated or implied.)
The computer system constitutes a plurality of items that constitute an individual storable unit of information that allows each item to be manipulated by a hardware / software interface system, and an organizational structure of the items. A hardware / software interface system for manipulating a plurality of items in a manner that each item belongs to at least one item folder and is capable of belonging to a plurality of item folders; It has.
アイテムまたは一部のアイテムのプロパティ値は、永続ストア（persistent store）から導出されるのではなく、動的に計算されることがある。つまり、ハードウェア／ソフトウェア・インターフェース・システムは、アイテムが格納されていることを要求せず、アイテムの現行セットを列挙する機能、またはストレージ・プラットフォームの識別子を与えられたアイテムを取り出す機能、などの特定の操作がサポートされる（これについては、アプリケーション・プログラミング・インターフェース、すなわちＡＰＩを説明するセクションでさらに詳細に説明する）。たとえば、アイテムは携帯電話の現在位置であることも、温度センサの計測温度であることもある。ハードウェア／ソフトウェア・インターフェース・システムは、複数のアイテムを操作することができ、ハードウェア／ソフトウェア・インターフェース・システムによって管理される複数のリレーションシップによって相互接続されているアイテムをさらに備えている。 Property values for items or some items may be calculated dynamically rather than being derived from a persistent store. This means that the hardware / software interface system does not require that the item be stored and can enumerate the current set of items or retrieve an item given a storage platform identifier, etc. Certain operations are supported (this is described in more detail in the section describing the application programming interface, or API). For example, the item may be the current position of the mobile phone or the temperature measured by the temperature sensor. The hardware / software interface system further comprises items that are capable of manipulating multiple items and interconnected by multiple relationships managed by the hardware / software interface system.
コンピュータ・システム用のハードウェア／ソフトウェア・インターフェース・システムは、コア・アイテムのセットを定義するコア・スキーマをさらに備え、それを、前記ハードウェア／ソフトウェア・インターフェース・システムが理解して、あらかじめ定義された予測可能な方法で直接処理することができる。複数のアイテムを操作するために、コンピュータ・システムは、前記アイテムを複数のリレーションシップと相互接続し、前記リレーションシップをハードウェア／ソフトウェア・インターフェース・システム・レベルで管理する。 A hardware / software interface system for a computer system further comprises a core schema that defines a set of core items, which are predefined by the hardware / software interface system as understood by the hardware / software interface system. Can be processed directly in a predictable way. In order to manipulate multiple items, the computer system interconnects the items with multiple relationships and manages the relationships at the hardware / software interface system level.
ストレージ・プラットフォームのＡＰＩは、ストレージ・プラットフォーム・スキーマのセットで定義されている各アイテム、アイテム拡張機能、およびリレーションシップに対するデータ・クラスを提供する。さらに、アプリケーション・プログラミング・インターフェースは、データ・クラスに対して振る舞いの共通セットを定義し、データ・クラスと共に、ストレージ・プラットフォームＡＰＩの基本プログラミング・モデルを提供する、フレームワーク・クラスのセットを提供する。ストレージ・プラットフォームＡＰＩは、基礎をなすデータベース・エンジンのクエリ言語の詳細からアプリケーション・プログラマを隔離するような方法で、アプリケーション・プログラマがデータ・ストア内のアイテムのさまざまなプロパティに基づいてクエリを形成できるようにする簡易クエリ・モデルを提供する。ストレージ・プラットフォームＡＰＩはさらに、アプリケーション・プログラムによって行われたアイテムへの変更を収集し、それらをデータ・ストアが実装されているデータベース・エンジン（または任意の種類のストレージ・エンジン）に必要とされる正しい更新に編成する。これにより、アプリケーション・プログラマは、メモリ内のアイテムに変更を行うことができ、しかも複雑なデータ・ストア・アップデートをＡＰＩに任せることができる。 The storage platform API provides a data class for each item, item extension, and relationship defined in the set of storage platform schemas. In addition, the application programming interface provides a set of framework classes that define a common set of behaviors for the data classes and, along with the data classes, provide the basic programming model of the storage platform API. . The storage platform API allows application programmers to build queries based on various properties of items in the data store in a way that isolates the application programmer from the details of the underlying database engine query language. Provide a simple query model to The storage platform API also collects changes to items made by application programs and is required by the database engine (or any type of storage engine) where the data store is implemented. Organize into correct updates. This allows the application programmer to make changes to the items in memory and leave the complex data store updates to the API.
本発明のストレージ・プラットフォームは、その共通のストレージ基盤および体系化されたデータを通じて、消費者、知識労働者および企業のさらに効率的なアプリケーション開発を実現することができる。このストレージ・プラットフォームは、機能豊富で拡張可能なアプリケーション・インターフェースを提供するが、これはそのデータ・モデルに固有の機能を利用できるようにするだけではなく、既存のファイル・システムおよびデータベース・アクセス方法も取り入れて拡張している。 The storage platform of the present invention can achieve more efficient application development for consumers, knowledge workers and enterprises through its common storage infrastructure and organized data. This storage platform provides a rich and extensible application interface that not only allows you to take advantage of the features specific to its data model, but also the existing file system and database access methods. Has also been expanded.
相互に関連する発明のこの包括的な構造（「詳細な説明」のセクションＩＩにおいて詳しく説明する）に照らして、本発明は特に、コンピュータ・システムにおけるすべてのイメージ・オブジェクト（イメージ・アイテム）のための共通のスキーマを対象としている。本発明の他の特徴および利点は、本発明の以下の詳細な説明および付属の図を参照すれば明らかになろう。 In light of this comprehensive structure of interrelated inventions (described in detail in Section II of the “Detailed Description”), the present invention is particularly for all image objects (image items) in a computer system. Target common schema. Other features and advantages of the present invention will become apparent with reference to the following detailed description of the invention and the accompanying drawings.
上記の概要および上記の本発明の詳細な説明は、付属の図を参照しながら読めばよりよく理解できよう。本発明を例示する目的で、本発明のさまざまな態様の例示的な実施例が図に示されている。ただし、本発明は、開示されている特定の方法および手段に限定されることはない。 The foregoing summary, as well as the foregoing detailed description of the invention, will be better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, there are shown in the drawings exemplary embodiments of various aspects of the invention. However, the invention is not limited to the specific methods and instrumentalities disclosed.
目次
Ｉ． 概要 −００２４−
Ａ． 例示的なコンピューティング環境 −００２５−
Ｂ． 従来型ファイル・ベースのストレージ −００３８−
ＩＩ． データの編成、検索、および共有のためのＷＩＮＦＳストレージ・プラットフォーム −００４１−
Ａ． 用語解説 −００４２−
Ｂ． ストレージ・プラットフォームの概要 −００４３−
Ｃ． データ・モデル −００４８−
１． アイテム −００５３−
２． アイテムの識別 −００６０−
３． アイテム・フォルダおよびカテゴリ −００６６−
４． スキーマ −００７１−
ａ） 基本スキーマ −００７１−
ｂ） コア・スキーマ −００７４−
５． リレーションシップ −００７８−
ａ） リレーションシップの宣言 −００８３−
ｂ） 保持のリレーションシップ −００８７−
ｃ） 埋め込みのリレーションシップ −００９８−
ｄ） 参照のリレーションシップ −０１０５−
ｅ） 規則および制約 −０１１０−
ｆ） リレーションシップの順序付け −０１１１−
６． 拡張性 −０１２４−
ａ） アイテムの拡張（Item extensions） −０１２８−
ｂ） ＮｅｓｔｅｄＥｌｅｍｅｎｔタイプの拡張 −０１４９−
Ｄ． データベース・エンジン −０１５７−
１． ＵＤＴを使用するデータ・ストアの実装 −０１６１−
２． アイテムのマッピング −０１６５−
３． 拡張のマッピング −０１６９−
４． ネスト化要素のマッピング −０１７０−
５． オブジェクトのＩＤ −０１７１−
６． ＳＱＬオブジェクトの命名 −０１７２−
７． カラムの命名 −０１７４−
８． 検索ビュー −０１７５−
ａ） アイテム −０１７８−
（１） マスタ・アイテム検索ビュー −０１７９−
（２） タイプ定義済みアイテム検索ビュー −０１８１−
ｂ） アイテムの拡張 −０１８３−
（１） マスタ拡張検索ビュー −０１８４−
（２） タイプ定義済み拡張検索ビュー −０１８６−
ｃ） ネスト化要素 −０１８８−
ｄ） リレーションシップ −０１８９−
（１） マスタ・リレーションシップ検索ビュー −０１９０−
（２） リレーションシップ・インスタンス拡張検索ビュー −０１９２−
ｅ）
９． 更新 −０１９４−
１０． 変更追跡およびトゥームストーン −０１９６−
ａ） 変更追跡 −０１９７−
（１） 「マスタ」検索ビューの変更追跡 −０１９９−
（２） 「タイプ定義済み」検索ビューの変更追跡 −０２０３−
ｂ） トゥームストーン −０２０５−
（１） アイテムのトゥームストーン −０２０６−
（２） 拡張のトゥームストーン −０２０８−
（３） リレーションシップのトゥームストーン −０２１０−
（４） トゥームストーンのクリーンアップ −０２１２−
１１． ヘルパーＡＰＩおよび関数 −０２１３−
ａ） 関数[System.Storage].Getltem −０２２４−
ｂ） 関数[System.Storage].GetExtension −０２２６−
ｃ） 関数[System.Storage].GetRelationship −０２１８−
１２． メタデータ −０２２０−
ａ） スキーマ・メタデータ −０２２１−
ｂ） インスタンス・メタデータ −０２２２−
Ｅ． セキュリティ −０２２４−
Ｆ． 通知および変更追跡 −０２２７−
Ｇ． 同期化 −０２３０−
１． ストレージ・プラットフォーム間の同期化 −０２３４−
ａ） 同期（Sync）制御アプリケーション −０２２７−
ｂ） スキーマの注釈 −０２４０−
ｃ） 同期の構成 −０２４５−
（１） コミュニティ・フォルダ−マッピング −０２４９−
（２） プロファイル −０２５０−
（３） スケジュール −０２５２−
ｄ） 競合の処理 −０２５３−
（１） 競合の検出 −０２５４−
（ａ） 知識ベースの競合 −０２５５−
（ｂ） 制約ベースの競合 −０２５７−
（２） 競合の処理 −０２６０−
（ａ） 自動競合解決 −０２６３−
（ｂ） 競合のロギング −０２６７−
（ｃ） 競合の検査および解決 −０２６８−
（ｄ） レプリカの集束および競合解決の伝搬 −０２６９−
２． 非ストレージ・プラットフォーム・データ・ストアへの同期化 −０２７３−
ａ） 同期サービス（Sync Service） −０２７６−
（１） 変更の列挙（Change Enumeration） −０２７７−
（２） 変更適用（Change Application） −０２８２−
（３） 競合の解決 −０２８４−
ｂ） アダプタの実装 −０２８５−
３． セキュリティ −０２８６−
４． 管理容易性 −０２８９−
Ｈ． 従来型ファイル・システムの相互運用性 −０２９１−
Ｉ． ストレージ・プラットフォームＡＰＩ −０２９４−
ＩＩＩ．イメージ・スキーマおよび従属スキーマ（イメージ・スキーマ・セット） −０３１２−
Ａ． イメージ・スキーマ −０３１５−
Ｂ． フォト・スキーマ −０３２７−
Ｃ． 分析プロパティ・スキーマ −０３２９−
ＩＶ． 結論 −０３３２−
table of contents
I. Overview −0024−
A. Exemplary Computing Environment −0025−
B. Conventional file-based storage
II. WINFS storage platform for data organization, retrieval and sharing
A. Glossary −0042−
B. Storage Platform Overview −0043−
C. Data model −0048−
1. Item -0053-
2. Item identification −0060−
3. Item folder and category
4). Schema -0071-
a) Basic schema -0071-
b) Core schema -0074-
5. Relationship −0078−
a) Declaration of relationship -0083-
b) Retention relationship -0087-
c) Embedding relationships -0098-
d) Reference relationships-0105-
e) Rules and constraints
f) Ordering of relationships
6). Extensibility -0124-
a) Item extensions −0128−
b) Extension of the NestedElement type −0149−
D. Database engine
1. Implementation of data store using UDT
2. Item Mapping -0165-
3. Extension mapping
4). Mapping of nested elements −0170−
5. Object ID -0171-
6). Naming of SQL objects -0172-
7). Naming of columns
8). Search view
a) Item -0178-
(1) Master item search view
(2) Type-defined item search view
b) Item expansion -0183
(1) Master extended search view -0184-
(2) Type-defined extended search view -0186-
c) Nested element -0188-
d) Relationships -0189-
(1) Master Relationship Search View -0190-
(2) Relationship Instance Extended Search View -0192-
e)
9. Update -0194-
10. Change Tracking and Tombstone -0196-
a) Change Tracking -0197-
(1) Change tracking of “master” search view −0199−
(2) Change tracking of “type defined” search view −0203−
b) Tombstone -0205-
(1) Item Tombstone-0206-
(2) Extended tombstone-0208-
(3) Relationship Tombstone -0210-
(4) Tombstone cleanup -0212-
11. Helper API and functions -0213-
a) Function [System.Storage] .Getltem −0224−
b) Function [System.Storage] .GetExtension -0226-
c) Function [System.Storage] .GetRelationship −0218−
12 Metadata -0220-
a) Schema metadata -0221-
b) Instance metadata -0222-
E. Security -0224-
F. Notification and Change Tracking -0227-
G. Synchronization −0230−
1. Synchronization between storage platforms −0234−
a) Synchronization control application −0227−
b) Schema annotation -0240-
c) Configuration of synchronization −0245−
(1) Community folder-mapping-0249-
(2) Profile -0250-
(3) Schedule -0252-
d) Conflict handling -0253-
(1) Detection of competition -0254-
(A) Knowledge base competition -0255-
(B) Constraint-based competition
(2) Conflict processing -0260-
(A) Automatic conflict resolution -0263-
(B) Conflict logging -0267-
(C) Competitive inspection and resolution -0268-
(D) Replica convergence and propagation of conflict resolution
2. Synchronization to non-storage platform data store
a) Sync Service -0276-
(1) Change Enumeration −0277−
(2) Change Application -0282-
(3) Resolving conflicts -0284-
b) Mounting the adapter −0285−
3. Security -0286-
4). Manageability −0289−
H. Interoperability of conventional file system -0291-
I. Storage platform API -0294-
III. Image schema and subordinate schema (image schema set) -0312-
A. Image schema -0315-
B. Photo Schema -0327-
C. Analysis property schema -0329-
IV. Conclusion -0332-
Ｉ．概要
本発明の主題について、法定要件を満たすために限定性を持って説明する。ただし、説明自体は、本発明の範囲を限定することを意図していない。むしろ、発明者は、主張されている主題が他の方法で実施することもでき、他の現在または将来の技術と併せて、本明細書に説明されているさまざまなステップまたはステップの組み合わせと類似したものを含めることができることを意図している。さらに、採用された方法のさまざまな要素を示すために本明細書において「ステップ」という用語が使用されるが、この用語は、個々のステップの順序が明示的に記述されている場合を除き、本明細書に開示されているさまざまなステップの間の特定の順序を暗示するものとして解釈すべきではない。
I. Overview The subject matter of the present invention will be described with a limitation to meet statutory requirements. However, the description itself is not intended to limit the scope of the present invention. Rather, the inventor believes that the claimed subject matter can be implemented in other ways, similar to the various steps or combinations of steps described herein, in conjunction with other current or future technologies. It is intended to be included. In addition, the term “step” is used herein to denote the various elements of the method employed, unless this term explicitly states the order of the individual steps. It should not be construed as implying a specific order between the various steps disclosed herein.
Ａ．例示的なコンピューティング環境
本発明の多数の実施例は、コンピュータ上で実行することができる。図１および以下の説明は、本発明が実施される適切なコンピューティング環境について簡単に概要を説明することを意図している。必須ではないが、本発明のさまざまな態様は、クライアント・ワークステーションまたはサーバのようなコンピュータによって実行されるプログラム・モジュールなど、コンピュータ実行可能命令の一般的なコンテクストに即して説明される。一般に、プログラム・モジュールには、特定のタスクを実行するかまたは特定の抽象データ・タイプを実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。さらに、本発明は、ハンドヘルド機器、マルチ・プロセッサ・システム、マイクロ・プロセッサベースまたはプログラマブル家庭用電化製品、ネットワークＰＣ、ミニ・コンピュータ、メインフレーム・コンピュータなど、他のコンピュータ・システムの構成により実施することができる。本発明はさらに、タスクが通信ネットワークを通じてリンクされたリモート処理装置によって実行される分散コンピューティング環境においても実施することができる。分散コンピューティング環境において、プログラム・モジュールは、ローカルおよびリモートのコンピュータ記憶装置に配置することができる。
A. Exemplary Computing Environment Numerous embodiments of the present invention may be executed on a computer. FIG. 1 and the following description are intended to provide a brief overview of a suitable computing environment in which the invention may be implemented. Although not required, various aspects of the invention will be described in the general context of computer-executable instructions, such as program modules, being executed by a computer such as a client workstation or server. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Furthermore, the present invention may be implemented with other computer system configurations such as handheld devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, mini computers, mainframe computers, etc. Can do. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote computer storage devices.
図１に示すように、例示的な汎用コンピューティング・システムは、処理装置２１、システム・メモリ２２、およびシステム・メモリを含むさまざまなシステム・コンポーネントを処理装置２１に接続するシステム・バス２３を含む、従来型のパーソナル・コンピュータ２０などを含んでいる。システム・バス２３は、メモリ・バスまたはメモリ・コントローラ、周辺バス、およびさまざまなバス・アーキテクチャのいずれかを使用するローカル・バスを含む、任意のタイプのバス構造であってもよい。システム・メモリは、読み取り専用メモリ（ＲＯＭ）２４およびランダム・アクセス・メモリ（ＲＡＭ）２５を含んでいる。起動時などにパーソナル・コンピュータ２０内の要素間の情報の転送を助ける基本ルーチンを含む基本入出力システム２６（ＢＩＯＳ）は、ＲＯＭ２４に格納される。パーソナル・コンピュータ２０はさらに、ハードディスク（図示せず）との間の読み取りまたは書き込みを行うハードディスク・ドライブ２７、取り外し可能の磁気ディスク２９との間の読み取りまたは書き込みを行う磁気ディスクドライ２８、およびＣＤ−ＲＯＭその他の光媒体など、取り外し可能の光ディスク３０との間の読み取りまたは書き込みを行う光ディスク・ドライブ３１を含むことができる。ハードディスク・ドライブ２７、磁気ディスク・ドライブ２８、および光ディスク・ドライブ３０は、それぞれハードディスク・ドライブ・インターフェース３２、磁気ディスク・ドライブ・インターフェース３３、および光ドライブ・インターフェース３４によってシステム・バス２３に接続されている。ドライブおよびその関連するコンピュータ可読媒体は、パーソナル・コンピュータ２０のコンピュータ可読命令、データ構造、プログラム・モジュール、およびその他のデータの不揮発性記憶装置を提供する。本明細書に記載の例示的な環境では、ハードディスク、取り外し可能磁気ディスク２９、および取り外し可能光ディスク７３１を採用しているが、磁気カセット、フラッシュ・メモリ・カード、デジタル・ビデオ・ディスク、ベルヌーイ・カートリッジ、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）などの、コンピュータによりアクセス可能なデータを格納できる他の種類のコンピュータ可読媒体も、例示的なオペレーティング環境に使用できることは当業者であれば理解するであろう。同様に、例示的な環境には、熱感知器および警備または火災報知システム、およびその他の情報源など、多くの種類の監視装置を含めることもできる。
As shown in FIG. 1, an exemplary general purpose computing system includes a
ハードディスク、磁気ディスク２９、光ディスク３１、ＲＡＭ２４またはＲＯＭ２５には、たとえばオペレーティング・システム３５、１つまたは複数のアプリケーション・プログラム３６、その他のプログラム・モジュール３７、およびプログラム・データ３８を含む、多数のプログラム・モジュールを格納することができる。ユーザは、キーボード４０およびポインティング・デバイス４２などの入力装置を介してパーソナル・コンピュータ２０にコマンドおよび情報を入力することができる。他の入力装置（図示せず）としては、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送用パラボラアンテナ、スキャナなどを含むことができる。上記およびその他の入力装置は、システム・バスに接続されているシリアル・ポート・インターフェース４６を介して処理装置２１に接続されることが多いが、パラレルポート、ゲームポート、またはユニバーサル・シリアル・バス（ＵＳＢ）など他のインターフェースによって接続することもできる。モニタ４７またはその他の種類の表示装置も、ビデオ・アダプタ４８などのインターフェースを介してシステム・バス２３に接続することができる。モニタ４７に加えて、パーソナル・コンピュータは通常、スピーカおよびプリンタなど、他の周辺出力装置（図示せず）を含んでいる。図１の例示的なシステムはさらに、ホスト・アダプタ５５、Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ（ＳＣＳＩ）バス５６、およびＳＣＳＩバス５６に接続されている外部格納装置６２も含んでいる。
The hard disk,
パーソナル・コンピュータ２０は、リモート・コンピュータ４９など、１つまたは複数のリモート・コンピュータへの論理接続を使用するネットワーク化された環境において動作することができる。リモート・コンピュータ４９は、パーソナル・コンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア・デバイスまたはその他の共通ネットワーク・ノードであってもよく、通常は上記でパーソナル・コンピュータ２０に関連して説明されている要素の多くまたはすべてを含んでいる。図１に示される論理接続は、ローカル・エリア・ネットワーク（ＬＡＮ）５１およびワイド・エリア・ネットワーク（ＷＡＮ）５２を含んでいる。そのようなネットワーク環境は、オフィス、企業規模のコンピュータ・ネットワーク、イントラネット、およびインターネットで一般化している。
The
ＬＡＮネットワーク環境に使用される場合、パーソナル・コンピュータ２０はネットワーク・インターフェースまたはアダプタ５３を介してＬＡＮ５１に接続される。ＷＡＮネットワーク環境に実装される場合、パーソナル・コンピュータ２０は通常、モデム５４または、インターネットなどのワイド・エリア・ネットワーク５２にわたる通信を確立するための他の手段、を含んでいる。モデム５４は、内蔵または外付けであってもよく、シリアル・ポート・インターフェース４６を介してシステム・バス２３に接続することができる。ネットワーク化された環境において、パーソナル・コンピュータ２０に関連して示されるプログラム・モジュール、またはその部分は、リモート記憶装置に格納することもできる。示されているネットワーク接続が例示的なものであり、コンピュータ間の通信リンクを確立する他の手段も使用できることを理解されたい。
When used in a LAN network environment, the
図２のブロック図に示されているように、コンピュータ・システム２００は、ハードウェア・コンポーネント２０２、ハードウェア／ソフトウェア・インターフェース・システムコンポーネント２０４、およびアプリケーション・プログラム・コンポーネント２０６（本明細書の特定のコンテクストにおいて「ユーザ・コンポーネント」または「ソフトウェア・コンポーネント」とも呼ばれる）という、３つのコンポーネント・グループに大きく分割することができる。
As shown in the block diagram of FIG. 2, the
コンピュータ・システム２００のさまざまな実施例において、図１に戻って参照すると、ハードウェア・コンポーネント２０２は、中央演算処理装置（ＣＰＵ）２１、メモリ（ＲＯＭ２４およびＲＡＭ２５）、基本入出力システム（ＢＩＯＳ）２６、および特にキーボード４０、マウス４２、モニタ４７、および／またはプリンタ（図示せず）などのさまざまな入出力（Ｉ／Ｏ）装置を備えることができる。ハードウェア・コンポーネント２０２は、コンピュータ・システム２００の基本物理インフラストラクチャを備えている。
In various embodiments of the
アプリケーション・プログラム・コンポーネント２０６は、コンパイラ、データベース・システム、ワード・プロセッサ、ビジネス・プログラム、ビデオ・ゲームなどを含むさまざまなソフトウェア・プログラムを備えているが、これらに限定されることはない。アプリケーション・プログラムは、さまざまなユーザ（マシン、他のコンピュータ・システムおよび／またはエンド・ユーザ）に対して問題の解決、解決策の提供、およびデータの処理を行うためにコンピュータ・リソースが利用される手段を提供する。
The
ハードウェア／ソフトウェア・インターフェース・システム・コンポーネント２０４は、ほとんどの場合シェルおよびカーネルを備えるオペレーティング・システムを備えている（一部の実施例においてはオペレーティング・システムのみで構成される）。「オペレーティング・システム」（ＯＳ）は、アプリケーション・プログラムとコンピュータ・ハードウェアの間の仲介としての役割を果たす特殊なプログラムである。ハードウェア／ソフトウェア・インターフェース・システム・コンポーネント２０４は、仮想マシン・マネージャ（ＶＭＭ）、共通言語ランタイム（ＣＬＲ）またはその機能的な相当物、Ｊａｖａ（登録商標）仮想マシン（ＪＶＭ）またはその機能的な相当物、またはコンピュータ・システムのオペレーティング・システムに代わるかまたはこれに追加する他のそのようなソフトウェア・コンポーネントも備えている。ハードウェア／ソフトウェア・インターフェース・システムの目的は、ユーザがアプリケーション・プログラムを実行できる環境を提供することにある。ハードウェア／ソフトウェア・インターフェース・システムの目標は、コンピュータ・システムを使いやすくし、効率的よくコンピュータ・ハードウェアを利用することである。
The hardware / software
ハードウェア／ソフトウェア・インターフェース・システムは一般に、起動時にコンピュータ・システムにロードされ、その後コンピュータ・システム内のすべてのアプリケーション・プログラムを管理する。アプリケーション・プログラムは、アプリケーション・プログラム・インターフェース（ＡＰＩ）を介してサービスを要求することによってハードウェア／ソフトウェア・インターフェースと対話する。一部のアプリケーション・プログラムは、コマンド言語またはグラフィカル・ユーザ・インターフェース（ＧＵＩ）などのユーザ・インターフェースを介してエンド・ユーザがハードウェア／ソフトウェア・インターフェースと対話できるようにする。 The hardware / software interface system is typically loaded into the computer system at startup and then manages all application programs in the computer system. Application programs interact with the hardware / software interface by requesting services through an application program interface (API). Some application programs allow end users to interact with the hardware / software interface via a user interface, such as a command language or a graphical user interface (GUI).
ハードウェア／ソフトウェア・インターフェース・システムは従来より、アプリケーション向けのさまざまなサービスを実行している。複数のプログラムが同時に実行することができるマルチ・タスキング・ハードウェア／ソフトウェア・インターフェース・システムにおいて、ハードウェア／ソフトウェア・インターフェース・システムは、どのアプリケーションをどの順序で実行すべきか、また別のアプリケーションに切り替えるまでに各アプリケーションにどのくらいの時間を与えるかを決定する。ハードウェア／ソフトウェア・インターフェース・システムはさらに、複数のアプリケーション間の内部メモリの共有も管理し、ハードディスク、プリンタ、およびダイヤルアップ・ポートなどの接続されたハードウェア装置との間の入出力も処理する。ハードウェア／ソフトウェア・インターフェース・システムはまた、オペレーションの状態および発生した可能性のあるエラーについて各アプリケーション（および特定の場合にはエンド・ユーザ）にメッセージを送信する。ハードウェア／ソフトウェア・インターフェース・システムはさらに、バッチ・ジョブ（たとえば印刷など）の管理をオフロードすることもでき、アプリケーションの初期化によりこの作業から解放されて他の処理および／またはオペレーションを再開できるようになっている。並列処理を提供できるコンピュータにおいて、ハードウェア／ソフトウェア・インターフェース・システムは、同時に複数のプロセッサ上で実行するようにプログラムの分割も管理する。 Hardware / software interface systems have traditionally performed various services for applications. In a multi-tasking hardware / software interface system in which multiple programs can be executed simultaneously, the hardware / software interface system switches which application should be executed in which order and to another application. Decide how much time you want to give each application by. The hardware / software interface system also manages internal memory sharing among multiple applications and handles input / output to and from connected hardware devices such as hard disks, printers, and dial-up ports. . The hardware / software interface system also sends a message to each application (and in certain cases the end user) about the status of the operation and any errors that may have occurred. The hardware / software interface system can also offload the management of batch jobs (eg, printing) and can be freed from this work by application initialization to resume other processing and / or operations. It is like that. In computers that can provide parallel processing, the hardware / software interface system also manages the partitioning of programs to run on multiple processors simultaneously.
ハードウェア／ソフトウェア・インターフェース・システム・シェル（本明細書では単に「シェル」と呼ぶ）は、ハードウェア／ソフトウェア・インターフェース・システムへのインタラクティブ・エンド・ユーザ・インターフェースである。（シェルはまた、「コマンド・インタープリタ」と呼ばれ、またオペレーティング・システムでは「オペレーティング・システム・シェル」とも呼ばれることがある）。シェルは、アプリケーション・プログラムおよび／またはエンド・ユーザによって直接アクセス可能なハードウェア／ソフトウェア・インターフェース・システムの外側のレイヤである。シェルとは対照的に、カーネルは、ハードウェア・コンポーネントと直接対話するハードウェア／ソフトウェア・インターフェース・システムの最も内側のレイヤである。 A hardware / software interface system shell (referred to herein simply as “shell”) is an interactive end user interface to a hardware / software interface system. (The shell is also referred to as the “command interpreter” and may be referred to as the “operating system shell” in the operating system). The shell is the outer layer of a hardware / software interface system that is directly accessible by application programs and / or end users. In contrast to the shell, the kernel is the innermost layer of the hardware / software interface system that interacts directly with the hardware components.
本発明の多数の実施例がコンピュータ化されたシステムに特に適切であることが想定されるが、本明細書においては本発明をそのような実施例に限定する意図はない。これに対して、本明細書において使用されている「コンピュータ・システム」という用語は、こうした装置が、電子的、機械的、論理的、あるいは性質上において仮想的であるか否かにかかわらず、情報を格納および処理できるあらゆる装置および／または格納された情報を使用して装置自体の振る舞いまたは実行を制御できるあらゆる装置を包含することを意図している。 Although numerous embodiments of the present invention are envisioned to be particularly suitable for computerized systems, there is no intention herein to limit the invention to such embodiments. In contrast, the term “computer system” as used herein refers to whether such a device is electronic, mechanical, logical, or virtual in nature. It is intended to encompass any device that can store and process information and / or any device that can use the stored information to control the behavior or execution of the device itself.
Ｂ．従来型ファイル・ベースのストレージ
現在のほとんどのコンピュータにおいて、「ファイル」とは、アプリケーション・プログラム、データセットなどだけでなく、ハードウェア／ソフトウェア・インターフェース・システムを含むことのできる格納可能な情報の単位である。すべての現代のハードウェア／ソフトウェア・インターフェース・システム（Ｗｉｎｄｏｗｓ（登録商標）、Ｕｎｉｘ（登録商標）、Ｌｉｎｕｘ、Ｍａｃ ＯＳ、仮想マシン・システムなど）において、ファイルとは、ハードウェア／ソフトウェア・インターフェース・システムによって操作できる情報（たとえばデータ、プログラムなど）の個々の（格納可能および取り出し可能な）基本単位である。ファイルのグループは一般に、「フォルダ」に編成される。Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）、Ｍａｃｉｎｔｏｓｈ ＯＳ、および他のハードウェア／ソフトウェアシステムにおいて、フォルダとは、１つの情報の単位として取り出し、移動、その他操作を行うことができるファイルの集合である。これらのフォルダは、「ディレクトリ」（本明細書において以下でさらに詳細に説明する）と呼ばれるツリー・ベースの階層的配列に編成される。ＤＯＳ、ｚ／ＯＳ、およびほとんどのＵｎｉｘ（登録商標）ベースのオペレーティング・システムのような、他の特定のハードウェア／ソフトウェア・インターフェース・システムにおいて、「ディレクトリ」および／または「フォルダ」は相互に置き換え可能であり、初期のＡｐｐｌｅコンピュータ・システム（たとえばＡｐｐｌｅ ＩＩｅ）ではディレクトリの代わりに「カタログ」という用語を使用していた。ただし、本明細書で使用するように、これらの用語の全ては、同義語であり、相互置き換え可能であって、階層情報ストレージ構造とそのフォルダおよびファイル・コンポーネントに対する、他のすべての等価語および参照とをさらに含むことを意図している。
B. Traditional file-based storage In most modern computers, a “file” is a unit of storable information that can include not only application programs, data sets, but also hardware / software interface systems. It is. In all modern hardware / software interface systems (Windows®, Unix®, Linux, Mac OS, virtual machine systems, etc.), a file is a hardware / software interface system An individual (storable and retrievable) basic unit of information (eg, data, programs, etc.) that can be manipulated by. A group of files is generally organized into “folders”. In Microsoft Windows (registered trademark), Macintosh OS, and other hardware / software systems, a folder is a collection of files that can be taken out, moved, and otherwise operated as a unit of information. These folders are organized in a tree-based hierarchical arrangement called a “directory” (described in further detail herein below). In other specific hardware / software interface systems, such as DOS, z / OS, and most Unix-based operating systems, "directory" and / or "folder" are interchanged Yes, early Apple computer systems (eg, Apple IIe) used the term “catalog” instead of directory. However, as used herein, all of these terms are synonymous and interchangeable, and all other equivalent terms and terms for the hierarchical information storage structure and its folder and file components It is intended to further include references.
従来、ディレクトリ（フォルダのディレクトリとも呼ばれる）は、ファイルがフォルダにグループ化されるツリー・ベースの階層構造であり、そこにおいてフォルダは、ディレクトリ・ツリーを構成する相対的なノードの位置に従って編成される。たとえば、図２Ａに示すように、ＤＯＳベースのファイル・システムのベース・フォルダ（つまり「ルート・ディレクトリ」）２１２は、複数のフォルダ２１４を備え、各フォルダがさらに（その特定のフォルダの「サブ・フォルダ」として）追加フォルダ２１６を備え、その各々がさらに追加フォルダ２１８を備えるというように際限なく続く。これらのフォルダはそれぞれ、ハードウェア／ソフトウェア・インターフェース・システムのレベルで１つまたは複数のファイル２２０を持つことができるが、フォルダ内の個々のファイルはツリー階層におけるその位置以外は何も共通点がない。当然のことながら、ファイルをフォルダ階層に編成するこの方法は、これらのファイルを格納するために使用される通常の記憶媒体（たとえばハードディスク、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭなど）の物理的編成を間接的に反映している。
Traditionally, a directory (also called a directory of folders) is a tree-based hierarchical structure in which files are grouped into folders, where the folders are organized according to the relative node positions that make up the directory tree. . For example, as shown in FIG. 2A, a DOS-based file system base folder (ie, a “root directory”) 212 comprises a plurality of
前述のことに加えて、各フォルダは、そのサブ・フォルダおよびそのファイルのためのコンテナである。つまり、各フォルダはそのサブ・フォルダとファイルを所有している。たとえば、フォルダがハードウェア／ソフトウェア・インターフェース・システムによって削除された場合、そのフォルダのサブ・フォルダおよびファイルも削除される（各サブ・フォルダの場合は、さらにその所有するサブ・フォルダおよびファイルも循環的に含まれる）。同様に、各ファイルは、一般に１つのフォルダのみに所有されており、ファイルはコピーすることができ、そのコピーは異なるフォルダに配置される場合でも、ファイルのコピーは、それ自体が別個の独立した単位であり、オリジナルに直接のリレーションシップはない（たとえば、オリジナル・ファイルに加えられた変更は、ハードウェア／ソフトウェア・インターフェース・システム・レベルでコピー・ファイルに反映されない）。したがって、この点で、フォルダは物理コンテナのように扱われ、ファイルはこれらのコンテナ内部の別個の独立した物理要素として扱われるので、事実上、ファイルおよびフォルダは、「物理的」な特徴を有する。 In addition to the foregoing, each folder is a container for its sub-folders and its files. That is, each folder owns its subfolders and files. For example, if a folder is deleted by the hardware / software interface system, its subfolders and files are also deleted (for each subfolder, its own subfolders and files are also cycled). Included). Similarly, each file is generally owned by only one folder and the file can be copied, even if the copy is placed in a different folder, the copy of the file is itself a separate and independent Unit, there is no direct relationship to the original (for example, changes made to the original file are not reflected in the copy file at the hardware / software interface system level). Thus, in this regard, files and folders have “physical” characteristics, since folders are treated like physical containers and files are treated as separate and independent physical elements within these containers. .
ＩＩ．データの編成、検索、および共有のためのＷＩＮＦＳストレージ・プラットフォーム
本発明は、先に説明したように参照により本明細書に組み込まれる関連発明と共に、データを編成し、検索し、共有するためのストレージ・プラットフォームを目的としている。本発明のストレージ・プラットフォームは、データ・プラットフォームを、前述の既存ファイル・システムおよびデータベース・システムの種類を超えて拡張／拡大し、「アイテム」と呼ばれる新しいデータの形態（form of data）を含むあらゆるタイプのデータの記憶装置（store）となるように設計される。
II. WINFS Storage Platform for Organizing, Retrieving, and Sharing Data The present invention, together with related inventions incorporated herein by reference as described above, is a storage for organizing, retrieving, and sharing data・ It is aimed at platforms. The storage platform of the present invention extends / extends the data platform beyond the types of existing file systems and database systems described above and includes any new form of data called “items”. Designed to be a type of data store.
Ａ．用語解説
本明細書および特許請求の範囲において使用されている以下の用語は、以下のとおりの意味を表している。
・ 「アイテム」は、ハードウェア／ソフトウェア・インターフェース・システムに利用可能な、格納可能な情報の単位であり、単なるファイルとは異なり、プロパティの基本セットを備えるオブジェクトであり、プロパティの基本セットは、ハードウェア／ソフトウェア・インターフェース・システム・シェルによってエンド・ユーザに見えるすべてのオブジェクトにわたって共通にサポートされる。アイテムはさらに、プロパティおよびリレーションシップ（relationships）も備え、これらは、新しいプロパティとリレーションシップを導入できるようにする機能を含み、すべてのアイテム・タイプにわたって共通にサポートされる、ている（本明細書の後半で詳細に説明する）。
・ 「オペレーティング・システム」（ＯＳ）は、アプリケーション・プログラムとコンピュータ・ハードウェアの間の仲介としての役割を果たす特殊なプログラムである。オペレーティング・システムはほとんどの場合、シェルおよびカーネルを備えている。
・ 「ハードウェア／ソフトウェア・インターフェース・システム」は、ソフトウェア、またはハードウェアおよびソフトウェアの組み合わせであり、コンピュータ・システムの基礎を成すハードウェア・コンポーネントとコンピュータ・システム上で実行するアプリケーションとの間のインターフェースとしての役割を果たす。ハードウェア／ソフトウェア・インターフェース・システムは通常、オペレーティング・システムを備えている（一部の実施例においてはオペレーティング・システムのみで構成される）。ハードウェア／ソフトウェア・インターフェース・システムはさらに、仮想マシン・マネージャ（ＶＭＭ）、共通言語ランタイム（ＣＬＲ）またはその機能的な相当物、Ｊａｖａ（登録商標）仮想マシン（ＪＶＭ）またはその機能的な相当物、またはコンピュータ・システムのオペレーティング・システムに代わるかまたはこれに追加する他のそのようなソフトウェア・コンポーネントも備えている。ハードウェア／ソフトウェア・インターフェース・システムの目的は、ユーザがアプリケーション・プログラムを実行できる環境を提供することにある。ハードウェア／ソフトウェア・インターフェース・システムの目標は、コンピュータ・システムを使いやすくし、効率的よくコンピュータ・ハードウェアを利用することである。
A. Glossary The following terms used in the present specification and claims have the following meanings.
An “item” is a storable unit of information that can be used in a hardware / software interface system. Unlike a mere file, an “item” is an object that has a basic set of properties. Commonly supported across all objects visible to the end user by the hardware / software interface system shell. Items also include properties and relationships, which include the ability to introduce new properties and relationships, and are commonly supported across all item types (herein) Will be explained in detail later in this article)
An “operating system” (OS) is a special program that acts as an intermediary between application programs and computer hardware. Most operating systems have a shell and a kernel.
"Hardware / Software Interface System" is software, or a combination of hardware and software, an interface between the hardware components that form the basis of a computer system and the applications that run on the computer system As a role. A hardware / software interface system typically includes an operating system (in some embodiments, it consists only of an operating system). The hardware / software interface system further includes a virtual machine manager (VMM), a common language runtime (CLR) or functional equivalent thereof, a Java virtual machine (JVM) or functional equivalent thereof. Or other such software components that replace or add to the operating system of the computer system. The purpose of the hardware / software interface system is to provide an environment in which a user can execute application programs. The goal of the hardware / software interface system is to make the computer system easier to use and to efficiently use the computer hardware.
Ｂ．ストレージ・プラットフォームの概要
図３を参照すると、ストレージ・プラットフォーム３００は、データベース・エンジン３１４上に実装されたデータ・ストア３０２を備えている。１つの実施例において、データベース・エンジンは、オブジェクト・リレーションシップ拡張（object relational extensions）を備えるリレーショナル・データベース・エンジンを備えている。１つの実施例において、リレーショナル・データベース・エンジン３１４は、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒリレーショナル・データベース・エンジンを備えている。データ・ストア３０２は、データの編成、検索、共有、同期化、およびセキュリティをサポートするデータ・モデル３０４を実装する。データの特定のタイプについては、スキーマ３４０などのスキーマに記述される。ストレージ・プラットフォーム３００は、以下に詳細に説明するように、これらのスキーマを展開するため、およびこれらのスキーマを拡張するためのツール３４６を提供する。
B. Storage Platform Overview Referring to FIG. 3, the
データ・ストア３０２内に実装されている変更追跡メカニズム３０６は、データ・ストアへの変更を追跡する機能を提供する。データ・ストア３０２はさらに、セキュリティ機能３０８およびプロモーション／デモーション機能３１０も提供するが、これらについては以下で詳細に説明する。データ・ストア３０２はまた、アプリケーションプログラミングインターフェース３１２のセットを提供し、データ・ストア３０２の機能を、ストレージ・プラットフォームを利用する他のストレージプラットフォームコンポーネントおよびアプリケーション・プログラム（たとえば、アプリケーション・プログラム３５０ａ、３５０ｂ、および３５０ｃ）に公開する。本発明のストレージ・プラットフォームは、アプリケーション・プログラム・インターフェース（ＡＰＩ）３２２をさらに備え、これは、アプリケーション・プログラム３５０ａ、３５０ｂ、および３５０ｃなどのアプリケーション・プログラムがストレージ・プラットフォームの前述のすべての機能にアクセスできるようにし、スキーマに記述されているデータにアクセスできるようにする。ストレージ・プラットフォームＡＰＩ３２２は、ＯＬＥ ＤＢ ＡＰＩ３２４およびＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）Ｗｉｎ３２ ＡＰＩ ３２６など他のＡＰＩと組み合わせてアプリケーション・プログラムが使用することができる。
A change tracking mechanism 306 implemented within the
本発明のストレージ・プラットフォーム３００は、ユーザまたはシステム間のデータの共有を容易にする同期化サービス３３０を含む、さまざまなサービス３２８をアプリケーション・プログラムに提供することができる。たとえば、同期化サービス３３０により、データ・ストア３０２と同じフォーマットを持つ他のデータ・ストア３４０との相互運用性、および他のフォーマットを持つデータ・ストア３４２へのアクセスが可能になる。ストレージ・プラットフォーム３００はさらに、Ｗｉｎｄｏｗｓ（登録商標）ＮＴＦＳファイル・システム３１８など、既存のファイル・システムとのデータ・ストア３０２の相互運用を可能にするファイル・システム機能も提供する。少なくとも一部の実施例において、ストレージ・プラットフォーム３２０はさらに、データが他のシステムに基づいて作用することを可能にしし、他のシステムとの対話を可能にする追加の機能をアプリケーション・プログラムに提供することができる。これらの機能は、Ｉｎｆｏ Ａｇｅｎｔサービス３３４および通知サービス３３２などの追加サービス３２８の形態で、また他のユーティリティ３３６の形態で実施することができる。
The
少なくとも一部の実施例において、ストレージ・プラットフォームは、コンピュータ・システムのハードウェア／ソフトウェア・インターフェース・システムに組み入れられるか、またはその不可欠部分（integral part）を形成する。たとえば、制限なく、本発明のストレージ・プラットフォームは、オペレーティング・システム、仮想マシン・マネージャ（ＶＭＭ）、共通言語ランタイム（ＣＬＲ）またはその機能的な相当物、あるいはＪａｖａ（登録商標）仮想マシン（ＪＶＭ）またはまたはその機能的な相当物に、組み入れられるか、またはその不可欠部分を形成することができる。本発明のストレージ・プラットフォームは、その共通のストレージ基盤および体系化されたデータを通じて、消費者、知識労働者および企業に対するさらに効率的なアプリケーション開発を実現することができる。このストレージ・プラットフォームは、機能豊富で拡張可能なプログラミングの外見上の面を提供し、これはそのデータ・モデルに固有の機能を利用できるようにするだけではなく、既存のファイル・システムおよびデータベース・アクセス方法も取り入れている。 In at least some embodiments, the storage platform is incorporated into or forms an integral part of the hardware / software interface system of the computer system. For example, without limitation, the storage platform of the present invention can be an operating system, a virtual machine manager (VMM), a common language runtime (CLR) or functional equivalent thereof, or a Java virtual machine (JVM). Or may be incorporated into or form an integral part of its functional equivalent. The storage platform of the present invention can enable more efficient application development for consumers, knowledge workers and enterprises through its common storage infrastructure and organized data. This storage platform provides a feature-rich and extensible programming aspect that not only allows you to take advantage of the features specific to that data model, but also the existing file system and database It also incorporates access methods.
以下の説明、およびさまざまな図において、本発明のストレージ・プラットフォーム３００は、「ＷｉｎＦＳ」と呼ぶことができる。ただし、このストレージ・プラットフォームを参照するこの名称の使用は、もっぱら説明上の便宜のためであり、決して限定することを意図するものではない。
In the following description and in the various figures, the
Ｃ．データ・モデル
本発明のストレージ・プラットフォーム３００のデータ・ストア３０２は、ストア内に常駐するデータの編成（organization）、検索、共有、同期化、およびセキュリティをサポートするデータ・モデルを実装する。本発明のデータ・モデルにおいて、「アイテム」とはストレージ情報の基本単位である。データ・モデルは、以下でさらに詳細に説明するように、アイテムおよびアイテム拡張機能を宣言し、アイテム間のリレーションシップを確立し、アイテム・フォルダおよびカテゴリ内のアイテムを編成するためのメカニズムを提供する。
C. Data Model The
データ・モデルは、タイプおよびリレーションシップという２つの基本的メカニズム（primitive mechanisms）に依存している。タイプは、タイプのインスタンスの形式（form）を規定するフォーマットを提供する構造である。フォーマットは、プロパティの順序付きセットとして表される。プロパティは、所定のタイプの値または値のセットの名前である。たとえば、ＵＳＰｏｓｔａｌＡｄｄｒｅｓｓタイプは、ＳｔｒｅｅｔおよびＣｉｔｙがＳｔｒｉｎｇタイプで、ＺｉｐがＩｎｔ３２のタイプで、プロパティＳｔｒｅｅｔ、Ｃｉｔｙ、Ｚｉｐ、Ｓｔａｔｅを持つものとする。Ｓｔｒｅｅｔは、アドレスがＳｔｒｅｅｔプロパティの複数の値を持てるようにする多値（つまり値のセット）にすることができる。システムは、他のタイプの構造に使用できる特定の基本タイプを定義する。これらには、Ｓｔｒｉｎｇ、Ｂｉｎａｒｙ、Ｂｏｏｌｅａｎ、Ｉｎｔ１６、Ｉｎｔ３２、Ｉｎｔ６４、Ｓｉｎｇｌｅ、Ｄｏｕｂｌｅ、Ｂｙｔｅ、ＤａｔｅＴｉｍｅ、ＤｅｃｉｍａｌおよびＧＵＩＤが含まれる。あるタイプのプロパティは、任意の基本タイプまたは（以下に示す何らかの制約を伴う）任意の構造タイプを使用して定義することができる。たとえばＬｏｃａｔｉｏｎタイプは、Ａｄｄｒｅｓｓプロパティが前述のようにＵＳＰｏｓｔａｌＡｄｄｒｅｓｓのタイプであるＣｏｏｒｄｉｎａｔｅおよびＡｄｄｒｅｓｓを持つように定義することができる。プロパティは、必須またはオプションにすることもできる。 The data model relies on two primitive mechanisms: type and relationship. A type is a structure that provides a format that defines the form of an instance of the type. The format is represented as an ordered set of properties. A property is the name of a given type of value or set of values. For example, in the USPostAddress type, Street and City are String types, Zip is an Int32 type, and have properties Street, City, Zip, and State. A Street can be multi-valued (ie, a set of values) that allows an address to have multiple values of the Street property. The system defines certain basic types that can be used for other types of structures. These include String, Binary, Boolean, Int16, Int32, Int64, Single, Double, Byte, DateTime, Decimal, and GUID. A certain type of property can be defined using any basic type or any structural type (with some constraints shown below). For example, the Location type can be defined such that the Address property has Coordinate and Address, which are the types of USPostAddress as described above. Properties can be required or optional.
リレーションシップは、宣言することができ、２つのタイプのインスタンスのセットの間のマッピングを表す。たとえば、どの人々がどの場所に住むかを定義するＬｉｖｅｓＡｔと呼ばれる、ＰｅｒｓｏｎタイプおよびＬｏｃａｔｉｏｎタイプの間で宣言されるリレーションシップがある。このリレーションシップは、名前と、２つのエンドポイント、つまりソース・エンド・ポイントおよびターゲット・エンド・ポイントを持つ。リレーションシップは、プロパティの順序付きセットを持つこともできる。ソース・エンド・ポイントおよびターゲット・エンド・ポイントはいずれも、名前とタイプを持つ。たとえば、ＬｉｖｅｓＡｔのリレーションシップは、ＰｅｒｓｏｎのタイプのＯｃｃｕｐａｎｔという名前のソースと、ＬｏｃａｔｉｏｎのタイプのＤｗｅｌｌｉｎｇという名前のターゲットを持ち、さらにその居住者がその住居に住んでいた期間を示すプロパティＳｔａｒｔＤａｔｅおよびＥｎｄＤａｔｅを持つ。あるＰｅｒｓｏｎが、ある期間複数の住居に住む場合もあり、住居に複数の居住者がある場合もあるので、ＳｔａｒｔＤａｔｅおよびＥｎｄＤａｔｅ情報を置く場所としては、リレーションシップ自体の上が最も可能性が高い。 A relationship can be declared and represents a mapping between a set of two types of instances. For example, there is a relationship declared between a Person type and a Location type called LivesAt that defines which people live in which place. This relationship has a name and two endpoints: a source endpoint and a target endpoint. A relationship can also have an ordered set of properties. Both source and target end points have names and types. For example, a relationship of LivesAt has a property named StartDate and EndDate that has a source named Occupant of type Person and a target named Dwelling of type Location and also indicates how long the resident lived in the residence. Have. A person may live in a plurality of residences for a certain period of time, and there may be a plurality of residents in the residence. Therefore, the place where the StartDate and EndDate information is placed is most likely on the relationship itself.
リレーションシップは、エンドポイントのタイプとして与えられたタイプによって制約されるインスタンス間のマッピングを定義する。たとえば、ＬｉｖｅｓＡｔのリレーションシップは、ＡｕｔｏｍｏｂｉｌｅはＰｅｒｓｏｎではないので、ＡｕｔｏｍｏｂｉｌｅがＯｃｃｕｐａｎｔ（居住者）であるというリレーションシップはあり得ない。 A relationship defines a mapping between instances that is constrained by a given type of endpoint. For example, in the relationship of LivesAt, since Automobile is not Person, there can be no relationship that Automobile is an Occupant.
データ・モデルは、タイプの間のサブタイプ−スーパー・タイプというリレーションシップを定義できるようにする。ＢａｓｅＴｙｐｅリレーションシップとしても知られるサブタイプ−スーパー・タイプのリレーションシップは、タイプＡがタイプＢのＢａｓｅＴｙｐｅであればＢのすべてのインスタンスもＡのインスタンスでなければならい、というような方法で定義される。これを言い換えると、Ｂに適合するすべてのインスタンスはＡにも適合する必要があるということである。たとえば、ＡがタイプＳｔｒｉｎｇのプロパティＮａｍｅを持ち、ＢがタイプＩｎｔ１６のプロパティＡｇｅを持つ場合、Ｂの任意のインスタンスはＮａｍｅおよびＡｇｅの両方を持つことになる。このタイプの階層は、ルートにおいて単一のスーパー・タイプを持つツリーとして考えることができる。ルートからの分岐は第１レベルのサブタイプを提供し、このレベルにおける分岐は第２レベルのサブタイプを提供する、というように続き、サブタイプを持たない末端のリーフまで至る。このツリーは、均一の深さとなるように制約されていないが、循環（cycles）を含むことはできない。所定のタイプは、ゼロまたは多数のサブタイプおよびゼロまたは１つのスーパー・タイプを持つことができる。所定のインスタンスは、そのタイプのスーパー・タイプと併せてその１つのタイプに適合することができる。言い換えれば、ツリー内の任意のレベルの所定のインスタンスの場合、インスタンスはそのレベルの多くとも１つのサブタイプに適合することができる。そのタイプのインスタンスがそのタイプのサブタイプのインスタンスでもある必要がある場合に、このタイプは抽象であると言われる。 The data model allows defining subtype-supertype relationships between types. A subtype-supertype relationship, also known as a BaseType relationship, is defined in such a way that if a Type A is a TypeB BaseType, all instances of B must also be instances of A. . In other words, all instances that match B must also match A. For example, if A has a property Name of type String and B has a property Age of type Int16, then any instance of B will have both Name and Age. This type of hierarchy can be thought of as a tree with a single supertype at the root. A branch from the root provides a first level subtype, a branch at this level provides a second level subtype, and so on, up to the end leaf without the subtype. This tree is not constrained to be of uniform depth, but cannot contain cycles. A given type can have zero or multiple subtypes and zero or one supertype. A given instance can conform to that one type along with its super type. In other words, for a given instance at any level in the tree, the instance can fit at most one subtype of that level. This type is said to be abstract if an instance of that type needs to be an instance of a subtype of that type.
１．アイテム
アイテムは、格納可能な情報の単位であり、単純なファイルとは異なり、エンド・ユーザまたはアプリケーション・プログラムに公開されるすべてのオブジェクトにわたってストレージ・プラットフォームが共通にサポートするプロパティの基本セットを備えるオブジェクトである。アイテムはさらに、以下で説明するように、新しいプロパティとリレーションシップを導入できるようにする機能を含むすべてのアイテム・タイプにわたって共通にサポートされるプロパティおよびリレーションシップも備えている。
1. Item An item is a unit of information that can be stored and, unlike a simple file, an object that has a basic set of properties that the storage platform commonly supports across all objects exposed to end users or application programs. It is. Items also have properties and relationships that are commonly supported across all item types, including the ability to introduce new properties and relationships, as described below.
アイテムは、コピー、削除、移動、開く、印刷、バックアップ、復元、複製など共通の操作のためのオブジェクトである。アイテムは、格納したり取り出したりすることのできる単位であり、ストレージ・プラットフォームによって操作されるあらゆる形式の格納可能な情報は、アイテム、アイテムのプロパティ、またはアイテム間のリレーションシップとして存在する。それぞれについては、本明細書において以下で詳細に説明する。 Items are objects for common operations such as copy, delete, move, open, print, backup, restore, and duplicate. An item is a unit that can be stored and retrieved, and any form of storable information manipulated by the storage platform exists as an item, an item property, or a relationship between items. Each is described in detail herein below.
アイテムは、連絡先、人々、サービス、場所、（あらゆる種類の）ドキュメントなどのように、現実世界の容易に理解できるデータの単位を表すよう意図されている。図５Ａは、アイテムの構造を示すブロック図である。アイテムの非修飾名（unqualified name）は、「Ｌｏｃａｔｉｏｎ」である。アイテムの修飾名（qualified name）は「Ｃｏｒｅ．Ｌｏｃａｔｉｏｎ」であり、これはこのアイテムの構造がコア・スキーマ内で特定のタイプのアイテムとして定義されることを示している。（コア・スキーマについては、本明細書の後半でさらに詳細に説明する。）
場所（location）のアイテムは、ＥＡｄｄｒｅｓｓｅｓ、ＭｅｔｒｏｐｏｌｉｔａｎＲｅｇｉｏｎ、Ｎｅｉｇｈｂｏｒｈｏｏｄ、およびＰｏｓｔａｌＡｄｄｒｅｓｓｅｓを含む複数のプロパティを備えている。各々のプロパティの特有のタイプは、プロパティ名のすぐ後に示されており、コロン（「：」）によってプロパティ名と区切られている。タイプ名の右側には、そのプロパティ・タイプに許可されている値の数が角括弧に囲まれて示されている。ここで、コロン（「：」）の右側のアスタリスク（「＊」）は不特定および／または無制限の数（「多数」）を示している。コロンの右側の「１」は、多くとも１つの値があることを示している。コロンの左側のゼロ（「０」）は、プロパティがオプションである（値が全くない場合もある）ことを示している。コロンの左側の「１」は、少なくとも１つの値（プロパティは必須）がなければならないことを示している。Ｎｅｉｇｈｂｏｒｈｏｏｄ およびＭｅｔｒｏｐｏｌｉｔａｎＲｅｇｉｏｎはいずれも、定義済みのデータ・タイプまたは「単純タイプ（simple type）」である（本明細書において大文字なしで示される）タイプ「ｎｖａｒｃｈａｒ」である。ただし、ＥＡｄｄｒｅｓｓおよびＰｏｓｔａｌＡｄｄｒｅｓｓは、それぞれタイプＥＡｄｄｒｅｓｓおよびＰｏｓｔａｌＡｄｄｒｅｓｓの事前定義済みのタイプまたは「複合タイプ（complex types）」（本明細書において大文字を使用して示される）のプロパティである。複合タイプは、１つまたは複数の単純データ・タイプおよび／または他の複合タイプから派生するタイプである。アイテムのプロパティの複合タイプは、その複合タイプの詳細が直属のアイテムにネストされてそのプロパティを定義するので、「ネストされた要素」（以下、ネスト化要素と記す）を構成し、これらの複合タイプに関連する情報はこれらのプロパティを持つアイテムで（本明細書の後半で説明するように、アイテムの境界内で）保持される。これらのタイプ定義の概念は周知のものであり、当業者には容易に理解されよう。
An item is intended to represent an easily understandable unit of data in the real world, such as contacts, people, services, places, documents (of any kind). FIG. 5A is a block diagram illustrating the structure of an item. The unqualified name of the item is “Location”. The qualified name of the item is “Core.Location”, which indicates that the structure of this item is defined as a specific type of item in the core schema. (The core schema is described in more detail later in this document.)
The location item has multiple properties including EAddresses, MetropolitanRegion, Neighborhood, and PostalAddresses. The specific type of each property is shown immediately after the property name and is separated from the property name by a colon (":"). To the right of the type name, the number of values allowed for that property type is shown in square brackets. Here, an asterisk (“*”) on the right side of the colon (“:”) indicates an unspecified and / or unlimited number (“many”). A “1” to the right of the colon indicates that there is at most one value. A zero ("0") to the left of the colon indicates that the property is optional (it may have no value at all). A “1” to the left of the colon indicates that there must be at least one value (property required). Both Neighborhood and MetropolitanRegion are defined data types or “simple types” of type “nvarchar” (shown here without capital letters). However, EAddress and PostAddress are properties of predefined types or “complex types” (shown using capital letters herein) of type EAddress and PostAddress, respectively. A complex type is a type that is derived from one or more simple data types and / or other complex types. The complex type of an item's property constitutes a “nested element” (hereinafter referred to as a nested element) because the complex type details are nested in the immediate item to define the property. Information related to the type is maintained in items with these properties (within the boundaries of the item, as described later in this document). These type definition concepts are well known and will be readily understood by those skilled in the art.
図５Ｂは、複合プロパティ・タイプＰｏｓｔａｌＡｄｄｒｅｓｓおよびＥＡｄｄｒｅｓｓを示すブロック図である。ＰｏｓｔａｌＡｄｄｒｅｓｓプロパティ・タイプは、プロパティ・タイプＰｏｓｔａｌＡｄｄｒｅｓｓのアイテムが、ゼロまたは１つのＣｉｔｙ値、ゼロまたは１つのＣｏｕｎｔｒｙＣｏｄｅ値、ゼロまたは１つのＭａｉｌＳｔｏｐ値、および任意の数の（ゼロから多数）のＰｏｓｔａｌＡｄｄｒｅｓｓＴｙｐｅなど（以下同様）を持つことを期待できるように定義する。このようにして、アイテム内の特定のプロパティのデータの形状が定義される。ＥＡｄｄｒｅｓｓプロパティ・タイプは、示されているように同様に定義される。本明細書においてオプションとしてこの応用例を使用したが、Ｌｏｃａｔｉｏｎアイテムの複合タイプを表すもう１つの方法は、そこに一覧されている各複合タイプの個々のプロパティでアイテムを描くことである。図５Ｃは、複合タイプがさらに説明されるＬｏｃａｔｉｏｎアイテムを示すブロック図である。ただし、図５ＣにおけるＬｏｃａｔｉｏｎアイテムのこの代替表現は、図５Ａに示されている全く同じアイテムを表すものである。本発明のストレージ・プラットフォームは、サブタイプ定義も可能にし、それにより、１つのプロパティ・タイプがもう１つのプロパティのサブタイプ（１つのプロパティ・タイプがもう一方の親プロパティ・タイプのプロパティを継承する）となることが可能になる。 FIG. 5B is a block diagram illustrating the composite property types PostAddress and EAddress. The PostAddress property type is an item of property type PostAddress, where zero or one City value, zero or one CountryCode value, zero or one MailStop value, and any number (zero to many) of PostalAddressType, etc. The same). In this way, the data shape of a specific property within the item is defined. The EAddress property type is defined similarly as shown. Although this application was used as an option here, another way to represent the complex type of a Location item is to draw an item with the individual properties of each complex type listed therein. FIG. 5C is a block diagram illustrating a Location item where the composite type is further described. However, this alternative representation of the Location item in FIG. 5C represents the exact same item shown in FIG. 5A. The storage platform of the present invention also allows subtype definitions, whereby one property type inherits the properties of another property (one property type inherits the properties of the other parent property type) ) Becomes possible.
プロパティおよびそのプロパティ・タイプとは類似しているが異なっているため、アイテムは、本質的に、サブタイプ定義の対象にもなりうる各自のアイテム・タイプを表している。言い換えれば、本発明のいくつかの実施例におけるストレージ・プラットフォームにより、アイテムは別のアイテムのサブタイプになることができる（１つのアイテムがもう一方の親アイテムのプロパティを継承する）。さらに、本発明のさまざまな実施例について、すべてのアイテムは、基本スキーマ内に見い出される最初の基本アイテム・タイプである「Ｉｔｅｍ」アイテム・タイプのサブタイプであるが、これはのつながりである。（基本スキーマについては、本明細書の後半でさらに詳細に説明する。）図６Ａは、基本スキーマ内に見い出されたＩｔｅｍアイテム・タイプのサブタイプとして、このインスタンスのアイテム、Ｌｏｃａｔｉｏｎアイテムを示している。この図において、矢印は、Ｌｏｃａｔｉｏｎアイテムが（他のすべてのアイテムと同様に）Ｉｔｅｍアイテム・タイプのサブタイプであることを示している。Ｉｔｅｍアイテム・タイプは、すべての他のアイテムがそこから派生する基本のアイテムとして、ＩｔｅｍＩｄなどのいくつかの重要なプロパティおよびさまざまなタイム・スタンプを持ち、これによりオペレーティング・システム内のすべてのアイテムの標準プロパティを定義する。この図において、Ｉｔｅｍアイテム・タイプのプロパティはロケーションが継承され、これにより、ロケーションのプロパティとなる。 Ｉｔｅｍアイテム・タイプから継承されたＬｏｃａｔｉｏｎアイテムのプロパティを表すもう１つの方法は、そこに一覧されている親アイテムからの各プロパティ・タイプの個々のプロパティでロケーションを描くことである。図６Ｂは、継承されたタイプが、その直接のプロパティに加えて、記述されるＬｏｃａｔｉｏｎアイテムを示すブロック図である。このアイテムは図５Ａに示されているアイテムと同じものであるが、現在の図においてＬｏｃａｔｉｏｎは、直接（この図および図５Ａに示されている）および継承（この図には示されるが図５Ａには示されていない）の両方のすべてのプロパティで示されている（しかし、図５Ａでは、これらのプロパティはＬｏｃａｔｉｏｎアイテムがＩｔｅｍアイテム・タイプのサブタイプであることを示す矢印で示すことにより参照される）ことに留意され、理解されたい。 Because they are similar but different from properties and their property types, items essentially represent their own item types that can also be subject to subtype definitions. In other words, the storage platform in some embodiments of the present invention allows an item to be a subtype of another item (one item inherits the properties of the other parent item). Further, for the various embodiments of the present invention, all items are subtypes of the “Item” item type, which is the first basic item type found in the base schema, but this is a link. (The basic schema will be described in more detail later in this specification.) FIG. 6A shows the item of this instance, the Location item, as a subtype of the Item item type found in the basic schema. . In this figure, the arrow indicates that the Location item is a subtype of the Item item type (as with all other items). The Item item type has some important properties such as ItemId and various time stamps as the base item from which all other items are derived, so that all items in the operating system Define standard properties. In this figure, the Item item type property inherits the location, thereby becoming the location property. Another way to represent Location item properties inherited from an Item item type is to draw a location with the individual properties of each property type from the parent item listed there. FIG. 6B is a block diagram showing the Location item in which the inherited type is described in addition to its immediate properties. This item is the same as the item shown in FIG. 5A, but in the current diagram, Location is direct (shown in this figure and FIG. 5A) and inheritance (shown in this figure but shown in FIG. 5A). (But not shown in Figure 5A) these properties are referenced by an arrow indicating that the Location item is a subtype of the Item item type. It should be noted and understood.
アイテムは、スタンド・アローンのオブジェクトである。従って、アイテムを削除した場合、アイテムの直接および継承された全てのプロパティも削除される。同様に、アイテムを取り出す場合、取り出されるものはアイテムとその直接および継承されたプロパティすべてである（その複合プロパティ・タイプに関連する情報を含む）。本発明の特定の実施例では、特定のアイテムを取り出すときにプロパティのサブセットを要求できるようにすることができる。ただし、そのような多くの実施例のデフォルトは、取り出される際のその直接および継承されたプロパティのすべてをアイテムに提供することである。さらに、アイテムのプロパティは、そのアイテムのタイプの既存のプロパティに新しいプロパティを追加することによって拡張することもできる。これらの「拡張」は、その後アイテムの真正のプロパティとなり、そのアイテム・タイプのサブタイプは自動的に拡張プロパティを含むことができる。 Items are stand-alone objects. Thus, when an item is deleted, all of the item's direct and inherited properties are also deleted. Similarly, when retrieving an item, what is retrieved is the item and all of its direct and inherited properties (including information related to its complex property type). Certain embodiments of the present invention may allow a subset of properties to be requested when retrieving a particular item. However, the default for many such embodiments is to provide an item with all of its direct and inherited properties when retrieved. In addition, an item's properties can be extended by adding new properties to the existing properties of the item type. These “extensions” then become authentic properties of the item, and subtypes of that item type can automatically include extended properties.
アイテムの「境界」は、（複合プロパティ・タイプ、拡張などを含む）そのプロパティによって表される。アイテムの境界はさらに、コピー、削除、移動、作成など、アイテムに対して実行される操作の制限も表す。たとえば、本発明のいくつかの実施例において、アイテムがコピーされるとき、そのアイテムの境界内にあるすべてのものもコピーされる。各アイテムに対して、境界は次のものを含む。
・ アイテムのアイテム・タイプ、および、アイテムが（すべてのアイテムが基本スキーマの単一のアイテムおよびアイテム・タイプから派生している、本発明のいくつかの実施例の場合のように）別のアイテムのサブタイプである場合、該当するサブタイプ情報（つまり、親アイテム・タイプに関連する情報）。コピーされる元のアイテムが別のアイテムのサブタイプである場合、コピーもその同じアイテムのサブタイプになる。
・ アイテムの複合タイプ・プロパティおよび拡張（ある場合）。元のアイテムが複合タイプのプロパティ（ネイティブまたは拡張）を持つ場合、コピーも同じ複合タイプを持つことができる。
・ 「Oownership relationships（所有権関係）」上のアイテムのレコード、つまり他のどのアイテム（「ターゲット・アイテム」）が現在のアイテムによって所有されるか（「Owning Item（所有アイテム）」）を一覧するアイテムの所有リスト。これは、以下でさらに詳細に説明するアイテム・フォルダについて、およびすべてのアイテムが少なくとも１つのアイテム・フォルダに属す必要があるという以下に述べられた規則、に特に関連する。さらに、組み込まれたアイテム（以下でさらに詳細に説明する）については、組み込まれたアイテムは、コピー、削除などの操作のために組み込まれているアイテムの一部と見なされている。
An item's “boundary” is represented by its properties (including complex property types, extensions, etc.). Item boundaries also represent restrictions on operations performed on items, such as copying, deleting, moving, and creating. For example, in some embodiments of the invention, when an item is copied, everything that is within the boundaries of the item is also copied. For each item, the boundary includes:
The item type of the item and the item is another item (as in some embodiments of the invention where all items are derived from a single item and item type in the base schema) If it is a subtype, the appropriate subtype information (that is, information related to the parent item type). If the original item being copied is a subtype of another item, the copy is also a subtype of that same item.
• Item complex type properties and extensions (if any). If the original item has complex type properties (native or extended), the copy can also have the same complex type.
• List records of items on “Oownership relationships”, ie what other items (“target items”) are owned by the current item (“Owning Item”) Item ownership list. This is particularly relevant to the item folder described in more detail below and to the rules described below that all items must belong to at least one item folder. Further, for embedded items (described in more detail below), the embedded items are considered part of the items that are included for operations such as copying, deleting, and the like.
２．アイテムの識別
アイテムはグローバルアイテム・スペース内でＩｔｅｍＩＤにより一意に識別される。Ｂａｓｅ．Ｉｔｅｍタイプは、アイテムのＩＤを格納するタイプＧＵＩＤのフィールドＩｔｅｍＩＤを定義する。アイテムは、データ・ストア３０２に厳密に１つのＩＤを持つ必要がある。
2. Item Identification Items are uniquely identified in the global item space by ItemID. Base. The Item type defines a field ItemID of a type GUID that stores an item ID. An item needs to have exactly one ID in the
アイテム参照は、アイテムの場所を見つけて識別するための情報を含むデータ構造である。データ・モデルにおいて、抽象タイプは、すべてのアイテム参照タイプが派生するＩｔｅｍＲｅｆｅｒｅｎｃｅという名前で定義される。ＩｔｅｍＲｅｆｅｒｅｎｃｅタイプは、Ｒｅｓｏｌｖｅという名前の仮想メソッドを定義する。Ｒｅｓｏｌｖｅメソッドは、ＩｔｅｍＲｅｆｅｒｅｎｃｅを解決してアイテムを返す。このメソッドは、ＩｔｅｍＲｅｆｅｒｅｎｃｅの具象サブタイプによってオーバーライドされるが、これは参照を与えられたアイテムを取り出す関数を実装する。Ｒｅｓｏｌｖｅメソッドは、ストレージ・プラットフォームＡＰＩ３２２の一部として呼び出される。 Item references are data structures that contain information for locating and identifying item locations. In the data model, an abstract type is defined by the name ItemReference from which all item reference types are derived. The ItemReference type defines a virtual method named Resolve. The Resolve method resolves the ItemReference and returns the item. This method is overridden by a concrete subtype of ItemReference, which implements a function that retrieves the item given the reference. The Resolve method is invoked as part of the storage platform API 322.
ＩｔｅｍＩＤＲｅｆｅｒｅｎｃｅは、ＩｔｅｍＲｅｆｅｒｅｎｃｅのサブタイプである。これは、ロケータおよびＩｔｅｍＩＤフィールドを定義する。Ｌｏｃａｔｏｒフィールドは、アイテム・ドメインに名前をつける（つまり識別する）。これは、アイテム・ドメインへのロケータの値を解決できるロケータ・レゾリューション・メソッドによって処理される。ＩｔｅｍＩＤフィールドはＩｔｅｍＩＤのタイプである。 ItemIDReference is a subtype of ItemReference. This defines the locator and ItemID fields. The Locator field names (ie identifies) the item domain. This is handled by a locator resolution method that can resolve the value of the locator to the item domain. The ItemID field is the type of ItemID.
ＩｔｅｍＰａｔｈＲｅｆｅｒｅｎｃｅは、ロケータおよびＰａｔｈフィールドを定義するＩｔｅｍＲｅｆｅｒｅｎｃｅの特殊化である。Ｌｏｃａｔｏｒフィールドは、アイテム・ドメインを識別する。これは、アイテム・ドメインへのロケータの値を解決できるロケータ・レゾリューション・メソッドによって処理される。Ｐａｔｈフィールドは、ロケータによって提供されたアイテム・ドメインにルートを置くストレージ・プラットフォームのネーム・スペースに（相対）パスを含んでいる。 ItemPathReference is a specialization of ItemReference that defines locators and Path fields. The Locator field identifies the item domain. This is handled by a locator resolution method that can resolve the value of the locator to the item domain. The Path field contains a (relative) path to the storage platform name space rooted in the item domain provided by the locator.
このタイプの参照は、セットオペレーションには使用することができない。参照は一般にパス解決プロセスを通じて解決される必要がある。ストレージ・プラットフォームＡＰＩ３２２は、この機能を提供する。 This type of reference cannot be used for set operations. References generally need to be resolved through a path resolution process. The storage platform API 322 provides this functionality.
前述の参照の形式は、図１１に示す参照タイプ階層を通じて表される。これらのタイプから継承される追加の参照タイプは、スキーマにおいて定義することができる。これらは、ターゲット・フィールドのタイプとしてリレーションシップの宣言に使用することができる。 The aforementioned reference format is represented through the reference type hierarchy shown in FIG. Additional reference types inherited from these types can be defined in the schema. These can be used to declare relationships as the type of the target field.
３．アイテム・フォルダおよびカテゴリ
以下でさらに詳細に説明するように、アイテムのグループは、（フィールド・フォルダと混同しないように）アイテム・フォルダと呼ばれる特殊なアイテムに編成することができる。しかし、ほとんどのファイル・システムの場合と異なり、アイテムは複数のアイテム・フォルダに属すことができ、この結果、アイテムが１つのアイテム・フォルダでアクセスされて修正されるとき、この修正済みアイテムは別のアイテム・フォルダから直接アクセスすることができるようになっている。本質的には、アイテムへのアクセスがさまざまなアイテム・フォルダから行われても、実際にアクセスされているのはまったく同一のアイテムなのである。しかし、アイテム・フォルダは必ずしもそのメンバ・アイテムのすべてを所有する必要はないか、または、他のフォルダと連動して単にアイテムを共同所有することができ、これによりアイテム・フォルダの削除が必ずしもアイテムを削除したことにはならない。それにもかかわらず、本発明のいくつかの実施例においては、特定のアイテムのたった１つのアイテム・フォルダが削除された場合に、一部の実施例ではアイテムが自動的に削除されるか、あるいは代替実施例においてはアイテムが自動的にデフォルトのアイテム・フォルダ（たとえば、「ゴミ箱」アイテム・フォルダは概念的には、さまざまなファイルおよびフォルダ・ベースのシステムで使用される類似した名前の付いたフォルダと似ている）のメンバになるように、アイテムは少なくとも１つのアイテム・フォルダに属す必要がある。
3. Item Folders and Categories As described in more detail below, groups of items can be organized into special items called item folders (not to be confused with field folders). However, unlike most file systems, an item can belong to multiple item folders, so that when an item is accessed and modified in one item folder, Can be accessed directly from the item folder. In essence, even if an item is accessed from various item folders, it is the exact same item that is actually being accessed. However, an item folder does not necessarily have to own all of its member items, or can simply co-own an item in conjunction with other folders, so that deleting an item folder does not necessarily Is not deleted. Nevertheless, in some embodiments of the present invention, if only one item folder for a particular item is deleted, in some embodiments the item is automatically deleted, or In an alternative embodiment, the item automatically defaults to the item folder (eg, the “Trash” item folder is conceptually a similarly named folder used in various file and folder based systems. The item must belong to at least one item folder.
以下でさらに詳細に説明するように、アイテムは、（ａ）アイテム・タイプ（複数もあり）、（ｂ）特定の直接または継承されたプロパティ（複数もあり）、または（ｃ）アイテム・プロパティに対応する特定の値（複数もあり）などの、共通の記述された特性に基づくカテゴリに属すこともできる。たとえば、個人連絡先情報の特定のプロパティを含むアイテムは、自動的に連絡先カテゴリに帰属し、連絡先情報プロパティを持つ任意のアイテムは同様にこのカテゴリに自動的に帰属するようになる。同様に、「Ｎｅｗ Ｙｏｒｋ Ｃｉｔｙ」の値を持つ場所プロパティを持つ任意のアイテムは、ＮｅｗＹｏｒｋＣｉｔｙカテゴリに自動的に帰属する。 As described in more detail below, items can be (a) item type (s), (b) specific direct or inherited property (s), or (c) item properties. It can also belong to a category based on common described characteristics, such as the corresponding specific value (s). For example, an item that includes a specific property of personal contact information automatically belongs to the contact category, and any item that has a contact information property will automatically belong to this category as well. Similarly, any item with a location property having a value of “New York City” automatically belongs to the New York City category.
アイテム・フォルダは、相互に関連しない（つまり共通の記述された特性を持たない）アイテムを含むことができるが、カテゴリ内の各アイテムはそのカテゴリに記述されている共通のタイプ、プロパティ、または値（「共通性」）を持ち、この共通性がカテゴリ内の他のアイテム間およびアイテムとのそのリレーションシップの基盤を形成しているという点で、カテゴリはアイテム・フォルダとは概念的に異なっている。さらに、特定のフォルダ内のアイテムのメンバーシップがそのアイテムの特定の局面に基づくことを義務付けられてはいないのに対して、特定の実施例ではカテゴリに明確に関連する共通性を持つすべてのアイテムは、ハードウェア／ソフトウェア・インターフェース・システムレベルにおいて自動的にカテゴリのメンバとなることができる。概念的に、カテゴリは、（データベースのコンテクストの場合のように）メンバーシップが特定のクエリの結果に基づく仮想アイテム・フォルダとして見なすこともでき、（カテゴリの共通性によって定義されている）このクエリの条件を満たすアイテムはカテゴリのメンバーシップを含むことになる。 An item folder can contain items that are not related to each other (that is, do not have common described characteristics), but each item in a category has a common type, property, or value described in that category ("Commonality"), and a category is conceptually different from an item folder in that this commonality forms the basis for that relationship between and with other items in the category. Yes. In addition, all items with commonality that are clearly related to a category in a specific embodiment, whereas membership of an item in a particular folder is not required to be based on a particular aspect of that item Can automatically become members of a category at the hardware / software interface system level. Conceptually, a category can also be viewed as a virtual item folder whose membership is based on the results of a particular query (as in the case of a database context), and this query (defined by the commonality of categories) Items that satisfy the condition will include category membership.
図４は、アイテム、アイテム・フォルダ、およびカテゴリの間の構造的リレーションシップを示す図である。複数のアイテム４０２、４０４、４０６、４０８、４１０、４１２、４１４、４１６、４１８、および４２０は、さまざまなアイテム・フォルダ４２２、４２４、４２６、４２８、および４３０のメンバである。一部のアイテムは、たとえばアイテム４０２がアイテム・フォルダ４２２および４２４に属す、というように複数のアイテム・フォルダに属することもできる。一部のアイテム、たとえば４０２、４０４、４０６、４０８、４１０、および４１２は複数のカテゴリ４３２、４３４、および４３６のメンバでもあるが、他のアイテム、たとえばアイテム４１４、４１６、４１８、および４２０はどのカテゴリにも属さない（ただしこれは、任意のプロパティの所有が自動的にカテゴリ内のメンバーシップを含意する特定の実施例においては、そうである見込みはなく、そのような実施例においていずれのカテゴリのメンバとならないためには、アイテムは完全に特徴のないものになる必要がある）。フォルダの階層的構造とは対照的に、カテゴリおよびアイテム・フォルダはいずれも、図のように有方グラフ（directed graphs）とさらによく似た構造を備えている。いずれにせよ、アイテム、アイテム・フォルダ、およびカテゴリは（たとえアイテム・タイプは異なっていても）すべてアイテムである。
FIG. 4 illustrates a structural relationship between items, item folders, and categories. The plurality of
ファイル、フォルダ、およびディレクトリとは対照的に、本発明のアイテム、アイテム・フォルダ、およびカテゴリは、アイテムが、物理コンテナの概念的な等化物を有さないので、本質的に特質上「物理的」ではなく、そのためアイテムは複数のそのような場所に存在できる。複数のアイテム・フォルダの場所に存在し、複数のカテゴリ（複数）に編成されるアイテム対する能力によって、ハードウェア／ソフトウェア・インターフェース・レベルにおいて、当技術分野で現在利用可能なレベルを上回る、強化され、豊富にされた高いデータ操作およびストレージ構造の可能性（capabilities）がもたらされる。 In contrast to files, folders, and directories, the items, item folders, and categories of the present invention are inherently “physical” because the items do not have a conceptual equivalent of a physical container. Rather, so an item can exist in multiple such locations. Enhanced at the hardware / software interface level, beyond what is currently available in the art, with the ability for items that reside in multiple item folder locations and organized into multiple categories. , Resulting in rich data manipulation and storage structure capabilities.
４．スキーマ
ａ）基本スキーマ
アイテムの作成および使用に普遍的な基盤を提供するため、本発明のストレージ・プラットフォームのさまざまな実施例は、アイテムおよびプロパティを作成して編成するための概念上のフレームワークを確立する基本スキーマを備えている。基本スキーマはアイテムおよびプロパティのある種の特定のタイプと、サブタイプがさらに派生できるこれらの特定の、基礎的タイプの特徴を定義する。この基本スキーマの使用により、プログラマは、アイテム（およびそれぞれのタイプ）をプロパティ（およびそれぞれのタイプ）と概念的に区別することができる。さらに、基本スキーマは、すべてのアイテム（およびその対応するアイテムタイプ）が基本スキーマのこの基礎的アイテム（およびその対応するアイテム・タイプ）から派生するので、すべてのアイテムが所有できるプロパティの基礎的セットを示している。
4). Schema a) Basic Schema In order to provide a universal basis for the creation and use of items, the various embodiments of the storage platform of the present invention provide a conceptual framework for creating and organizing items and properties. Has a basic schema to establish. The base schema defines certain specific types of items and properties, and the characteristics of these specific, basic types from which subtypes can be further derived. The use of this basic schema allows programmers to conceptually distinguish items (and their respective types) from properties (and their respective types). In addition, the base schema is a basic set of properties that all items can own because every item (and its corresponding item type) is derived from this base item (and its corresponding item type) in the base schema. Is shown.
図７に示すように、本発明のいくつかの実施例に関して、基本スキーマは、Ｉｔｅｍ、Ｅｘｔｅｎｓｉｏｎ、およびＰｒｏｐｅｒｔｙＢａｓｅという３つの最上位のタイプを定義する。図のように、アイテム・タイプは、この基礎的「Ｉｔｅｍ」アイテム・タイプのプロパティによって定義される。一方、最上位プロパティ・タイプ「ＰｒｏｐｅｒｔｙＢａｓｅ」は、事前定義済みのプロパティを持たず、単にアンカーに過ぎず、そこから他のすべてのプロパティ・タイプが派生し、およびそこを通してすべての派生したプロパティ・タイプが（単一のプロパティ・タイプから共通に派生して）相互に関連付けられる。Ｅｘｔｅｎｔｉｏｎタイプ・プロパティは、その拡張（extention）が拡張するアイテムを定義し、またアイテムが複数の拡張を持つことができるので拡張をそれぞれ区別するためのＩＤを定義する。 As shown in FIG. 7, for some embodiments of the present invention, the basic schema defines three top-level types: Item, Extension, and PropertyBase. As shown, the item type is defined by the properties of this basic “Item” item type. On the other hand, the top-level property type “PropertyBase” does not have a predefined property, it is just an anchor, from which all other property types are derived, and through which all derived property types are derived. Are related to each other (commonly derived from a single property type). The Extension type property defines an item whose extension is extended, and also defines an ID for distinguishing each extension since an item can have a plurality of extensions.
ＩｔｅｍＦｏｌｄｅｒは、Ｉｔｅｍアイテム・タイプのサブタイプであり、アイテムから継承されたプロパティに加えて、そのメンバ（ある場合）へのリンクを確立するためのリレーションシップを特徴づけ、一方、ＩｄｅｎｔｉｔｙＫｅｙおよびＰｒｏｐｅｒｔｙは共にＰｒｏｐｅｒｔｙＢａｓｅのサブタイプである。ＣａｔｅｇｏｒｙＲｅｆは、ＩｄｅｎｔｉｔｙＫｅｙのサブタイプである。 ItemFolder is a subtype of Item item type, and in addition to the properties inherited from the item, it characterizes the relationship to establish a link to its member (if any), while IdentityKey and Property are both It is a subtype of PropertyBase. CategoryRef is a subtype of IdentityKey.
ｂ）コア・スキーマ
本発明のストレージ・プラットフォームのさまざまな実施例はさらに、最上位のＩｔｅｍタイプ構造のための概念上のフレームワークを提供するコア・スキーマを備えている。図８Ａは、コア・スキーマ内のアイテムを示すブロック図であり、図８Ｂはコア・スキーマ内のプロパティ・タイプを示すブロック図である。異なる拡張子（＊．ｃｏｍ、＊．ｅｘｅ、＊．ｂａｔ、＊．ｓｙｓ）を持つファイル間で行われる区別、ファイルおよびフォルダ・ベースのシステムにおける他のそのような基準は、コア・スキーマの機能と類似している。アイテム・ベースのハードウェア／ソフトウェア・インターフェース・システムにおいて、コア・スキーマは、アイテム・ベースのハードウェア／ソフトウェア・インターフェース・システムが理解して、あらかじめ定義された予測可能な方法で直接処理することができる１つまたは複数のコア・スキーマアイテム・タイプにすべてのアイテムを、直接に（アイテム・タイプにより）または間接（アイテム・サブタイプにより）に、特徴付けるコア・アイテム・タイプのセットを定義する。事前定義済みアイテム・タイプは、アイテム・ベースのハードウェア／ソフトウェア・インターフェース・システムにおいて最も一般的なアイテムを反映し、この結果で、効率性のあるレベルが、コア・スキーマを構成するこれらの事前定義済みアイテム・タイプを理解するアイテム・ベースのハードウェア／ソフトウェア・インターフェース・システムによって得られる。
b) Core Schema Various embodiments of the storage platform of the present invention further comprise a core schema that provides a conceptual framework for the top-level Item type structure. FIG. 8A is a block diagram showing items in the core schema, and FIG. 8B is a block diagram showing property types in the core schema. The distinction made between files with different extensions (* .com, * .exe, * .bat, * .sys), other such criteria in file and folder based systems are the functions of the core schema Is similar. In an item-based hardware / software interface system, the core schema can be understood and processed directly by the item-based hardware / software interface system in a predefined and predictable manner. Define a set of core item types that characterize all items in one or more core schema item types that can be, directly (by item type) or indirectly (by item subtype). Predefined item types reflect the most common items in an item-based hardware / software interface system, so that an efficient level of those pre-configured core schemas Obtained by an item-based hardware / software interface system that understands predefined item types.
特定の実施例において、コア・スキーマは拡張可能ではない。つまり、コア・スキーマの一部である固有の事前定義済み派生アイテム・タイプの場合を除いて、追加のアイテム・タイプは、基本スキーマのアイテム・タイプから直接サブタイプ定義することができない。コア・スキーマへの拡張を防ぐ（つまりコア・スキーマへの新しいアイテムの追加を防ぐ）ことにより、すべての後続のアイテム・タイプが必然的にコアシステムアイテム・タイプのサブタイプになるため、ストレージ・プラットフォームはコア・スキーマのアイテム・タイプの使用を義務付ける。この構造により、追加のアイテム・タイプを定義する際の柔軟性の度合いが適度に高まり、しかもコア・アイテム・タイプの事前定義済みセットを備える利点も保持することができる。 In certain embodiments, the core schema is not extensible. That is, except for the unique predefined derived item types that are part of the core schema, additional item types cannot be subtyped directly from the base schema item type. By preventing extensions to the core schema (that is, preventing new items from being added to the core schema), all subsequent item types are necessarily subtypes of the core system item type, so storage storage The platform mandates the use of core schema item types. This structure provides a modest degree of flexibility in defining additional item types while still retaining the benefits of having a predefined set of core item types.
本発明のさまざまな実施例について、図８Ａを参照すると、コア・スキーマによってサポートされる特定のアイテム・タイプは１つまたは複数の以下の事項を含むことができる。
・ Ｃａｔｅｇｏｒｉｅｓ：このアイテム・タイプのアイテム（およびそこから派生したサブタイプ）は、アイテム・ベースのハードウェア／ソフトウェア・インターフェース・システムにおける有効なカテゴリを表す。
・ Ｃｏｍｍｏｄｉｔｉｅｓ：識別可能な値であるアイテム。
・ Ｄｅｖｉｃｅｓ：情報処理機能をサポートする論理構造を持つアイテム。
・ Ｄｏｃｕｍｅｎｔｓ：アイテム・ベースのハードウェア／ソフトウェア・インターフェース・システムによって解釈されないが、代わりにドキュメントタイプに対応するアプリケーション・プログラムによって解釈されるコンテンツを持つアイテム。
・ Ｅｖｅｎｔｓ：環境内の特定のオカレンスを記録するアイテム。
・ Ｌｏｃａｔｉｏｎｓ：物理的位置（地理的位置など）を表すアイテム。
・ Ｍｅｓｓａｇｅｓ：２つ以上のプリンシパル（以下で定義される）間の通信のアイテム。
・ Ｐｒｉｎｃｉｐａｌｓ：ＩｔｅｍＩｄを除いて少なくとも１つの決定的に証明可能なＩＤを持つアイテム（たとえば、人物、組織、グループ、世帯、当局、サービスなど）。
・ Ｓｔａｔｅｍｅｎｔｓ：ポリシー、サブスクリプション、証明書など（これらに限定されないが）を含む環境に関する特殊情報を持つアイテム。
For various embodiments of the present invention and referring to FIG. 8A, a particular item type supported by the core schema may include one or more of the following:
Category: Items of this item type (and subtypes derived from it) represent valid categories in an item-based hardware / software interface system.
• Commodities: Items that are identifiable values.
Devices: Items having a logical structure that supports information processing functions.
Documents: Items with content that is not interpreted by the item-based hardware / software interface system but is instead interpreted by the application program corresponding to the document type.
Events: Items that record specific occurrences in the environment.
Locations: items that represent physical locations (such as geographical locations).
Messages: Items of communication between two or more principals (defined below).
• Principles: items with at least one definitive identifiable ID except ItemId (eg, person, organization, group, household, authority, service, etc.).
Statements: Items with special information about the environment, including (but not limited to) policies, subscriptions, certificates, etc.
同様に、図８Ｂを参照すると、コア・スキーマによってサポートされる特定のプロパティ・タイプは１つまたは複数の以下の事項を含むことができる。
・ Ｃｅｒｔｉｆｉｃａｔｅｓ（基本スキーマの基礎的ＰｒｏｐｅｒｔｙＢａｓｅタイプから派生）
・ Ｐｒｉｎｃｉｐａｌ Ｉｄｅｎｔｉｔｙ Ｋｅｙｓ（基本スキーマのＩｄｅｎｔｉｔｙＫｅｙタイプから派生）
・ Ｐｏｓｔａｌ Ａｄｄｒｅｓｓ（基本スキーマのＰｒｏｐｅｒｔｙタイプから派生）
・ Ｒｉｃｈ Ｔｅｘｔ（基本スキーマのＰｒｏｐｅｒｔｙタイプから派生）
・ ＥＡｄｄｒｅｓｓ（基本スキーマのＰｒｏｐｅｒｔｙタイプから派生）
・ ＩｄｅｎｔｉｔｙＳｅｃｕｒｉｔｙＰａｃｋａｇｅ（基本スキーマのＲｅｌａｔｉｏｎｓｈｉｐタイプから派生）
・ ＲｏｌｅＯｃｃｕｐａｎｃｙ（基本スキーマのＲｅｌａｔｉｏｎｓｈｉｐタイプから派生）
・ ＢａｓｉｃＰｒｅｓｅｎｃｅ（基本スキーマのＲｅｌａｔｉｏｎｓｈｉｐタイプから派生）
これらのアイテムおよびプロパティはさらに、図８Ａおよび図８Ｂに示されているそれぞれのプロパティによって説明される。
Similarly, referring to FIG. 8B, certain property types supported by the core schema may include one or more of the following:
Certificates (derived from the basic PropertyBase type of the basic schema)
· Principal Identity Keys (derived from IdentityKey type of basic schema)
-Post Address (derived from the Property type of the basic schema)
-Rich Text (derived from the Property type of the basic schema)
EAddress (derived from the Property type of the basic schema)
・ IdentitySecurityPackage (derived from the Relationship type of the basic schema)
-RoleOccupancy (derived from the relationship type of the basic schema)
-BasicPresence (derived from the basic schema Relationship type)
These items and properties are further described by the respective properties shown in FIGS. 8A and 8B.
５．リレーションシップ（Relationship）
リレーションシップは、一方のアイテムがソースとして指定され、もう一方のアイテムがターゲットとして指定される２項関係（binary relationships）である。ソース・アイテムおよびターゲット・アイテムは、リレーションシップによって関連している。ソース・アイテムは一般に、リレーションシップの存続期間を制御する。つまり、ソース・アイテムが削除されると、アイテム間のリレーションシップも削除される。
5. Relationship
A relationship is a binary relationship in which one item is designated as a source and the other item is designated as a target. Source items and target items are related by relationships. The source item generally controls the lifetime of the relationship. That is, when the source item is deleted, the relationship between items is also deleted.
リレーションシップは、包含および参照のリレーションシップに分類される。包含リレーションシップはターゲット・アイテムの存続期間を制御するが、参照リレーションシップは存続期間管理セマンティクスを提供しない。図１２は、リレーションシップ（Relationship）が分類される方法を示す図である。 Relationships are classified into containment and reference relationships. Inclusive relationships control the lifetime of target items, but reference relationships do not provide lifetime management semantics. FIG. 12 is a diagram illustrating a method for classifying relationships.
包含（Containment）リレーションシップ・タイプはさらに、保持（Holding）および埋め込み（Embedding）のリレーションシップに分類される。アイテムへのすべての保持リレーションシップが除去されると、アイテムは削除される。保持リレーションシップは、参照カウント・メカニズム（reference counting mechanism）を通じてターゲットの存続期間を制御する。埋め込みリレーションシップは、複合アイテムのモデリングを可能にし、排他的な保持リレーションシップと考えることができる。アイテムは、１つまたは複数の保持リレーションシップのターゲットになりうる。しかし、アイテムは厳密に１つの埋め込みリレーションシップのターゲットとなることができる。埋め込みリレーションシップのターゲットであるアイテムは、他の保持または埋め込みリレーションシップのターゲットになることはできない。 Containment relationship types are further classified into holding and embedding relationships. An item is deleted when all retained relationships to the item are removed. Retention relationships control the lifetime of the target through a reference counting mechanism. Embedded relationships allow modeling of complex items and can be thought of as exclusive holding relationships. An item can be the target of one or more retention relationships. However, an item can be the target of exactly one embedded relationship. An item that is the target of an embedded relationship cannot be the target of any other retention or embedded relationship.
参照リレーションシップは、ターゲット・アイテムのライフタイムを制御しない。これらは、ｄａｎｇｌｉｎｇ（未決）の場合もある。つまり、ターゲット・アイテムが存在しない場合もある。参照リレーションシップを使用して、グローバル・アイテム・ネーム・スペースのどこにでも（リモート・データストアを含む）アイテムへの参照をモデル化することができる。 Reference relationships do not control the lifetime of the target item. These may be dangling. That is, the target item may not exist. Reference relationships can be used to model references to items (including remote datastores) anywhere in the global item namespace.
アイテムのフェッチ（取り出し）は、自動的にそのリレーションシップをフェッチしない。アプリケーションは、アイテムのリレーションシップを明示的に要求する必要がある。さらに、リレーションシップを変更することでは、ソースまたはターゲット・アイテムは変更されない。同様に、リレーションシップを追加しても、ソースまたはターゲット・アイテムには影響を与えない。 Fetching (retrieving) an item does not automatically fetch that relationship. The application needs to explicitly request item relationships. Furthermore, changing the relationship does not change the source or target item. Similarly, adding a relationship does not affect the source or target item.
ａ）リレーションシップ（Relationship）の宣言
明示的なリレーションシップ・タイプは、以下の要素により定義される。
・ リレーションシップ名は、名前属性で指定される。
・ リレーションシップ・タイプは、保持、埋め込み、参照のいずれかである。これは、タイプ属性で指定される。
・ ソースおよびターゲット・エンド・ポイント。各エンドポイントは、参照先アイテムの名前およびターゲットを指定する。
・ ソース・エンド・ポイント・フィールドは、一般にＩｔｅｍＩＤ（宣言されていない）のタイプであり、リレーションシップ・インスタンスと同じデータ・ストアにあるアイテムを参照する必要がある。
・ 保持および埋め込みのリレーションシップでは、ターゲット・エンド・ポイント・フィールドはＩｔｅｍＩＤＲｅｆｅｒｅｎｃｅのタイプである必要があり、リレーションシップ・インスタンスと同じストアにあるアイテムを参照する必要がある。参照のリレーションシップでは、ターゲット・エンド・ポイントは任意のＩｔｅｍＲｅｆｅｒｅｎｃｅタイプにすることができ、他のストレージ・プラットフォームのデータ・ストア内のアイテムを参照することができる。
・ オプションで、スカラの１つまたは複数のフィールド、またはＰｒｏｐｅｒｔｙＢａｓｅタイプを宣言することができる。これらのフィールドは、リレーションシップに関連付けられているデータを含むことができる。
・ リレーションシップ・インスタンスは、グローバル・リレーションシップ・テーブルに格納される。
・ すべてのリレーションシップ・インスタンスは、組み合わせ（ソースＩｔｅｍＩＤ、リレーションシップＩＤ）により一意に識別される。リレーションシップＩＤは、そのタイプにはかかわりなく所定のアイテムに供給されたすべてのリレーションシップに対して所定のソースＩｔｅｍＩＤ内で一意である。
a) Relationship Declaration An explicit relationship type is defined by the following elements:
-The relationship name is specified by the name attribute.
-The relationship type is either retention, embedding, or reference. This is specified by the type attribute.
• Source and target end points. Each endpoint specifies the name and target of the referenced item.
The source end point field is generally of type ItemID (not declared) and needs to reference an item in the same data store as the relationship instance.
For retention and embedded relationships, the target endpoint field must be of type ItemIDReference and must reference an item in the same store as the relationship instance. In a reference relationship, the target end point can be of any ItemReference type and can reference items in the data store of other storage platforms.
Optionally, you can declare one or more fields of the scalar, or a PropertyBase type. These fields can contain data associated with the relationship.
Relationship instances are stored in the global relationship table.
• All relationship instances are uniquely identified by a combination (source ItemID, relationship ID). The relationship ID is unique within a given source ItemID for all relationships supplied to a given item regardless of its type.
ソース・アイテムは、リレーションシップの所有者である。所有者として指定されたアイテムは、リレーションシップの存続期間を制御するが、リレーションシップ自体はその関連するアイテムからは分離されている。ストレージ・プラットフォームＡＰＩ３２２は、アイテムに関連付けられているリレーションシップを公開するメカニズムを提供する。
以下にリレーションシップの宣言の例を示す。
The source item is the relationship owner. An item designated as the owner controls the lifetime of the relationship, but the relationship itself is separated from its associated items. The storage platform API 322 provides a mechanism for publishing relationships associated with items.
The following is an example of a relationship declaration.
これは、参照のリレーションシップの例である。ソース参照によって参照されている人物アイテムが存在しない場合、リレーションシップは作成することはできない。さらに、人物アイテムが削除された場合、人物と組織の間のリレーションシップ・インスタンスが削除される。ただし、組織アイテムが削除された場合、リレーションシップは削除されず、ｄａｎｇｌｉｎｇ（未決）となる。 This is an example of a reference relationship. A relationship cannot be created if no person item is referenced by the source reference. Further, when a person item is deleted, the relationship instance between the person and the organization is deleted. However, when the organization item is deleted, the relationship is not deleted and becomes dangling (undecided).
ｂ）保持のリレーションシップ
保持リレーションシップは、ターゲット・アイテムの参照カウントベースの存続期間管理をモデル化するために使用される。
b) Retention relationships Retention relationships are used to model reference item-based lifetime management of target items.
アイテムは、アイテムとのゼロ以上のリレーションシップに対するソース・エンド・ポイントになることができる。埋め込みアイテムではないアイテムは、１つまたは複数の保持リレーションシップのターゲットになることができる。 An item can be a source end point for zero or more relationships with the item. Items that are not embedded items can be the target of one or more retention relationships.
ターゲット・エンド・ポイント参照タイプはＩｔｅｍＩＤＲｅｆｅｒｅｎｃｅである必要があり、リレーションシップ・インスタンスと同じストアにあるアイテムを参照する必要がある。 The target end point reference type must be ItemIDReference and must reference an item in the same store as the relationship instance.
保持リレーションシップは、ターゲット・エンド・ポイントのライフタイム管理を強制する。保持リレーションシップ・インスタンスの作成、およびそれがターゲットにするアイテムの作成は、アトミック・オペレーションである。同じアイテムをターゲットにする追加の保持リレーションシップ・インスタンスを作成することができる。所定のアイテムをターゲット・エンド・ポイントとして持つ最後の保持リレーションシップ・インスタンスが削除された場合、ターゲット・アイテムも削除される。 Retention relationships enforce lifetime management of target end points. Creating a retention relationship instance and the items it targets are atomic operations. You can create additional retention relationship instances that target the same item. When the last retained relationship instance with a given item as a target end point is deleted, the target item is also deleted.
リレーションシップ宣言で指定されているエンドポイント・アイテムのタイプは一般に、リレーションシップのインスタンスが作成されるときに、強制される。エンドポイント・アイテムのタイプは、リレーションシップが確立された後は変更することができない。 The type of endpoint item specified in the relationship declaration is generally enforced when the relationship instance is created. The type of endpoint item cannot be changed once the relationship is established.
保持リレーションシップは、アイテム・ネーム・スペースを形成する際に重要な役割を果たす。保持リレーションシップは、ソース・アイテムに関連してターゲット・アイテムの名前を定義する「Ｎａｍｅ」プロパティを含んでいる。この相対名は、所定のアイテムから供給されるすべての保持リレーションシップに対して一意である。ルート・アイテムから始まり所定のアイテムまで至るこの相対名の順序付きリストは、アイテムに対するフルネームを形成する。 Retention relationships play an important role in forming item name spaces. The retention relationship includes a “Name” property that defines the name of the target item in relation to the source item. This relative name is unique for all retention relationships supplied from a given item. This ordered list of relative names starting from the root item to the given item forms the full name for the item.
保持リレーションシップは、有向非周期グラフ（ＤＡＧ；directed acyclic graph）を形成する。保持リレーションシップが作成されるとき、システムはサイクルが作成されないようにして、アイテム・ネーム・スペースがＤＡＧを形成するようにする。 The retention relationship forms a directed acyclic graph (DAG). When a retention relationship is created, the system prevents the cycle from being created so that the item name space forms a DAG.
保持リレーションシップはターゲット・アイテムの存続期間を制御するが、これはターゲット・エンド・ポイントアイテムの操作上の整合性は制御しない。ターゲット・アイテムは、保持リレーションシップを通じてこれを所有するアイテムから操作上独立している。保持リレーションシップのソースであるアイテムに対するコピー、移動、バックアップその他の操作は、同じリレーションシップのターゲットであるアイテムには影響を与えない。たとえば、フォルダ・アイテムをバックアップしても、フォルダ内のすべてのアイテム（ＦｏｌｄｅｒＭｅｍｂｅｒリレーションシップのターゲット）が自動的にバックアップされることはない。 A retention relationship controls the lifetime of the target item, but it does not control the operational integrity of the target end point item. A target item is operationally independent of the item that owns it through a retention relationship. Copy, move, backup, and other operations on an item that is the source of a retention relationship will not affect the item that is the target of the same relationship. For example, backing up a folder item does not automatically back up all items in the folder (FolderMember relationship target).
保持リレーションシップの例を以下に示す。 An example of a retention relationship is shown below.
ＦｏｌｄｅｒＭｅｍｂｅｒｓリレーションシップにより、アイテムの汎用コレクションとしてのフォルダの概念が可能になる。 The FolderMembers relationship allows the concept of a folder as a general collection of items.
ｃ）埋め込みのリレーションシップ
埋め込みリレーションシップは、ターゲット・アイテムのライフタイムの排他制御の概念をモデル化する。埋め込みリレーションシップは、複合アイテムの概念を可能にする。
c) Embedding relationships Embedding relationships model the concept of exclusive control of the lifetime of a target item. Embedded relationships allow the concept of compound items.
埋め込みリレーションシップ・インスタンスおよびそれがターゲットにするアイテムの作成は、アトミック・オペレーションである。アイテムは、ゼロ以上の埋め込みリレーションシップのソースになることができる。ただし、アイテムは、１つだけの埋め込みリレーションシップのターゲットになることができる。埋め込みリレーションシップのターゲットであるアイテムは、保持リレーションシップのターゲットになることはできない。 The creation of an embedded relationship instance and the item it targets is an atomic operation. An item can be the source of zero or more embedded relationships. However, an item can be the target of only one embedded relationship. An item that is the target of an embedded relationship cannot be the target of a retention relationship.
ターゲット・エンド・ポイント参照タイプはＩｔｅｍＩＤＲｅｆｅｒｅｎｃｅである必要があり、リレーションシップ・インスタンスと同じデータ・ストアにあるアイテムを参照する必要がある。 The target end point reference type must be ItemIDReference and must reference an item in the same data store as the relationship instance.
リレーションシップ宣言で指定されているエンドポイント・アイテムのタイプは一般に、リレーションシップのインスタンスが作成されるときに強制される。エンドポイント・アイテムのタイプは、リレーションシップが確立された後は変更することができない。 The type of endpoint item specified in the relationship declaration is generally enforced when the relationship instance is created. The type of endpoint item cannot be changed once the relationship is established.
埋め込みリレーションシップは、ターゲット・エンド・ポイントの操作上の整合性を制御する。たとえば、アイテムをシリアル化する操作は、そのアイテムから供給されるすべての埋め込みリレーションシップおよびそのすべてのターゲットのシリアル化を含むことができる。アイテムをコピーすると、その埋め込みアイテムもすべてコピーされる。 Embedded relationships control the operational integrity of the target end point. For example, the operation of serializing an item can include serialization of all embedded relationships and all its targets supplied from that item. When you copy an item, all of its embedded items are also copied.
宣言の例を以下に示す。 An example declaration is shown below.
ｄ）参照のリレーションシップ
参照リレーションシップは、それが参照するアイテムの存続期間を制御しない。さらに、参照リレーションシップは、ターゲットの存在を保証することも、リレーションシップ宣言で指定されているターゲットのタイプを保証することもない。つまり、参照リレーションシップは、ｄａｎｇｌｉｎｇであることができるということである。さらに、参照リレーションシップは、他のデータ・ストアにあるアイテムを参照することができる。参照リレーションシップは、Ｗｅｂページにおけるリンクと類似した概念と考えることができる。
d) Reference relationships A reference relationship does not control the lifetime of the item it references. Furthermore, reference relationships do not guarantee the existence of a target or the type of target specified in the relationship declaration. That is, the reference relationship can be dangling. In addition, reference relationships can reference items in other data stores. Reference relationships can be thought of as a concept similar to links in web pages.
参照リレーションシップの宣言の例を以下に示す。 An example of a reference relationship declaration is shown below.
ターゲット・エンド・ポイントでは任意の参照タイプが許可される。参照リレーションシップに加わるアイテムは、任意のアイテム・タイプであってもよい。 Any reference type is allowed at the target endpoint. Items that participate in a reference relationship may be of any item type.
参照リレーションシップは、アイテム間の、多くの非ライフタイム管理リレーションシップをモデル化するために使用される。ターゲットの存在が強制されないので、参照リレーションシップは、疎結合のリレーションシップをモデル化する際に便利である。参照リレーションシップを使用して、他のコンピュータ上のストアを含む他のデータ・ストアにあるアイテムをターゲットにすることができる。 Reference relationships are used to model many non-lifetime management relationships between items. Reference relationships are useful in modeling loosely-coupled relationships because the existence of the target is not enforced. Reference relationships can be used to target items in other data stores, including stores on other computers.
ｅ）規則および制約事項
以下の追加の規則および制約事項がリレーションシップに適用される。
・ アイテムは「厳密に１つの埋め込みリレーションシップ」または「１つまたは複数の保持リレーションシップ」のターゲットでなければならない。１つの例外は、ルート・アイテムである。アイテムは、ゼロ以上の参照リレーションシップのターゲットになることができる。
・ 埋め込みリレーションシップのターゲットであるアイテムは、保持リレーションシップのソースになることはできない。これは、参照のリレーションシップのソースであることができる。
・ アイテムは、ファイルから格上げされる場合には保持リレーションシップのソースになることはできない。これは、埋め込みリレーションシップおよび参照リレーションシップのソースになることができる。
・ ファイルから格上げされるアイテムは、埋め込みリレーションシップのターゲットになることはできない。
e) Rules and restrictions The following additional rules and restrictions apply to relationships.
• The item must be the target of “exactly one embedded relationship” or “one or more holding relationships”. One exception is the root item. An item can be the target of zero or more reference relationships.
• An item that is the target of an embedded relationship cannot be the source of a retention relationship. This can be the source of a reference relationship.
• An item cannot be the source of a retention relationship when promoted from a file. This can be the source of embedded relationships and reference relationships.
• Items promoted from a file cannot be the target of an embedded relationship.
ｆ）リレーションシップの順序付け
少なくとも１つの実施例において、本発明のストレージ・プラットフォームはリレーションシップの順序付けをサポートする。順序付けは、基本リレーションシップ定義中の「Ｏｒｄｅｒ」という名前のプロパティを通じて行われる。Ｏｒｄｅｒフィールドには一意性の制約はない。同じ「順序」プロパティ値とのリレーションシップの順序は保証されない。ただし、下位の「順序」値を有するリレーションシップの後および上位の「順序」フィールド値を有するリレーションシップの前に順序付けられることは保証される。
f) Relationship Ordering In at least one embodiment, the storage platform of the present invention supports relationship ordering. The ordering is done through a property named “Order” in the basic relationship definition. There is no uniqueness restriction in the Order field. The order of relationships with the same “order” property value is not guaranteed. However, it is guaranteed to be ordered after the relationship with the lower “order” value and before the relationship with the higher “order” field value.
アプリケーションは、組み合わせ（ＳｏｕｒｄｅＩｔｅｍＩＤ、ＲｅｌａｔｉｏｎｓｈｉｐＩＤ、Ｏｒｄｅｒ）の順序付けによりデフォルトの順序でリレーションシップを取得することができる。所定のアイテムから供給されるすべてのリレーションシップ・インスタンスは、コレクション内のリレーションシップのタイプにはかかわりなく、単一のコレクションとして順序付けされる。ただし、これは所定のタイプ（たとえばＦｏｌｄｅｒＭｅｍｂｅｒｓ）のすべてのリレーションシップが、所定のアイテムに対するリレーションシップのコレクションの順序付きサブセットであることを保証する。 The application can obtain relationships in a default order by ordering combinations (SourceItemID, RelationshipID, Order). All relationship instances supplied from a given item are ordered as a single collection regardless of the type of relationship within the collection. However, this ensures that all relationships of a given type (eg, FolderMembers) are an ordered subset of the collection of relationships for a given item.
リレーションシップを操作するためのデータ・ストアＡＰＩ３１２は、リレーションシップの順序付けをサポートするオペレーション・セットを実装する。オペレーションについて説明する上で役立つように、以下の用語を紹介しておく。
・ ＲｅｌＦｉｒｓｔは、順序値ＯｒｄＦｉｒｓｔを持つ順序付きコレクションにおける最初のリレーションシップである。
・ ＲｅｌＬａｓｔは、順序値ＯｒｄＬａｓｔを持つ順序付きコレクションにおける最後のリレーションシップである。
・ ＲｅｌＸは、順序値ＯｒｄＸを持つコレクションにおける所定のリレーションシップである。
・ ＲｅｌＰｒｅｖは、ＲｅｌＸにコレクション内で最も近い、ＯｒｄＸよりも小さい順序値ＯｒｄＰｒｅｖを持つリレーションシップである。
・ ＲｅｌＮｅｘｔは、ＲｅｌＸにコレクション内で最も近い、ＯｒｄＸよりも大きい順序値ＯｒｄＮｅｘｔを持つリレーションシップである。
The data store API 312 for manipulating relationships implements a set of operations that support relationship ordering. The following terms are introduced to help explain the operation.
RelFirst is the first relationship in the ordered collection with the order value OrdFirst.
RelLast is the last relationship in the ordered collection with the order value OrdLast.
RelX is a predetermined relationship in the collection with the order value OrdX.
RelPrev is a relationship having an order value OrdPrev that is closest to RelX in the collection and is smaller than OrdX.
RelNext is a relationship having an order value OrdNext that is closest to RelX in the collection and is greater than OrdX.
オペレーションは、以下のものを含むが、これらに限定されることはない。
・ ＩｎｓｅｒｔＢｅｆｏｒｅＦｉｒｓｔ（ＳｏｕｒｃｅＩｔｅｍＩＤ、Ｒｅｌａｔｉｏｎｓｈｉｐ）は、コレクション内の最初のリレーションシップとしてリレーションシップを挿入する。新しいリレーションシップの「Ｏｒｄｅｒ」プロパティの値は、ＯｒｄＦｉｒｓｔよりも小さくなる。
・ ＩｎｓｅｒｔＡｆｔｅｒＬａｓｔ（ＳｏｕｒｃｅＩｔｅｍＩＤ、Ｒｅｌａｔｉｏｎｓｈｉｐ）は、コレクション内の最後のリレーションシップとしてリレーションシップを挿入する。新しいリレーションシップの「Ｏｒｄｅｒ」プロパティの値は、ＯｒｄＬａｓｔよりも大きくなる。
・ ＩｎｓｅｒｔＡｔ（ＳｏｕｒｃｅＩｔｅｍＩＤ、ｏｒｄ、Ｒｅｌａｔｉｏｎｓｈｉｐ）は、「Ｏｒｄｅｒ」プロパティに指定されている値を持つリレーションシップを挿入する。
・ ＩｎｓｅｒｔＢｅｆｏｒｅ（ＳｏｕｒｃｅＩｔｅｍＩＤ、ｏｒｄ、Ｒｅｌａｔｉｏｎｓｈｉｐ）は、所定の順序値を持つリレーションシップの前にリレーションシップを挿入する。新しいリレーションシップは、非包含的なＯｒｄＰｒｅｖとｏｒｄの間の「Ｏｒｄｅｒ」値を割り当てられる。
・ ＩｎｓｅｒｔＡｆｔｅｒ（ＳｏｕｒｃｅＩｔｅｍＩＤ、ｏｒｄ、Ｒｅｌａｔｉｏｎｓｈｉｐ）は、所定の順序値を持つリレーションシップの後にリレーションシップを挿入する。新しいリレーションシップは、非包含的なｏｒｄとＯｒｄＮｅｘｔの間の「Ｏｒｄｅｒ」値を割り当てられる。
・ ＭｏｖｅＢｅｆｏｒｅ（ＳｏｕｒｃｅＩｔｅｍＩＤ、ｏｒｄ、ＲｅｌａｔｉｏｎｓｈｉｐＩＤ）は、指定されている「Ｏｒｄｅｒ」値を持つリレーションシップの前に所定のリレーションシップＩＤを持つリレーションシップを移動する。リレーションシップは、非包含的なＯｒｄＰｒｅｖとｏｒｄの間の新しい「Ｏｒｄｅｒ」値を割り当てられる。
・ ＭｏｖｅＡｆｔｅｒ（ＳｏｕｒｃｅＩｔｅｍＩＤ、ｏｒｄ、ＲｅｌａｔｉｏｎｓｈｉｐＩＤ）は、指定されている「Ｏｒｄｅｒ」値を持つリレーションシップの後に所定のリレーションシップＩＤを持つリレーションシップを移動する。リレーションシップは、非包含的なｏｒｄとＯｒｄＮｅｘｔの間の新しい順序値を割り当てられる。
Operations include, but are not limited to:
InsertBeforeFirst (SourceItemID, Relationship) inserts a relationship as the first relationship in the collection. The value of the “Order” property of the new relationship will be less than OrdFirst.
InsertAfterLast (SourceItemID, Relationship) inserts a relationship as the last relationship in the collection. The value of the “Order” property of the new relationship will be greater than OrdLast.
InsertAt (SourceItemID, ord, Relationship) inserts a relationship having the value specified in the “Order” property.
InsertBefore (SourceItemID, ord, Relationship) inserts a relationship before a relationship having a predetermined order value. The new relationship is assigned a “Order” value between the non-inclusive OrdPrev and ord.
InsertAfter (SourceItemID, ord, Relationship) inserts a relationship after a relationship having a predetermined order value. The new relationship is assigned an “Order” value between non-inclusive ordNext.
MoveBefore (SourceItemID, ord, RelationshipID) moves a relationship having a predetermined relationship ID before a relationship having a specified “Order” value. The relationship is assigned a new “Order” value between the non-inclusive OrdPrev and ord.
MoveAfter (SourceItemID, ord, RelationshipID) moves a relationship having a predetermined relationship ID after a relationship having a specified “Order” value. The relationship is assigned a new order value between the non-inclusive ord and OrdNext.
前述のように、すべてのアイテムはアイテム・フォルダのメンバでなければならない。リレーションシップに関して、すべてのアイテムはアイテム・フォルダとのリレーションシップを有する必要がある。本発明のいくつかの実施例において、特定のリレーションシップはアイテム間に存在するリレーションシップによって表される。 As mentioned above, all items must be members of an item folder. With respect to relationships, every item must have a relationship with an item folder. In some embodiments of the present invention, a particular relationship is represented by a relationship that exists between items.
本発明のさまざまな実施例に対して実装されると、リレーションシップは、１つのアイテム（ソース）によってもう１つのアイテム（ターゲット）に「拡張される」有向２項リレーションシップを提供する。リレーションシップは、ソース・アイテム（拡張したアイテム）によって所有されているので、ソースが除去された場合にリレーションシップが除去される（たとえばソース・アイテムが削除されるとそのリレーションシップが削除される）。さらに、特定のインスタンスにおいて、リレーションシップはターゲット・アイテムの所有を共有（共同所有）することができ、そのような所有はリレーションシップ（リレーションシップ・プロパティ・タイプに関する図７を参照）のＩｓＯｗｎｅｄプロパティ（またはその相当物）に反映されることがある。これらの実施例において、新しいＩｓＯｗｎｅｄリレーションシップの作成は、自動的にターゲット・アイテムの参照カウントを増分し、そのようなリレーションシップの削除はターゲット・アイテムの参照カウントを減分することになる。これらの特定の実施例の場合、アイテムは、ゼロよりも大きい参照カウントを持つ場合に引き続き存在し、カウントがゼロに達するときは自動的に削除される。この場合も、アイテム・フォルダは、他のアイテムへのリレーションシップのセットを持つ（または持つことができる）アイテムであり、これらの他のアイテムはアイテム・フォルダのメンバーシップを備えている。リレーションについての他の実際の実装も可能であり、本明細書に説明されている機能を達成することが、本発明によって可能であり、また期待されている。 When implemented for various embodiments of the present invention, relationships provide directed binary relationships that are “extended” by one item (source) to another item (target). The relationship is owned by the source item (extended item), so the relationship is removed when the source is removed (for example, when the source item is deleted, the relationship is deleted) . Furthermore, in a particular instance, a relationship can share (co-own) ownership of the target item, and such ownership is the IsOwned property of the relationship (see FIG. 7 for relationship property types) ( Or its equivalent). In these examples, the creation of a new IsOwned relationship automatically increments the reference count of the target item, and deletion of such a relationship will decrement the reference count of the target item. In these particular embodiments, items continue to exist when they have a reference count greater than zero and are automatically deleted when the count reaches zero. Again, an item folder is an item that has (or can have) a set of relationships to other items, and these other items have item folder membership. Other actual implementations of relations are possible, and it is possible and expected by the present invention to achieve the functions described herein.
実際の実施態様にはかかわりなく、リレーションシップは１つのオブジェクトから別のオブジェクトへの選択可能な接続である。アイテムが複数のアイテム・フォルダおよび複数のカテゴリに属すことができる機能と、これらのアイテム、フォルダ、およびカテゴリがパブリックまたはプライベートであるかどうかは、アイテム・ベースの構造におけるその存在（またはその不足）に与えられる意味によって決められる。これらの論理リレーションシップは、物理的実装にかかわりなく、本明細書に説明されている機能を達成するために具体的に採用される、リレーションシップのセットに割り当てられた意味である。論理リレーションシップは、アイテム・フォルダおよびカテゴリが本質的には、それぞれアイテムの特殊なタイプであるので、あるアイテムとそのアイテム・フォルダまたはカテゴリ（その逆もあり）の間に確立される。したがって、アイテム・フォルダおよびカテゴリは、コピー、電子メール・メッセージへの追加、ドキュメントへの埋め込みなど、制限なく、他のアイテムと同じように制限なく処理することができる。アイテム・フォルダおよびカテゴリは、他のアイテムと同じメカニズムを使用してシリアル化およびデシリアル化することができる。（たとえば、ＸＭＬにおいて、すべてのアイテムはシリアル化フォーマットを持つ場合があり、このフォーマットはアイテム・フォルダ、カテゴリ、およびアイテムに同等に適用される。）
アイテムとそのアイテム・フォルダの間のリレーションシップを表す前述のリレーションシップは、アイテムからアイテム・フォルダへ、アイテム・フォルダからアイテムへ、またはその両方へ論理的に拡張することができる。アイテムからアイテム・フォルダに論理的に拡張するリレーションシップは、アイテム・フォルダがそのアイテムにパブリックでありそのメンバーシップ情報をそのアイテムと共有することを示している。逆に、アイテムからアイテム・フォルダへの論理リレーションシップの不足は、アイテム・フォルダがそのアイテムにプライベートであり、そのメンバーシップ情報をそのアイテムと共有しないことを示している。同様に、アイテム・フォルダからアイテムに論理的に拡張するリレーションシップは、アイテムがパブリックでありそのアイテム・フォルダに共有可能であることを示しているが、これに反して、アイテム・フォルダからアイテムへの論理リレーションシップの不足は、アイテムがプライベートであり共有可能ではないことを示している。したがって、アイテム・フォルダが他のシステムにエクスポートされるとき、これは新しいコンテクストで共有される「パブリック」アイテムであり、アイテムが他の共有可能なアイテムのそのアイテム・フォルダを検索するとき、これはそこに属する共有可能なアイテムに関する情報をアイテムに提供する「パブリック」アイテム・フォルダである。
Regardless of the actual implementation, a relationship is a selectable connection from one object to another. The ability for an item to belong to multiple item folders and multiple categories, and whether these items, folders, and categories are public or private is their presence (or lack thereof) in the item-based structure It is decided by the meaning given to. These logical relationships are the meanings assigned to the set of relationships that are specifically employed to accomplish the functions described herein, regardless of physical implementation. A logical relationship is established between an item and its item folder or category (and vice versa) because item folders and categories are essentially special types of items. Thus, item folders and categories can be processed without restrictions, just like other items, without restrictions such as copying, appending to email messages, embedding in documents. Item folders and categories can be serialized and deserialized using the same mechanism as other items. (For example, in XML, all items may have a serialized format, which applies equally to item folders, categories, and items.)
The aforementioned relationships that represent the relationship between an item and its item folder can be logically extended from item to item folder, item folder to item, or both. A relationship that logically extends from item to item folder indicates that the item folder is public to the item and shares its membership information with the item. Conversely, a lack of an item-to-item folder logical relationship indicates that the item folder is private to the item and does not share its membership information with the item. Similarly, a relationship that logically extends from an item folder to an item indicates that the item is public and can be shared to that item folder, but on the contrary, from the item folder to the item. The lack of logical relationships indicates that the item is private and cannot be shared. Thus, when an item folder is exported to another system, this is a “public” item that is shared in the new context, and when an item searches its item folder for other shareable items, this is A “public” item folder that provides items with information about sharable items belonging to them.
図９は、アイテム・フォルダ（この場合も、これは１つのアイテム自体である）、そのメンバ・アイテム、およびアイテム・フォルダとそのメンバ・アイテムとの相互接続リレーションシップを示すブロック図である。アイテム・フォルダ９００は、複数のアイテム９０２、９０４、および９０６をメンバとして備えている。アイテム・フォルダ９００は、それ自身からアイテム９０２へのリレーションシップ９１２を備えているが、これはアイテム９０２が、アイテム・フォルダ９００、そのメンバ９０４および９０６、およびアイテム・フォルダ９００にアクセスする可能性のあるその他のアイテム・フォルダ、カテゴリ、またはアイテム（図示せず）に対してパブリックであり共有可能であることを示している。ただし、アイテム９０２からアイテム・フォルダ９００へのリレーションシップはなく、このことは、アイテム・フォルダ９００がアイテム９０２にプライベートであり、そのメンバーシップ情報をアイテム９０２と共有しないことを示している。一方、アイテム９０４は、それ自身からアイテム・フォルダ９００へのリレーションシップを備え、このことは、アイテム・フォルダ９００がパブリックであり、そのメンバーシップ情報をアイテム９０４と共有することを示している。ただし、アイテム・フォルダ９００からアイテム９０４へのリレーションシップはなく、これはアイテム９０４が、アイテム・フォルダ９００、その他のメンバ９０２および９０６、およびアイテム・フォルダ９００にアクセスする可能性のあるその他のアイテム・フォルダ、カテゴリ、またはアイテム（図示せず）に対してプライベートであり共有可能ではないことを示している。アイテム９０２および９０４へのそのリレーションシップとは対照的に、アイテム・フォルダ９００は、それ自身からアイテム９０６へのリレーションシップ９１６を備え、アイテム９０６はアイテム９００に戻るリレーションシップ９２６を備えているが、これは共に、アイテム９０６が、アイテム・フォルダ９００、そのメンバ９０２および９０４、およびアイテム・フォルダ９００にアクセスする可能性のあるその他のアイテム・フォルダ、カテゴリ、またはアイテム（図示せず）に対してパブリックであり共有可能であり、アイテム・フォルダ９００がパブリックであってそのメンバーシップ情報をアイテム９０６と共有することを示している。
FIG. 9 is a block diagram illustrating an item folder (again, this is an item itself), its member items, and the interconnection relationship between the item folder and its member items. The
前述のように、アイテム・フォルダは「記述されない」ので、アイテム・フォルダ内のアイテムは共通性を共有する必要はない。一方、カテゴリは、そのメンバ・アイテムすべてに共通する共通性によって記述される。したがって、カテゴリのメンバーシップは本質的に、記述された共通性を備えるアイテムに制限され、特定の実施例において、カテゴリの記述に適合するすべてのアイテムは自動的にカテゴリのメンバとされる。この結果、アイテム・フォルダは単純タイプ（trivial type）の構造がそのメンバーシップによって表されことを可能にし、カテゴリは、メンバーシップが定義済みの共通性に基づくこと可能にする。 As mentioned above, the item folder is “not described”, so the items in the item folder need not share commonality. On the other hand, a category is described by commonality common to all of its member items. Thus, category membership is essentially limited to items with the described commonality, and in certain embodiments, all items that meet the category description are automatically made members of the category. As a result, an item folder allows a trivial type structure to be represented by its membership, and a category allows membership to be based on a defined commonality.
もちろん、カテゴリの記述は本来論理的であり、そのためカテゴリはタイプ、プロパティ、および／または値の任意の論理表現によって記述することができる。たとえば、カテゴリの論理表現は、２つのプロパティのいずれか、または両方を持つアイテムを備えるようなメンバーシップにすることができる。カテゴリのこれらの記述されたプロパティが「Ａ」および「Ｂ」である場合、カテゴリのメンバーシップは、プロパティＡを有しプロパティＢを有しないアイテム、プロパティＢを有しプロパティＡを有しないアイテム、およびプロパティＡおよびＢを共に有するアイテムを備えることができる。プロパティのこの論理表現は、ここでカテゴリによって記述されるメンバのセットはプロパティＡまたはＢを有するアイテムである場合に論理演算子「ＯＲ」によって記述することができる。当業者であれば、同様の論理オペランド（「ＡＮＤ」、「ＸＯＲ」、および「ＮＯＴ」の単独または組み合わせ、ただしこれらに限定されない）を使用してもカテゴリを記述できることが理解されよう。 Of course, category descriptions are logical in nature, so categories can be described by any logical representation of type, property, and / or value. For example, a logical representation of a category can be a membership that includes items with either or both of two properties. If these described properties of a category are “A” and “B”, the membership of the category is an item that has property A and does not have property B, an item that has property B and does not have property A, And an item having both properties A and B. This logical representation of a property can be described by the logical operator “OR” if the set of members described here by category is an item with property A or B. One skilled in the art will appreciate that categories can be described using similar logical operands (either alone or in combination of “AND”, “XOR”, and “NOT”, but not limited thereto).
アイテム・フォルダ（記述されない）およびカテゴリ（記述される）の相違にもかかわらず、アイテムへのカテゴリのリレーションシップおよびカテゴリへのアイテムのリレーションシップは本質的に、本発明の多くの実施例におけるアイテム・フォルダおよびアイテムについて本明細書で先に開示されている方法と同様である。 Despite the differences between item folders (not described) and categories (described), category relationships to items and item relationships to categories are essentially items in many embodiments of the present invention. • Similar to the methods previously disclosed herein for folders and items.
図１０は、カテゴリ（この場合も、これは１つのアイテム自体である）、そのメンバ・アイテム、およびカテゴリとそのメンバ・アイテムとの相互接続リレーションシップを示すブロック図である。カテゴリ１０００は、複数のアイテム１００２、１００４、および１００６をメンバとして備えており、そのすべてが、カテゴリ１０００によって記述されているように（共通性記述１００８）共通のプロパティ、値、またはタイプの組み合わせ１００８を共有している。カテゴリ１０００は、それ自身からアイテム１００２へのリレーションシップ１０１２を備えているが、これはアイテム１００２が、カテゴリ１０００、そのメンバ１００４および１００６、およびカテゴリ１０００にアクセスする可能性のあるその他のカテゴリ、アイテム・フォルダ、またはアイテム（図示せず）に対してパブリックであり共有可能であることを示している。ただし、アイテム１００２からカテゴリ１０００へのリレーションシップはなく、このことは、カテゴリ１０００がアイテム１００２にプライベートであり、そのメンバーシップ情報をアイテム１００２と共有しないことを示している。一方、アイテム１００４は、それ自身からカテゴリ１０００へのリレーションシップを備え、このことは、カテゴリ１０００がパブリックであり、そのメンバーシップ情報をアイテム１００４と共有することを示している。ただし、カテゴリ１０００からアイテム１００４へ拡張されたリレーションシップはなく、これはアイテム１００４が、カテゴリ１０００、その他のメンバ１００２および１００６、およびカテゴリ１０００にアクセスする可能性のあるその他のカテゴリ、アイテム・フォルダ、またはアイテム（図示せず）に対してプライベートであり共有可能ではないことを示している。アイテム１００２および１００４とのそのリレーションシップ（またはその不在）とは対照的に、カテゴリ１０００は、それ自身からアイテム１００６へのリレーションシップ１０１６を備え、アイテム１００６はカテゴリ１０００に戻るリレーションシップ１０２６を備えているが、これは共に、アイテム１００６が、カテゴリ１０００、そのアイテム・メンバ１００２および１００４、およびカテゴリ１０００にアクセスする可能性のあるその他のカテゴリ、アイテム・フォルダ、またはアイテム（図示せず）に対してパブリックであり共有可能であり、カテゴリ１０００がパブリックであってそのメンバーシップ情報をアイテム１００６と共有することを示している。
FIG. 10 is a block diagram illustrating a category (again, this is an item itself), its member items, and the interconnection relationship between a category and its member items. The
最後に、カテゴリおよびアイテム・フォルダは、それ自体がアイテムであり、アイテムは相互にリレーションシップすることができるので、カテゴリはアイテム・フォルダとの間のリレーションシップを備えることができ、特定の代替実施例において、カテゴリ、アイテム・フォルダ、およびアイテムは、それぞれ他のカテゴリ、アイテム・フォルダ、およびアイテムにリレーションシップを備えることができる。ただし、さまざまな実施例において、アイテム・フォルダ構造および／またはカテゴリ構造は、ハードウェア／ソフトウェア・インターフェース・システム・レベルにおいて、サイクル（循環）を含むことが禁止されている。アイテム・フォルダおよびカテゴリ構造は、有向グラフと似ており、サイクルを禁止するこの実施例は、グラフ理論の分野における数学的定義によって、同一の頂点で開始および終了するパスがない有向グラフである有向非周期グラフ（ＤＡＧ：directed acyclic graphs）と類似したものになる。 Finally, because categories and item folders are themselves items, and items can be related to each other, categories can have relationships with item folders and certain alternative implementations In the example, categories, item folders, and items can have relationships to other categories, item folders, and items, respectively. However, in various embodiments, the item folder structure and / or category structure is prohibited from including cycles at the hardware / software interface system level. The item folder and category structure is similar to a directed graph, and this example of forbidden cycles is a directed non-directed graph with no path starting and ending at the same vertex by mathematical definition in the field of graph theory. It becomes similar to periodic graphs (DAG: directed acyclic graphs).
６．拡張性
ストレージ・プラットフォームは、前述したように、スキーマ３４０の初期セットが提供されるように設計される。しかしさらに、少なくとも一部の実施例において、ストレージ・プラットフォームは、独立系ソフトウェアベンダ（ＩＳＶ）を含む顧客が新しいスキーマ３４４（新しいアイテムおよびネスト化要素のタイプなど）を作成できるようにする。このセクションでは、スキーマ３４０の初期セットにおいて定義されるアイテム・タイプおよびネスト化要素タイプ（または単に「要素」タイプ）を拡張することによってそのようなスキーマを作成するためのメカニズムについて説明する。
6). Scalability The storage platform is designed such that an initial set of
アイテムおよびネスト化要素タイプの初期セットの拡張は、以下のように制約されることが好ましい。
・ ＩＳＶは、新しいタイプ、つまりＢａｓｅ．Ｉｔｅｍのサブタイプを導入することができる。
・ ＩＳＶは、新しいネスト化要素タイプ、つまりＢａｓｅ．ＮｅｓｔｅｄＥｌｅｍｅｎｔのサブタイプを導入することができる。
・ ＩＳＶは、新しい拡張、つまりＢａｓｅ．ＮｅｓｔｅｄＥｌｅｍｅｎｔのサブタイプを導入することができる。しかし、
・ ＩＳＶはストレージ・プラットフォーム・スキーマ３４０の初期セットによって定義されるいかなるタイプ（アイテム、ネスト化要素、またはＥｘｔｅｎｓｉｏｎタイプ）もサブタイプ定義することはできない。
Expansion of the initial set of items and nested element types is preferably constrained as follows.
ISV is a new type, Base. Item subtypes can be introduced.
ISV is a new nested element type, Base. NestedElement subtypes can be introduced.
ISV is a new extension, Base. NestedElement subtypes can be introduced. But,
ISVs cannot subtype any type (item, nested element, or extension type) defined by the initial set of
ストレージ・プラットフォーム・スキーマの初期セットによって定義されるアイテム・タイプまたはネスト化要素タイプはＩＳＶアプリケーションのニーズとは厳密には一致しないので、ＩＳＶがタイプをカスタマイズできるようにする必要がある。これは、Ｅｘｔｅｎｓｉｏｎの概念により可能になる。Ｅｘｔｅｎｓｉｏｎは、強く型付けされたインスタンス（strongly typed instances）であるが、（ａ）独立して存在することはできず、（ｂ）アイテムまたはネスト化要素に添付される必要がある。 The item type or nested element type defined by the initial set of storage platform schema does not exactly match the needs of the ISV application, so it is necessary to allow the ISV to customize the type. This is made possible by the concept of Extension. Extensions are strongly typed instances, but (a) cannot exist independently and (b) need to be attached to items or nested elements.
スキーマ拡張性のニーズに対処することに加えて、Ｅｘｔｅｎｓｉｏｎは「マルチタイピング（multi-typing）」の問題に対処することも目的としている。一部の実施例において、ストレージ・プラットフォームは、複数の継承（multiple inheritance）または重複サブタイプ（overlapping subtypes）をサポートすることができないため、アプリケーションは重複タイプ・インスタンス（たとえば、ドキュメントは法律関係書類であり、その上機密保護文書である）をモデル化する方法として、Ｅｘｔｅｎｓｉｏｎを使用することができる。 In addition to addressing the need for schema extensibility, Extension also aims to address the “multi-typing” problem. In some embodiments, the storage platform cannot support multiple inheritance or overlapping subtypes, so that the application is a duplicate type instance (eg, the document is a legal document) Extension can be used as a way to model (and is a secure document).
ａ）アイテムの拡張
アイテムの拡張性を提供するため、データ・モデルはさらに、Ｂａｓｅ．Ｅｘｔｅｎｓｉｏｎという名前の抽象タイプを定義する。これは、拡張タイプ（extension types）の階層に対するルート・タイプである。アプリケーションは、Ｂａｓｅ．Ｅｘｔｅｎｓｉｏｎをサブタイプ定義して特定の拡張タイプを作成することができる。
a) Item Extensions To provide item extensibility, the data model is further based on Base. Define an abstract type named Extension. This is the root type for the hierarchy of extension types. The application is Base. Extensions can be subtyped to create specific extension types.
Ｂａｓｅ．Ｅｘｔｅｎｓｉｏｎタイプは、以下のように基本スキーマで定義される。 Base. The Extension type is defined in the basic schema as follows.
ＩｔｅｍＩＤフィールドは、拡張が関連付けられているアイテムのＩｔｅｍＩＤを含んでいる。このＩｔｅｍＩＤを持つアイテムは、存在する必要がある。所定のＩｔｅｍＩＤを持つアイテムが存在しない場合には、拡張は作成することができない。アイテムが削除されると、同じＩｔｅｍＩＤを持つすべての拡張は削除される。このタプル（ＩｔｅｍＩＤ、ＥｘｔｅｎｓｉｏｎＩＤ）は、拡張インスタンスを一意に定義する。 The ItemID field contains the ItemID of the item with which the extension is associated. An item having this ItemID needs to exist. An extension cannot be created if there is no item with a given ItemID. When an item is deleted, all extensions with the same ItemID are deleted. This tuple (ItemID, ExtensionID) uniquely defines an extension instance.
拡張タイプの構造は、アイテム・タイプの構造と類似している。
・ 拡張タイプはフィールドを持つ。
・ フィールドは、基本またはネスト化要素タイプにすることができる。
・ 拡張タイプはサブタイプ定義することができる。
The extension type structure is similar to the item type structure.
-The extension type has a field.
• Fields can be basic or nested element types.
• Extension types can be defined as subtypes.
拡張タイプには以下の制約が適用される。
・ 拡張は、リレーションシップのソースおよびターゲットにすることができない。
・ 拡張タイプ・インスタンスは、アイテムから独立して存在することができない。また、
・拡張タイプはストレージ・プラットフォーム・タイプ定義でフィールドタイプとして使用することができない。
The following restrictions apply to extension types:
• Extensions cannot be the source and target of relationships.
Extension type instances cannot exist independently of items. Also,
• Extension types cannot be used as field types in storage platform type definitions.
所定のアイテム・タイプに関連付けることのできる拡張のタイプには、何の制約も課されない。任意の拡張タイプが、任意のアイテム・タイプを拡張することができる。複数の拡張インスタンスが１つのアイテムに添付される場合、これらは構造および振る舞いのいずれにおいても相互に独立したものになる。 There are no restrictions on the type of extension that can be associated with a given item type. Any extension type can extend any item type. When multiple extension instances are attached to an item, they are independent of each other in structure and behavior.
拡張インスタンスは、アイテムとは個別に格納され、アクセスされる。すべての拡張タイプ・インスタンスは、グローバル拡張ビューからアクセス可能である。関連付けられているアイテムのタイプにはかかわりなく、拡張の所定のタイプのインスタンスをすべて返す効率的なクエリを作成することができる。ストレージ・プラットフォームＡＰＩは、アイテムの拡張を格納し、取り出し、変更することができるプログラミング・モデルを提供する。 Extension instances are stored and accessed separately from items. All extension type instances are accessible from the global extension view. An efficient query can be created that returns all instances of a given type of extension regardless of the type of item associated with it. The storage platform API provides a programming model that can store, retrieve, and modify item extensions.
拡張タイプは、ストレージ・プラットフォームの単一継承モデルを使用してサブタイプ定義されたタイプにすることができる。拡張タイプからの派生は、新しい拡張タイプを作成する。拡張の構造または振る舞いは、アイテム・タイプ階層の構造または振る舞いをオーバーライドまたは置き換えることはできない。アイテム・タイプと同様に、Ｅｘｔｅｎｓｉｏｎタイプ・インスタンスは、拡張タイプに関連付けられているビューを通じて直接アクセスすることができる。拡張のＩｔｅｍＩＤは、属しているアイテムを示し、グローバル・アイテム・ビューから対応するアイテム・オブジェクトを取り出すために使用することができる。拡張は、オペレーション上の整合性を保つ目的で、アイテムの一部と見なされる。ストレージ・プラットフォームが定義するコピー／移動、バックアップ／復元、および他の共通の操作は、アイテムの一部として拡張に関して操作することもできる。 Extension types can be subtyped using the storage platform's single inheritance model. Deriving from an extension type creates a new extension type. The structure or behavior of the extension cannot override or replace the structure or behavior of the item type hierarchy. Similar to item types, Extension type instances can be accessed directly through the view associated with the extension type. The extension's ItemID indicates the item to which it belongs and can be used to retrieve the corresponding item object from the global item view. Extensions are considered part of an item for the purpose of maintaining operational consistency. Copy / move, backup / restore, and other common operations defined by the storage platform can also operate on extensions as part of the item.
次のような例を考察する。Ｃｏｎｔａｃｔタイプは、Ｗｉｎｄｏｗｓ（登録商標）タイプセットで定義される。 Consider the following example: The Contact type is defined in the Windows (registered trademark) type set.
ＣＲＭアプリケーション開発者は、ストレージ・プラットフォームに格納されている連絡先にＣＲＭアプリケーション拡張を添付したいと考えるであろう。アプリケーション開発者は、アプリケーションが操作できる追加のデータ構造を含むようなＣＲＭ拡張を定義するであろう。 CRM application developers will want to attach a CRM application extension to contacts stored on the storage platform. An application developer will define a CRM extension that includes additional data structures that the application can manipulate.
ＨＲアプリケーション開発者は、連絡先を持つ追加データも添付したいと考えるであろう。このデータは、ＣＲＭアプリケーションデータからは独立している。この場合も、アプリケーション開発者は拡張を作成することができる。 HR application developers will want to attach additional data with contacts. This data is independent of the CRM application data. Again, the application developer can create an extension.
ＣＲＭＥｘｔｅｎｓｉｏｎおよびＨＲＥｘｔｅｎｓｉｏｎは、Ｃｏｎｔａｃｔアイテムに添付できる２つの独立した拡張である。これらは、相互に独立して、作成され、アクセスされる。 CRMExtension and HRExtension are two independent extensions that can be attached to a Contact item. These are created and accessed independently of each other.
上記の例において、ＣＲＭＥｘｔｅｎｓｉｏｎタイプのフィールドおよびメソッドは、Ｃｏｎｔａｃｔ階層のフィールドまたはメソッドをオーバーライドすることはできない。ＣＲＭＥｘｔｅｎｓｉｏｎタイプのインスタンスは、Ｃｏｎｔａｃｔ以外のアイテム・タイプに添付できることに留意されたい。 In the above example, CRMExtension type fields and methods cannot override fields or methods in the Contact hierarchy. Note that an instance of the CRMExtension type can be attached to an item type other than Contact.
Ｃｏｎｔａｃｔアイテムが取り出されるとき、そのアイテム拡張が自動的に取り出されることはない。Ｃｏｎｔａｃｔアイテムを与えられて、その関連するアイテム拡張は、同じＩｔｅｍＩｄを持つ拡張に対してグローバル拡張ビューにクエリを行うことによってアクセスすることができる。 When a Contact item is retrieved, its item extension is not automatically retrieved. Given a Contact item, its associated item extension can be accessed by querying the global extension view for extensions with the same ItemId.
システム内のすべてのＣＲＭＥｘｔｅｎｓｉｏｎ拡張は、属しているアイテムにはかかわりなく、ＣＲＭＥｘｔｅｎｓｉｏｎタイプ・ビューを通じてアクセスすることができる。アイテムのすべてのアイテム拡張は、同じアイテムＩＤを共有する。上記の例において、Ｃｏｎｔａｃｔアイテム・インスタンスと、添付されたＣＲＭＥｘｔｅｎｓｉｏｎおよびＨＲＥｘｔｅｎｓｉｏｎインスタンスは、同じＩｔｅｍＩＤを共有する。 All CRMExtension extensions in the system can be accessed through the CRMExtension type view, regardless of the item to which it belongs. All item extensions for an item share the same item ID. In the above example, the Contact item instance and the attached CRMExtension and HRExtension instances share the same ItemID.
以下の表に、Ｉｔｅｍ、Ｅｘｔｅｎｓｉｏｎ、およびＮｅｓｔｅｄＥｌｅｍｅｎｔタイプの類似点および相違点を概要して示す。 The following table outlines the similarities and differences between the Item, Extension, and NestedElement types.
ｂ）ＮｅｓｔｅｄＥｌｅｍｅｎｔタイプの拡張
ネスト化要素タイプは、アイテム・タイプと同じメカニズムでは拡張されない。ネスト化要素の拡張は、ネスト化要素タイプのフィールドと同じメカニズムで格納され、アクセスされる。
b) Extension of the NestedElement type Nested element types are not extended by the same mechanism as item types. Nested element extensions are stored and accessed by the same mechanism as nested element type fields.
データ・モデルは、Ｅｌｅｍｅｎｔという名前のネスト化要素タイプのルートを定義する。 The data model defines the root of a nested element type named Element.
ＮｅｓｔｅｄＥｌｅｍｅｎｔタイプは、このタイプから継承する。ＮｅｓｔｅｄＥｌｅｍｅｎｔ要素タイプはさらに、要素のマルチセットであるフィールドを定義する。 The NestedElement type inherits from this type. The NestedElement element type further defines a field that is a multiset of elements.
ＮｅｓｔｅｄＥｌｅｍｅｎｔ拡張は、以下の点でアイテム拡張とは異なっている。
・ ネスト化要素拡張は、拡張タイプではない。これらは、Ｂａｓｅ．Ｅｘｔｅｎｓｉｏｎタイプにルートされる拡張タイプ階層に属していない。
・ ネスト化要素拡張は、アイテムの他のフィールドと共に格納され、グローバルにアクセス可能ではない。所定の拡張タイプのすべてのインスタンスを取り出すクエリは作成することができない。
・ これらの拡張は、（アイテムの）他のネスト化要素が格納される方法と同じ方法で格納される。他のネスト化セットと同様に、ＮｅｓｔｅｄＥｌｅｍｅｎｔ拡張はＵＤＴに格納される。これらは、ネスト化要素タイプのＥｘｔｅｎｓｉｏｎ・フィールドを通じてアクセス可能である。
・ 多値のプロパティ（multi-valued properties）にアクセスするために使用されるコレクション・インターフェースは、タイプ拡張のセットにアクセスして繰り返すためにも使用される。
The nested element extension differs from the item extension in the following points.
-Nested element extension is not an extension type. These are based on Base. It does not belong to the extension type hierarchy that is routed to the Extension type.
• Nested element extensions are stored with the other fields of the item and are not globally accessible. A query that retrieves all instances of a given extension type cannot be created.
These extensions are stored in the same way that other nested elements (of the item) are stored. As with other nested sets, the Necessary Element extension is stored in the UDT. These are accessible through the Extension field of the nested element type.
The collection interface used to access multi-valued properties is also used to access and iterate over a set of type extensions.
以下の表で、Ｉｔｅｍ拡張およびＮｅｓｔｅｄＥｌｅｍｅｎｔ拡張を概要して比較する。 The following table outlines and compares the Item and NestedElement extensions.
Ｄ．データベース・エンジン
前述のように、データ・ストアはデータベース・エンジン上に実装される。本発明の実施例において、データベース・エンジンは、オブジェクト・リレーションシップ拡張を備える、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒエンジンなどの、ＳＱＬクエリ言語を実装するリレーショナル・データベース・エンジンを備えている。このセクションでは、データ・ストアが実装するデータ・モデルのリレーショナル・ストアへのマッピングについて説明し、本発明の実施例に従って、ストレージ・プラットフォーム・クライアントによって消費される論理ＡＰＩに関する情報を提供する。ただし、異なるデータベース・エンジンが採用される場合に異なるマッピングを採用できることを理解されたい。実際、リレーショナル・データベース・エンジンにストレージ・プラットフォームの概念データ・モデルを実装することに加えて、オブジェクト指向およびＸＭＬデータベースなど、他の種類のデータベースに実装することも可能である。
D. Database Engine As mentioned above, the data store is implemented on the database engine. In an embodiment of the present invention, the database engine comprises a relational database engine that implements the SQL query language, such as the Microsoft SQL Server engine with object relationship extensions. This section describes the mapping of the data model implemented by the data store to a relational store and provides information regarding the logical API consumed by the storage platform client, in accordance with an embodiment of the present invention. However, it should be understood that different mappings can be employed when different database engines are employed. Indeed, in addition to implementing the storage platform conceptual data model in a relational database engine, it can also be implemented in other types of databases, such as object-oriented and XML databases.
オブジェクト指向（ＯＯ）データベース・システムは、プログラミング言語オブジェクト（たとえばＣ＋＋、Ｊａｖａ（登録商標）など）の永続性（persistence）およびトランザクションを提供する。ストレージ・プラットフォームの「アイテム」の概念は、埋め込みコレクションをオブジェクトに追加する必要があるけれども、オブジェクト指向システムにおける「オブジェクト」に適切に対応する。他のストレージ・プラットフォームの概念は、継承およびネスト化要素タイプと同様に、オブジェクト指向タイプのシステムにも対応する。オブジェクト指向システムは通常、既にオブジェクトＩＤをサポートしており、したがって、アイテムＩＤはオブジェクトＩＤにマップすることができる。アイテムの振る舞い（operations）は、オブジェクト・メソッドに適切に対応する。しかし、オブジェクト指向システムは通常、組織的な能力に欠けており、検索機能も劣っている。また、オブジェクト指向システムは、構造化されていない半構造のデータにサポートを提供しない。本明細書に説明する完全なストレージ・プラットフォーム・データ・モデルをサポートするために、リレーションシップ、フォルダ、および拡張などの概念をオブジェクト・データ・モデルに追加する必要がある。さらに、格上げ（promotions）、同期化、通知、およびセキュリティなどのメカニズムも実装する必要がある。 Object oriented (OO) database systems provide persistence and transactions for programming language objects (eg, C ++, Java, etc.). The storage platform “item” concept appropriately corresponds to an “object” in an object-oriented system, although an embedded collection needs to be added to the object. Other storage platform concepts address object-oriented systems as well as inheritance and nested element types. Object-oriented systems usually already support object IDs, so item IDs can be mapped to object IDs. Item behaviors correspond appropriately to object methods. However, object-oriented systems usually lack organizational capabilities and have poor search capabilities. Also, object oriented systems do not provide support for unstructured semi-structured data. In order to support the complete storage platform data model described herein, concepts such as relationships, folders, and extensions need to be added to the object data model. In addition, mechanisms such as promotions, synchronization, notifications, and security need to be implemented.
オブジェクト指向システムと同様に、ＸＳＤ（ＸＭＬスキーマ定義）に基づくＸＭＬデータベースは、単一継承ベースのタイプ・システム（single-inheritance based type system）をサポートする。本発明のアイテム・タイプ・システムは、ＸＳＤタイプモデルにマップすることもできる。ＸＳＤもまた、振る舞いへのサポートを提供しない。アイテム用のＸＳＤは、アイテムの振る舞いに対して増強される必要がある。ＸＭＬデータベースは単一のＸＳＤドキュメントを扱い、組織化および広範な検索能力が不足している。オブジェクト指向データベースの場合と同様に、本明細書に説明するデータ・モデルをサポートするため、リレーションシップなどの他の概念、およびフォルダはそのようなＸＭＬデータベースに組み込まれる必要がある。さらに、同期化、通知およびセキュリティのようなメカニズムも実装される必要がある。 Similar to object-oriented systems, XML databases based on XSD (XML Schema Definition) support a single-inheritance based type system. The item type system of the present invention can also be mapped to an XSD type model. XSD also does not provide support for behavior. The XSD for an item needs to be enhanced for the item's behavior. The XML database handles a single XSD document and lacks organization and extensive search capabilities. As with object-oriented databases, other concepts such as relationships and folders need to be incorporated into such XML databases to support the data model described herein. In addition, mechanisms such as synchronization, notification and security need to be implemented.
以下のサブセクションに関して、一般情報の開示を容易にするためにいくつかの図が示される。図１３は、通知メカニズムを示す図である。図１４は、２つのトランザクションが共に新しいレコードを同じＢツリーに挿入する例を示す図である。図１５は、データ変更検出プロセスを示す図である。図１６は、例示的なディレクトリ・ツリーを示す図である。図１７は、ディレクトリ・ベースのファイル・システムの既存フォルダがストレージ・プラットフォームのデータ・ストアに移動される例を示す図である。 For the following subsections, several figures are shown to facilitate disclosure of general information. FIG. 13 is a diagram illustrating a notification mechanism. FIG. 14 is a diagram illustrating an example in which two transactions both insert a new record into the same B-tree. FIG. 15 is a diagram illustrating a data change detection process. FIG. 16 is a diagram illustrating an exemplary directory tree. FIG. 17 is a diagram illustrating an example in which an existing folder of a directory-based file system is moved to a storage platform data store.
１．ＵＤＴ（ユーザ定義タイプ）を使用するデータ・ストアの実装
本発明の実施例において、リレーショナル・データベース・エンジン３１４は、１つの実施例でＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒエンジンを備えており、組み込みスカラ・タイプをサポートする。組み込みスカラ・タイプは、「ネイティブ」でしかも「単純（simple）」である。これは、ユーザが独自のタイプを定義できないという意味でネイティブであり、複雑な構造をカプセル化できないという点で単純である。ユーザ定義タイプ（User-defined types）（以下ＵＤＴと呼ぶ）は、複雑な構造化タイプを定義してユーザがタイプ・システムを拡張できるようにすることによって、ネイティブのスカラ・タイプ・システムを超えるタイプ拡張性のメカニズムを提供する。ユーザによって定義されると、ＵＤＴは、組み込みスカラ・タイプが使用されるタイプ・システム内のどこでも使用することができる。
1. Data Store Implementation Using UDT (User Defined Type) In an embodiment of the present invention, the relational database engine 314, in one embodiment, includes the Microsoft SQL Server engine and supports built-in scalar types. . The built-in scalar type is “native” and “simple”. This is simple in that users are native in the sense that they cannot define their own types, and complex structures cannot be encapsulated. User-defined types (hereinafter referred to as UDTs) are types that go beyond the native scalar type system by allowing users to extend the type system by defining complex structured types. Provides an extensibility mechanism. Once defined by the user, the UDT can be used anywhere in the type system where built-in scalar types are used.
本発明の態様によれば、ストレージ・プラットフォーム・スキーマは、データベース・エンジン・ストア内のＵＤＴクラスにマップされる。データ・ストア・アイテムは、Ｂａｓｅ．Ｉｔｅｍタイプから派生するＵＤＴクラスにマップされる。アイテムと同様に、ＥｘｔｅｎｓｉｏｎはＵＤＴクラスにもマップされ、継承を利用する。ルートＥｘｔｅｎｓｉｏｎタイプはＢａｓｅ．Ｅｘｔｅｎｓｉｏｎであり、これからすべてのＥｘｔｅｎｓｉｏｎタイプが派生する。 In accordance with aspects of the invention, the storage platform schema is mapped to UDT classes in the database engine store. The data store item is Base. Maps to a UDT class derived from the Item type. Like items, Extensions are also mapped to UDT classes and use inheritance. The root extension type is Base. Extension, from which all Extension types are derived.
ＵＤＴはＣＬＲクラスである。これは状態（データ・フィールドなど）および振る舞い（ルーチンなど）を備えている。ＵＤＴは、Ｃ＃、ＶＢ．ＮＥＴなど、管理下の言語を使用して定義される。ＵＤＴメソッドおよび演算子は、そのタイプのインスタンスに対してＴ−ＳＱＬで呼び出すことができる。ＵＤＴは、行（rows）内のカラムのタイプ、Ｔ−ＳＱＬ内のルーチンのパラメータのタイプ、またはＴ−ＳＱＬ内の変数のタイプのいずれかにできる。 UDT is a CLR class. It has state (such as data fields) and behavior (such as routines). UDT is C #, VB. Defined using a managed language, such as NET. UDT methods and operators can be called in T-SQL for instances of that type. The UDT can be either the type of a column in rows, the type of a routine parameter in T-SQL, or the type of a variable in T-SQL.
ストレージ・プラットフォームのスキーマのＵＤＴクラスへのマッピングは、高レベルにおいてかなり直接的である。一般に、ストレージ・プラットフォーム・スキーマはＣＬＲネーム・スペースにマップされる。ストレージ・プラットフォーム・タイプは、ＣＬＲクラスにマップされる。ＣＬＲクラス継承は、ストレージ・プラットフォーム・タイプ継承をミラーリングし、ストレージ・プラットフォーム・プロパティはＣＬＲクラス・プロパティにマップされる。 The mapping of the storage platform schema to the UDT class is fairly straightforward at a high level. In general, the storage platform schema is mapped to the CLR namespace. The storage platform type is mapped to the CLR class. CLR class inheritance mirrors storage platform type inheritance, and storage platform properties are mapped to CLR class properties.
２．アイテムのマッピング
アイテムがグローバルに検索可能であることの望ましさ、および本発明の実施例のリレーショナル・データベースにおける継承およびタイプ代替性のサポートを考慮すれば、データベース・ストアにおけるアイテムストレージの１つの可能な実施態様は、すべてのアイテムをタイプＢａｓｅ．Ｉｔｅｍのカラムを持つ単一のテーブルに格納することになる。タイプ代替性を使用して、すべてのタイプのアイテムは格納することができ、検索はＹｕｋｏｎの「ｉｓ ｏｆ（Ｔｙｐｅ）」演算子を使用して、アイテム・タイプおよびサブタイプによってフィルタすることができる。
2. Item Mapping One possible item storage in the database store given the desirability of the item being globally searchable and the support of inheritance and type substitutability in the relational database of embodiments of the present invention. Embodiments include all items of type Base. It is stored in a single table having Item columns. Using type substitutability, all types of items can be stored, and searches can be filtered by item type and subtype using Yukon's “is of (Type)” operator. .
しかし、そのような方法に関連付けられるオーバーヘッドの懸念のために、本発明の実施例においては、アイテムは、各タイプのアイテム「ｆａｍｉｌｙ」が別々のテーブルに格納されるように、最上位タイプによって分割される。この区分化方式のもとで、テーブルはＢａｓｅ．Ｉｔｅｍから直接に継承するアイテム・タイプごとに作成される。これらより下位で継承するタイプは、前述のタイプ代替性を使用して適切なタイプ・ファミリ・テーブルに格納される。Ｂａｓｅ．Ｉｔｅｍからの継承の第１レベルのみが、特別に処理される。 However, because of the overhead concerns associated with such methods, in embodiments of the present invention, items are divided by top-level type so that each type of item “family” is stored in a separate table. Is done. Under this partitioning scheme, the table is Base. Created for each item type that inherits directly from an Item. Types inheriting below these are stored in the appropriate type family table using the type substitutability described above. Base. Only the first level of inheritance from Item is handled specially.
「シャドー」テーブルは、すべてのアイテムのグローバルに検索可能なプロパティのコピーを格納するために使用される。このテーブルは、ストレージ・プラットフォームＡＰＩのＵｐｄａｔｅ（）メソッドによって保持され、これを通じてすべてのデータ変更が行われる。タイプ・ファミリ・テーブルとは異なり、このグローバルなアイテム・テーブルは、完全なＵＤＴアイテム・オブジェクトではなく、アイテムの最上位スカラ・プロパティのみを含んでいる。このグローバルなアイテム・テーブルは、ＩｔｅｍＩＤおよびＴｙｐｅＩＤを公開することによってタイプ・ファミリ・テーブルに格納されているアイテム・オブジェクトへのナビゲーションを可能にする。ＩｔｅｍＩＤは一般に、データ・ストア内のアイテムを一意に識別する。ＴｙｐｅＩＤはメタデータを使用してタイプ名、およびアイテムを含むビューにマップすることができるが、このことについては本明細書では説明しない。アイテムをそのＩｔｅｍＩＤによって見つけることは、グローバルなアイテム・テーブルおよびその他のコンテクストにおいて、一般的なオペレーションであるため、ＧｅｔＩｔｅｍ（）関数が、アイテムのＩｔｅｍＩＤを与えられたアイテム・オブジェクトを取り出すために提供される。 The “shadow” table is used to store a globally searchable copy of the properties of all items. This table is maintained by the Update () method of the storage platform API, through which all data changes are made. Unlike the type family table, this global item table is not a full UDT item object, but contains only the top-level scalar properties of the item. This global item table allows navigation to item objects stored in the type family table by exposing ItemID and TypeID. An ItemID typically uniquely identifies an item in a data store. TypeIDs can be mapped to type names and views containing items using metadata, but this is not described here. Because finding an item by its ItemID is a common operation in the global item table and other contexts, the GetItem () function is provided to retrieve an item object given the item's ItemID. The
アクセスを便利にするため、また実施態様の詳細を可能な範囲内で秘匿するため、アイテムのすべてのクエリは前述のアイテム・テーブルを基に構築したビューに対するものにできる。特に、ビューは、適切なタイプ・ファミリ・テーブルに対してアイテム・タイプごとに作成することができる。これらのタイプ・ビューは、サブタイプを含む関連するタイプのすべてのアイテムを選択することができる。便宜上、ＵＤＴオブジェクトに加えて、ビューは、継承されたフィールドを含むそのタイプの最上位のフィールドすべてのカラムを公開する（見えるようにする）ことができる。 For convenience of access and to keep implementation details as confidential as possible, all queries for items can be for views built on the item table described above. In particular, a view can be created for each item type against the appropriate type family table. These type views can select all items of related types, including subtypes. For convenience, in addition to the UDT object, the view can expose (make visible) the columns of all top-level fields of that type, including inherited fields.
３．拡張のマッピング
Ｅｘｔｅｎｓｉｏｎは、アイテムと非常によく似ており、同じ要件をいくつか備えている。継承をサポートするもう１つのルート・タイプとして、Ｅｘｔｅｎｓｉｏｎは、ストレージにおける多くの同じ考慮事項およびトレードオフの影響を受けやすい。そのため、単一テーブルの方法ではなく、類似するファミリ・マッピングのタイプが、Ｅｘｔｅｎｓｉｏｎに適用される。もちろん、他の実施例において、単一テーブルの方法を使用することもできる。本発明の実施例において、ＥｘｔｅｎｓｉｏｎはＩｔｅｍＩＤにより厳密に１つのアイテムに関連付けられており、アイテムのコンテクストで一意のＥｘｔｅｎｓｉｏｎＩＤを含んでいる。アイテムの場合と同様に、その識別を与えられたＥｘｔｅｎｓｉｏｎを取り出すために関数が提供される。これはＩｔｅｍＩＤおよびＥｘｔｅｎｓｉｏｎＩＤのペアで構成される。ビューは、Ｅｘｔｅｎｓｉｏｎタイプごとに作成される。これはアイテム・タイプ・ビューと類似している。
3. Extension mapping Extensions are very similar to items and have some of the same requirements. As another route type that supports inheritance, Extension is susceptible to many of the same considerations and trade-offs in storage. Therefore, similar family mapping types apply to Extensions rather than single table methods. Of course, in other embodiments, a single table method may be used. In an embodiment of the present invention, the Extension is associated with exactly one item by ItemID and includes a unique ExtensionID in the context of the item. As with an item, a function is provided to retrieve an Extension given its identity. This consists of a pair of ItemID and ExtensionID. A view is created for each Extension type. This is similar to the item type view.
４．ネスト化要素（Nested Element）のマッピング
ネスト化要素は、アイテム、Ｅｘｔｅｎｓｉｏｎ、リレーションシップ、または深くネストされた構造を形成するために他のネスト化要素に埋め込まれることができるタイプである。アイテムおよびＥｘｔｅｎｓｉｏｎと同様に、ネスト化要素はＵＤＴとして実装されるが、これらはアイテムおよびＥｘｔｅｎｓｉｏｎ内に格納される。したがってネスト化要素は、そのアイテムおよびＥｘｔｅｎｓｉｏｎのコンテナを超えるストレージ・マッピングは備えていない。つまり、ＮｅｓｔｅｄＥｌｅｍｅｎｔタイプのインスタンスを直接格納する、システム内のテーブルはなく、ネスト化要素に特に専用化されたビューもない。
4). Nested Element Mapping Nested elements are types that can be embedded in other nested elements to form items, extensions, relationships, or deeply nested structures. Similar to items and extensions, nested elements are implemented as UDTs, but they are stored within items and extensions. Thus, a nested element does not have a storage mapping beyond its item and extension containers. That is, there is no table in the system that directly stores instances of the NestedElement type, and there is no view specifically dedicated to nested elements.
５．オブジェクトのＩＤ｝（identity）
データ・モデル内の各エンティティ、つまり各アイテム、Ｅｘｔｅｎｓｉｏｎ、およびリレーションシップは、一意のキー値（key value）を持っている。アイテムは、そのＩｔｅｍＩｄによって一意に識別される。Ｅｘｔｅｎｓｉｏｎは、（ＩｔｅｍＩｄ、ＥｘｔｅｎｓｉｏｎＩｄ）の複合キーによって一意に識別される。リレーションシップは、（ＩｔｅｍＩｄ、ＲｅｌａｔｉｏｎｓｈｉｐＩｄ）の複合キーによって一意に識別される。ＩｔｅｍＩｄ、ＥｘｔｅｎｓｉｏｎＩｄ、およびＲｅｌａｔｉｏｎｓｈｉｐＩｄは、ＧＵＩＤ値である。
5. Object ID} (identity)
Each entity in the data model, i.e., each item, extension, and relationship, has a unique key value. An item is uniquely identified by its ItemId. The Extension is uniquely identified by a composite key of (ItemId, ExtensionId). The relationship is uniquely identified by a composite key of (ItemId, RelationshipId). ItemId, ExtensionId, and RelationshipId are GUID values.
６．ＳＱＬオブジェクトの命名
データ・ストアで作成されたすべてのオブジェクトは、ストレージ・プラットフォーム・スキーマ名から派生したＳＱＬスキーマ名で格納することができる。たとえば、ストレージ・プラットフォーム基本スキーマ（多くは「Ｂａｓｅ」と呼ばれる）は、「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．Ｉｔｅｍ」などの「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］」ＳＱＬスキーマでタイプを生成することができる。生成される名前には、命名上の競合をなくすために先頭に修飾子が付けられる。必要に応じて、名前の各論理部分の区切り記号として感嘆符文字（！）が使用される。以下の表は、データ・ストア内のオブジェクトに使用される命名規則の概要を示している。各スキーマ要素（アイテム、Ｅｘｔｅｎｓｉｏｎ、リレーションシップおよびビュー）は、データ・ストア内のインスタンスにアクセスするために使用される装飾された命名規則と共に一覧されている。
6). SQL Object Naming All objects created in the data store can be stored with a SQL schema name derived from the storage platform schema name. For example, a storage platform base schema (often referred to as “Base”) may generate types in a “[System.Storage]” SQL schema, such as “[System.Storage] .Item”. Generated names are prefixed with a qualifier to eliminate naming conflicts. If necessary, an exclamation point character (!) Is used as a separator for each logical part of the name. The following table outlines the naming convention used for objects in the data store. Each schema element (item, extension, relationship and view) is listed with a decorated naming convention used to access instances in the data store.
７．カラムの命名
オブジェクト・モデルをストア内にマッピングするとき、アプリケーション・オブジェクトと共に格納される追加情報が原因となり、命名の衝突が発生する可能性がある。命名の衝突を防ぐために、すべての非タイプの特定のカラム（non-type specific columns）（タイプ宣言における名前付きプロパティに直接マップされないカラム）には、下線（＿）文字が先頭に付けられる。本発明の実施例において、下線（＿）文字は、識別子プロパティの開始文字としては許可されない。さらに、ＣＬＲおよびデータ・ストアの間の命名を統一するため、ストレージ・プラットフォーム・タイプまたはスキーマ要素（リレーションシップなど）のすべてのプロパティは、最初の文字を大文字にする必要がある。
7). Column Naming When mapping an object model in the store, additional information stored with the application object can cause naming conflicts. To prevent naming conflicts, all non-type specific columns (columns that do not map directly to named properties in the type declaration) are prefixed with an underscore (_) character. In an embodiment of the present invention, the underscore (_) character is not allowed as the start character of the identifier property. In addition, all properties of a storage platform type or schema element (such as relationships) need to capitalize the first letter in order to unify naming between CLRs and data stores.
８．検索ビュー
ビューは、格納されているコンテンツを検索するためにストレージ・プラットフォームによって提供される。ＳＱＬビューは、アイテムおよびＥｘｔｅｎｓｉｏｎタイプごとに提供される。さらに、ビューは、リレーションシップおよび（データ・モデルによって定義される）Ｖｉｅｗをサポートするために提供される。ストレージ・プラットフォーム内のすべてのＳＱＬビューと基礎をなすテーブルは、読み取り専用である。データは、以下でさらに詳細に説明するように、ストレージ・プラットフォームＡＰＩのＵｐｄａｔｅ（）メソッドを使用して格納または変更することができる。
8). Search view A view is provided by the storage platform to search stored content. SQL views are provided for each item and extension type. In addition, views are provided to support relationships and views (defined by the data model). All SQL views and underlying tables in the storage platform are read-only. Data can be stored or modified using the Update () method of the storage platform API, as described in more detail below.
ストレージ・プラットフォーム・スキーマ（スキーマ設計者によって定義されるもので、ストレージ・プラットフォームによって自動的に生成されない）で明示的に定義された各ビューは、名前付きＳＱＬビュー［＜ｓｃｈｅｍａ−ｎａｍｅ＞］．［Ｖｉｅｗ！＜ｖｉｅｗ−ｎａｍｅ＞］によってアクセスすることができる。たとえば、スキーマ「ＡｃｍｅＰｕｂｌｉｓｈｅｒ．Ｂｏｏｋｓ」内の「ＢｏｏｋＳａｌｅｓ」という名前のビューは、「［ＡｃｍｅＰｕｂｌｉｓｈｅｒ．Ｂｏｏｋｓ］．［Ｖｉｅｗ！ＢｏｏｋＳａｌｅｓ］」という名前を使用してアクセス可能である。ビューの出力フォーマットはビュー単位ベースのカスタムである（ビューを定義する当事者が提供する任意のクエリによって定義される）ため、カラムはスキーマ・ビュー定義に基づいて直接マップされる。 Each view explicitly defined in the storage platform schema (defined by the schema designer and not automatically generated by the storage platform) is a named SQL view [<schema-name>]. [View! It can be accessed by <view-name>]. For example, a view named “BookSales” in the schema “AcmePublisher.Books” is accessible using the name “[AcmePublisher.Books]. [View! BookSales]”. Because the view output format is custom per view (defined by any query provided by the party defining the view), the columns are mapped directly based on the schema view definition.
ストレージ・プラットフォーム・データ・ストア内のすべてのＳＱＬ検索ビューは、カラムに対して以下の順序付けの規則を使用する。
・ ＩｔｅｍＩｄ、ＥｌｅｍｅｎｔＩｄ、ＲｅｌａｔｉｏｎｓｈｉｐＩｄなどのビュー結果の論理「Ｋｅｙ」カラム
・ ＴｙｐｅＩｄなどの結果のタイプに関するメタデータ情報
・ Ｃｒｅａｔｅ Ｖｅｒｓｉｏｎ、Ｕｐｄａｔｅ Ｖｅｒｓｉｏｎなどの変更追跡カラム
・ タイプ固有のカラム（宣言済みタイプのプロパティ）
・ タイプ固有のビュー（ファミリ・ビュー）はオブジェクトを返すオブジェクト・カラムも含む
各タイプ・ファミリのメンバは、一連のアイテム・ビューを使用して検索可能であり、データ・ストア内のアイテム・タイプごとに１つのビューがある。図２８は、アイテム検索ビューの概念を示す図である。
All SQL search views in the storage platform data store use the following ordering rules for columns:
• Logical “Key” column for view results such as ItemId, ElementId, RelationshipId, etc.
Metadata information about the result type, such as TypeId
-Change tracking columns such as Create Version and Update Version
-Type-specific columns (declared type properties)
• Type-specific views (family views) also include object columns that return objects. Each type family member can be searched using a set of item views, per item type in the data store Has one view. FIG. 28 is a diagram showing the concept of the item search view.
ａ）アイテム
各アイテム検索ビューは、固有のタイプまたはそのサブタイプのアイテムのインスタンスごとに行（row）を含んでいる。たとえば、Ｄｏｃｕｍｅｎｔのビューは、Ｄｏｃｕｍｅｎｔ、ＬｅｇａｌＤｏｃｕｍｅｎｔおよびＲｅｖｉｅｗＤｏｃｕｍｅｎｔのインスタンスを返すことができる。この例を上げると、アイテム・ビューは図２９に示されているように概念的に説明することができる。
a) Items Each item search view includes a row for each instance of an item of a unique type or its subtype. For example, a Document view can return instances of Document, LegalDocument, and ReviewDocument. Taking this example, the item view can be conceptualized as shown in FIG.
（１）マスタ・アイテム検索ビュー
ストレージ・プラットフォーム・データ・ストアの各インスタンスは、マスタ・アイテム・ビューと呼ばれる特殊なアイテム・ビューを定義する。このビューは、データ・ストア内の各アイテムに関する概要情報を提供する。ビューは、アイテム・タイプ・プロパティごとに１つのカラム、アイテムのタイプを記述するカラム、および変更追跡と同期化情報を提供するために使用される複数のカラムを提供する。マスタ・アイテム・ビューは、名前「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．［Ｍａｓｔｅｒ！Ｉｔｅｍ］」を使用してデータ・ストア内で識別される。
(1) Master Item Search View Each instance of the storage platform data store defines a special item view called a master item view. This view provides summary information about each item in the data store. The view provides one column for each item type property, a column that describes the type of item, and multiple columns that are used to provide change tracking and synchronization information. The master item view is identified in the data store using the name “[System.Storage]. [Master! Item]”.
（２）タイプ定義済みアイテム検索ビュー
各アイテム・タイプも検索ビューを備えている。ルート・アイテム・ビューと類似しているが、このビューは「＿Ｉｔｅｍ」カラムを介してアイテム・オブジェクトへのアクセスも提供する。各タイプ定義済みアイテム検索ビューは、名前［ｓｃｈｅｍａＮａｍｅ］．［ｉｔｅｍＴｙｐｅＮａｍｅ］を使用してデータ・ストア内で識別される。たとえば、［ＡｃｍｅＣｏｒｐ．Ｄｏｃ］．［ＯｆｆｉｃｅＤｏｃ］である。
(2) Type-defined item search view Each item type also has a search view. Similar to the root item view, but this view also provides access to the item object via the “_Item” column. Each type-defined item search view has a name [schemaName]. Identified in the data store using [itemTypeName]. For example, [Acme Corp. Doc]. [OfficeDoc].
ｂ）アイテムＥｘｔｅｎｓｉｏｎ
ＷｉｎＦＳ ＳｔｏｒｅにおけるすべてのアイテムＥｘｔｅｎｓｉｏｎは、検索ビューを使用してもアクセス可能である。
b) Item Extension
All item extensions in the WinFS Store are also accessible using the search view.
（１）マスタＥｘｔｅｎｓｉｏｎ検索ビュー
データ・ストアの各インスタンスは、「マスタＥｘｔｅｎｓｉｏｎビュー」と呼ばれる特殊Ｅｘｔｅｎｓｉｏｎビューを定義する。このビューは、データ・ストア内の各Ｅｘｔｅｎｓｉｏｎに関する概要情報を提供する。ビューは、Ｅｘｔｅｎｓｉｏｎプロパティごとに１つのカラム、Ｅｘｔｅｎｓｉｏｎのタイプを記述するカラム、および変更追跡と同期化情報を提供するために使用される複数のカラムを備えている。マスタ拡張ビューは、名前「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．［Ｍａｓｔｅｒ！Ｅｘｔｅｎｓｉｏｎ］」を使用してデータ・ストア内で識別される。
(1) Master Extension Search View Each instance of the data store defines a special Extension view called “Master Extension View”. This view provides summary information about each Extension in the data store. The view has one column for each Extension property, a column that describes the type of Extension, and multiple columns that are used to provide change tracking and synchronization information. The master extended view is identified in the data store using the name “[System.Storage]. [Master! Extension]”.
（２）タイプ定義済みＥｘｔｅｎｓｉｏｎ検索ビュー
各Ｅｘｔｅｎｓｉｏｎタイプも検索ビューを備えている。マスタ拡張ビューと類似しているが、このビューはＥｘｔｅｎｓｉｏｎカラムを介してアイテム・オブジェクトへのアクセスも提供する。各タイプ定義済み拡張検索ビューは、名前［ｓｃｈｅｍａＮａｍｅ］．［Ｅｘｔｅｎｓｉｏｎ！ｅｘｔｅｎｓｉｏｎＴｙｐｅＮａｍｅ］を使用してデータ・ストア内で識別される。たとえば、［ＡｃｍｅＣｏｒｐ．Ｄｏｃ］．［Ｅｘｔｅｎｓｉｏｎ！ＯｆｆｉｃｅＤｏｃＥｘｔ］である。
(2) Type-defined Extension Search View Each Extension type also has a search view. Similar to the master extension view, this view also provides access to the item object via the Extension column. Each type-defined extended search view has the name [schemaName]. [Extension! It is identified in the data store using extensionTypeName]. For example, [Acme Corp. Doc]. [Extension! OfficeDocExt].
ｃ）ネスト化要素
すべてのネスト化要素は、アイテム、Ｅｘｔｅｎｓｉｏｎまたはリレーションシップ・インスタンス内に格納される。したがって、これらは、適切なアイテム、Ｅｘｔｅｎｓｉｏｎ、またはリレーションシップ検索ビューにクエリを行うことによりアクセスできる。
c) Nested elements All nested elements are stored in items, extensions or relationship instances. Thus, they can be accessed by querying the appropriate item, extension, or relationship search view.
ｄ）リレーションシップ
前述のように、リレーションシップはストレージ・プラットフォーム・データ・ストア内のアイテム間をリンクする基本単位を形成する。
d) Relationships As mentioned above, relationships form the basic unit that links items in the storage platform data store.
（１）マスタ・リレーションシップ検索ビュー
各データ・ストアは、マスタ・リレーションシップ・ビューを提供する。このビューは、データ・ストア内のすべてのリレーションシップ・インスタンスに関する情報を提供する。マスタ・リレーションシップ・ビューは、名前「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．［Ｍａｓｔｅｒ！Ｒｅｌａｔｉｏｎｓｈｉｐ］」を使用してデータ・ストア内で識別される。
(1) Master Relationship Search View Each data store provides a master relationship view. This view provides information about all relationship instances in the data store. The master relationship view is identified in the data store using the name “[System.Storage]. [Master! Relationship]”.
（２）リレーションシップ・インスタンス拡張検索ビュー
各宣言済みリレーションシップは、特定のリレーションシップのすべてのインスタンスを返す検索ビューも備えている。マスタ・リレーションシップ・ビューと類似しているが、このビューはリレーションシップ・データのプロパティごとに名前付きカラムも提供する。各リレーションシップ・インスタンス検索ビューは、名前［ｓｃｈｅｍａＮａｍｅ］．［Ｒｅｌａｔｉｏｎｓｈｉｐ！ｒｅｌａｔｉｏｎｓｈｉｐＮａｍｅ］を使用してデータ・ストア内で識別される。たとえば、［ＡｃｍｅＣｏｒｐ．Ｄｏｃ］．［Ｒｅｌａｔｉｏｎｓｈｉｐ！ＤｏｃｕｍｅｎｔＡｕｔｈｏｒ］である。
(2) Relationship Instance Extended Search View Each declared relationship also has a search view that returns all instances of a specific relationship. Similar to the master relationship view, but this view also provides a named column for each property in the relationship data. Each relationship instance search view has a name [schemaName]. [Relationship! relationName] is identified in the data store. For example, [Acme Corp. Doc]. [Relationship! DocumentAuthor].
ｅ）
９．更新
ストレージ・プラットフォーム・データ・ストア内のすべてのビューは、読み取り専用である。データ・モデル要素（アイテム、Ｅｘｔｅｎｓｉｏｎまたはリレーションシップ）の新しいインスタンスを作成するため、または既存のインスタンスを更新するため、ストレージ・プラットフォームＡＰＩのＰｒｏｃｅｓｓＯｐｅｒａｔｉｏｎまたはＰｒｏｃｅｓｓＵｐｄａｔｅｇｒａｍメソッドを使用する必要がある。ＰｒｏｃｅｓｓＯｐｅｒａｔｉｏｎメソッドは、データ・ストアによって定義される単一のストアド・プロシージャであり、これは、実行すべきアクションを詳述する「ｏｐｅｒａｔｉｏｎ」を消費する。ＰｒｏｃｅｓｓＵｐｄａｔｅｇｒａｍメソッドは、「ｕｐｄａｔｅｇｒａｍ」として知られるオペレーションの順序付きセットを取り込むストアド・プロシージャであり、これは、実行すべきアクションのセットを一括して詳述する。
e)
9. Update All views in the storage platform data store are read-only. In order to create a new instance of a data model element (item, extension or relationship) or to update an existing instance, it is necessary to use the ProcessOperation or ProcessUpdategram method of the storage platform API. The ProcessOperation method is a single stored procedure defined by the data store that consumes an “operation” detailing the action to be performed. The ProcessUpdategram method is a stored procedure that captures an ordered set of operations known as “updategram”, which details the set of actions to be performed in a batch.
オペレーション・フォーマットは、拡張可能であり、スキーマ要素に対してさまざまなオペレーションを提供する。共通のオペレーションには次のようなものがある。
１．アイテムのオペレーション：
ａ．ＣｒｅａｔｅＩｔｅｍ（埋め込みまたは保持リレーションシップのコンテクストで新しいアイテムを作成する）
ｂ．ＵｐｄａｔｅＩｔｅｍ（既存のアイテムを更新する）
２．リレーションシップのオペレーション：
ａ．ＣｒｅａｔｅＲｅｌａｔｉｏｎｓｈｉｐ（参照または保持リレーションシップのインスタンスを作成する）
ｂ．ＵｐｄａｔｅＲｅｌａｔｉｏｎｓｈｉｐ（リレーションシップ・インスタンスを更新する）
ｃ．ＤｅｌｅｔｅＲｅｌａｔｉｏｎｓｈｉｐ（リレーションシップ・インスタンスを削除する）
３．Ｅｘｔｅｎｓｉｏｎのオペレーション：
ａ．ＣｒｅａｔｅＥｘｔｅｎｓｉｏｎ（既存のアイテムに拡張を追加する）
ｂ．ＵｐｄａｔｅＥｘｔｅｎｓｉｏｎ（既存の拡張を更新する）
ｃ．ＤｅｌｅｔｅＥｘｔｅｎｓｉｏｎ（拡張を削除する）
The operation format is extensible and provides various operations on schema elements. Common operations include the following:
1. Item operations:
a. CreateItem (creates a new item in the context of an embedded or retained relationship)
b. UpdateItem (updates an existing item)
2. Relationship operations:
a. CreateRelationship (creates an instance of a reference or retention relationship)
b. UpdateRelationship (update relationship instance)
c. DeleteRelationship (deletes a relationship instance)
3. Extension operations:
a. CreateExtension (adds an extension to an existing item)
b. UpdateExtension (updates an existing extension)
c. DeleteExtension (delete extension)
１０．変更追跡およびトゥームストーン
変更追跡およびトゥームストーン・サービスは、データ・ストアによって提供されるが、これについては以下でさらに詳細に説明する。このセクションでは、データ・ストア内で公開される変更追跡情報の概要について説明する。
10. Change Tracking and Tombstone Change tracking and tombstone services are provided by the data store and are described in more detail below. This section provides an overview of the change tracking information published in the data store.
ａ）変更追跡
データ・ストアが提供す各検索ビューは、変更追跡情報を提供するために使用されるカラムを含んでいる。このカラムは、すべてのアイテム、Ｅｘｔｅｎｓｉｏｎおよびリレーションシップ・ビューにわたり共通である。スキーマ設計者によって明示的に定義されるストレージ・プラットフォーム・スキーマ・ビューは、変更追跡情報を自動的には提供しない。そのような情報は、ビューそのものが構築される検索ビューを通じて間接的に提供される。
a) Change Tracking Each search view provided by the data store includes a column that is used to provide change tracking information. This column is common across all items, extensions, and relationship views. Storage platform schema views that are explicitly defined by the schema designer do not automatically provide change tracking information. Such information is provided indirectly through a search view in which the view itself is constructed.
データ・ストア内の要素ごとに、変更追跡情報は、「マスタ」要素ビューおよび「タイプ定義済み」要素ビューという２つの場所から提供される。たとえば、ＡｃｍｅＣｏｒｐ．Ｄｏｃｕｍｅｎｔ．Ｄｏｃｕｍｅｎｔ Ｉｔｅｍタイプに関する変更追跡情報は、マスタ・アイテム・ビュー「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．［Ｍａｓｔｅｒ！Ｉｔｅｍ］」およびタイプ定義済みアイテム検索ビュー［ＡｃｍｅＣｏｒｐ．Ｄｏｃｕｍｅｎｔ］．［Ｄｏｃｕｍｅｎｔ］から利用可能である。 For each element in the data store, change tracking information is provided from two locations: a “master” element view and a “type defined” element view. For example, Acme Corp. Document. Change tracking information for the Document Item type includes the master item view “[System.Storage]. [Master! Item]” and the type-defined item search view [AcmeCorp. Document]. Available from [Document].
（１）「マスタ」検索ビューの変更追跡
マスタ検索ビューの変更追跡情報は、要素の作成および更新バージョンに関する情報、要素を作成した同期パートナ、要素を最終更新した同期パートナに関する情報、および作成と更新に対する各パートナからのバージョン番号を提供する。同期リレーションシップ（以下で説明）のパートナは、パートナキーによって識別される。タイプ［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｓｔｏｒｅ］．ＣｈａｎｇｅＴｒａｃｋｉｎｇＩｎｆｏのＣｈａｎｇｅＴｒａｃｋｉｎｇＩｎｆｏという名前の単一のＵＤＴオブジェクトは、この情報をすべて含んでいる。このタイプは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅスキーマで定義される。ＣｈａｎｇｅＴｒａｃｋｉｎｇＩｎｆｏは、アイテム、Ｅｘｔｅｎｓｉｏｎおよびリレーションシップのすべてのグローバル検索ビューで使用することができる。ＣｈａｎｇｅＴｒａｃｋｉｎｇＩｎｆｏのタイプ定義は以下のとおりである。
(1) Change tracking of the “master” search view The change tracking information of the master search view includes information about the creation and update version of the element, the synchronization partner that created the element, information about the synchronization partner that last updated the element, and creation and update. Provide the version number from each partner for. A partner in a synchronous relationship (described below) is identified by a partner key. Type [System. Storage. Store]. A single UDT object named ChangeTrackingInfo in ChangeTrackingInfo contains all this information. This type is described in System. It is defined in the Storage schema. ChangeTrackingInfo can be used in all global search views for items, extensions, and relationships. The type definition of ChangeTrackingInfo is as follows.
これらのプロパティは、以下の情報を含んでいる。 These properties include the following information:
（２）「タイプ定義済み」検索ビューの変更追跡
グローバル検索ビューと同じ情報を提供することに加えて、各タイプ定義済み検索ビューは、同期トポロジの各要素の同期状態を記録する追加情報を提供する。
(2) Change tracking of “type-defined” search views In addition to providing the same information as the global search views, each type-defined search view provides additional information that records the synchronization status of each element of the synchronization topology. To do.
ｂ）トゥームストーン
データ・ストアは、アイテム、Ｅｘｔｅｎｓｉｏｎ、およびリレーションシップのトゥームストーン情報を提供する。トゥームストーン・ビューは、１つの場所で、生のエンティティ（live entity）およびトゥームストーンに入れられたエンティティ（アイテム、拡張およびリレーションシップ）に関する情報を提供する。アイテムおよび拡張のトゥームストーン・ビューは対応するオブジェクトへのアクセスを提供しないが、リレーションシップ・トゥームストーン・ビューはリレーションシップ・オブジェクトへのアクセスを提供する（トゥームストーンにあるリレーションシップの場合、そのリレーションシップ・オブジェクトはＮＵＬＬである）。
b) Tombstone The data store provides tombstone information for items, extensions, and relationships. Tombstone views provide information about live entities and entities put into tombstones (items, extensions and relationships) in one place. Item and extended tombstone views do not provide access to the corresponding object, but relationship tombstone views provide access to the relationship object (if the relationship is in tombstone, the relationship Ship object is NULL).
（１）アイテムのトゥームストーン
アイテム・トゥームストーンは、ビュー「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．［Ｔｏｍｂｓｔｏｎｅ！Ｉｔｅｍ］」を介してシステムから取り出される。
(1) Item Tombstone Item Tombstone is retrieved from the system via the view “[System.Storage]. [Tombostone! Item]”.
（２）拡張のトゥームストーン
拡張トゥームストーンは、ビュー「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．［Ｔｏｍｂｓｔｏｎｅ！Ｅｘｔｅｎｓｉｏｎ］」を介してシステムから取り出される。Ｅｘｔｅｎｓｉｏｎ変更追跡情報は、アイテムに提供される情報と類似しているが、さらにＥｘｔｅｎｓｉｏｎＩｄプロパティが加わっている。
(2) Extended Tombstone The extended tombstone is retrieved from the system via the view “[System.Storage]. [Tombostone! Extension]”. Extension change tracking information is similar to the information provided for an item, but additionally has an ExtensionId property.
（３）リレーションシップのトゥームストーン
リレーションシップ・トゥームストーンは、ビュー「［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．［Ｔｏｍｂｓｔｏｎｅ！Ｒｅｌａｔｉｏｎｓｈｉｐ］」を介してシステムから取り出される。リレーションシップ・トゥームストーン情報は、Ｅｘｔｅｎｓｉｏｎで提供されるものと同様である。ただし、追加情報は、リレーションシップ・インスタンスのターゲットＩｔｅｍＲｅｆで提供される。さらに、リレーションシップ・オブジェクトも選択される。
(3) Relationship Tombstone The relationship tombstone is retrieved from the system via the view “[System.Storage]. [Tombostone! Relationship]”. The relationship tombstone information is the same as that provided in Extension. However, additional information is provided in the target ItemRef of the relationship instance. In addition, a relationship object is also selected.
（４）トゥームストーンのクリーンアップ
トゥームストーン情報の際限のない増大を防ぐために、データ・ストアはトゥームストーン・クリーンアップ・タスクを提供する。このタスクは、トゥームストーン情報をいつ廃棄できるか決める。このタスクは、ローカルの作成／更新バージョンのバウンドを計算してから、以前のトゥームストーン・バージョンをすべて廃棄することによりトゥームストーン情報を切り捨てる。
(4) Tombstone cleanup To prevent the endless growth of tombstone information, the data store provides a tombstone cleanup task. This task determines when tombstone information can be discarded. This task calculates the local create / update version bound and then truncates the tombstone information by discarding all previous tombstone versions.
１１．ヘルパーＡＰＩおよび関数
基本マッピングは、いくつかのヘルパー関数も提供する。これらの関数は、データ・モデルに対する共通のオペレーションを補助するために供給される。
11. Helper APIs and Functions The basic mapping also provides some helper functions. These functions are provided to assist in common operations on the data model.
ａ）関数［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．ＧｅｔＩｔｅｍ a) Function [System. Storage]. GetItem
ｂ）関数［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．ＧｅｔＥｘｔｅｎｓｉｏｎ b) Function [System. Storage]. GetExtension
ｃ）関数［Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ］．ＧｅｔＲｅｌａｔｉｏｎｓｈｉｐ c) Function [System. Storage]. GetRelationship
１２．メタデータ
ストアで表されるメタデータのタイプには、インスタンス・メタデータ（アイテムのタイプなど）およびタイプ・メタデータの２つがある。
12 There are two types of metadata represented in the metadata store: instance metadata (such as item type) and type metadata.
ａ）スキーマ・メタデータ
スキーマ・メタデータは、Ｍｅｔａスキーマからのアイテム・タイプのインスタンスとしてデータ・ストアに格納される。
a) Schema metadata Schema metadata is stored in the data store as an instance of the item type from the Meta schema.
ｂ）インスタンス・メタデータ
インスタンス・メタデータは、アイテムのタイプのクエリを行いう、アイテムに関連付けられているＥｘｔｅｎｓｉｏｎを見つけるためにアプリケーションによって使用される。アイテムのＩｔｅｍＩｄを与えられると、アプリケーションは、アイテムのタイプを返すようにグローバル・アイテム・ビューにクエリを行って、その値を使用してアイテムの宣言済みタイプに関する情報を返すように、Ｍｅｔａ．Ｔｙｐｅビューにクエリを行うことができる。たとえば、以下のようになる。
b) Instance metadata Instance metadata is used by an application to find the Extension associated with an item that will be queried for the type of item. Given an ItemId of an item, the application queries the global item view to return the item type and uses that value to return information about the declared type of the item. You can query the Type view. For example:
Ｅ．セキュリティ
一般に、すべての確保できるオブジェクトは、図２６に示すアクセス・マスク・フォーマットを使用してそのアクセス権を調整する。このフォーマットにおいて、下位の１６ビットはオブジェクト固有のアクセス権用であり、次の７ビットは標準アクセス権用であり（ほとんどのオブジェクトのタイプに適用する）、上位の４ビットは、汎用アクセス権を指定するために使用され、ここで、各オブジェクト・タイプは標準およびオブジェクト固有のアクセス権の設定にマップできる。ＡＣＣＥＳＳ−ＳＹＳＴＥＭ−ＳＥＣＵＲＩＴＹビットは、オブジェクトのＳＡＣＬにアクセスする権利に対応する。
E. Security In general, all securable objects use the access mask format shown in FIG. 26 to adjust their access rights. In this format, the lower 16 bits are for object-specific access rights, the next 7 bits are for standard access rights (applies to most object types), and the upper 4 bits are for general access rights. Used to specify where each object type can be mapped to standard and object specific access settings. The ACCESS-SYSTEM-SECURITY bit corresponds to the right to access the SACL of the object.
図２６のアクセス・マスク構造において、アイテム固有のアクセス権は、オブジェクト固有アクセス権セクション（下位１６ビット）に配置される。本発明の実施例において、ストレージ・プラットフォームは、セキュリティを管理するために、Ｗｉｎ３２およびストレージ・プラットフォームＡＰＩという２つのＡＰＩのセットを公開するので、ストレージプラットフォーム・オブジェクト固有アクセス権の設計を動機付けるためにファイル・システム・オブジェクト固有アクセス権を考慮する必要がある。 In the access mask structure of FIG. 26, the item-specific access right is arranged in the object-specific access right section (lower 16 bits). In an embodiment of the present invention, the storage platform exposes two sets of APIs, Win32 and storage platform APIs, to manage security, so files to motivate the design of storage platform object specific permissions. • System object specific access rights need to be considered.
本発明のストレージ・プラットフォームのセキュリティ・モデルについては、先に本明細書に参照により組み込まれている関連出願において詳細に説明されている。この関連で、図２７（ａ、ｂ、およびｃ部分）は、セキュリティ・モデルの１つの実施例による、既存のセキュリティ領域から切り取られる、新しい、同様に保護されるセキュリティ領域を示している。 The storage platform security model of the present invention is described in detail in the related applications previously incorporated herein by reference. In this regard, FIG. 27 (parts a, b, and c) illustrates a new, similarly protected security area that is cut from an existing security area, according to one embodiment of a security model.
Ｆ．通知および変更追跡
本発明のもう１つの態様によれば、ストレージ・プラットフォームは、アプリケーションがデータ変更を追跡できる通知機能を提供する。この機能は主に、揮発性状態を維持するか、またはデータ変更イベントに関してビジネス・ロジックを実行するかするアプリケーションを対象としている。アプリケーションは、アイテム、アイテムＥｘｔｅｎｓｉｏｎおよびアイテム・リレーションシップに関する通知を登録する。通知は、データ変更が確定された後に非同期的に配信される。アプリケーションは、アイテム、Ｅｘｔｅｎｓｉｏｎおよびリレーションシップ・タイプ、さらにオペレーションのタイプによって通知をフィルタリングすることができる。
F. Notification and Change Tracking According to another aspect of the present invention, the storage platform provides a notification function that allows applications to track data changes. This functionality is primarily intended for applications that maintain volatile state or perform business logic on data change events. The application registers notifications for items, item extensions, and item relationships. The notification is delivered asynchronously after the data change is confirmed. The application can filter notifications by item, extension and relationship type, as well as the type of operation.
１つの実施例に拠れば、ストレージ・プラットフォームＡＰＩ３２２は、通知のための２種類のインターフェースを提供する。第１に、アプリケーションは、アイテム、アイテムＥｘｔｅｎｓｉｏｎおよびアイテム・リレーションシップに対する変更によりトリガされる単純データ変更イベントを登録する。第２に、アプリケーションは、アイテムのセット、アイテムＥｘｔｅｎｓｉｏｎおよびアイテムの間のリレーションシップを監視する「ウォッチャ」オブジェクトを作成する。ウォッチャ・オブジェクトの状態は、保存することができ、システム障害の後、または長期間にわたりシステムがオフラインになった後に再作成することができる。単一の通知は、複数の更新を反映することができる。 According to one embodiment, the storage platform API 322 provides two types of interfaces for notification. First, the application registers simple data change events that are triggered by changes to items, item extensions, and item relationships. Second, the application creates a “watcher” object that monitors a set of items, item extensions, and relationships between items. The state of the watcher object can be saved and recreated after a system failure or after the system has been offline for an extended period of time. A single notification can reflect multiple updates.
この機能に関する詳細については、先に参照により本明細書に組み込まれている関連出願において説明されている。 Details regarding this function are described in the related applications previously incorporated herein by reference.
Ｇ．同期化
本発明のもう１つの態様によれば、ストレージ・プラットフォームは、同期化サービス３３０を提供し、これは、（ｉ）ストレージ・プラットフォームの複数のインスタンス（各々独自のデータ・ストア３０２を備える）が柔軟な規則のセットに従ってそのコンテンツの部分を同期化することができるようにし、（ｉｉ）本発明のストレージ・プラットフォームのデータ・ストアを、独自仕様のプロトコルを実装する他のデータ・ソースと同期させるサード・パーティのためのインフラストラクチャを提供する。
G. Synchronization According to another aspect of the present invention, the storage platform provides a synchronization service 330, which includes (i) multiple instances of the storage platform (each with its own data store 302). Can synchronize portions of its content according to a flexible set of rules, and (ii) synchronize the storage platform data store of the present invention with other data sources that implement proprietary protocols Provide infrastructure for third parties to
ストレージ・プラットフォーム間の同期化は、関与するレプリカのグループ間で発生する。たとえば、図３を参照すると、おそらくは別のコンピュータ・システム上で稼動するストレージ・プラットフォームのもう１つのインスタンスの制御のもとで、ストレージ・プラットフォーム３００のデータ・ストア３０２ともう１つのリモート・データストア３３８との間の同期化を提供することが望ましい場合がある。このグループの合計メンバーシップ数は必ずしも、所定の時間において所定のレプリカに認識されている必要はない。
Synchronization between storage platforms occurs between groups of participating replicas. For example, referring to FIG. 3, a
異なるレプリカは、単独で（つまり並行して）変更を行うことができる。同期化のプロセスは、他のレプリカによって行われた変更をすべてのレプリカに認識させるように定義される。この同期化機能は、本質的にマルチ・マスタである。 Different replicas can make changes alone (ie in parallel). The synchronization process is defined to make all replicas aware of changes made by other replicas. This synchronization function is inherently multi-master.
本発明の同期化機能により、レプリカは以下のことを行うことができる。
・ もう１つのレプリカが認識する変更を判断する
・ このレプリカが認識しない変更に関する情報を要求する
・ 他のレプリカが認識しない変更に関する情報を伝達する
・ ２つの変更が相互に競合しているときを判断する
・ ローカルに変更を適用する
・ 集束を確実にするように他のレプリカに競合の解決を伝達する
・ 指定されている競合解決のポリシーに基づいて競合を解決する
１．ストレージ・プラットフォーム間の同期化
ストレージ・プラットフォームの同期化サービス３３０の主な用途は、ストレージ・プラットフォームの複数のインスタンスを（それぞれのデータ・ストアと）同期化することにある。同期化サービスは、（データベース・エンジン３１４の基礎をなすテーブルではなく）ストレージ・プラットフォーム・スキーマのレベルにおいて機能する。したがって、たとえば「Ｓｃｏｐｅｓ」は、以下で説明するように同期化セットを定義するために使用される。
With the synchronization function of the present invention, the replica can:
Determine which changes are recognized by another replica
Request information about changes not recognized by this replica
Communicate information about changes not recognized by other replicas
Determine when two changes are in conflict with each other
Apply changes locally
Communicate conflict resolution to other replicas to ensure convergence
-Resolve conflicts based on the specified conflict resolution policy. Synchronization between storage platforms The primary use of the storage platform synchronization service 330 is to synchronize multiple instances of the storage platform (with their respective data stores). The synchronization service works at the storage platform schema level (rather than the tables underlying the database engine 314). Thus, for example, “Scopes” is used to define a synchronization set as described below.
同期化サービスは、「ｎｅｔ ｃｈａｎｇｅｓ」の原則に基づいて稼動する。同期化サービスでは、（トランザクションの複製の場合のように）個々のオペレーションを記録して送信するのではなく、これらのオペレーションの最終結果を送信して、複数のオペレーションの結果を単一の結果の変更に統合する。 The synchronization service operates based on the principle of “net changes”. Instead of recording and sending individual operations (as in transactional replication), the synchronization service sends the final results of these operations and combines the results of multiple operations into a single result. Integrate into changes.
同期化サービスは一般に、トランザクションの境界を考慮しない。つまり、単一トランザクションで一つのストレージ・プラットフォーム・データ・ストアに２つの変更が行われた場合、これらの変更が他のすべてのレプリカでアトミックに適用される保証はなく、一方が、他方なしで反映される可能性がある。この原則の例外は、同じトランザクション内で同じアイテムに２つの変更が行われた場合、これらの変更は他のレプリカにアトミックに送信されて適用されることが保証される点にある。従って、アイテムは、同期化サービスの整合性の単位である。 Synchronization services generally do not consider transaction boundaries. This means that if two changes are made to a single storage platform data store in a single transaction, there is no guarantee that these changes will be applied atomically on all other replicas, one without the other It may be reflected. An exception to this principle is that if two changes are made to the same item within the same transaction, these changes are guaranteed to be sent atomically to other replicas and applied. Thus, an item is a unit of consistency for a synchronization service.
ａ）同期（Sync）制御アプリケーション
任意のアプリケーションを同期化サービスに接続し、同期化オペレーションを開始することができる。そのようなアプリケーションは、同期化を実行するために必要なパラメータをすべて提供する（以下の同期プロファイルを参照）。そのようなアプリケーションは、本明細書において同期制御アプリケーション（ＳＣＡ）と呼ぶ。
a) Sync Control Application Any application can connect to the synchronization service and initiate a synchronization operation. Such an application provides all the parameters necessary to perform the synchronization (see the synchronization profile below). Such an application is referred to herein as a synchronous control application (SCA).
２つのプラットフォームインスタンスを同期化するとき、ＳＣＡによって同期化は一方の側で初期化される。そのＳＣＡは、リモート・パートナと同期化するようローカルの同期化サービスに通知する。もう一方の側では、同期化サービスが、発信元マシンからの同期化サービスによって送信されたメッセージにより起動される。これは、宛先マシンにある永続的構成情報（以下のマッピングを参照）に基づいて応答する。同期化サービスは、スケジュール通りに、またはイベントに応答して稼動することができる。そのような場合、スケジュールを実装する同期化サービスはＳＣＡになる。 When synchronizing two platform instances, the synchronization is initialized on one side by the SCA. The SCA notifies the local synchronization service to synchronize with the remote partner. On the other side, the synchronization service is activated by a message sent by the synchronization service from the originating machine. This responds based on persistent configuration information (see mapping below) at the destination machine. The synchronization service can operate on schedule or in response to events. In such a case, the synchronization service that implements the schedule is the SCA.
同期化を可能にするには、２つの手順が取られる必要がある。第１に、スキーマ設計者が、ストレージ・プラットフォーム・スキーマに適切な同期化セマンティクスで（以下に説明するように変更単位を指定して）注釈を付ける必要がある。第２に、同期化は、（以下に説明するように）同期化に参与するストレージ・プラットフォームのインスタンスを持つすべてのマシンに関して適正に構成される必要がある。 Two steps need to be taken to enable synchronization. First, the schema designer needs to annotate the storage platform schema with the appropriate synchronization semantics (specifying the change unit as described below). Second, synchronization must be properly configured for all machines that have an instance of the storage platform that participates in synchronization (as described below).
ｂ）スキーマの注釈
同期化サービスの基本概念は、変更単位の基本概念である。変更単位は、ストレージ・プラットフォームによって個々に追跡されるスキーマの最小部分である。すべての変更単位について、同期化サービスはそれが変更されたか、または前回の同期化以来変更されていないかを決定することができる。
b) Schema annotation The basic concept of the synchronization service is the basic concept of the change unit. A change unit is the smallest part of a schema that is individually tracked by a storage platform. For every change unit, the synchronization service can determine whether it has changed or has not changed since the last synchronization.
スキーマ内で変更単位を指定することは、いくつかの目的に適っている。第１に、これは同期化サービスが電線上でどの程度のやり取りをするかを決める。変更単位内部で変更が行われた場合、変更単位のどの部分が変更されたのか同期化サービスには分からないので、変更単位全体が他のレプリカに送信される。第２に、これは競合検出の細分性を決める。２つの同時変更（これらの用語は以下のセクションで詳細に定義される）が同じ変更単位に行われた場合、同期化サービスは競合を発生する。一方、同時変更が異なる変更単位に行われた場合、競合は発生せず、変更は自動的に統合される。第３に、これはシステムによって保持されるメタデータの量に大きな影響を及ぼす。同期化サービスのメタデータの多くは、変更単位ごとに保持される。したがって、変更単位を小さくすることで同期化のオーバーヘッドが増大する。 Specifying change units in the schema serves several purposes. First, it determines how much the synchronization service interacts on the wire. When a change is made within the change unit, the synchronization service does not know which part of the change unit has been changed, so the entire change unit is sent to another replica. Second, this determines the granularity of conflict detection. If two simultaneous changes (these terms are defined in detail in the following sections) are made to the same change unit, the synchronization service generates a conflict. On the other hand, if simultaneous changes are made to different change units, there is no conflict and the changes are automatically integrated. Third, this greatly affects the amount of metadata held by the system. Much of the synchronization service metadata is retained for each change unit. Therefore, reducing the change unit increases the synchronization overhead.
変更単位を定義するには、適正なトレードオフを見い出す必要がある。そうした理由から、同期化サービスではスキーマ設計者がこのプロセスに参加できるようになっている。 To define a change unit, you need to find the right trade-off. For that reason, the synchronization service allows schema designers to participate in this process.
１つの実施例において、同期化サービスは、ある要素よりも大きい変更単位をサポートしない。ただし、同期化サービスは、スキーマ設計者がある要素よりも小さい変更単位を指定する能力、つまり、ある要素の複数の属性を別個の変更単位にグループ化する能力をサポートする。その実施例において、このことは、以下の構文を使用して行われる。 In one embodiment, the synchronization service does not support change units larger than an element. However, the synchronization service supports the ability of a schema designer to specify a change unit that is smaller than an element, that is, the ability to group multiple attributes of an element into separate change units. In that embodiment, this is done using the following syntax:
ｃ）同期の構成
ストレージ・プラットフォーム・パートナのグループで、彼らのデータの特定部分の同期をとりたいと望むグループは、同期コミュニティと呼ばれる。コミュニティのメンバは同期を保ちたいと考えているが、必ずしもまったく同じ方法でデータを表す必要はない。つまり、同期パートナは、同期化しようとしているデータを変換することができる。
c) Configuration of synchronization A group of storage platform partners who wants to synchronize a specific part of their data is called a synchronization community. Community members want to stay in sync, but they don't have to represent data in exactly the same way. That is, the synchronization partner can convert the data to be synchronized.
ピア・ツー・ピアのシナリオにおいて、ピアがそのパートナすべてに対して変換マッピングを保持することは実際的ではない。その代わり、同期化サービスが「コミュニティ・フォルダ」を定義する方法をとる。コミュニティ・フォルダは、すべてのコミュニティ・メンバが同期化している仮想の「共有フォルダ」を表す抽象である。 In a peer-to-peer scenario, it is impractical for a peer to maintain a translation mapping for all its partners. Instead, the synchronization service takes a way to define a “community folder”. A community folder is an abstraction that represents a virtual “shared folder” in which all community members are synchronized.
この概念は、例示によって分かりやすく説明することができる。ジョーが数台のコンピュータにあるＭｙ Ｄｏｃｕｍｅｎｔｓフォルダの同期をとりたい場合、ジョーは、たとえばＪｏｅｓＤｏｃｕｍｅｎｔｓという名前のコミュニティ・フォルダを定義する。次に、ジョーは、すべてのコンピュータで、仮想のＪｏｅｓＤｏｃｕｍｅｎｔｓフォルダとローカルのＭｙ Ｄｏｃｕｍｅｎｔｓフォルダ間のマッピングを構成する。それ以降は、ジョーのコンピュータが相互に同期化するとき、ローカル・アイテムではなく、ＪｏｅｓＤｏｃｕｍｅｎｔｓのドキュメントに関してやりとりするようになる。このようにして、ジョーのすべてのコンピュータは、他のコンピュータが何であるか認識する必要もなく互いを理解しあい、コミュニティ・フォルダは同期コミュニティの共通言語となる。 This concept can be easily explained by an example. If Joe wants to synchronize the My Documents folder on several computers, Joe defines a community folder named, for example, JoesDocuments. Next, Joe configures a mapping between the virtual Joe Documents folder and the local My Documents folder on all computers. From then on, when Joe's computers synchronize with each other, they will interact with the JoesDocuments document, not the local items. In this way, all of Joe's computers understand each other without having to know what the other computer is, and the community folder becomes the common language of the synchronized community.
同期化サービスの構成は、次の３つのステップから成り、（１）ローカル・フォルダおよびコミュニティ・フォルダ間のマッピングを定義するステップ、（２）何が同期化されるか（たとえば、何と同期するか、またどのサブセットを送信すべきか、またどれを受信したか）を決める同期プロファイルを定義するステップ、および（３）さまざまな同期プロファイルが稼動する、またはこれらを手動で実行するスケジュールを定義するステップである。 The configuration of the synchronization service consists of the following three steps: (1) defining the mapping between local and community folders; (2) what is synchronized (eg what to synchronize with) Defining synchronization profiles that determine which subsets should be transmitted and which received), and (3) defining a schedule for running or manually running various synchronization profiles. is there.
（１）コミュニティ・フォルダ−マッピング
コミュニティ・フォルダのマッピングは、個々のマシン上にＸＭＬ構成ファイルとして格納される。各マッピングは、以下のようなスキーマを備えている。
／ｍａｐｐｉｎｇｓ／ｃｏｍｍｕｎｉｔｙＦｏｌｄｅｒ
この要素は、このマッピングの対象となるコミュニティ・フォルダに名前を付ける。名前は、フォルダの構文規則に従う。
／ｍａｐｐｉｎｇｓ／ｌｏｃａｌＦｏｌｄｅｒ
この要素は、このマッピングが変換されるローカル・フォルダに名前を付ける。名前は、フォルダの構文規則に従う。フォルダは、マッピングが有効になるように常に存在する必要がある。このフォルダ内のアイテムは、このマッピングごとの同期化のために考慮される。
／ｍａｐｐｉｎｇｓ／ｔｒａｎｓｆｏｒｍａｔｉｏｎｓ
この要素は、コミュニティ・フォルダからローカル・フォルダ、およびその逆にアイテムを変換する方法を定義する。これが欠けているかまたは空の場合、変換は行われない。特に、これはＩＤがマップされないということである。この構成は主として、フォルダのキャッシュを作成する場合に有用である。
／ｍａｐｐｉｎｇｓ／ｔｒａｎｓｆｏｒｍａｔｉｏｎｓ／ｍａｐＩＤｓ
この要素は、コミュニティＩＤを再使用するのではなく、新しく生成されたローカルＩＤが、コミュニティ・フォルダからマップされたすべてのアイテムに割り当てられるよう要求する。同期ランタイムはＩＤマッピングを保持し、アイテムを前後に往復して変換する。
／ｍａｐｐｉｎｇｓ／ｔｒａｎｓｆｏｒｍａｔｉｏｎｓ／ｌｏｃａｌＲｏｏｔ
この要素は、コミュニティ・フォルダ内のすべてのルート・アイテムが指定されたルートの子にされるよう要求する。
／ｍａｐｐｉｎｇｓ／ｒｕｎＡｓ
この要素は、このマッピングに対する要求が処理される権限を制御する。ない場合には、送信者が想定される。
／ｍａｐｐｉｎｇｓ／ｒｕｎＡｓ／ｓｅｎｄｅｒ
この要素の存在は、このマッピングへのメッセージの送信者が偽名を使用しているはずなので、その結果、その証明書のもとに要求が処理される必要があることを示している。
(1) Community folder-mapping Community folder mappings are stored as XML configuration files on individual machines. Each mapping has the following schema.
/ Mappings / communityFolder
This element names the community folder that is the subject of this mapping. The name follows the folder syntax rules.
/ Mappings / localFolder
This element names the local folder to which this mapping is converted. The name follows the folder syntax rules. The folder must always exist for the mapping to be valid. Items in this folder are considered for synchronization per this mapping.
/ Mappings / transformations
This element defines how to convert items from community folders to local folders and vice versa. If it is missing or empty, no conversion is performed. In particular, this means that the ID is not mapped. This configuration is mainly useful when creating a folder cache.
/ Mappings / transformations / mapIDs
This element does not reuse the community ID, but requires that a newly generated local ID be assigned to all items mapped from the community folder. The sync runtime keeps the ID mapping and converts the item back and forth back and forth.
/ Mappings / transformations / localRoot
This element requests that all root items in the community folder be children of the specified root.
/ Mappings / runAs
This element controls the authority with which requests for this mapping are processed. If not, the sender is assumed.
/ Mappings / runAs / sender
The presence of this element indicates that the sender of the message to this mapping should be using a pseudonym, so that the request needs to be processed under that certificate.
（２）プロファイル
同期プロファイルは、同期化を開始するために必要なパラメータの全セットである。これは、ＳＣＡによって同期ランタイムに供給され、同期化を開始する。ストレージ・プラットフォーム間の同期化のための同期化プロパティは、以下の情報を含んでいる。
・ ローカル・フォルダ、変更の送信元および宛先としての役割を果たす。
・ 同期化するリモートフォルダ名 −− このフォルダは上記で定義されているマッピングの方法によりリモート・パートナからパブリッシュされる必要がある。
・ 方向−同期化サービスは、送信専用、受信専用、および送受信の同期をサポートする。
・ ローカル・フィルタ −− リモート・パートナに送信するローカル情報を選択する。ローカル・フォルダへのストレージ・プラットフォーム・クエリとして表される。
・ リモート・フィルタ −− リモート・パートナから取り出すリモート情報を選択する。− コミュニティ・フォルダへのストレージ・プラットフォーム・クエリとして表される。
・ 変換 −− アイテムとローカル・フォーマットとの間で変換する方法を定義する。
・ ローカル・セキュリティ −− リモート・エンドポイントから取り出された変更が、（impersonated：偽装された）リモート・エンドポイントの許可のもと、または同期化をローカルに開始したユーザの許可のもとに適用されるのかを指定する
・ 競合解決ポリシー −− 競合が拒否されるか、ログに記録されるか、または自動的に解決されるかを指定する − 後者の場合は、使用する競合リゾルバ、その構成パラメータを指定する。
(2) Profile A synchronization profile is the full set of parameters required to initiate synchronization. This is supplied by the SCA to the synchronization runtime to initiate synchronization. Synchronization properties for synchronization between storage platforms include the following information:
• Acts as a local folder, change source and destination.
• Name of remote folder to synchronize-This folder needs to be published from the remote partner by the mapping method defined above.
The direction-synchronization service supports transmission only, reception only, and transmission / reception synchronization.
• Local filter-Selects local information to be sent to the remote partner. Expressed as a storage platform query to a local folder.
• Remote filter --- Select remote information to be retrieved from the remote partner. -Expressed as a storage platform query to the community folder.
• Conversion-Defines how to convert between items and local formats.
• Local security-changes taken from the remote endpoint are applied under the permission of the (impersonated) remote endpoint or with the permission of the user who initiated the synchronization locally Specify what will be done
Conflict resolution policy-Specifies whether the conflict is rejected, logged or automatically resolved-In the latter case, specifies the conflict resolver to use and its configuration parameters.
同期化サービスは、同期プロファイルを簡単に構築できるようにするランタイムＣＬＲクラスを提供する。プロファイルはさらに、（多くの場合スケジュールと共に）容易に格納できるようにＸＭＬファイルにシリアル化し、およびそこからシリアル化することもできる。ただし、ストレージ・プラットフォームにはすべてのプロファイルが格納される標準的な場所はない。ＳＣＡでは、固執することなくその場でプロファイルを自由に構築できるようにしている。同期化を開始するためにローカル・マッピングを備える必要はないことに留意されたい。すべての同期化情報は、プロファイルに指定することができる。ただし、マッピングは、リモート側によって開始された同期化要求に応答するために必要になる。 The synchronization service provides a runtime CLR class that makes it easy to build a synchronization profile. The profile can also be serialized into and out of an XML file for easy storage (often with a schedule). However, there is no standard place on the storage platform where all profiles are stored. SCA makes it possible to build a profile freely on the spot without sticking. Note that it is not necessary to have a local mapping to initiate synchronization. All synchronization information can be specified in the profile. However, mapping is required to respond to synchronization requests initiated by the remote side.
（３）スケジュール
１つの実施例において、同期化サービスはその独自のスケジュール・インフラストラクチャを提供しない。その代わり、このタスクを実行する他のコンポーネントに依存している。それは、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）オペレーティング・システムに付属のＷｉｎｄｏｗｓ（登録商標）Ｓｃｈｅｄｕｌｅｒである。同期化サービスには、ＳＣＡとしての役割を果たし、ＸＭＬファイルに保存されている同期プロファイルに基づいて同期化をトリガする、コマンド・ライン・ユーティリティが含まれている。このユーティリティにより、Ｗｉｎｄｏｗｓ（登録商標）Ｓｃｈｅｄｕｌｅｒがスケジュールどおり、あるいはユーザのログオンまたはログオフなどのイベントに応じて同期化を実行するように構成することが非常に簡単になる。
(3) Schedule In one embodiment, the synchronization service does not provide its own schedule infrastructure. Instead, it relies on other components that perform this task. It is the Windows (R) Scheduler that comes with the Microsoft Windows (R) operating system. The synchronization service includes a command line utility that acts as an SCA and triggers synchronization based on a synchronization profile stored in an XML file. This utility makes it very easy to configure a Windows® Scheduler to perform synchronization on schedule or in response to events such as user logon or logoff.
ｄ）競合の処理
同期化サービスにおける競合処理は、次の３つの段階で構成される。（１）変更適用の時点で発生する競合検出−このステップでは変更が安全に適用できるかどうかを決定する、（２）自動競合解決およびログ記録−このステップ（競合が検出された直後に行われる）中に、競合を解決できるかどうか確認するために自動競合リゾルバが相談にあづかり−解決できない場合、競合はオプションでログに記録される、および（３）競合検査および解決 − このステップは、競合がログに記録されている場合に行われ、同期化セッションのコンテクストの外部で発生する−この時点で、ログに記録された競合は解決されてログから削除することができる。
d) Contention processing Contention processing in the synchronization service consists of the following three stages. (1) Conflict detection that occurs at the time of change application-this step determines whether the change can be safely applied, (2) automatic conflict resolution and logging-this step (performed immediately after a conflict is detected) ) During, the automatic conflict resolver consults to determine if the conflict can be resolved-if it cannot be resolved, the conflict is optionally logged, and (3) conflict checking and resolution-this step Occurs if it is logged and occurs outside the context of the synchronization session—At this point, the logged conflict can be resolved and removed from the log.
（１）競合の検出
１つの実施例において、同期化サービスは、知識ベースおよび制約ベースという２つの種類の競合を検出する。
(1) Conflict detection In one embodiment, the synchronization service detects two types of conflicts: knowledge-based and constraint-based.
（ａ）知識ベース（knowledge-based）の競合
知識ベースの競合は、２つのレプリカが同じ変更単位に独立した変更を行った場合に発生する。２つの変更は、相互を認識（knowledge）することなく行われる場合、言い替えれば、第１のバージョンが第２のバージョンによって認識されていない場合、またはその逆の場合に、独立した変更と呼ばれる。同期化サービスは、前述のようにレプリカの認識（knowledge）に基づいてそのような競合をすべて自動的に検出する。
(A) Knowledge-based contention Knowledge-based contention occurs when two replicas make independent changes to the same change unit. Two changes are called independent changes if they are made without knowledge of each other, in other words if the first version is not recognized by the second version, or vice versa. The synchronization service automatically detects all such conflicts based on replica knowledge as described above.
競合を変更単位のバージョン履歴におけるフォーク（分岐）と考えると参考になる場合もある。変更単位の寿命（life）内に競合が発生しない場合、そのバージョン履歴は単純なチェーンである。各変更は、それぞれ以前の（一つの）変更の後に発生する。知識ベースの競合の場合は、２つの変更が並行して発生し、チェーンが分割してバージョン・ツリーになる。 Considering the conflict as a fork in the version history of the change unit, it may be helpful. If no conflicts occur within the life of a change unit, its version history is a simple chain. Each change occurs after the previous (one) change. In the case of knowledge base conflicts, two changes occur in parallel, splitting the chain into a version tree.
（ｂ）制約ベースの競合
独立した変更は、一緒に適用される場合、整合性の制約に違反する場合もある。たとえば、同じディレクトリに同じ名前を持つファイルを作成する２つのレプリカは、そのような競合が発生する原因となる可能性がある。
(B) Constraint-based conflicts Independent changes may violate integrity constraints when applied together. For example, two replicas that create a file with the same name in the same directory can cause such a conflict.
制約ベースの競合は、２つの独立した変更に伴って生ずる（知識ベースの競合と同様）が、同じ変更単位に影響を与えることはない。むしろ、これらは、間に制約が存在する場合にのみ、異なる変更単位に影響を与える。 Constraint-based conflicts occur with two independent changes (similar to knowledge-based conflicts), but do not affect the same change unit. Rather, they affect different change units only if there are constraints in between.
同期化サービスは、変更適用の時点で制約違反を検出し、制約ベースの競合を自動的に提起する。制約ベースの競合を解決するには通常、制約に違反しないような方法で変更を修正するカスタム・コードが必要である。同期化サービスは、これを行うための汎用メカニズムを提供しない。 The synchronization service detects constraint violations at the time of change application and automatically raises constraint-based conflicts. Resolving constraint-based conflicts typically requires custom code that modifies changes in a way that does not violate the constraints. The synchronization service does not provide a general purpose mechanism for doing this.
（２）競合の処理
競合が検出されると、同期化サービスは、（同期プロファイルの同期化イニシエータによって選択される）次の３つのうち１つの処置をとることができる。（１）変更を拒否し、これを送信側に戻す、（２）競合を競合ログに記録する、または（３）競合を自動的に解決する。
(2) Conflict handling When a conflict is detected, the synchronization service can take one of the following three actions (selected by the synchronization initiator in the synchronization profile): (1) reject the change and return it to the sender, (2) record the conflict in the conflict log, or (3) automatically resolve the conflict.
変更が拒否される場合、同期化サービスは、変更がレプリカに到達しなかったかのうように動作する。否定応答は、発信元に送り返される。この解決ポリシーは主に、競合をログ記録することが可能ではないヘッドレス・レプリカ（ファイル・サーバなど）では有用である。その代わり、そのようなレプリカは、他のレプリカが変更を拒否することによって競合を処理するように強要する。 If the change is rejected, the synchronization service behaves as if the change did not reach the replica. A negative response is sent back to the source. This resolution policy is mainly useful for headless replicas (such as file servers) where it is not possible to log conflicts. Instead, such replicas force other replicas to handle the conflict by rejecting the change.
同期イニシエータは、その同期プロファイルに競合解決を構成する。同期化サービスは、次の方法で、単一のプロファイルの複数の競合リゾルバの組み合わせをサポートしている。第１は、競合リゾルバのリストの１つが成功するまで、リストを次々と試験するよう指定すること。第２は、競合リゾルバを競合タイプと関連付けること、たとえば、更新−更新の知識ベースの競合を１つのリゾルバに振り向け、他のすべての競合はログに振り向ける。 The synchronization initiator configures conflict resolution for its synchronization profile. The synchronization service supports the combination of multiple competing resolvers of a single profile in the following manner. The first is to specify that the list is tested one after another until one of the list of competing resolvers is successful. Second, associating a conflict resolver with a conflict type, for example, directing update-update knowledge base conflicts to one resolver and all other conflicts to the log.
（ａ）自動競合解決
同期化サービスは、いくつかのデフォルトの競合リゾルバを提供する。以下のものがあげられる。
・ｌｏｃａｌ−ｗｉｎｓ：ローカルに格納されているデータと競合している場合は着信変更を無視する
・ｒｅｍｏｔｅ−ｗｉｎｓ：着信変更と競合している場合はローカルデータを無視する
・ｌａｓｔ−ｗｒｉｔｅｒ−ｗｉｎｓ：変更のタイム・スタンプに基づいて変更単位ごとにｌｏｃａｌ−ｗｉｎｓまたはｒｅｍｏｔｅ−ｗｉｎｓのいずれかを選ぶ（一般に同期化サービスはクロック値に依存しないことに留意されたい。この競合リゾルバはその規則の唯一の例外である）
・Ｄｅｔｅｒｍｉｎｉｓｔｉｃ：すべてのレプリカで同じになるよう保証されるような（そうでなければ意味をなさない）方法で勝者を選ぶ − この同期化サービスの１つの実施例では、パートナＩＤの辞書式比較を使用してこの機能を実装する
さらに、ＩＳＶは独自の競合リゾルバを実装してインストールすることができる。カスタムの競合リゾルバは、構成パラメータを受け入れることになる。そのようなパラメータは、同期プロファイルの競合解決セクションでＳＣＡによって指定される必要がある。
(A) Automatic conflict resolution The synchronization service provides several default conflict resolvers. The following are listed.
Local-wins: ignore incoming changes if conflicting with locally stored data
Remote-wins: ignore local data if conflicting with incoming call changes
Last-writer-wins: choose between local-wins or remote-wins for each change unit based on the time stamp of the change (note that synchronization services are generally independent of clock values. This contention The resolver is the only exception to that rule)
Deterministic: Picking a winner in a way that ensures that all replicas are the same (otherwise it makes no sense)-In one embodiment of this synchronization service, a lexicographic comparison of partner IDs Use to implement this functionality In addition, ISVs can implement and install their own competitive resolvers. A custom conflict resolver will accept the configuration parameters. Such parameters need to be specified by the SCA in the conflict resolution section of the synchronization profile.
競合リゾルバが競合を処理するとき、実行する必要のあるオペレーションのリストを（変更が競合することの変わりに）ランタイムに返す。次に、同期化サービスは、競合ハンドラが考慮したことを含めるようリモートの知識を適切に調整させて、これらのオペレーションを適用する。 When the conflict resolver handles the conflict, it returns to the runtime a list of operations that need to be performed (instead of conflicting changes). The synchronization service then applies these operations with the remote knowledge appropriately adjusted to include what the contention handler has considered.
解決を適用している間に別の競合が検出される可能性もある。そのような場合、新しい競合は、元の処理が再開する前に解決する必要がある。 Another conflict may be detected while applying the solution. In such cases, the new conflict needs to be resolved before the original process resumes.
競合をアイテムのバージョン履歴における分岐として考えると、競合解決は、２つの分岐を組み合わせて単一ポイントを形成する、結合と見なすことができる。したがって、競合解決はバージョン履歴をＤＡＧに変える。 Considering a conflict as a branch in an item's version history, conflict resolution can be viewed as a join that combines two branches to form a single point. Thus, conflict resolution changes the version history to DAG.
（ｂ）競合のロギング
非常に特殊な種類の競合リゾルバは、ＣｏｎｆｌｉｃｔＬｏｇｇｅｒである。同期化サービスは、競合を、タイプＣｏｎｆｌｉｃｔＲｅｃｏｒｄのアイテムとしてログに記録する。これらの記録は、（アイテム自体が削除されていない限り）競合している元のアイテムに関連している。各競合レコードは、競合を引き起こした着信変更、競合の種類（更新−更新、更新−削除、削除−更新、挿入−挿入、または制約）、および着信変更のバージョンとそれを送信するレプリカの知識を含んでいる。ログに記録された競合は、以下に説明するように検査および解決に使用することができる。
(B) Conflict logging A very special type of conflict resolver is ConflictLogger. The synchronization service logs the conflict as an item of type ConflictRecord. These records relate to the original item in conflict (unless the item itself has been deleted). Each conflict record contains knowledge of the incoming change that caused the conflict, the type of conflict (update-update, update-delete, delete-update, insert-insert, or constraint), and the version of the incoming change and the replica that sends it. Contains. Logged conflicts can be used for inspection and resolution as described below.
（ｃ）競合の検査および解決
同期化サービスは、アプリケーションのＡＰＩを提供して、競合ログを調べ、その中の競合の解決を提案する。ＡＰＩにより、アプリケーションは、すべての競合、または所定のアイテムに関連する競合を列挙することができる。さらにこれにより、そのようなアプリケーションは、次のうちの１つの方法でログに記録された競合を解決することもできるようになる。（１）リモートの勝利 −− ログに記録された変更を受け入れ、競合するローカルの変更を上書きする、（２）ローカルの勝利 −− ログに記録された変更の競合部分を無視する、および（３）新しい変更を提案 −− アプリケーションが自身の判断で競合を解決するマージを提案する。アプリケーションによって競合が解決されると、同期化サービスはこれらをログから削除する。
(C) Conflict checking and resolution The synchronization service provides the application API, examines the conflict log, and proposes resolution of the conflicts therein. The API allows an application to enumerate all conflicts or conflicts associated with a given item. This also allows such applications to resolve conflicts logged in one of the following ways: (1) Remote win--accept the logged changes and overwrite conflicting local changes, (2) Local win--ignore the conflicting portion of the logged changes, and (3 ) Propose new changes --- Propose a merge where the application resolves conflicts at its discretion. As conflicts are resolved by the application, the synchronization service removes them from the log.
（ｄ）レプリカの集束および競合解決の伝搬
複雑な同期化のシナリオにおいて、同じ競合が複数のレプリカで検出されることがある。これが発生した場合、次のようなことが起こる可能性がある。（１）競合は１つのレプリカ上で解決することができ、解決はもう一方のレプリカに送信される、（２）競合は両方のレプリカで自動的に解決される、または（３）競合は両方のレプリカで（競合検査ＡＰＩを通じて）手動で解決される。
(D) Replica Convergence and Propagation of Conflict Resolution In complex synchronization scenarios, the same conflict may be detected at multiple replicas. If this happens, the following may occur: (1) Conflicts can be resolved on one replica and the resolution is sent to the other replica, (2) Conflicts are resolved automatically on both replicas, or (3) Conflicts are both Resolved manually (through a conflict checking API).
集束を確実にするために、同期化サービスは競合解決を他のレプリカに転送する。競合を解決する変更がレプリカに到達すると、同期化サービスは、この更新によって解決されるログ内の競合レコードを自動的に見つけ出し、これらを除去する。その意味では、１つのレプリカにおける競合解決は他のすべてのレプリカを結合している。 In order to ensure convergence, the synchronization service forwards the conflict resolution to other replicas. When changes that resolve conflicts reach the replica, the synchronization service automatically finds and removes conflict records in the log that are resolved by this update. In that sense, contention resolution in one replica combines all other replicas.
同じ競合に対して異なる勝者が異なるレプリカによって選択された場合、同期化サービスは競合解決を結合する原則を適用して、２つの解決のうちの一方を選んで自動的に他方に勝つようにする。勝者は、常に同じ結果を生成するよう保証されている決定論的な方法で選ばれる（１つの実施例ではレプリカＩＤ辞書式比較を使用する）。 If different winners are selected by different replicas for the same conflict, the synchronization service applies the principle of combining conflict resolutions to pick one of the two solutions and automatically win the other . The winner is chosen in a deterministic manner that is guaranteed to always produce the same result (one embodiment uses a replica ID lexicographic comparison).
同じ競合に対して異なるレプリカによって異なる「新しい変更」が提案された場合、同期化サービスは、この新しい競合を特殊競合として処理し、ＣｏｎｆｌｉｃｔＬｏｇｇｅｒを使用してこれが他のレプリカに伝搬しないように防ぐ。そのような状況は一般に手動の競合解決で発生する。 If different “new changes” are proposed by different replicas for the same conflict, the synchronization service treats this new conflict as a special conflict and uses ConflictLogger to prevent it from propagating to other replicas. Such a situation typically occurs with manual conflict resolution.
２．非ストレージ・プラットフォーム・データ・ストアへの同期化
本発明のストレージ・プラットフォームのもう１つの態様によれば、ストレージ・プラットフォームはＩＳＶ向けアーキテクチャを提供して、ストレージ・プラットフォームがＭｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ、ＡＤ、Ｈｏｔｍａｉｌなどの既存のシステムに同期化することができる同期アダプタを実装する。同期アダプタは、以下に説明するように同期化サービスによって提供される多くのＳｙｎｃサービスからの恩恵を受ける。
2. Synchronization to a non-storage platform data store According to another aspect of the storage platform of the present invention, the storage platform provides an architecture for ISVs, such as Microsoft Exchange, AD, Hotmail, etc. Implement a synchronization adapter that can be synchronized to any existing system. The synchronization adapter benefits from the many Sync services provided by the synchronization service as described below.
その名前にもかかわらず、同期アダプタは、一部のストレージ・プラットフォーム・アーキテクチャにプラグインとして実装される必要はない。必要に応じて、「同期アダプタ」は単に、変更列挙などのサービスおよびアプリケーションを取得するために同期化サービス・ランタイム・インターフェースを利用するアプリケーションであってもよい。 Despite its name, the synchronization adapter does not need to be implemented as a plug-in in some storage platform architectures. As required, a “synchronization adapter” may simply be an application that utilizes a synchronization service runtime interface to obtain services and applications such as change enumeration.
他の人々がもっと簡単に同期化を所定のバックエンドに構成して同期化を実行できるようにするため、同期アダプタの作成者は、前述のように同期プロファイルを与えられて同期を実行する、標準同期アダプタ・インターフェースを公開するよう推奨される。このプロファイルは、アダプタに構成情報を提供し、その一部をアダプタは同期ランタイムに渡し、ランタイム・サービスを制御する（たとえば同期化するフォルダなど）。 To allow other people to more easily configure synchronization for a given backend and perform the synchronization, the creator of the synchronization adapter is given a synchronization profile as described above to perform the synchronization, It is recommended to expose the standard sync adapter interface. This profile provides configuration information to the adapter, which the adapter passes to the synchronization runtime and controls the runtime services (for example, folders to synchronize).
ａ）Ｓｙｎｃサービス（Sync Service）
同期化サービスは、いくつかのＳｙｎｃサービスをアダプタ作成者に提供する。これ以降このセクションでは、ストレージ・プラットフォームが同期化を行っているマシンを「クライアント」と呼び、アダプタが通信する非ストレージ・プラットフォーム・バックエンドを「サーバ」と呼ぶことが好都合である。
a) Sync service
The synchronization service provides a number of Sync services to the adapter creator. From now on, in this section, it is convenient to refer to the machine on which the storage platform is synchronizing as the "client" and to the non-storage platform backend with which the adapter communicates as the "server".
（１）変更の列挙（Change Enumeration）
同期化サービスによって保持される変更追跡データに基づいて、変更列挙は、このパートナが試行した前回の同期化以来データ・ストア・フォルダに発生した変更を同期アダプタが容易に列挙できるようにする。
(1) Change Enumeration
Based on the change tracking data maintained by the synchronization service, change enumeration allows the synchronization adapter to easily enumerate changes that have occurred in the data store folder since the last synchronization attempted by this partner.
変更は、「アンカー」の概念に基づいて列挙される。これは前回の同期化に関する情報を表す不透明な構造である。アンカーは、先のセクションで説明されているように、ストレージ・プラットフォーム知識の形態をとる。変更列挙サービスを利用する同期アダプタは、「格納されたアンカー」を使用するものと、「供給されたアンカー」を使用するものという、２つの広義のカテゴリに分類される。 Changes are enumerated based on the concept of “anchors”. This is an opaque structure that represents information about the previous synchronization. Anchors take the form of storage platform knowledge, as described in the previous section. Synchronous adapters that utilize the change enumeration service fall into two broad categories: those that use “stored anchors” and those that use “provided anchors”.
この区別は、前回の同期についての情報がクライアント上に格納されるの、またはサーバ上に格納されるのかを基にしている。多くの場合、アダプタがこの情報をクライアントに格納するほうが容易であり、バックエンドはこの情報を都合よく格納することができない場合が多い。一方、複数のクライアントが同じバックエンドに同期化する場合、この情報をクライアントに格納することは非効率的であり、場合によっては正しくなく、これは１つのクライアントが、既にサーバまで他のクライアントが押し上げた変更に気づかなくしてしまう場合がある。アダプタがサーバに格納されたアンカーを使用する場合は、アダプタは変更列挙の時点でこれをストレージ・プラットフォームに戻して供給する必要がある。 This distinction is based on whether information about the previous synchronization is stored on the client or on the server. In many cases, it is easier for the adapter to store this information on the client, and the back end often cannot store this information conveniently. On the other hand, when multiple clients synchronize to the same backend, storing this information on the client is inefficient and in some cases incorrect, as one client is already up to the server and the other clients You may be unaware of the push-up changes. If the adapter uses an anchor stored on the server, the adapter must supply it back to the storage platform at the time of change enumeration.
ストレージ・プラットフォームが（ローカルまたはリモート・ストレージの）アンカーを保持するためには、ストレージ・プラットフォームはサーバで正常に適用された変更を認識している必要がある。これら、且つこれらのみの変更が、アンカーに含むことができる。変更の列挙中、同期アダプタは、どの変更が正常に適用されたかをレポートするために肯定応答インターフェースを使用する。同期化の終わりに、供給されたアンカーを使用しているアダプタは（すべての正常に適用された変更を取り込む）新しいアンカーを読み取り、これをそのバックエンドに送信する必要がある。 In order for a storage platform to maintain an anchor (local or remote storage), the storage platform needs to be aware of changes that have been successfully applied on the server. These and only these changes can be included in the anchor. During enumeration of changes, the sync adapter uses an acknowledgment interface to report which changes have been successfully applied. At the end of the synchronization, the adapter using the supplied anchor needs to read the new anchor (capturing all successfully applied changes) and send it to its backend.
多くの場合、アダプタは、ストレージ・プラットフォームに挿入するアイテムと共にアダプタ固有のデータを格納する必要がある。そのようなデータの一般的な例には、リモートＩＤおよびリモート・バージョン（タイム・スタンプ）がある。同期化サービスは、このデータを格納するメカニズムを提供し、変更列挙は、この特別なデータを返された変更と共に受け取るメカニズムを提供する。これにより、ほとんどの場合、アダプタがデータベースに再度クエリを行う必要がなくなる。 In many cases, adapters need to store adapter-specific data along with items that are inserted into the storage platform. Common examples of such data are remote ID and remote version (time stamp). The synchronization service provides a mechanism for storing this data, and change enumeration provides a mechanism for receiving this special data with the returned changes. This in most cases eliminates the need for the adapter to query the database again.
（２）変更適用（Change Application）
変更適用は、同期アダプタが、そのバックエンドから受け取った変更をローカル・ストレージ・プラットフォームに適用することを可能にする。アダプタは、ストレージ・プラットフォーム・スキーマに変更を変換することが期待される。図２４は、ストレージ・プラットフォーム・スキーマからストレージ・プラットフォームＡＰＩクラスが生成されるプロセスを示す図である。
(2) Change Application
Applying changes allows the sync adapter to apply changes received from its backend to the local storage platform. The adapter is expected to convert changes to the storage platform schema. FIG. 24 illustrates the process by which the storage platform API class is generated from the storage platform schema.
変更適用（Change Application）の主な機能は、自動的に競合を検出することである。ストレージ・プラットフォーム間の同期の場合のように、競合は、２つの重複する変更が相互を認識することなく行われるものとして定義される。アダプタは変更適用を使用するとき、競合検出が実行されたアンカーを指定する必要がある。変更適用は、アダプタの知識にカバーされていない重複するローカルの変更が検出された場合に、競合を提起する。変更列挙と同様に、アダプタは格納されたアンカーまたは供給されたアンカーを使用することができる。変更適用は、アダプタ固有のメタデータの効率的な格納をサポートする。そのようなデータは、アダプタによって適用される変更に接続することができ、同期化サービスによって格納することもできる。このデータは、次の変更列挙で戻されることになる。 The main function of Change Application is to automatically detect conflicts. As in the case of synchronization between storage platforms, contention is defined as two overlapping changes made without recognizing each other. When an adapter uses change apply, it must specify the anchor on which conflict detection was performed. Change application raises a conflict when duplicate local changes are detected that are not covered by the adapter knowledge. Similar to change enumeration, the adapter can use a stored anchor or a supplied anchor. Change application supports efficient storage of adapter-specific metadata. Such data can be connected to changes applied by the adapter and can also be stored by the synchronization service. This data will be returned in the next change enumeration.
（３）競合の解決
前述の競合解決メカニズム（ロギングおよび自動解決のオプション）は、同期アダプタでも使用することができる。同期アダプタは、変更を適用するときに競合解決のポリシーを指定することができる。指定した場合、競合は指定された競合ハンドラに渡されて（可能であれば）解決される。競合はログに記録することもできる。アダプタが、ローカルの変更をバックエンドに適用しようとしたときに、競合を検出する可能性もある。そのような場合、アダプタは、さらに、その競合を同期ランタイムに渡して、ポリシーに従って解決されるようにすることができる。さらに、同期アダプタは、同期化サービスによって検出された競合を処理のために、送り戻すように要求することもできる。これは、バックエンドが競合を格納または解決できるような場合に、特に便利である。
(3) Conflict Resolution The conflict resolution mechanism described above (logging and automatic resolution options) can also be used with the synchronous adapter. The synchronization adapter can specify a conflict resolution policy when applying changes. If specified, the conflict is passed to the specified conflict handler and resolved (if possible). Conflicts can also be logged. It is also possible for the adapter to detect a conflict when trying to apply local changes to the backend. In such cases, the adapter can further pass the conflict to the synchronization runtime to be resolved according to policy. In addition, the synchronization adapter may request that conflicts detected by the synchronization service be sent back for processing. This is particularly useful when the backend can store or resolve conflicts.
ｂ）アダプタの実装
一部の「アダプタ」は、単に、ランタイム・インターフェースを使用するアプリケーションであるが、アダプタは標準アダプタ・インターフェースを実装するよう推奨される。これらのインターフェースにより、同期制御アプリケーションは、アダプタが所定の同期プロファイルに従って同期化を実行するよう要求すること、実行中の同期化を取り消すこと、実行中の同期化に関する進行状況レポート（完了したパーセント）を受け取ること、が可能になる。
b) Adapter implementation Some "adapter" is simply an application that uses the runtime interface, but it is recommended that the adapter implement the standard adapter interface. These interfaces allow the synchronization control application to request that the adapter perform synchronization according to a given synchronization profile, cancel the ongoing synchronization, and a progress report on the ongoing synchronization (percent completed) Can be received.
３．セキュリティ
同期化サービスは、ストレージ・プラットフォームによって実装されるセキュリティ・モデルに持ち込むものを、できるだけ少なくしようと努める。同期のための新しい権限を定義するのではなく、既存の権限が使用される。具体的には、次のようになっている。
・ データ・ストア・アイテムを読み取りできる者は誰でもそのアイテムへの変更を列挙することができる。
・ データ・ストア・アイテムに書き込みできる者は誰でもそのアイテムへの変更を適用することができる。
・ データ・ストア・アイテムを拡張できる者は誰でも同期メタデータをそのアイテムに関連付けることができる。
3. Security Synchronization services strive to reduce as much as possible the security model implemented by the storage platform. Rather than defining new permissions for synchronization, existing permissions are used. Specifically, it is as follows.
• Anyone who can read a data store item can enumerate changes to that item.
• Anyone who can write to a data store item can apply changes to that item.
Anyone who can extend a data store item can associate sync metadata with that item.
同期化サービスは、セキュリティ保護された作成者情報（secure authorship information）を保持しない。ユーザＵによって変更がレプリカＡに行われ、レプリカＢに転送された場合、最初にＡ（またはＵによって）変更が行われたという事実は失われる。Ｂがこの変更をレプリカＣに転送する場合、これはＡの権限ではなく、Ｂの権限のもとで行われる。このことは、レプリカがアイテムに独自の変更を行うことを任されていない場合、これは他のレプリカによって行われた変更を転送することができないという制約をもたらす。 The synchronization service does not maintain secure authorship information. If a change is made to replica A by user U and forwarded to replica B, the fact that the change was first made (or by U) is lost. If B forwards this change to replica C, this is done under B's authority, not A's authority. This places the constraint that if a replica is not entrusted to make its own changes to an item, this cannot transfer changes made by other replicas.
同期化サービスが開始されると、これは同期制御アプリケーションによって行われる。同期化サービスは、ＳＣＡのＩＤを偽装し、そのＩＤのもとですべてのオペレーションを（ローカルならびにリモートに）実行する。たとえば、ユーザＵは、ユーザＵが読み取りアクセス権を持たないアイテムのリモート・ストレージ・プラットフォームから変更を取り出すことをローカルの同期化サービスにさせることはできないことに注目されたい。 This is done by the synchronization control application when the synchronization service is started. The synchronization service impersonates the SCA's ID and performs all operations (locally and remotely) under that ID. For example, note that user U cannot have the local synchronization service retrieve changes from a remote storage platform for items for which user U does not have read access.
４．管理容易性（Manageability）
レプリカについての分散コミュニティを監視することは、複雑な問題である。同期化サービスは、「スイープ」アルゴリズムを使用して、レプリカの状態に関する情報を収集して配信することができる。スイープ・アルゴリズムのプロパティは、すべての構成済みのレプリカに関する情報が最終的には収集されること、および失敗した（非応答）レプリカが検出されることを、確実にする。
4). Manageability
Monitoring the distributed community for replicas is a complex issue. The synchronization service can collect and distribute information about the state of the replica using a “sweep” algorithm. The properties of the sweep algorithm ensure that information about all configured replicas is eventually collected and that failed (non-responding) replicas are detected.
このコミュニティ全体の監視情報は、すべてのレプリカで使用できるようになっている。監視ツールは、任意に選択されたレプリカで実行し、この監視情報を検査して管理上の意思決定を行うことができる。構成の変更は、影響を受けるレプリカで直接行う必要がある。 This community-wide monitoring information is made available to all replicas. The monitoring tool can be executed on an arbitrarily selected replica and inspect this monitoring information to make a management decision. Configuration changes must be made directly on the affected replica.
Ｈ．従来型ファイル・システムの相互運用性
前述のように、本発明のストレージ・プラットフォームは、少なくとも一部の実施例において、コンピュータ・システムのハードウェア／ソフトウェア・インターフェース・システムの不可欠部分として組み入れられることを目的としている。たとえば、本発明のストレージ・プラットフォームは、オペレーティング・システムのＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）ファミリなど、オペレーティング・システムの不可欠部分として組み入れることもできる。その能力において、ストレージ・プラットフォームＡＰＩは、アプリケーション・プログラムがそれを通してオペレーティング・システムと対話するオペレーティング・システムＡＰＩの一部となる。したがって、ストレージ・プラットフォームは、それを通してアプリケーション・プログラムがオペレーティング・システムに情報を格納する手段となり、そのためストレージ・プラットフォームのアイテム・ベースのデータ・モデルはそのようなオペレーティング・システムの従来型ファイル・システムに取って代わるものになる。たとえば、オペレーティングのＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）ファミリに組み入れられると、ストレージ・プラットフォームは、そのオペレーティング・システムに実装されているＮＴＦＳファイル・システムに取って代わることもできる。現在、アプリケーション・プログラムは、オペレーティング・システムのＷｉｎｄｏｗｓ（登録商標）ファミリによって公開されているＷｉｎ３２ ＡＰＩを通じてＮＴＦＳファイル・システムのサービスにアクセスしている。
H. Conventional File System Interoperability As noted above, the storage platform of the present invention is incorporated in at least some embodiments as an integral part of a computer system hardware / software interface system. It is aimed. For example, the storage platform of the present invention may be incorporated as an integral part of an operating system, such as the Microsoft Windows® family of operating systems. In its capabilities, the storage platform API becomes part of the operating system API through which application programs interact with the operating system. Thus, the storage platform provides the means through which application programs store information in the operating system, so that the storage platform's item-based data model is in the traditional file system of such operating system. It will replace it. For example, when incorporated into the Microsoft Windows family of operating systems, the storage platform can also replace the NTFS file system implemented in that operating system. Currently, application programs access NTFS file system services through the Win32 API published by the Windows® family of operating systems.
しかし、本発明のストレージ・プラットフォームがＮＴＦＳファイル・システムに完全に取って代わるには、既存のＷｉｎ３２ベースのアプリケーション・プログラムの再コード化が必要になることになり、そのような再コード化は望ましくない場合もあることを認識すると、本発明のストレージ・プラットフォームがＮＴＦＳなどの既存のファイル・システムとの何らかの相互運用性を提供することは有益であると考えられる。したがって、本発明の１つの実施例において、このストレージ・プラットフォームは、Ｗｉｎ３２プログラミング・モデルに依存するアプリケーション・プログラムがこのストレージ・プラットフォームのデータ・ストアおよび従来型ＮＴＦＳファイル・システムの両方のコンテンツにアクセスできるようにする。この目的のために、このストレージ・プラットフォームでは、Ｗｉｎ３２命名規則のスーパーセットである命名規則を使用して相互運用を容易にする。さらに、このストレージ・プラットフォームは、Ｗｉｎ３２ ＡＰＩを通じてストレージ・プラットフォーム・ボリューム内に格納されているファイルおよびディレクトリへのアクセスをサポートする。 However, in order for the storage platform of the present invention to completely replace the NTFS file system, re-coding of existing Win32-based application programs will be required, and such re-coding is desirable. Recognizing that this may not be the case, it would be beneficial for the storage platform of the present invention to provide some interoperability with existing file systems such as NTFS. Thus, in one embodiment of the present invention, the storage platform allows application programs that rely on the Win32 programming model to access the contents of both the storage platform data store and the traditional NTFS file system. Like that. For this purpose, this storage platform uses a naming convention that is a superset of the Win32 naming convention to facilitate interoperability. In addition, the storage platform supports access to files and directories stored within the storage platform volume through the Win32 API.
この機能性に関する詳細については、先に参照により本明細書に組み込まれている関連出願において説明されている。 Details regarding this functionality are described in the related applications previously incorporated herein by reference.
Ｉ．ストレージ・プラットフォームＡＰＩ
ストレージ・プラットフォームは、アプリケーションが前述のストレージ・プラットフォームの特徴および機能にアクセスして、データ・ストアに格納されているアイテムにアクセスできるようにするＡＰＩを備えている。このセクションでは、本発明によるストレージ・プラットフォームのストレージ・プラットフォームＡＰＩの１つの実施例について説明する。この機能性に関する詳細については、先に参照により本明細書に組み込まれている関連出願において説明されているが、以下に便宜のためその情報の一部をまとめておく。
I. Storage platform API
The storage platform includes an API that allows applications to access the storage platform features and functions described above to access items stored in the data store. This section describes one embodiment of the storage platform API of the storage platform according to the present invention. Details regarding this functionality have been described in the related applications previously incorporated herein by reference, but some of that information is summarized below for convenience.
図１８を参照すると、包含フォルダは他のアイテムへの保持リレーションシップを収容するアイテムであり、ファイル・システム・フォルダの一般的な概念に相当するものである。各アイテムは、少なくとも１つの包含フォルダ内に「含まれて」いる。 Referring to FIG. 18, an inclusion folder is an item that contains a retention relationship to another item, and corresponds to the general concept of a file system folder. Each item is “contained” in at least one inclusion folder.
図１９は、本発明の実施例によるストレージ・プラットフォームＡＰＩの基本アーキテクチャを示している。ストレージ・プラットフォームＡＰＩは、ＳＱＬクライアント１９００を使用してローカル・データ・ストア３０２と通信し、さらにＳＱＬクライアント１９００を使用してリモート・データ・ストア（たとえばデータ・ストア３４０）と通信することもできる。ローカル・ストア３０２は、ＤＱＰ（分散クエリ・プロセッサ）を使用するかまたは前述のストレージ・プラットフォーム同期化サービス（「Ｓｙｎｃ」）を通じてリモート・データストア３４０とも通信することができる。ストレージ・プラットフォームＡＰＩ３２２は、データ・ストア通知のためのブリッジＡＰＩとしての役割も果たして、前述のように、アプリケーションのサブスクリプションを通知エンジン３３２に渡し、ルーティング通知をアプリケーション（たとえばアプリケーション３５０ａ、３５０ｂ、３５０ｃ）に渡す。１つの実施例において、ストレージ・プラットフォームＡＰＩ３２２は、Ｍｉｃｒｏｓｏｆｔ ＥｘｃｈａｎｇｅおよびＡＤ内のデータにアクセスできるように限定「プロバイダ」アーキテクチャを定義することもできる。
FIG. 19 illustrates the basic architecture of the storage platform API according to an embodiment of the present invention. The storage platform API may communicate with the
図２０は、ストレージ・プラットフォームＡＰＩのさまざまなコンポーネントを概略的に表している。ストレージ・プラットフォームＡＰＩは、以下のコンポーネントを備えている。（１）ストレージ・プラットフォーム要素およびアイテム・タイプを表すデータ・クラス２００２、（２）オブジェクト永続性を管理してクラス２００６にサポートを提供するランタイム・フレームワーク２００４、および（３）ストレージ・プラットフォーム・スキーマからＣＬＲクラスを生成するために使用されるツール２００８。
FIG. 20 schematically represents the various components of the storage platform API. The storage platform API includes the following components: (1) a
所定のスキーマにより生じるクラスの階層は、そのスキーマ内のタイプの階層に直接反映する。一例として、図２１Ａおよび図２１Ｂに示すような連絡先スキーマで定義されているアイテム・タイプを考察する。 The hierarchy of classes generated by a given schema directly reflects the type hierarchy within that schema. As an example, consider an item type defined in a contact schema as shown in FIGS. 21A and 21B.
図２２は、オペレーションにおけるランタイム・フレームワークを示している。ランタイム・フレームワークは、以下のように機能する。
１．アプリケーション３５０ａ、３５０ｂ、または３５０ｃは、ストレージ・プラットフォーム内のアイテムにバインドする。
２．フレームワーク２００４は、バインドされるアイテムに対応するＩｔｅｍＣｏｎｔｅｘｔオブジェクト２２０２を作成して、それをアプリケーションに返す。
３．アプリケーションはこのＩｔｅｍＣｏｎｔｅｘｔにＦｉｎｄをサブミットしてアイテムのコレクションを取得する。返されたコレクションは概念上は（リレーションシップにより）オブジェクト・グラフ２２０４である。
４．アプリケーションは、データを変更、削除、および挿入する。
５．アプリケーションは、Ｕｐｄａｔｅ（）メソッドを呼び出すことにより変更を保存する。
FIG. 22 shows the runtime framework in operation. The runtime framework works as follows:
1. Application 350a, 350b, or 350c binds to an item in the storage platform.
2. The
3. The application submits Find to this ItemContext to obtain a collection of items. The returned collection is conceptually an object graph 2204 (by relationship).
4). The application changes, deletes, and inserts data.
5. The application saves changes by calling the Update () method.
図２３は、「ＦｉｎｄＡｌｌ」オペレーションの実行を示している。 FIG. 23 illustrates execution of the “FindAll” operation.
図２４は、ストレージ・プラットフォーム・スキーマからストレージ・プラットフォームＡＰＩクラスが生成されるプロセスを示している。 FIG. 24 illustrates the process by which the storage platform API class is generated from the storage platform schema.
図２５は、ファイルＡＰＩが基にするスキーマを示す図である。ストレージ・プラットフォームＡＰＩは、ファイル・オブジェクトを処理するネーム・スペースを備えている。このネーム・スペースは、Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｆｉｌｅｓと呼ばれる。Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｆｉｌｅｓのクラスのデータ・メンバは、ストレージ・プラットフォーム・ストアに格納されている情報に直接反映する。この情報は、ファイル・システム・オブジェクトから「プロモート」されるか、またはＷｉｎ３２ ＡＰＩを使用してネイティブに作成される。Ｓｙｓｔｅｍ．Ｓｔｏｒａｇｅ．Ｆｉｌｅｓには、ＦｉｌｅＩｔｅｍおよびＤｉｒｅｃｔｏｒｙＩｔｅｍという２つのクラスがある。これらのクラスおよびそのメソッドのメンバは、図２５のスキーマ図を見ることによって容易に予測することができる。ＦｉｌｅＩｔｅｍおよびＤｉｒｅｃｔｏｒｙＩｔｅｍは、ストレージ・プラットフォームＡＰＩから読み取り専用である。これらを変更するためには、Ｗｉｎ３２ ＡＰＩまたはＳｙｓｔｅｍ．ＩＯのクラスを使用する必要がある。 FIG. 25 is a diagram showing a schema on which the file API is based. The storage platform API has a name space for processing file objects. This name space is called System. Storage. Called Files. System. Storage. The data members of the Files class reflect directly in the information stored in the storage platform store. This information is “promoted” from the file system object or created natively using the Win32 API. System. Storage. There are two classes of Files: FileItem and DirectoryItem. The members of these classes and their methods can be easily predicted by looking at the schema diagram of FIG. FileItem and DirectoryItem are read-only from the storage platform API. To change these, either Win32 API or System. It is necessary to use the IO class.
ＡＰＩに関して、プログラミング・インターフェース（あるいは単にインターフェース）は、コードの１つまたは複数のセグメントがコードの１つまたは複数の他のセグメントによって提供される機能と通信またはアクセスできるようにする任意のメカニズム、プロセス、プロトコルと考えることができる。あるいは、プログラミング・インターフェースは、他のコンポーネントの１つまたは複数のメカニズム、メソッド、関数呼び出し、モジュールなどに通信の接続が可能なシステムのコンポーネントの１つまたは複数のメカニズム、メソッド、関数呼び出し、モジュール、オブジェクトなどとして考えることができる。前の文章において「コードのセグメント」という用語は、１つまたは複数の命令またはコードの行（lines）を含むことを意図しており、適用される用語、コード・セグメントが別個にコンパイルされるかどうか、あるいはコード・セグメントがソース、中間、またはオブジェクトコードとして提供されるかどうか、コード・セグメントがランタイム・システムまたはプロセスで使用されるかどうか、これらが同じまたは異なるマシンに位置するかまたは複数のマシンにわたり分散されるか、あるいはコードのセグメントによって現される機能性が全体としてソフトウェアに、全体としてハードウェアに、またはハードウェアとソフトウェアの組み合わせに実装されるかどうかにかかわりなく、たとえばコード・モジュール、オブジェクト、サブルーチン、関数などを含んでいる。 With respect to an API, a programming interface (or simply an interface) is any mechanism, process that allows one or more segments of code to communicate or access functions provided by one or more other segments of code. Can be considered a protocol. Alternatively, the programming interface can be one or more mechanisms, methods, function calls, modules, components of a system that can be connected in communication to one or more mechanisms, methods, function calls, modules, etc. of other components. Think of it as an object. In the previous sentence, the term “code segment” is intended to include one or more instructions or lines of code, and the term applied, whether the code segment is compiled separately Whether or not the code segment is provided as source, intermediate, or object code, whether the code segment is used in a runtime system or process, whether they are located on the same or different machines, or multiple Regardless of whether the functionality distributed across the machine or represented by a segment of code is implemented entirely in software, entirely in hardware, or a combination of hardware and software, for example, code modules , Object, support Routine, and includes a like function.
概念的には、プログラミング・インターフェースは、図３０Ａまたは図３０Ｂに示すように一般的に表すことができる。図３０Ａでは、インターフェースＩｎｔｅｒｆａｃｅ１を、第１のコード・セグメントおよび第２のコード・セグメントとの間の通信で使用するコンジットとして示している。図３０Ｂでは、システムの第１および第２のコード・セグメントが媒体Ｍを介して通信できるようにするインターフェース・オブジェクトＩ１およびＩ２（これらは、第１および第２のコードの一部であっても一部でなくてもよい）を備えるインターフェースを示している。図３０Ｂの視点として、インターフェース・オブジェクトＩ１およびＩ２を同じシステムの別個のインターフェースと見なすこともでき、またはオブジェクトＩ１およびＩ２と媒体Ｍがインターフェースを構成していると見なすこともできる。図３０Ａおよび３０Ｂは、双方向フローおよびそのフローの両側のインターフェースを示しているが、特定の実施態様では、単方向の情報フロー（または以下に説明するように情報フローなし）しか持つことができない、または一方の側にインターフェース・オブジェクトを持つことしかできない。一例として、アプリケーション・プログラミング・インターフェース（ＡＰＩ）、エントリポイント、メソッド、関数、サブルーチン、リモート・プロシージャ呼び出し、およびコンポーネント・オブジェクト・モデル（ＣＯＭ）インターフェースは、プログラミング・インターフェースの定義の範囲内に包含されるが、これらに限定されることはない。 Conceptually, the programming interface can be generally represented as shown in FIG. 30A or FIG. 30B. In FIG. 30A, the interface Interface1 is shown as a conduit used in communication between the first code segment and the second code segment. In FIG. 30B, interface objects I1 and I2 (which may be part of the first and second code) that allow the first and second code segments of the system to communicate over the medium M. FIG. 2 shows an interface that may not be a part). From the perspective of FIG. 30B, interface objects I1 and I2 can be considered as separate interfaces of the same system, or objects I1 and I2 and medium M can be considered to constitute an interface. Although FIGS. 30A and 30B show a bidirectional flow and interfaces on both sides of that flow, in certain implementations it can only have a unidirectional information flow (or no information flow as described below). Or you can only have an interface object on one side. As an example, application programming interfaces (APIs), entry points, methods, functions, subroutines, remote procedure calls, and component object model (COM) interfaces are included within the definition of programming interfaces. However, it is not limited to these.
そのようなプログラミング・インターフェースの態様は、第１のコード・セグメントが情報（ここで「情報」は、その最も広い意味で使用され、データ、コマンド、要求などを含んでいる）を第２のコード・セグメントに伝送する方法、第２のコード・セグメントが情報を受け取る方法、および情報の構造、シーケンス、構文、編成、スキーマ、タイミング、コンテンツを含むことができる。この点において、情報がインターフェースによって定義された方法でトランスポートされる限り、媒体が有線または無線あるいは両方の組み合わせであっても、基礎を成すトランスポート媒体自体はインターフェースのオペレーションにとって重要ではない。特定の状況において、情報の転送が他のメカニズム（たとえば、コード・セグメント間の情報フローから分離したバッファ、ファイルなどに置かれた情報）を介するかまたは存在しない場合もあり、１つのコード・セグメントが単に第２のコード・セグメントによって実行される機能にアクセスする場合のように、情報が従来の意味では単方向または双方向に渡されないこともある。それらの任意の態様またはすべての態様は、たとえばコード・セグメントが疎結合または密結合の構成のシステムの一部であるかどうかに応じてなど、所定の状況において重要となる場合がある。そのため、このリストは例示的なものであって、限定的ではないと考えるべきである。 An aspect of such a programming interface is that a first code segment uses information (where "information" is used in its broadest sense and includes data, commands, requests, etc.) It can include how to transmit to the segment, how the second code segment receives information, and the structure, sequence, syntax, organization, schema, timing, content of the information. In this regard, the underlying transport medium itself is not critical to the operation of the interface, as long as the information is transported in a manner defined by the interface, whether the medium is wired or wireless or a combination of both. In certain circumstances, the transfer of information may be through other mechanisms (eg, information placed in buffers, files, etc. that are separate from the information flow between code segments), or may not exist in one code segment Information may not be passed unidirectionally or bidirectionally in the conventional sense, such as when accessing the function performed by the second code segment. Any or all of those aspects may be important in a given situation, for example depending on whether the code segment is part of a loosely coupled or tightly coupled configuration system. As such, this list should be considered exemplary and not limiting.
このプログラミング・インターフェースの概念は、当業者には周知であり、本発明の前述の詳細な説明から明瞭である。ただし、プログラミング・インターフェースを実装する他の方法もあり、明示的に除外されていない限り、これらも本明細書の特許請求の範囲に含まれるものとする。そのような他の方法は、単純化した図３０Ａおよび図３０Ｂに比べて精巧または複雑なものに見えることもあるが、これらはそれでもなお同様の機能を実行して同じ全体的な結果を達成する。ここでプログラミング・インターフェースの例示的な代替実施態様について簡単に説明する。 This programming interface concept is well known to those skilled in the art and is clear from the foregoing detailed description of the invention. However, there are other ways of implementing the programming interface, and these are intended to be included within the scope of the claims herein, unless explicitly excluded. Such other methods may appear elaborate or complex compared to the simplified FIGS. 30A and 30B, but they still perform similar functions to achieve the same overall result. . An exemplary alternative implementation of the programming interface will now be briefly described.
ファクタリング（Factoring；要素への分解）：１つのコード・セグメントからもう１つのコード・セグメントへの通信は、通信を複数の別個の通信に分割することにより間接的に達成できる。このことについては、図３１Ａおよび図３１Ｂに概略が示されている。図示されているように、一部のインターフェースは機能の分割可能なセットの観点から説明することができる。したがって、図３０Ａおよび図３０Ｂのインターフェース機能は、ちょうど数学的に、２４を、あるいは２×２×３×２を提供するように、同じ結果を達成するために要素に分解することができる。その結果、図３１Ａに示すように、インターフェース１によって提供される機能が分割されて、インターフェースの通信をインターフェース１Ａ、インターフェース１Ｂ、インターフェース１Ｃなどの複数のインターフェースに変換され、しかも同じ結果を達成することができる。図３１Ｂに示すように、インターフェースＩ１によって提供される機能は、インターフェースＩ１ａ、インターフェースＩ１ｂ、インターフェースＩ１ｃなどの複数のインターフェースに分割され、しかも同じ結果を達成することができる。同様に、第１のコード・セグメントから情報を受け取る第２のコード・セグメントのインターフェースＩ２は、複数のインターフェースＩ２ａ、Ｉ２ｂ、Ｉ２ｃなどにファクタリングすることができる。ファクタリングするとき、第１のコード・セグメントに含まれるインターフェースの数は、第２のコード・セグメントに含まれるインターフェースの数と一致する必要はない。図３１Ａおよび図３１Ｂのいずれの場合でも、インターフェースＩおよびＩ１の機能上の意図は、それぞれ図３０Ａおよび図３０Ｂの場合と同じ状態のままである。インターフェースのファクタリングはさらに、連想（associative）、可換（commutative）、その他の数学的プロパティにも従うことができ、それによって、そのファクタリングをわかりにくくすることができる。たとえば、オペレーションの順序付けは重要ではないこともあり、その場合、インターフェースによって実行される関数は、インターフェースに到達する相当前に実行したり、他のコードまたはインターフェースによって実行したり、またはシステムの別のコンポーネントによって実行したりすることができる。さらに、プログラミングの技術分野の当業者であれば、同じ結果を達成する異なる関数呼び出しを行うさまざまな方法があることを理解できよう。
Factoring: Communication from one code segment to another can be achieved indirectly by dividing the communication into multiple separate communications. This is outlined in FIGS. 31A and 31B. As shown, some interfaces can be described in terms of a separable set of functions. Thus, the interface function of FIGS. 30A and 30B can be broken down into elements to achieve the same result, just mathematically, to provide 24, or 2 × 2 × 3 × 2. As a result, as shown in FIG. 31A, the function provided by the
再定義（Redefinition）：場合によっては、意図した結果を達成しながらも、プログラミング・インターフェースの特定の態様（たとえばパラメータ）を無視、追加、または再定義することが可能である。これは、図３２Ａおよび図３２Ｂに示されている。たとえば、図３０Ａのインターフェース１が、３つのパラメータｉｎｐｕｔ、ｐｒｅｃｉｓｉｏｎおよびｏｕｔｐｕｔを含む呼び出しである、関数呼び出しＳｑｕａｒｅ（ｉｎｐｕｔ、ｐｒｅｃｉｓｉｏｎ、ｏｕｔｐｕｔ）を含んでおり、これが第１のコード・セグメントから第２のコード・セグメントに発行されると想定する。中央のパラメータｐｒｅｃｉｓｉｏｎが、図３２Ａに示すように所定のシナリオにおいて無用の場合、これを単に無視したり、または意味のない（この状況において）パラメータに置き換えられることもできる。さらに、関係のない追加パラメータを加えることもできる。いずれの場合にも、ｉｎｐｕｔが第２のコード・セグメントによって二乗された後にｏｕｔｐｕｔが返される限り、Ｓｑｕａｒｅの機能は達成することができる。ｐｒｅｃｉｓｉｏｎは、コンピューティング・システムの一部の下流や他の部分にとって十分に意味のあるパラメータである。しかし、ｐｒｅｃｉｓｉｏｎが二乗を計算する狭義の目的には必要ないと認識されると、これは置き換えられるかまたは無視される可能性がある。たとえば、有効なｐｒｅｃｉｓｉｏｎ値を渡す代わりに、誕生日などの意味のない値を結果に悪影響を及ぼすことなく渡すこともできる。同様に、図３２Ｂに示すように、インターフェースＩ１はインターフェースＩ１’に置き換えられ、パラメータを無視するかまたはインターフェースにパラメータを追加するように再定義される。インターフェースＩ２は、インターフェースＩ２’と同様に再定義され、不必要なパラメータまたは他の場所で処理されるパラメータを無視するように再定義される。ここで重要なことは、場合によってはプログラミング・インターフェースが、一部の目的には必要のないパラメータなどの態様（aspect）を含むこともでき、そのためこれらは無視したり、再定義したり、または他の目的のために他の場所で処理したりすることができるということである。
Redefinition: In some cases, certain aspects (eg, parameters) of the programming interface can be ignored, added, or redefined while achieving the intended result. This is illustrated in FIGS. 32A and 32B. For example,
インライン・コーディング：２つの別個のコード・モジュールの機能の一部または全体を、それらの間の「インターフェース」形状を変えるように、マージすることも実現可能である。たとえば、図３０Ａおよび図３０Ｂの機能は、それぞれ図３３Ａおよび図３３Ｂの機能に変換することができる。図３３Ａにおいて、図３０Ａの以前の第１および第２のコード・セグメントは、その両方を含む１つのモジュールにマージされる。この場合、コード・セグメントは引き続き相互に通信しているが、インターフェースは単一モジュールにより適した形態に適合することができる。したがって、たとえば、正式なＣａｌｌおよびＲｅｔｕｒｎステートメントはもはや必要なくなるが、インターフェース１に準じた同様の処理または応答は引き続き有効である場合がある。同様に、図３３Ｂに示されているように、図３０ＢからのインターフェースＩ２の一部または全体がインターフェースＩ１にインラインで書き込まれてインターフェースＩ１”を形成することができる。図に示すように、インターフェースＩ２はＩ２ａおよびＩ２ｂに分割され、インターフェース部分Ｉ２ａはインターフェースＩ１によりインラインでコーディングされてインターフェースＩ１”を形成する。具体的な例として、図３０ＢのインターフェースＩ１が、関数呼び出しＳｑｕａｒｅ（ｉｎｐｕｔ、ｏｕｔｐｕｔ）を実行し、これがインターフェースＩ２によって受け取られ、第２のコード・セグメントによって（二乗すべき）ｉｎｐｕｔで渡された値の処理した後に、二乗の結果がｏｕｔｐｕｔとして戻されるとする。そのような場合には、第２のコード・セグメントによって実行される処理（ｉｎｐｕｔを二乗する）は、インターフェースへの呼び出しを行わずに第１のコード・セグメントによって実行することができる。
Inline coding: It is also feasible to merge some or all of the functions of two separate code modules to change the “interface” shape between them. For example, the functions of FIGS. 30A and 30B can be converted to the functions of FIGS. 33A and 33B, respectively. In FIG. 33A, the previous first and second code segments of FIG. 30A are merged into one module containing both. In this case, the code segments continue to communicate with each other, but the interface can be adapted to a more suitable form for a single module. Thus, for example, formal Call and Return statements are no longer needed, but similar processing or responses according to
ディボース（Divorce：分離）：１つのコード・セグメントからもう１つのコード・セグメントへの通信は、通信を複数の別個の通信に分割（breaking）することにより間接的に達成できる。このことについては、図３４Ａおよび図３４Ｂに概略が示されている。図３４Ａに示すように、第１のインターフェースであるインターフェース１上の通信を異なるインターフェース（この場合はインターフェース２Ａ、インターフェース２Ｂおよびインターフェース２Ｃ）に適合するように変換するために、１つまたは複数のミドルウェア（分離インターフェース、機能および／またはインターフェース機能を元のインターフェースから分離するので）が提供される。こうしたことを行うのは、たとえば、インターフェース１プロトコルに従ってオペレーティング・システムと通信するように設計されているアプリケーションのインストールされたベースがある場合であり、しかし、この場合、オペレーティング・システムは異なるインターフェース（この場合はインターフェース２Ａ、インターフェース２Ｂおよびインターフェース２Ｃ）を使用するように変更される。このポイントは、第２のコード・セグメントで使用されていた元のインターフェースがもはや、第１のコード・セグメントによって使用されるインターフェースとの互換性を保たなくなり、そこで、以前のインターフェースと新しいインターフェースの互換をとるように仲介物が使用される。同様に、図３４Ｂに示すように、第３のコード・セグメントを導入して、インターフェースＩ１からの通信を分離インターフェースＤＩ１で受け取り、分離インターフェースＤＩ２からインターフェース機能を、たとえば、ＤＩ２と動作するように再設計されたインターフェースＩ２ａおよびＩ２ｂに送信して、機能的に同じ結果を得ることができる。同様に、ＤＩ１およびＤＩ２は連携して、図３０ＢのインターフェースＩ１およびＩ２の機能を新しいオペレーティング・システム向けに変換し、しかも同じまたは同等の機能的結果を提供することができる。
Divorce: Communication from one code segment to another can be achieved indirectly by breaking the communication into multiple separate communications. This is outlined in FIGS. 34A and 34B. As shown in FIG. 34A, one or more middlewares to convert communications on the first interface,
再書き込み（Rewriting）：さらにもう１つの可能な変形は、コードを動的に再書き込みして、インターフェース機能を同じ全体的結果を達成する他のものと置き換えることである。たとえば、中間言語（Ｍｉｃｒｏｓｏｆｔ ＩＬ、Ｊａｖａ（登録商標）ＢｙｔｅＣｏｄｅなど）で提示されたコード・セグメントが実行環境（Ｎｅｔフレームワーク、Ｊａｖａ（登録商標）ランタイム環境、または他の同様のランタイムタイプの環境によって提供される実行環境）においてＪｕｓｔ−Ｉｎ−Ｔｉｍｅ（ＪＩＴ）コンパイラまたはインタープリタに提供されるシステムもある。ＪＩＴコンパイラは、第１のコード・セグメントから第２のコード・セグメントへの通信を動的に変換するように、すなわち、これらを第２のコード・セグメント（元のまたは異なる第２のコード・セグメントのいずれでも）に要求される可能性のある異なるインターフェースに適合させるように、再書き込みされる。これは、図３５Ａおよび図３５Ｂに示されている。図３５Ａに示すように、この手法は、前述のディボースのシナリオと類似している。これは、たとえば、複数のアプリケーションがインストールされたベースが、インターフェース１プロトコルに従ってオペレーティング・システムと通信するように設計されている場合であり、そのためにオペレーティング・システムが異なるインターフェースを使用するように変更される場合に行われる。ＪＩＴコンパイラは、インストール・ベースのアプリケーションからの通信をオペレーティング・システムの新しいインターフェースに、直ちに（on the fly）に準拠させるために使用することができる。図３５Ｂに示すように、インターフェースを動的に再書き込みするこの手法は、インターフェースの動的なファクタリングや改変に適用することができる。
Rewriting: Yet another possible variant is to dynamically rewrite the code, replacing interface functions with others that achieve the same overall result. For example, code segments presented in intermediate languages (Microsoft IL, Java ByteCode, etc.) are provided by an execution environment (Net framework, Java runtime environment, or other similar runtime type environment) Some systems are provided to a Just-In-Time (JIT) compiler or interpreter. The JIT compiler dynamically translates communication from the first code segment to the second code segment, i.e., converts them into the second code segment (original or different second code segment). Rewritten to adapt to different interfaces that may be required. This is illustrated in FIGS. 35A and 35B. As shown in FIG. 35A, this approach is similar to the previously described debose scenario. This is the case, for example, when a base with multiple applications installed is designed to communicate with the operating system according to the
代替実施例を介して同じまたは類似したインターフェースとして結果を達成する前述のシナリオは、著くれるおよび／または並列式にさまざまな方法で組み合わせることも、あるいは他の介在コードと組み合わせることもできることに留意されたい。したがって、上記で提示されている代替実施例は相互に排他的なものではなく、図３０Ａおよび図３０Ｂに提示されている汎用のシナリオと同じまたは同様のシナリオを生成するために、混在させ、整合させ、よび結合させることも可能である。さらに、多くのプログラミング構成体の場合と同様に、本明細書において説明されていないが、それでもなお本発明の精神および範囲によって表される、同じまたは同等のインターフェースの機能を達成する同様の方法が他にもあることにも留意されたい。すなわち、それは少なくとも部分的に、インターフェースの価値の基礎をなすインターフェースによって表される機能、およびそれによって実現される有利な結果であることに留意されたい。 It is noted that the above-mentioned scenario, which achieves the result as the same or similar interface through alternative embodiments, can be combined in various ways in a prominent and / or parallel fashion, or with other intervening code. I want. Thus, the alternative embodiments presented above are not mutually exclusive and can be mixed and matched to produce the same or similar scenario as the generic scenario presented in FIGS. 30A and 30B. And can be combined. Further, as with many programming constructs, there is a similar method that achieves the same or equivalent interface functionality that is not described herein, but is still represented by the spirit and scope of the present invention. Note that there are others. That is, it should be noted that it is at least partly the function represented by the interface that underlies the value of the interface, and the advantageous results achieved thereby.
ＩＩＩ．イメージ・スキーマおよび従属スキーマ（イメージ・スキーマ・セット）
本明細書に開示する本発明のさまざまな実施例において、イメージ（たとえばＪＰＥＧ、ＴＩＦＦ、ビットマップなど）はコア・プラットフォーム・オブジェクト（「イメージ・アイテム」あるいは簡単に「イメージ」）として処理され、本発明は、システムにおけるイメージの拡張可能な表現、つまりイメージの特性、およびどのようにイメージがシステムにおける他のアイテムに関連しているか、を提供する「イメージ・スキーマ」を備えている。このために、イメージ・スキーマは、システムにおけるイメージのプロパティ、振る舞い、およびリレーションシップを定義し、さらにスキーマは、たとえばデータ固有のイメージが何を含むべきか、データ固有のイメージがオプションで何を含むべきか、固有のイメージがどのように拡張できるかなど、イメージに関する規則も強制する。イメージ・スキーマは、イメージの意味内容を表すプロパティだけでなく、イメージを表すためのファイル・フォーマットのプロパティ（ＧＩＦ、ＴＩＦＦ、ＪＰＥＧその他周知のイメージ・オブジェクト・タイプなど）を含む、さまざまな種類のイメージを表すために必要なタイプ情報を含んでいる。本発明のさまざまな実施例のイメージ・スキーマは、すべてのイメージ関連の機能性が構築される基盤である。
III. Image schemas and dependent schemas (image schema sets)
In various embodiments of the invention disclosed herein, images (eg, JPEG, TIFF, bitmaps, etc.) are processed as core platform objects (“image items” or simply “images”) The invention comprises an “image schema” that provides an extensible representation of the image in the system, ie the characteristics of the image, and how the image is related to other items in the system. To this end, the image schema defines the properties, behaviors, and relationships of the image in the system, and the schema also includes what the data-specific image should contain, for example, what the data-specific image should contain It also enforces image rules such as what should be done and how a unique image can be expanded. Image schemas include a variety of image types, including properties that represent the semantic content of the image, as well as file format properties for representing the image (such as GIF, TIFF, JPEG, and other well-known image object types). Contains type information necessary to represent The image schema of the various embodiments of the present invention is the basis on which all image related functionality is built.
イメージ・スキーマに加えて、「フォト」、「分析プロパティ」、「場所（location）」アイテムの関連従属スキーマも本明細書において提供されて説明されており（全体で「イメージ・スキーマ・セット」）、本発明の特定の実施例は１つまたは複数のこれらの従属スキーマを備えている。フォト・スキーマは、写真オブジェクト（「フォト・アイテム」または簡単に「フォト」）の拡張可能表現であり、ここでフォト・アイテム・タイプはイメージ・アイテム・タイプのサブタイプである。分析プロパティ・スキーマ（ＡＰスキーマ）は、自動顔認識、イメージ類似など写真用の高機能比較機能を実現するフォト・アイテムの分析プロパティ（ＡＰ）の拡張可能表現である。場所（location）スキーマは、フォト・アイテムの物理的（地理的）場所プロパティの拡張可能表現である。 In addition to the image schema, the associated dependent schema for the “Photo”, “Analysis Properties”, and “Location” items are also provided and described herein (collectively “Image Schema Set”). Certain embodiments of the present invention comprise one or more of these dependent schemas. A photo schema is an extensible representation of a photo object (“photo item” or simply “photo”), where a photo item type is a subtype of an image item type. An analysis property schema (AP schema) is an extensible representation of an analysis property (AP) of a photo item that implements a high-performance comparison function for photographs such as automatic face recognition and image similarity. A location schema is an extensible representation of a physical (geographic) location property of a photo item.
図３６Ａおよび図３６Ｂは、本発明のさまざまな実施例のイメージ・スキーマ（アイテムおよびプロパティ）を、（図７の）基本スキーマおよび（図８Ａおよび図８Ｂの）コア・スキーマの選択された要素と共に示して、各スキーマ間の相互リレーションシップを示している。（便宜上、個々のプロパティは図では省略してある。） 36A and 36B show the image schema (items and properties) of the various embodiments of the present invention, along with selected elements of the base schema (of FIG. 7) and the core schema (of FIGS. 8A and 8B). And show the mutual relationships between the schemas. (For convenience, individual properties are omitted in the figure.)
Ａ．イメージ・スキーマ
前述のように、イメージ・スキーマは、さまざまな種類のイメージ・アイテムを表すために必要なアイテム、プロパティ、およびリレーションシップを含んでいる。これは、特定のイメージ・タイプ（ＧＩＦ、ＴＩＦＦ、ＪＰＥＧなど）を表すネイティブのファイル・フォーマットのプロパティの他にイメージの意味内容を表すプロパティを含んでいる。このために、任意のイメージ・アイテムに対して、Ｉｍａｇｅ Ｔｙｐｅは、すべてのイメージによって共有される基本アイテム・タイプであり、図３６に示すようにＣｏｒｅ．Ｄｏｃｕｍｅｎｔアイテム・タイプ（つまり「コア」スキーマの「ドキュメント」タイプ）から分かれた直接の拡張である。（Ｃｏｒｅ．Ｄｏｃｕｍｅｎｔタイプは、図８Ａに示されるコア・スキーマの一部にすることもできる。）イメージ・タイプは、一般的なイメージを記述し、フォーマットにはかかわりなくすべてのイメージに適用可能なフィールドを含んでいる。イメージ・スキーマの主要なアイテム・タイプはイメージ・タイプであり、以下にイメージ・タイプの一部のフィールドを示す。
A. Image Schema As mentioned above, an image schema contains the items, properties, and relationships needed to represent various types of image items. This includes properties that represent the semantic content of the image in addition to the native file format properties that represent a particular image type (GIF, TIFF, JPEG, etc.). For this reason, for any image item, Image Type is the basic item type shared by all images, and as shown in FIG. A direct extension separated from the Document item type (ie, the “document” type of the “core” schema). (The Core.Document type can also be part of the core schema shown in Figure 8A.) The image type describes a generic image and can be applied to all images regardless of format. Contains fields. The main item type of the image schema is the image type, and some fields of the image type are shown below.
イメージ・スキーマはさらに、以下のようなＢａｓｅ．ＰｒｏｐｅｒｔｙＢａｓｅから拡張する追加のプロパティ（ネスト化要素）も備えている。 ・ 「Ｒｅｇｉｏｎ」：Ｒｅｇｉｏｎプロパティは、イメージ内の領域を表し、以下のフィールドを備えている。 The image schema is further based on Base. It also has additional properties (nested elements) that extend from PropertyBase. “Region”: The Region property represents an area in the image and has the following fields:
・ 「ＲｅｇｉｏｎＯｆＩｎｔｅｒｅｓｔ」：このプロパティは、イメージ内の特定の注目の情報を表し、以下のフィールドを備えている。 “RegionOfInterest”: This property represents information of particular interest in the image and has the following fields:
さらに、イメージ・スキーマは、以下に示すように、図３６Ａに示すイメージ・アイテムおよび他のアイテムとの間の一連のリレーションシップを備えることもできる。 ・ 「ＰｅｒｓｏｎＲｅｆｅｒｅｎｃｅ」：イメージは、連絡先またはプリンシパル・アイテム（図８ＡのＣｏｒｅ．Ｐｒｉｎｃｉｐａｌ）への１つまたは複数のＰｅｒｓｏｎＲｅｆｅｒｅｎｃｅリンクを持ち、特定のフォト内の人物を示すことができ、以下のフィールドを備えている。 In addition, the image schema may comprise a series of relationships between the image item shown in FIG. 36A and other items, as shown below. “PersonReference”: The image has one or more PersonReference links to contacts or principal items (Core.Principal in FIG. 8A) and can show the following fields: I have.
・ 「ＥｖｅｎｔＲｅｆｅｒｅｎｃｅ」：イメージはさらに、イベント・アイテム（図８ＡのＣｏｒｅ．Ｅｖｅｎｔ）へのＥｖｅｎｔＲｅｆｅｒｅｎｃｅリンクを持って特定のフォトのイベントを示すこともでき、以下のフィールドを備えている。 “EventReference”: The image can also indicate an event for a particular photo with an EventReference link to the event item (Core.Event in FIG. 8A) and has the following fields:
・ 「ＬｏｃａｔｉｏｎＲｅｆｅｒｅｎｃｅ」：イメージはさらに、場所アイテム（図８ＡのＣｏｒｅ．Ｌｏｃａｔｉｏｎ）へのＬｏｃａｔｉｏｎＲｅｆｅｒｅｎｃｅリンクを持って特定のフォトの場所（location）を示すこともでき、以下のフィールドを備えている。 “LocationReference”: The image can also indicate the location of a particular photo with a LocationReference link to a location item (Core.Location in FIG. 8A) and has the following fields:
Ｂ．フォト・スキーマ
イメージ・スキーマの従属スキーマであるフォト・スキーマは、実際に何らかの写真であるイメージに適用される。任意のフォト・アイテムに対して、フォト・タイプはイメージ・フォーマットに関わりなくフォトを記述するプロパティのセットを表し、フォト・タイプは図３６に示すようにＩｍａｇｅ．Ｉｍａｇｅタイプ（つまり「イメージ」スキーマ内の「イメージ」タイプ）を拡張する。以下にフォト・タイプの一部のフィールドを示す。
B. Photo Schema A photo schema, which is a subordinate schema of an image schema, is applied to an image that is actually some photograph. For any photo item, the photo type represents a set of properties that describe the photo regardless of the image format, and the photo type is Image. Extends the Image type (ie, the “Image” type in the “Image” schema). The following are some photo type fields.
Ｃ．分析プロパティ・スキーマ
デジタル写真の場合、プロパティのセットは分析アプリケーションによってその写真に関して算出することができる。ただし、これらのプロパティは、算出に高くつき、時間およびプロセッサ・リソースの観点から再計算される。さらに、これらのフィールドはアプリケーションに固有であり、他のアプリケーションはこれらのフィールドの内部フォーマットを理解することができない。
C. Analysis Property Schema For digital photos, a set of properties can be calculated for the photo by an analysis application. However, these properties are expensive to calculate and are recalculated in terms of time and processor resources. In addition, these fields are application specific and other applications cannot understand the internal format of these fields.
フォト・アイテムの場合、その代わりに分析プロパティの標準セットが使用前にこれらのアプリケーションによって計算され、フォト・アイテム・タイプの拡張の形式でフォト・アイテムに追加される。分析プロパティ・スキーマ（ＡＰスキーマ）は、図７に示すように、自身が基本スキーマのＢａｓｅ．Ｅｘｔｅｎｓｉｏｎ拡張タイプの拡張であるＡＰ拡張のＡＰタイプを提供することによってこれを行っている。ＡＰタイプ拡張は、次のフィールドを備えている。 In the case of photo items, instead, a standard set of analysis properties is calculated by these applications before use and added to the photo item in the form of an extension of the photo item type. As shown in FIG. 7, the analysis property schema (AP schema) is Base. This is done by providing an AP extension AP type that is an extension of the Extension extension type. The AP type extension has the following fields:
ＩＶ．結論
以上説明してきたように、本発明は、データを編成、検索、共有するためのストレージ・プラットフォームを目的としている。本発明のストレージ・プラットフォームは、既存のファイル・システムおよびデータベース・システムを超えてデータ・ストレージの概念を拡張して広げ、リレーショナル（表）データ、ＸＭＬ、およびアイテムと呼ばれる新しいデータの形態など、構造化、非構造化、または半構造化データを含むあらゆるタイプのデータの記憶装置（data store）となるように設計される。本発明のストレージ・プラットフォームは、その共通のストレージ基盤および体系化されたデータを通じて、消費者、知識労働者および企業のさらに効率的なアプリケーション開発を実現することができる。このストレージ・プラットフォームは、機能豊富で拡張可能なアプリケーション・インターフェースを提供し、これはそのデータ・モデルに固有の機能を利用できるようにするだけではなく、既存のファイル・システムおよびデータベース・アクセス方法も取り入れて、拡張している。その広範な発明の概念から逸脱することなく前述の実施例には変更を加えることができることが理解されよう。したがって、本発明は、開示される特定の実施例に限定されることはないが、添付の特許請求の範囲によって定義されている発明の精神および範囲の中のすべての変更を網羅することを意図している。
IV. Conclusion As described above, the present invention is directed to a storage platform for organizing, retrieving and sharing data. The storage platform of the present invention extends and extends the concept of data storage beyond existing file and database systems, including structures such as new data forms called relational (table) data, XML, and items. Designed to be a data store for any type of data, including structured, unstructured, or semi-structured data. The storage platform of the present invention can achieve more efficient application development for consumers, knowledge workers and enterprises through its common storage infrastructure and organized data. This storage platform provides a rich and extensible application interface that not only allows you to take advantage of the features specific to that data model, but also the existing file system and database access methods. Incorporates and expands. It will be understood that modifications may be made to the foregoing embodiments without departing from the broad inventive concept. Accordingly, the invention is not limited to the specific embodiments disclosed, but is intended to cover all modifications within the spirit and scope of the invention as defined by the appended claims. is doing.
以上の説明から明らかなように、本発明のさまざまなシステム、方法、および態様の全体または部分は、プログラム・コード（つまり命令）の形態で組み入れることができる。このプログラム・コードは、フロッピー（登録商標）ディスケット、ＣＤ−ＲＯＭ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ，磁気テープ、フラッシュ・メモリ、ハードディスク・ドライブ、または他の機械可読ストレージ媒体を含む、磁気、電気、または光ストレージ媒体などのコンピュータ可読媒体上に格納することができ、プログラム・コードが、コンピュータまたはサーバなどのマシンによってロードされ実行されるときに、マシンは本発明を実施するための装置となることを特徴としている。本発明はさらに、電気配線またはケーブリング経由、光ファイバ経由、インターネットまたはイントラネットを含むネットワーク経由、あるいは他の伝送形態経由など、一部の伝送媒体上を伝送されるプログラム・コードの形態で組み入れることもでき、プログラム・コードがコンピュータなどのマシンによってロードされ実行されるときに、マシンは本発明を実施するための装置となることを特徴としている。汎用プロセッサ上で実装される場合、プログラム・コードはプロセッサと結合して、特定の論理回路に同じように機能する一意の装置を提供する。
［以下余白］
As will be apparent from the foregoing description, all or portions of the various systems, methods, and aspects of the present invention may be incorporated in the form of program code (ie, instructions). The program code includes a floppy diskette, CD-ROM, CD-RW, DVD-ROM, DVD-RAM, magnetic tape, flash memory, hard disk drive, or other machine-readable storage medium, When the program code can be loaded and executed by a machine such as a computer or server, the machine can be stored on a computer readable medium such as a magnetic, electrical, or optical storage medium. It is a device. The present invention is further incorporated in the form of program code transmitted over some transmission media, such as via electrical wiring or cabling, via optical fiber, via the network including the Internet or intranet, or via other transmission forms. In addition, when the program code is loaded and executed by a machine such as a computer, the machine is a device for carrying out the present invention. When implemented on a general-purpose processor, the program code combines with the processor to provide a unique apparatus that functions similarly to a specific logic circuit.
[The following margins]
Claims (12)
前記複数のイメージデータに基づき、少なくとも１つのイメージ・アイテムおよび少なくとも１つのイメージ・プロパティを定義するための手段と、
アイテムを、前記イメージ・アイテムが全てそこから派生する基礎アイテム・タイプを構成する基礎アイテムとして確立するための手段と、
前記基礎アイテムによって定義される写真のデジタル・イメージ・アイテムと前記写真のデジタル・イメージ・アイテムの領域において表された少なくとも１人の人物に関連するアイテムとの間のリンクを確立するための手段と、
を備え、
前記基礎アイテム・タイプは、前記写真のデジタル・イメージ・アイテムの中の１つにおける注目の領域の属性を含む属性を定義し、前記注目の領域の属性は、前記写真のデジタル・イメージ・アイテムの中の１つの、第１の領域内で、少なくとも１人の人物を確認するフィールドと、前記写真のデジタル・イメージ・アイテムの中の１つの、第２の領域内で、少なくとも１つの注目の領域を確認する第２のフィールドとを含むことを特徴とするシステム。A system for processing a plurality of image data stored in a storage device, wherein the plurality of image data includes individual information units associated with an image, the system comprising:
Means for defining at least one image item and at least one image property based on the plurality of image data;
Means for establishing an item as a base item comprising a base item type from which all said image items are derived;
Means for establishing a link between a digital image item of a photo defined by the base item and an item associated with at least one person represented in the area of the digital image item of the photo; ,
With
The base item type defines an attribute that includes an attribute of a region of interest in one of the digital image items of the photo, and the attribute of the region of interest includes the digital image item of the photo A field for identifying at least one person within a first region, and at least one region of interest within a second region of one of the digital image items of the photograph. And a second field for confirming .
Applications Claiming Priority (7)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US10/646,632 US7529811B2 (en) | 2003-08-21 | 2003-08-21 | Systems and methods for the implementation of a core schema for providing a top-level structure for organizing units of information manageable by a hardware/software interface system |
| US10/646,632 | 2003-08-21 | ||
| USPCT/US03/26144 | 2003-08-21 | ||
| PCT/US2003/026144 WO2005029313A1 (en) | 2003-08-21 | 2003-08-21 | Systems and methods for data modeling in an item-based storage platform |
| US10/692,779 | 2003-10-24 | ||
| US10/692,779 US8238696B2 (en) | 2003-08-21 | 2003-10-24 | Systems and methods for the implementation of a digital images schema for organizing units of information manageable by a hardware/software interface system |
| PCT/US2004/024437 WO2005024550A2 (en) | 2003-08-21 | 2004-07-29 | System and method for implementation of a digital image schema in a hardware/software interface |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2007517268A JP2007517268A (en) | 2007-06-28 |
| JP2007517268A5 JP2007517268A5 (en) | 2007-09-13 |
| JP4901472B2 true JP4901472B2 (en) | 2012-03-21 |
Family
ID=34279604
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2006523867A Expired - Fee Related JP4901472B2 (en) | 2003-08-21 | 2004-07-29 | System and method for implementation of a digital image schema that organizes units of information manageable by a hardware / software interface system |
Country Status (5)
| Country | Link |
|---|---|
| EP (1) | EP1620781A4 (en) |
| JP (1) | JP4901472B2 (en) |
| KR (1) | KR20060113353A (en) |
| CN (1) | CN101416153B (en) |
| WO (1) | WO2005024550A2 (en) |
Families Citing this family (22)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8131739B2 (en) | 2003-08-21 | 2012-03-06 | Microsoft Corporation | Systems and methods for interfacing application programs with an item-based storage platform |
| US8238696B2 (en) | 2003-08-21 | 2012-08-07 | Microsoft Corporation | Systems and methods for the implementation of a digital images schema for organizing units of information manageable by a hardware/software interface system |
| US7590643B2 (en) | 2003-08-21 | 2009-09-15 | Microsoft Corporation | Systems and methods for extensions and inheritance for units of information manageable by a hardware/software interface system |
| US8166101B2 (en) | 2003-08-21 | 2012-04-24 | Microsoft Corporation | Systems and methods for the implementation of a synchronization schemas for units of information manageable by a hardware/software interface system |
| US7711835B2 (en) | 2004-09-30 | 2010-05-04 | Citrix Systems, Inc. | Method and apparatus for reducing disclosure of proprietary data in a networked environment |
| US8095940B2 (en) | 2005-09-19 | 2012-01-10 | Citrix Systems, Inc. | Method and system for locating and accessing resources |
| US7680758B2 (en) | 2004-09-30 | 2010-03-16 | Citrix Systems, Inc. | Method and apparatus for isolating execution of software applications |
| US8171479B2 (en) | 2004-09-30 | 2012-05-01 | Citrix Systems, Inc. | Method and apparatus for providing an aggregate view of enumerated system resources from various isolation layers |
| US8613048B2 (en) | 2004-09-30 | 2013-12-17 | Citrix Systems, Inc. | Method and apparatus for providing authorized remote access to application sessions |
| US7805422B2 (en) | 2005-02-28 | 2010-09-28 | Microsoft Corporation | Change notification query multiplexing |
| US7930346B2 (en) | 2005-08-24 | 2011-04-19 | Microsoft Corporation | Security in peer to peer synchronization applications |
| US8533846B2 (en) | 2006-11-08 | 2013-09-10 | Citrix Systems, Inc. | Method and system for dynamically associating access rights with a resource |
| US8490148B2 (en) | 2007-03-12 | 2013-07-16 | Citrix Systems, Inc | Systems and methods for managing application security profiles |
| US7865589B2 (en) | 2007-03-12 | 2011-01-04 | Citrix Systems, Inc. | Systems and methods for providing structured policy expressions to represent unstructured data in a network appliance |
| US7853679B2 (en) | 2007-03-12 | 2010-12-14 | Citrix Systems, Inc. | Systems and methods for configuring handling of undefined policy events |
| US7853678B2 (en) | 2007-03-12 | 2010-12-14 | Citrix Systems, Inc. | Systems and methods for configuring flow control of policy expressions |
| US8631147B2 (en) | 2007-03-12 | 2014-01-14 | Citrix Systems, Inc. | Systems and methods for configuring policy bank invocations |
| US8171483B2 (en) | 2007-10-20 | 2012-05-01 | Citrix Systems, Inc. | Method and system for communicating between isolation environments |
| US8090797B2 (en) | 2009-05-02 | 2012-01-03 | Citrix Systems, Inc. | Methods and systems for launching applications into existing isolation environments |
| MX2017011512A (en) | 2015-03-12 | 2018-01-11 | Koninklijke Philips Nv | Methods of displaying the antimicrobial sensitivity of biological isolates. |
| CN108924653B (en) * | 2018-07-19 | 2021-01-01 | 武汉斗鱼网络科技有限公司 | Bullet screen message distribution method, device, equipment and storage medium |
| CN110706147B (en) * | 2019-09-29 | 2023-08-11 | 阿波罗智联(北京)科技有限公司 | Image processing environment determination method, device, electronic equipment and storage medium |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2000330858A (en) * | 1999-05-25 | 2000-11-30 | Fujitsu Ltd | Image processor and program storage medium |
| JP2001084274A (en) * | 1999-07-14 | 2001-03-30 | Fuji Photo Film Co Ltd | Image retrieval method and image processing method |
| JP2002278993A (en) * | 2001-03-16 | 2002-09-27 | Nippon Telegr & Teleph Corp <Ntt> | Method and system for registering and reproducing picture data, program and recording medium therefor |
| JP2003150932A (en) * | 2001-11-12 | 2003-05-23 | Olympus Optical Co Ltd | Image processing unit and program |
| JP2003216518A (en) * | 2002-01-08 | 2003-07-31 | Hewlett Packard Co <Hp> | Method and apparatus for identifying digital image and for accessing digital image via network |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0744617A (en) * | 1993-07-30 | 1995-02-14 | Olympus Optical Co Ltd | Device and method for controlling image storage |
| US6310647B1 (en) * | 1997-04-15 | 2001-10-30 | Eastman Kodak Company | Image format for storing digital images and including multiple application segments |
| JPH1155447A (en) * | 1997-08-07 | 1999-02-26 | Toshiba Corp | Device for inputting image information and its method |
| US6515765B1 (en) * | 1998-06-15 | 2003-02-04 | Matsushita Electric Industrial Co., Ltd. | Image data management system and method thereof |
-
2004
- 2004-07-29 CN CN2004800015016A patent/CN101416153B/en not_active Expired - Fee Related
- 2004-07-29 EP EP04779482A patent/EP1620781A4/en not_active Ceased
- 2004-07-29 WO PCT/US2004/024437 patent/WO2005024550A2/en active Application Filing
- 2004-07-29 KR KR1020057009283A patent/KR20060113353A/en not_active Application Discontinuation
- 2004-07-29 JP JP2006523867A patent/JP4901472B2/en not_active Expired - Fee Related
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2000330858A (en) * | 1999-05-25 | 2000-11-30 | Fujitsu Ltd | Image processor and program storage medium |
| JP2001084274A (en) * | 1999-07-14 | 2001-03-30 | Fuji Photo Film Co Ltd | Image retrieval method and image processing method |
| JP2002278993A (en) * | 2001-03-16 | 2002-09-27 | Nippon Telegr & Teleph Corp <Ntt> | Method and system for registering and reproducing picture data, program and recording medium therefor |
| JP2003150932A (en) * | 2001-11-12 | 2003-05-23 | Olympus Optical Co Ltd | Image processing unit and program |
| JP2003216518A (en) * | 2002-01-08 | 2003-07-31 | Hewlett Packard Co <Hp> | Method and apparatus for identifying digital image and for accessing digital image via network |
Also Published As
| Publication number | Publication date |
|---|---|
| EP1620781A4 (en) | 2008-12-03 |
| KR20060113353A (en) | 2006-11-02 |
| CN101416153A (en) | 2009-04-22 |
| CN101416153B (en) | 2010-09-29 |
| WO2005024550A2 (en) | 2005-03-17 |
| JP2007517268A (en) | 2007-06-28 |
| WO2005024550A3 (en) | 2007-11-22 |
| EP1620781A2 (en) | 2006-02-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR101120817B1 (en) | Systems and methods for providing relational and hierarchical synchronization services for units of information manageable by hardware/software interface system | |
| US8131739B2 (en) | Systems and methods for interfacing application programs with an item-based storage platform | |
| US8238696B2 (en) | Systems and methods for the implementation of a digital images schema for organizing units of information manageable by a hardware/software interface system | |
| US7693858B2 (en) | Systems and methods for extensions and inheritance for units of information manageable by a hardware/software interface system | |
| JP4738908B2 (en) | System and method for providing contention processing for peer-to-peer synchronization of units of information manageable by a hardware / software interface system | |
| US7739316B2 (en) | Systems and methods for the implementation of base schema for organizing units of information manageable by a hardware/software interface system | |
| US7349913B2 (en) | Storage platform for organizing, searching, and sharing data | |
| US7483915B2 (en) | Systems and method for representing relationships between units of information manageable by a hardware/software interface system | |
| JP4901472B2 (en) | System and method for implementation of a digital image schema that organizes units of information manageable by a hardware / software interface system | |
| US20050125621A1 (en) | Systems and methods for the implementation of a synchronization schemas for units of information manageable by a hardware/software interface system | |
| US20050055380A1 (en) | Systems and methods for separating units of information manageable by a hardware/software interface system from their physical organization | |
| JP4580390B2 (en) | System and method for extending and inheriting information units manageable by a hardware / software interface system | |
| JP4580389B2 (en) | System and method for synchronizing computer systems via an intermediary file system share or intermediary device | |
| JP4583375B2 (en) | System for implementation of synchronization schema | |
| JP2007521537A (en) | Storage platform for data organization, retrieval and sharing | |
| KR101109390B1 (en) | Systems and methods for providing synchronization services for units of information manageable by a hardware/software interface system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070730 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20070730 |
|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20090812 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20090824 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100318 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20100618 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20100625 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20100720 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20100727 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100921 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20101102 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20110202 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20110209 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20110302 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20110309 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20110404 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20110411 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20110502 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20110616 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20111017 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20111026 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20111201 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20111227 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4901472 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20150113 Year of fee payment: 3 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |