JP2007503051A - System and method for extending and inheriting information units manageable by a hardware / software interface system - Google Patents

Abstract

By modeling real-world application objects using composite structures, behaviors, and behaviors described by schemas enforced by the hardware / software interface system, various embodiments of the present invention enable existing item types. Extensive subtype specifications (3602, 3604, 3606, 6322, 3624, 3626, 3642, 3644) are provided by extending “items” with extensions that provide additional data structures to the structure. An extension is a strongly typed instance that cannot exist alone and must be attached to an item or “nested” element. The extension is also intended to address the problem of multiple typing by allowing type instances to overlap.

Description

  The present invention relates generally to the field of information storage and retrieval, and more particularly to an active storage platform that organizes, retrieves, and shares different types of data in a computer system. Various embodiments of the present invention are directed to the use of extension and inheritance methods used by hardware / software interface systems to manage data.

  This application is a US patent application Ser. No. 10 / 693,574 filed Oct. 24, 2003 (Docket MSFT2847) “SYSTEMS AND METHODS FOR EXTENSIONS AND INHERITANCE”, the contents of which are incorporated herein by reference. FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM ", US patent application No. 10 / 646,580 filed on August 21, 2003 (reference number MSFT2735)" SYSTEMS AND METHODS FOR DATA MODELING IN AN ITEM-BASED " STORAGE PLATFORM "and international application PCT / US03 / 26144 (reference number MSFT2779) filed on August 21, 2003," SYSTEMS AND METHODS FOR DATA MODELING IN AN ITEM-BASED STORAGE PLATFORM ".

  This application is incorporated herein by reference in its entirety (and some of which are summarized herein for convenience), assigned to the assignee of the present invention, August 21, 2003. US Patent Application No. 10 / 647,058 (reference number MSFT1748), "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 Applied US Patent Application No. 10 / 646,941 (reference number MSFT1749) “SYSTEMS AND METHODS FOR SEPARATING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM FROM THEIR PHYSICAL ORGANIZATION”, US filed on August 21, 2003 Patent Application No. 10 / 646,940 (reference number MSFT1750) “SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A BASE SCHEMA FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM ”, US Patent Application No. 10 / 646,632, filed August 21, 2003 (reference number MSFT1751)“ 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 ”, US patent application Ser. No. 10 / 646,645 filed Aug. 21, 2003 (reference number MSFT1752)“ SYSTEMS AND METHOD FOR REPRESENTING RELATIONSHIPS BETWEEN UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM ”, US Patent Application No. 10 / 646,575 filed on August 21, 2003 (reference number MSFT2733) WITH AN ITEM-BASED STORAGE PLATFORM ", US filed on August 21, 2003 National Patent Application No. 10 / 646,646 (reference number MSFT2734) “STORAGE PLATFORM FOR ORGANIZING, SEARCHING, AND SHARING DATA”, US Patent Application No. 10 / 692,779 (reference number) filed on October 24, 2003 MSFT2829) “SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A DIGITAL IMAGES SCHEMA FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM”, US Patent Application No. 10 / 692,515 filed October 24, 2003 No. MSFT2844) "SYSTEMS AND METHODS FOR PROVIDING SYNCHRONIZATION SERVICES FOR UNITS OF INFORMATION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM", US Patent Application No. 10 / 692,508 filed on the same date as this application AND METHODS FOR PROVIDING RELATIONAL AND HIERARCHICAL SYNCHRONIZATION SERVICES FOR UNITS OF INFORMA TION MANAGEABLE BY A HARDWARE / SOFTWARE INTERFACE SYSTEM "and US Patent Application No. 10 / 693,362 filed October 24, 2003 (reference number MSFT2846)" SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A SYNCHRONIZATION SCHEMAS FOR UNITS OF " The subject matter relates to the invention disclosed in the application “Information Manual by A Hardware / Software Interface System”.

  Individual disk capacity has increased by approximately 70% annually over the past decade. Moore's Law accurately predicted the tremendous progress in central processing unit (CPU) capabilities that occurred over the years. Wired and wireless technology has provided tremendous connectivity and bandwidth. Assuming current trends continue, in a few years the average laptop computer will have about 1 terabyte (TB) of storage and will accommodate millions of files, 500 gigabytes (GB) The drive will be common.

  Whether the information handled is conventional personal information manager (PIM) style data or media such as digital music or photos, consumers mainly use computers for communication and editing of personal information. While the amount of digital content and the ability to store raw bytes has increased significantly, the way in which consumers can use and organize and unify the data has lagged. Knowledge workers spend a great deal of time managing and sharing information, and some studies estimate that knowledge workers spend 15-25% of their time on unproductive information-related activities Yes. Other studies estimate that a typical knowledge worker spends about 2.5 hours per day searching for information.

  Developers and information technology (IT) departments invest a great deal of time and money in building their own data stores for common storage abstractions that represent things like people, places, time, and events. As a result, not only duplication of work occurs, but also an island made of common data is created that does not have a common mechanism for searching or sharing common data. Consider how many address books today can exist on a computer running a Microsoft Windows operating system. Many applications, such as e-mail clients and personal finance programs, maintain separate address books, but there is little sharing between the address book data applications that each such program maintains individually. Absent. As a result, financial programs (such as Microsoft Money) do not share payee addresses with addresses maintained in email contact folders (folders in Microsoft Outlook). In fact, many users have multiple devices and should logically synchronize their personal data across a wide variety of additional sources including multiple devices and cell phones to commercial services such as MSN and AOL. is there. Nevertheless, the collaborative work of sharing a document is mainly performed inefficiently by attaching the document to an email message, that is, manually.

  One reason for the lack of collaboration is that traditional approaches to organizing information in computer systems are based on the abstraction of the physical organization of storage media used to store files. The focus was on using files, folders, and directory-based systems (“file systems”) to organize files into a directory hierarchy of folders. Developed in the 1960s, the Multitics operating system could gain trust by pioneering the use of files, folders, and directories to manage storable data units at the operating system level. Specifically, Multics used symbolic addresses in file hierarchies where the physical address of the file is not transparent to users (applications and end users) (thus introducing the concept of file paths). This file system was totally indifferent to the file format of any individual file, and the relationship between the files was deemed insignificant at the operating system level (ie other than the location of the file in the hierarchy). Since the advent of Multics, storable data has been organized into files, folders, and directories at the operating system level. Such files generally include the file hierarchy itself (“directory”) implemented in the form of special files maintained by the file system. This directory maintains a list of entries corresponding to all the other files in the directory and the location of such a file's node in the hierarchy (referred to herein as a folder). The field has been in this situation for about 40 years.

  However, despite providing a reasonable way to represent information that resides in a computer's physical storage system, a file system is an abstraction of that physical storage system, and therefore the file's Usage involves some indirection between what the user manipulates (contexts, features, and units that have relationships with other units) and what the operating system provides (files, folders, and directories) (Translation) is necessary. As a result, users (applications and / or end users) can only choose to force the information unit into a file system structure, even if it is inefficient and inconsistent or undesirable to do so. There is no room. In addition, existing file systems have very little knowledge of the data structures stored in individual files, so most of the information is only accessible (and understandable) to the application that wrote the file. Will remain locked. As a result, the lack of the outline description of information and the information management mechanism creates a silo consisting of data, and data sharing is hardly performed between individual silos. For example, file organization presents a major challenge for such PC users, so many personal computer (PC) users have separate stores that contain some information about the people they interact with, such as Outlook Contacts, online There are more than five friend lists for account recipients, Windows address book, Quick Payes, and instant messaging (IM). Most existing file systems use nested folder metaphors to organize files and folders, so as the number of files increases, the work required to maintain a flexible and efficient organization scheme is very It becomes troublesome. In such a situation, it would be very useful to classify one file in various ways. However, using hard or soft links in existing file systems is cumbersome and difficult to maintain.

  Several attempts have been made in the past to address these shortcomings of file systems, but with no success. Some of these previous attempts involved the use of associative memory to provide a mechanism for accessing data by content rather than physical address. However, associative memory was useful for small-scale use by devices, such as caches and memory management units, but large-scale use for devices such as physical storage media is still impossible for a variety of reasons. The effort is unsuccessful, so there is no such solution at all. Other attempts to use object-oriented database (OODB) systems have also been made, but these attempts featured powerful database characteristics and excellent non-file representation, but were not effective in handling file representations and file The speed, efficiency, and simplicity of hierarchical structures based on folders and folders could not be reproduced at the hardware / software interface system level. Other efforts, such as those that attempted to use SmallTalk (and other derivatives), were also very effective in dealing with file and non-file representations, but the relationships that exist between the various data files Such overall system efficiency was unacceptable because it lacked the database features necessary to efficiently organize and use. Yet other attempts to use BeOS (and other such operating system studies) also provide some necessary database features and represent files appropriately, while The same core drawback as the system was not suitable for handling non-file expressions.

  Database technology is another area of the field where similar challenges exist. For example, the relational database model has been very successful commercially, but in practice, independent software vendors (ISVs) generally performed only a fraction of the functionality available in relational database software products (such as Microsoft SQL Server). Only. Rather, most of the application interaction with such products is in the form of simple “get” and “put”. This can have several obvious reasons, such as being platform or database-independent, but one of the most important reasons that are often not noticed is that the database is really needed by major business application vendors. This means that accurate abstraction is not always realized. For example, the real world has the concept of “items”, such as “customers” and “orders” (along with the embedded “line items” of orders, which are themselves items), but relational databases have table and row “items” Only interact with the concept. As a result, an application may want to have item-level consistency, locking, security, and / or triggering aspects (to name a few examples), but in general, a database is responsible for these features Provide only at level. This can work well if each item is mapped to one row of some table in the database, but for orders with multiple line items, why the item is actually mapped to multiple tables In this case, a simple relational database system does not provide the correct abstraction. As a result, applications must build logic on top of the database to provide these basic abstractions. In other words, the basic relational model does not provide a sufficient platform for storing data on which more sophisticated applications can be easily developed. This is because the basic relational model requires some degree of indirection between the application and the storage system, in which case the semantic structure of the data can only be visible in the application in certain instances. is there. Some database vendors are building more advanced features in their products, such as providing object-relational performance, new configuration models, etc., but every vendor has the kind of comprehensive solution they need A truly comprehensive solution is a useful data model abstraction (eg “items”, “extensions”, “relationships”) and a useful domain abstraction (eg. "Person", "location", "event", etc.).

  In view of the deficiencies in existing data storage and database technologies described above, a new storage platform, or existing file, that improves the ability to organize, search, and share all types of data in computer systems There is a need for a storage platform that is designed to expand and expand the data platform to surpass systems and database systems and become a store for all types of data. The present invention fulfills this need along with related inventions incorporated herein by reference above. Specifically, the present invention provides a method for extending and inheriting objects manipulated by a hardware / software interface system.

  The following summary provides an overview of various aspects of the present invention, which are described in connection with related inventions (“related inventions”) incorporated herein by reference. This summary is not intended to provide a comprehensive description of all of the important aspects of the invention or to define the scope of the invention. Rather, this summary is intended to serve as a detailed description and an introduction to the drawings that follow.

  The present invention, as well as related inventions, are collectively directed to a storage platform for organizing, searching and sharing data. The storage platform of the present invention extends and expands the data platform beyond existing file systems and database systems to become a store for any type of data, including structured, unstructured, or semi-structured data. Designed to.

  The storage platform of the present invention comprises a data store implemented on a database engine. The database engine comprises a relational database engine having an object relational extension. The data store implements a data model that supports data organization, search, sharing, synchronization, and security. The concrete data types are described in the schema, and the platform provides a mechanism to extend the schema set to define new data types (essentially, subtypes of basic types are provided by the schema) ). Synchronization performance facilitates data sharing between users or systems. While providing a data store interoperability with existing file systems, such file system performance is provided that does not limit such conventional file systems. A change tracking mechanism allows tracking changes to the data store. The storage platform further comprises a set of application program interfaces that allow applications to take advantage of all of the above capabilities of the storage platform and access data described in the schema.

  The data model implemented by the data store defines data storage units with respect to items, elements, and relationships. An item is a unit of data that can be stored in a data store and may include one or more elements and relationships. An element is an instance of a type that includes one or more fields (also referred to herein as properties). A relationship is a link between two items. (As used herein, these and other specific terms may be capitalized to separate them from other terms used nearby, except for capitalized terms such as “ There is no intent to distinguish between “Item (“ item ”)” and the same terms that are not capital letters, such as “item”, and such distinction should not be inferred or implied).

  The computer system includes a plurality of items, each item constituting a separate storable information unit that can be handled by a hardware / software interface system, and a plurality of “item folders” constituting the organizational structure of the “item”. And a hardware / software interface system that handles a plurality of “items”, and each “item” belongs to at least one “item folder” and may also belong to a plurality of item folders.

  “Item” or some of its “item” property values can be calculated dynamically as opposed to derivation from the persistent store. In other words, the hardware / software interface system does not require “items” to be stored, and given the storage platform's ability to enumerate the current “item” set, or “item” identifier. Certain actions are supported, such as the ability to obtain that “item” (described in more detail in the section describing the application programming interface, or API). For example, the “item” may be the current location of the cell phone or the temperature read on the temperature sensor. The hardware / software interface system may handle multiple “items” and may further comprise “items” interconnected by multiple “relationships” managed by the hardware / software interface system.

  A hardware / software interface system for a computer system is a core schema for defining a set of core “items” that the hardware / software interface system understands and can directly process in a predetermined and predictable manner. Is further provided. In order to handle 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 set of behaviors common to the data classes and provide a basic programming model for the storage platform API along with the data classes. . The storage platform API allows the application programmer to form queries based on various properties of items in the data store in a manner that does not involve the application programmer in the details of the underlying database engine query language. Provide a simplified query model. The storage platform API also collects changes made to items made by the application program, and these changes are then correctly updated by the database engine on which the data store is implemented (or by any type of storage engine). Organize into. As a result, application programmers can make changes to items in memory, leaving the complexity of data store updates to the API.

  With a common storage infrastructure and data organization, the storage platform of the present invention enables more efficient application development for consumers, knowledge workers, and businesses. The storage platform of the present invention provides a rich and extensible application programming interface that not only makes available the performance inherited in the data model, but also encompasses and extends existing file systems and database access methods.

  In view of this generic structure of interrelated inventions (described in detail in section II of the embodiment), the present invention uses “extensions” to extend “item” and “property” type functionality, and related Of particular interest is the use of "inheritance" to facilitate efficient searching and organization between items (described in detail in Section III of the embodiment). Other features and advantages of the present invention will become apparent from the following detailed description of the invention and the accompanying drawings.

  The foregoing summary, as well as the following 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.

Table of Contents I. Introduction A. Exemplary computer environment Conventional file-based storage II. WINFS storage platform for organizing, searching and sharing data Glossary D. Overview of storage platform Data model Item 2. 2. Item identification Item folder and category Schema a) Basic schema b) Core schema Relationships a) Declaration of relationship b) Retention relationship c) Embedding relationship d) Reference relationship e) Rules and constraints f) Ordering of relationships Extensibility a) Item expansion b) NestedElement type expansion Database engine 1. Implementation of data store using UDT 2. Item mapping Extension mapping 4. Mapping of nested elements Object identification SQL object naming Naming of columns Search view a) Item (1) Master item search view (2) Type-specified item search view b) Item expansion (1) Master extended search (2) Type-specific extended search view c) Nested elements d) Relationship (1 ) Master relationship search view (2) Relationship instance search view e)
9. Update 10. Change Tracking and Deletion Indicators a) Change Tracking (1) Change Tracking in “Master” Search View (2) Change Tracking in “Type Design” Search View b) Delete Indicator (1) Item Delete Indicator (2) Extended Delete Indicator (3) ) Relationship deletion indicator (4) Delete indicator cleanup Helper API and functions a) Function [System. Storage]. GetItem
b) Function [System. Storage]. GetExtension
c) Function [System. Storage]. GetRelationship
12 Metadata a) Schema metadata b) Instance metadata G. Security H. Notification and Change Tracking I. Synchronization 1. Synchronization between storage platforms a) Synchronization (Sync) control application b) Schema annotation c) Synchronization configuration (1) Community folder mapping (2) Profile (3) Schedule d) Conflict operation (1) Conflict detection (a ) Knowledge-based contention (b) Constraint-based contention (2) Conflict processing (a) Automatic contention resolution (b) Contention logging (c) Contention checking and resolution (d) Convergence of replicas and propagation of contention Synchronization with non-storage platform data store a) Synchronization service (1) Enumeration of changes (2) Application of changes (3) Conflict resolution b) Adapter implementation Security 4. Manageability J. Interoperability of conventional file systems Storage platform API
III. Extension and inheritance Mold System B. Type family Nested element type Item type Relation type a) Relational semantics b) Relational rules and constraints Extended C.I. Extended functions Inheritance Expansion IV. Conclusion

I. Preface In order to meet legal requirements, the subject matter of the present invention is clearly explained. However, the description itself is not intended to limit the scope of this patent. Rather, the inventor believes that the claimed subject matter in other ways, along with other current or future technologies, may include different steps or combinations of steps similar to those described in this document. Is intended to be implemented. Further, the term “step” can be used herein to mean a different element of the method utilized, but this term is intended to be used herein unless the order of the individual steps is explicitly stated. It should not be construed to imply any specific order between the various steps disclosed in the document.

A. Exemplary Computer Environment Many embodiments of the invention may be executed on a computer. FIG. 1 and the following description are intended to provide a concise and general description of a suitable computing environment in which the invention may be implemented. Although not required to do so, various aspects of the invention can be described in the general context of computer-executable instructions, such as program modules, being executed by computers such as client workstations and servers. . Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Further, those skilled in the art will appreciate that the present invention can be implemented with other computer system configurations such as handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. Let's be done. The invention may also be practiced in distributed computing environments where certain 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 memory storage devices.

  As shown in FIG. 1, an exemplary general purpose computer system includes a conventional personal computer 20 or the like, which couples various system components such as a processing unit 21, a system memory 22, and a system memory to the processing unit 21. Including a system bus 23. The system bus 23 may be any of several types of bus structures such as a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory includes a ROM (Read Only Memory) 24 and a RAM (Random Access Memory) 25. The BIOS 26 (basic input / output system) includes a basic routine that helps to transfer information between elements inside the personal computer 20 during startup, for example, and is stored in the ROM 24. The personal computer 20 includes a hard disk drive 27 that reads from and writes to a hard disk (not shown), a magnetic disk drive 28 that reads from or writes to a removable magnetic disk 29, and a CD ROM, for example, It may further include an optical disk drive 30 that reads from or writes to a removable optical disk 31 such as other optical media. The hard disk drive 27, magnetic disk drive 28, and optical disk drive 30 are connected to the system bus 23 by a hard disk drive interface 32, a magnetic disk drive interface 33, and an optical drive interface 34, respectively. Such drives and associated computer readable media provide non-volatile storage of computer readable instructions, data structures, program modules, and other data to the personal computer 20. The exemplary environment described herein uses a hard disk, a removable magnetic disk 29, and a removable optical disk 31, but other types that are computer readable that can store data accessible by a computer. Those skilled in the art will appreciate that these media can also be used in an exemplary operating environment. As such other types of media, magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, RAM (Random Access Memory), ROM (Read Only Memory), etc. can also be used in an exemplary operating environment. . Similarly, exemplary environments may also include many types of monitoring devices, such as heat detectors and security or file alarm systems, as well as other information sources.

  Several program modules such as operating system 35, one or more application programs 36, other program modules 37, and program data 38 may be stored on the hard disk, magnetic disk 29, optical disk 31, ROM 24, or RAM 25. . A user can input commands and information into the personal computer 20 via an input device such as a keyboard 40 and a pointing device 42. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, and the like. These and other input devices are often connected to the processing unit 21 via a serial port interface 46 coupled to the system bus, but connected by other interfaces such as parallel ports, game ports, USB (Universal Serial Bus). You can also A monitor 47 or other type of display device is also connected to the system bus 23 via an interface, such as a video adapter 48. In addition to the monitor 47, personal computers typically include other peripheral output devices (not shown), such as speakers and printers. The exemplary system of FIG. 1 also includes a host adapter 55, a SCSI (Small Computer System Interface) bus 56, and an external storage device 62 connected to the SCSI bus 56.

  Personal computer 20 may operate in a networked environment using logical connections to one or more remote computers, such as remote computer 49. The remote computer 49 may be another personal computer, server, router, network PC, peer device or other common network node and typically includes many or all of the elements described above in connection with the personal computer 20, although FIG. Only the memory storage device 50 is shown. The logical connection shown in FIG. 1 includes a LAN (Local Area Network) 51 and a WAN (Wide Area Network) 52. Such network environments are common in companies, enterprise-wide computer networks, intranets and the Internet.

  When used in a LAN network environment, the personal computer 20 is connected to the LAN 51 via a network interface or adapter 53. When used in a WAN network environment, the personal computer 20 typically includes a modem 54 or other means of establishing communications over a wide area network 52 such as the Internet. The modem 54 may be internal or external and is connected to the system bus 23 via the serial port interface 46. In a networked environment, the program modules illustrated in connection with the personal computer 20 or portions thereof may be stored in a remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers can be used.

  As shown in the block diagram of FIG. 2, the computer system 200 includes a hardware component 202, a hardware / software interface system component 204, and an application program component 206 (in the specific context herein, “user component” or “ It can be roughly divided into three component groups (also called “software components”).

  In various embodiments of computer system 200, referring again to FIG. 1, hardware component 202 includes, among other things, central processing unit (CPU) 21, memory (both ROM 24 and RAM 25), and basic input / output system. (BIOS) 26 and various input / output (I / O) devices such as a keyboard 40, mouse 42, monitor 47, and / or printer (not shown) may be provided. Hardware component 202 comprises the basic physical infrastructure for computer system 200.

  Application program component 206 comprises various software programs including but not limited to compilers, database systems, word processors, business programs, video games, and the like. Application programs solve problems for various users (machines, other computer systems, and / or end users), provide solutions, and provide a means to use computer resources to process data To do.

  The hardware / software interface system component 204 most often comprises an operating system that itself comprises a shell and a kernel (and may, in some embodiments, consist solely of an operating system). An “operating system” (OS) is a special program that acts as an intermediary between application programs and computer hardware. The hardware / software interface system component 204 is a virtual machine manager (VMM), common language runtime (CLR) or functional equivalent thereof, Java virtual, in a computer system, instead of or in addition to an operating system. A machine (JVM) or functional equivalent thereof, or other such software components may also be provided. The purpose of the hardware / software interface system is to provide an environment in which a user can execute application programs. Every hardware / software interface system aims to make the computer system easy to use and to efficiently use the computer hardware.

  The hardware / software interface system is generally 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 system by requesting services via an application program interface (API). Some application programs allow end users to interact with a hardware / software interface system via a user interface such as a command language or a graphical user interface (GUI).

  The hardware / software interface system, as before, performs various services for applications. In a multitasking hardware / software interface system in which a plurality of programs can be executed simultaneously, the hardware / software interface system determines which application should be executed in what order, and before switching to another application. Determine how much time should be allowed for each application. The hardware / software interface system also manages the sharing of internal memory among multiple applications and handles input and output to and from connected hardware devices such as hard disks, printers, and dialup ports . The hardware / software interface system also sends messages to each application (and, in certain cases, the end user) regarding the operating status and any possible errors. The hardware / software interface system can offload management of batch jobs (eg, printing) and resume other processing and / or operations so that application initiation is not tied to batch jobs. In computers that can provide parallel processing, the hardware / software interface system also manages the division of the program so that the program is executed on multiple processors at once.

  A hardware / software interface system shell (referred to herein simply as a “shell”) is an interactive end-user interface with a hardware / software interface system. (The shell can also be called a “command interpreter” and, in the operating system, it can also be called an “operating system shell”). A shell is an external 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 many embodiments of the present invention are envisioned to be particularly compatible with computer-based systems, no part of this document is intended to limit the present invention to such embodiments. Conversely, the term “computer system” as used herein can store and process information regardless of whether the device is electronic, mechanical, logical, or virtual in nature, and / or It is intended to encompass any device that can use stored information to control the operation or execution of such a device itself.

B. Traditional File-Based Storage Today, in most computer systems, a “file” is a storable unit of information that can include hardware / software interface systems as well as application programs, data sets, and the like. In all current hardware / software interface systems (Windows®, Unix®, Linux, Mac OS, virtual machine systems, etc.), files can be handled by the hardware / software interface system Individual (storable and retrievable) information unit (eg, data, program, etc.). Groups of files are generally organized into “folders”. In Microsoft Windows®, Macintosh OS, and other hardware / software interface systems, a folder is a collection of files that can be acquired, moved, and handled as a single unit of information. These folders are organized into a tree-based hierarchy called a “directory” (discussed in more detail later herein). In other specific hardware / software interface systems, such as DOS, z / OS, and most Unix-based operating systems, the terms “directory” and / or “folder” are interchangeable and Although Apple's Apple computer system (eg, Apple IIe) used the term “catalog” rather than a directory, all of these terms used herein are considered synonymous and interchangeable, It is intended to further include references to the information storage structure and all other equivalent terms and components for its folder and file components.

  Conventionally, a directory (also called a directory consisting of folders) is a tree-based hierarchical structure in which files are grouped into folders, and folders are arranged according to the location of relative nodes including the directory tree. For example, as shown in FIG. 2A, a base folder (or “root directory”) 212 of a DOS-based file system can include a plurality of folders 214, each as a “subfolder” of that specific folder. ) Additional folders 216 can be included, and each additional folder 216 can also include infinite additional folders 218. Each of these folders can have one or more files 220, but at the hardware / software interface system level, the individual files in the folder have nothing in common except for their location in the tree hierarchy. Not surprisingly, this approach to organizing files into folder hierarchies is a common storage medium used to store such files (eg, hard disks, floppy disks, CD-ROMs, etc.). Indirectly reflects physical organization.

  In addition to the above, each folder is a container for its subfolders and files. That is, each folder owns its subfolders and files. For example, when a folder is deleted by the hardware / software interface system, the subfolders and files of that folder are also deleted (each subfolder recursively further includes its own subfolders and files). Similarly, each file is generally owned by only one folder, the file can be copied and this copy can be placed in a different folder, but the copy of the file is directly related to the original file A completely different unit (for example, changes to the original file are not reflected in the copy file at the hardware / software interface system level). In this regard, files and folders are inherently “physical” in nature because folders are treated like physical containers and files are treated as completely different physical elements within such containers. is there.

II. WINFS Storage Platform for Organizing, Searching, and Sharing Data The present invention is directed to a storage platform for organizing, searching, and sharing data, along with related inventions incorporated by reference, as described hereinabove. . The storage platform of the present invention is designed to expand and expand the data platform to exceed existing file and database systems and become a store for all types of data, including new forms of data called “items”. The

C. Glossary The following terms used in the specification and claims have the following meanings.
“Item” is a storable unit of information accessible to the hardware / software interface system, and unlike a simple file, all objects exposed to the end user by the hardware / software interface system shell An object that has a basic set of properties that are generally supported across. “Items” also have properties and relationships that are generally supported across all “item” types, including features that introduce new properties and relationships (discussed in detail later herein).
An “operating system” (OS) is a special program that acts as an intermediary between application programs and computer hardware. Most operating systems include a shell and a kernel.
A “hardware / software interface system” is software, or a combination of hardware and software, that serves as an interface between the underlying hardware components of a computer system and applications running on the computer system. The hardware / software interface system component generally comprises an operating system (and in some embodiments may consist solely of the operating system). The hardware / software interface system component may be a virtual machine manager (VMM), common language runtime (CLR) or functional equivalent thereof, Java virtual machine in a computer system instead of or in addition to an operating system. (JVM) or functional equivalents thereof, or other such software components. The purpose of the hardware / software interface system is to provide an environment in which a user can execute application programs. Every hardware / software interface system aims to make the computer system easy to use and to use the computer hardware efficiently.

D. Storage Platform Overview Referring to FIG. 3, the storage platform 300 includes a data store 302 implemented on a database engine 314. In one embodiment, the database engine comprises a relational database engine having an object relational extension. In one embodiment, the relational database engine 314 comprises a relational database engine called Microsoft SQL Server. The data store 302 implements a data model 304 that supports data organization, retrieval, sharing, synchronization, and security. As will be described in greater detail below, specific data types are described in a schema, such as schema 340, and storage platform 300 provides tools 346 for expanding and extending such schemas.

  A change tracking mechanism 306 implemented in the data store 302 provides the ability to track changes to the data store. The data store 302 also provides a security capability 308 and a promotion / demotion capability 310, both of which will be discussed in more detail later. The data store 302 also provides a set of application programming interfaces for exposing the performance of the data store 302 to other storage platform components and application programs that use the storage platform (eg, application programs 350a, 350b, and 350c). 312 is provided. The storage platform of the present invention allows application programs such as application programs 350a, 350b, and 350c to utilize all of the above capabilities of the storage platform and to access data described in the schema. An interface (API) 322 is further provided. The storage platform API 322 can be used by application programs in combination with other APIs such as the OLE DB API 324 and the Microsoft Windows (registered trademark) Win32 API 326.

  The storage platform 300 of the present invention may provide various services 328 to application programs, including a synchronization service 330 that facilitates sharing of data between users or systems. For example, the synchronization service 330 may allow interoperability with other data stores 340 having the same format as the data store 302, as well as access to data stores 342 having other formats. The storage platform 300 also provides file system capabilities that allow the data store 302 to interoperate with existing file systems, such as the Windows NTFS file system 318. In at least some embodiments, the storage platform 320 may also provide additional performance application programs that allow for interacting with data and allowing interaction with other systems. Such performance may be realized in the form of additional services 328, such as information agent service 334 and notification service 332, as well as other utilities 336.

  In at least some embodiments, the storage platform is implemented as or forms an integral part of a hardware / software interface system of a computer system. By way of example, and not limitation, the storage platform of the present invention includes an operating system, a virtual machine manager (VMM), a common language runtime (CLR) or functional equivalent thereof, or a Java virtual machine (JVM) or function thereof. May be realized as an integral part of a technical equivalent and may form such an integral part. With a common storage infrastructure and data organization, the storage platform of the present invention enables more efficient application development for consumers, knowledge workers, and businesses. The storage platform of the present invention provides a rich and extensible programming surface area that not only makes available the performance inherited in the data model, but also encompasses and extends existing file systems and database access methods.

  In the following description and various drawings, the storage platform 300 of the present invention may be referred to as “WinFS”. However, the use of this name to refer to the storage platform is for descriptive convenience only and is not intended to be in any way limiting.

E. Data Model The data store 302 of the storage platform 300 of the present invention implements a data model that supports the organization, retrieval, sharing, synchronization, and security of data residing in the store. In the data model of the present invention, an “item” is a basic unit of stored information. The data model declares "item" and "item" extensions, establishes a relationship between "items", and "items" as "item folders" and "categories", as will be explained in full detail later. Provides a mechanism to organize.

  The data model relies on two basic element mechanisms: “types” and “relationships”. A “type” is a structure that provides a form that governs the shape of an instance of a “type”. A format is expressed as an ordered set of “properties”. A “property” is a value name or a set of values of a given “type”. For example, the USPostAddress type can have properties of street name, city, zip code, state, where the street name, city, and state are “string” types, and “zip code” is an Int32 type. The street name may be multi-valued (ie, a set of values), with the address having multiple values for the “street name” property. The system defines certain basic element types that can be used in the construction of other types. Basic element types include String, Binary, Boolean, Int16, Int32, Int64, Single, Double, Byte, DateTime, Decimal, and GUID. A "type" "property" can be defined using any of the base element types (with some limitations mentioned later). For example, a “location type” having “coordinate” and “address” properties may be defined, where the “address property” is the USPostAddress “type” described above. Properties may be required or optional.

  A relationship can be declared and can represent a mapping between a set of instances of two types. For example, there may be a “relationship” called LivesAt that defines which person lives in which place, declared between “human type” and “place type”. This “relationship” has a name, two endpoints, a source endpoint and a target endpoint. A relationship can also have an ordered set of properties. Both the “source” and “target” endpoints have a “name” and a “type”. For example, a LivesAt “relationship” has a “person” of type “people”, a “source” called “resident”, and a “target” called “resident” of the “location” type. Has StartDate and EndDate properties that indicate the period of residence. A “person” may live in multiple residences over a long period of time, and there may be multiple residents in a residence, so the most suitable place to have StartDate and EndDate information is the relationship itself Please note that.

  A relationship defines a mapping between instances that is constrained by a type given as an endpoint type. For example, since “automobile” is not “person”, the LivesAt relationship should not be a relationship in which “automobile” is “resident”.

  The data model allows the definition of relationships between subtypes between types and supertypes. The relationship between subtypes, also known as BaseType relationships, and supertypes is defined such that if “type” A is a BaseType of “type” B, then all instances of B are also instances of A. The In other words, every instance that conforms to B must also conform to A. For example, if A has a “name” property of type “string” and B has an “age” property of type “Int16”, then every instance of B will have both “name” and “age” Will have to. The type hierarchy can be assumed as a tree with one 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 similarly, the lowest-level (leaf- Most) subtype. The tree is not constrained to be a uniform depth, but cannot contain cycles. A given “type” can have zero or many subtypes and zero or one supertype. A given instance may conform to at most one type and at the same time conform to its supertype. In other words, for any given instance of a level in the tree, an instance can conform to at most one subtype at that level. A type is said to be “abstract” if an instance of the type must also be an instance of a subtype of that type.

1. Item An “item” is a storable unit of information that, unlike a simple file, is a basic set of information that is generally supported across all objects exposed by the storage platform to end users or application programs. An object that has properties. “Items” also have properties and relationships that are generally supported across all “item” types, including features that introduce new properties and relationships, as will be discussed later.

  An item is an object for common operations such as copying, erasing, moving, opening, printing, backup, restoration, and duplication. An item is a unit that can be stored and retrieved, and any form of storable information that is manipulated by the storage platform is as an "item", "item" property, or "relationship" between "items" Each of which is described in more detail later herein.

  Items are intended to represent easy-to-understand data units, such as the real world and “all kinds” “contacts”, “people”, “services”, “locations”, “documents”, and the like. FIG. 5A is a block diagram showing the structure of “item”. The non-limiting name of “item” is “Location”. The limited name of “item” is “Core.Location” indicating that this “item” structure is defined as a specific type of “item” in the “core schema”. ("Core schema" is discussed in more detail later in this document).

  The Location “item” has multiple properties including EAddresses, MetropolitanRegion, Neighborhood, and PostAddresses. The specific type of property for each 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 the property type is shown in parentheses ("[]"), and the asterisk ("*") to the right of the colon (":") is unspecified. And / or infinite ("many"). A “1” to the right of the colon indicates that at most one value can exist. A zero (“0”) to the left of the colon indicates that the property is optional (it may not have a value). A “1” to the left of the colon indicates that there must be at least one value (its property is required). Both Neighborhood and MetropolitanRegion are “nvarchar” (or equivalent) types that are predefined data types or “simple types” (shown here without capitalization). However, EAddresses and PostAddresses are properties of a defined type or “composite type” (capitalized herein) of the EAddress and PostAddress types, respectively. A complex type is a type derived from one or more simple data types and / or other complex types. The complex type of the “item” property also constitutes a “nested element”. This is because the details of complex types are nested directly in “items” to define the properties of “items”, and the information associated with these complex types, along with “items” with these properties (in this document, As will be discussed later, within the boundaries of the “item”. The concept of such typing is well known and will be readily understood by those skilled in the art.

  FIG. 5B is a block diagram illustrating composite property types PostAddress and EAddress. The PostAddress property type is that the “Item” of the PostAddress property is zero or one City value, zero or one CountryCode value, zero or one MailStop value, and any number (zero to many) of PostalAddressType, etc. Define what can be expected to have Thus, the data shape of a particular property in the “item” is defined here. Similarly, the EAddress property type is defined as shown in the figure. Although optionally used herein, another way of representing a complex type in a Location item is to write an “item” in it that lists the individual properties of each complex type. FIG. 5C is a block diagram showing the Location item and further describing its composite type. However, it should be understood that this alternative representation of the Location item of FIG. 5C is exactly the same “item” as shown in FIG. 5A. The storage platform of the present invention also allows sub-typing so that one property type can be a sub-type of another property type (one property type inherits the properties of another parent property type) ).

  Similar to but strictly different from a property and its property type, an item essentially represents a unique “item type” that can also be subtyped. In other words, the storage platform in some embodiments of the present invention causes an “item” to be a subtype of another “item” (by doing so, an item can have properties of other parent “items” Inherit). Further, in the various embodiments of the present invention, all “items” are subtypes of the “item” type called Item, which is the first basic “item” type found in the “base schema”. is there. ("Base Schema" will also be discussed in detail later in this specification.) FIG. 6A shows "Item" as a subtype of "Item" type "Item" found in "Base Schema", ie, this "Instance" "Is a figure which shows a Location item. In FIG. 6A, the arrow indicates that the Location item (like all other “items”) is a subtype of the “item” type of Item. The Item "item" type has some important properties, such as ItemId and various timestamps, as the basic "item" from which all other "items" are derived. Defines standard properties for all items in the operating system. In this figure, these “item” type properties, Item, are inherited by Location and, by doing so, become properties of Location.

  Another way to represent properties in a Location item, inherited from the Item type called Item, is to write a Location that lists the individual properties of each property type in it. FIG. 6B is a block diagram illustrating the Location item and describing its inheritance type in addition to its direct properties. This “item” is the same “item” as shown in FIG. 5A, but in FIG. 6A, Location has all of its properties directly as shown in both FIG. 6A and FIG. Although not shown in FIG. 6A, it is shown by having inheritance as shown in FIG. 6A (in FIG. 5A, these properties indicate that the Location item is a subtype of the “Item” type of Item. It is noted and understood).

  An item is an independent object. Thus, deleting an “item” also deletes all the direct and inherited properties of that “item”. Similarly, when an “item” is obtained, all that is received is the “item” and its direct and inherited properties (including information associated with the property type). In certain embodiments of the invention, it may be possible to request a subset of properties when obtaining a specific “item”, but the default for many such embodiments is that when obtained, To provide an “item” with all of its direct and inherited properties. In addition, the properties of an “item” can be extended by adding new properties to existing properties of that “item” type. These “extensions” then become formal properties of “items”, and subtypes of that “item” type can automatically include extended properties.

The “boundary” of “item” is represented by its properties (including complex property types, extensions, etc.). The “item” boundary represents a limit of operations performed on the “item”, for example, copying, deleting, moving, creating, and the like. For example, in some embodiments of the invention, when an “item” is copied, everything within the boundaries of that “item” is also copied. For each “item”, the boundary includes:
・ "Item type" of "item", and when "item" is a subtype of another "item" (all "items" are a single "item" and "item" in the "base schema" As with some embodiments of the present invention derived from "type", any applicable subtype information (ie, information associated with the parent "item type"). If the original copied “item” is a subtype of another “item”, the copy can also be a subtype of that same “item”.
• “Item” complex properties and extensions, if any. If the original “item” has complex type properties (unique or extended), the copy may also have the same complex type.
・ Record of “item” in “ownership relationship”, that is, what other “item” (“target item”) is owned by the current “item” (“owning item”), "Item" own list. This list is particularly suitable for “item folders”, discussed in more detail later, and the rules listed below that all “items” must belong to at least one “item folder”. Further, with respect to embedded items, discussed in more detail later, embedded items are considered part of an “item” that is embedded for operations such as copying, erasing, and the like.

2. Item Identification Items are uniquely identified using ItemIDs in the global item space. Base. The Item type defines a GUID type ItemID field that stores the identification of an “item”. An “item” must have only one identification in the data store 302.

  The item reference is a data structure including information for finding and identifying an “item”. In the data model, an abstract type named ItemReference is defined from which all item reference types are derived. The ItemReference type defines a virtual method named Resolve. The Resolve method resolves ItemReference and returns “item”. This method is overridden by specific subtypes of ItemReference, which implements a function that gets an “item” when given a reference. The Resolve method is invoked as part of the storage platform API 322.

  ItemIDReference is a subtype of ItemReference. ItemIDReference defines the Locator and ItemID fields. The Locator field names (ie identifies) the item domain. The Locator field is processed by a locator resolution method that can resolve the value of the Locator to the item domain. The ItemID field is an ItemID type.

  ItemPathReference defines ItemReference that defines the Locator and Path fields. The Locator field identifies the item domain. The Locator field is processed by a locator resolution method that can resolve the value of the Locator to the item domain. The Path field contains a (relative) path in the storage platform namespace rooted at the item domain given by the Locator.

  This reference type cannot be used in a set operation. This reference must generally be resolved through a path resolution process. The Resolve method of the storage platform API 322 provides this function.

  The reference form described above is represented by the reference type hierarchy shown in FIG. Additional reference types inherited from these types can be defined in the schema. These additional reference types can be used as target field types in relationship declarations.

3. Item Folders and Categories As discussed in more detail later, groups of “items” can be organized into special “items” called “item folders” (which should not be confused with file folders). However, unlike most file systems, “items” can belong to multiple “item folders”, so that “items” are accessed and reviewed in one “item folder”. This reviewed “item” can then be accessed directly from another “item” folder. In essence, access to “items” can occur from different “item folders”, but what is actually being accessed is exactly the same “items”. However, an “item folder” does not necessarily own all of its members “items”, or can only co-own “items” with other folders, so that the “item folder” Erasing does not necessarily delete the “item”. Nevertheless, in some embodiments of the present invention, an “item” must belong to at least one “item folder”, so that the only “item” of a particular “item” When the “folder” is deleted, in some embodiments, the “item” is automatically deleted, or in alternative embodiments, the “item” is automatically a member of the default “item folder” (eg, various A “item folder” called “Trash” that is conceptually similar to a similarly named folder used in simple file and folder based systems).

  As also discussed in more detail later, an “item” can be (a) an “item type” (or multiple “types”), (b) a specific direct or inherited property (or multiple properties), or (c ) Can also belong to “category” based on common descriptive characteristics such as specific value (or values) corresponding to “item” property. For example, an “item” containing specific properties for personal contact information can automatically belong to a “contact category”, and any “item” with a contact information property can also have this “ It will automatically belong to “Category”. Similarly, any “item” with a location property with a value of “New York City” can automatically belong to the New York City category.

  An “item folder” can include “items” that are not interrelated (ie, have no common descriptive properties), and each “item” in a “category” is described for that “category”. A category is a conceptually different form of "item folder" in that it has a common type, property, or value ("commonness"), with other "items" in the "category", and It is this commonality that forms the basis for the relationship between them. Furthermore, the attribution of an “item” in a particular “folder” is not mandatory based on any specific aspect of that “item”, but in certain embodiments it is absolutely in a “category”. All “items” that have relevant relevance can be automatically members of that “category” at the hardware / software interface system level. Conceptually, a “category” can also be thought of as a virtual “item folder” whose attribution is based on a concrete query result (such as in the context of a database). Thus, an “item” that satisfies (as defined by) will include a “category” attribution.

  FIG. 4 shows the structural relationship between “item”, “item folder”, and “category”. The plurality of items 402, 404, 406, 408, 410, 412, 414, 416, 418, and 420 are members of various “item folders” 422, 424, 426, 430, and 430. Some items can belong to multiple “item folders”, for example, “item” 402 belongs to “item folders” 422 and 424. Some “items”, eg, “items” 402, 404, 406, 408, 410, and 412 are also members of one or more “categories” 432, 434, and 436, and sometimes, for example, “items” ”414, 416, 418, and 420 may not belong to any“ category ”(however, this is a specific embodiment in which ownership of any property automatically implies attribution in“ category ”) In such an embodiment, the “item” must be completely unique so that it does not become a member of any category). In contrast to the folder hierarchy, both “categories” and “item folders” have a structure that is relatively similar to a directed graph, as shown. In any case, "item", "item folder", and "category" are all "items" (even if they are different "item types").

  In contrast to files, folders, and directories, the “items”, “item folders”, and “categories” of the present invention are not inherently “physical” in nature. This is because “items” can exist in more than one such location because they have no conceptual equivalent to physical containers. By allowing “items” to exist in multiple “item folders” locations, and organized into “categories”, data processing and storage structure performance is currently in the field at the hardware / software interface level. It will be richer, better than what is available.

4). Schema a) "Basic schema"
In order to provide a universal basis for the creation and use of “items”, various embodiments of the storage platform of the present invention establish a conceptual framework for creating and organizing “items” and properties. A “basic schema” is provided. The “base schema” defines certain special types of “items” and properties, and characteristics of these basic special types from which subtypes can be further derived. By using this “base schema”, a programmer can conceptually distinguish “items” (and “item” types) from properties (and property types). In addition, since every “item” (and corresponding “item type”) is derived from this basic “item” in the “base schema” (and corresponding “item type”), the “base schema” Reveal the basic set of properties that all items can own.

  As shown in FIG. 7, in connection with some embodiments of the present invention, a “base schema” defines three top-level types: Item, Extension, and PropertyBase. As explained, the “item” type is defined by this basic “item” type property. In contrast, the top-level property type “PropertyBase” has no predefined properties, all other property types are derived from it, and all derived property types are passed through it. Are just anchors that are related to each other (generally derived from a single property type). Since an “item” can have multiple extensions, an “extension” type property defines an “item” that the extension extends as well as an identification that distinguishes one extension from another.

  ItemFolder is a subtype of Item type called Item that characterizes the "inheritance" that establishes links to its members (if any) in addition to the properties inherited from Item, both IdentityKey and Property are Both are subtypes 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 a 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”. Files are distinguished by different extensions (* .com, * .exe, * .bat, * .sys, etc.), and other such criteria in file and folder based systems are functions of the “core schema” Is similar. In an “item” based hardware / software interface system, the “core schema” refers to all “items”, “items”, either directly (by the “item” type) or indirectly (by the “item” subtype). A set of core “items” that characterizes one or more “core schema” “item” types that can be understood and processed directly in a predetermined and predictable manner by the base hardware / software interface system Define the type. Predefined “item” types reflect most common “items” in “item” based hardware / software interface systems and thus include “core schemas”. An “item” based hardware / software interface system that understands certain benefits.

  In certain embodiments, the “core schema” is not extensible. That is, any additional “item” type is subtyped directly from the “item” type in the “base schema”, except for the specific predefined derived “item” type that is part of the “core schema”. Can not do it. All subsequent “item” types are always subtypes of the “core schema item” type, so by preventing extensions to the “core schema” (that is, preventing new “items” from being added to the “core schema”) The storage platform mandates the use of the “core schema item” type. This structure provides a reasonable degree of flexibility in defining additional “item” types, while maintaining the advantage of having a predefined set of core “item” types.

For various embodiments of the present invention, referring to FIG. 8A, a specific “item” type supported by a “core schema” may include one or more of the following:
Category: This “item type” “item” (and sub-types derived from it) represents a valid “category” in an “item” based hardware / software interface system.
• Commodity: an item whose value is identifiable.
Device: An item having a logical structure that supports information processing capability.
Document: An item that is not translated by an “item” based hardware / software interface system but has content that is translated by an application program corresponding to the document type.
Event: An item that records a specific event in the environment.
Location: An item that represents a physical location (eg, a geographical location).
Message: An item of communication between two or more principals (defined below).
Principal: An item with at least one identity that can be definitively proved in addition to ItemId (eg, identity of person, edit, group, family, authority, service, etc.)
-Statement: An item with special information about the environment including, but not limited to, policy, registration details, certifications, etc.
Similarly, referring to FIG. 8B, specific property types supported by the “core schema” may include one or more of the following:
Certificate (derived from the basic PropertyBase type in the "Basic Schema")
・ Principal Identity Key (derived from IdentityKey type in “Basic Schema”)
-Post Address (derived from Property type in "Basic Schema")
Rich Text (derived from the Property type in the “Basic Schema”)
EAddress (derived from Property type in “Basic Schema”)
・ IdentitySecurityPackage (derived from the Relation type in the “Basic Schema”)
-RoleOccupancy (derived from the Relation type in the "Basic Schema")
BasicPresence (derived from the Relation type in the “Basic Schema”)
These “items” and “properties” are further described by the respective properties shown in FIGS. 8A and 8B.

5). Relationship If a “item” is specified as a source and another “item” is specified as a target, the relationship is a binary relationship. 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.

  Relationships are categorized into “inclusion” and “reference” relationships. The containment relationship controls the lifetime of the target “item”, but the reference relationship does not provide any lifetime management semantics. FIG. 12 is a diagram illustrating a relationship classification method.

  “Inclusion” relationship types are further classified into “hold” and “embedded” relationships. When all the holding relationships with “item” are deleted, “item” is deleted. The retention relationship controls the lifetime of the target by a reference counting mechanism. Embedding relationships allow modeling of synthetic “items” and can be viewed as exclusive holding relationships. An “item” can be one or more holding relationship targets, but an “item” can be a single embedded relationship target. An “item” that is the target of an embedded relationship cannot be the target of any other retention or embedded relationship.

  The reference relationship does not control the lifetime of the target “item”. The reference relationship may be dangling, i.e. the target "item" may not exist. Reference relationships can be used to model references to “items” anywhere in the global “item” namespace (ie, including remote data stores).

  Taking out an "item" does not automatically take out the relationship. An application must explicitly request an “item” relationship. Furthermore, modifying a relationship does not modify the source or the target “item”. Similarly, adding a relationship does not affect the source / target “item”.

a) Declaration of relationship An explicit relationship type is defined using the following elements:
• A relation name is specified in the “name” attribute.
A relation type that is one of “hold”, “embed”, and “reference”. It is specified in the “type” attribute.
• Source and target endpoints. Each endpoint specifies the name and type of the reference “item”.
The source endpoint field is generally of type ItemID (not declared) and must reference “items” in the same data store as relationship instances.
For “hold” and “embed” relationships, the target endpoint field must be of type ItemIDReference and must reference “item” in the same store as the relationship instance. For “reference” relationships, the target endpoint can be of any ItemReference type and can reference “items” in other storage platform datastores.
Optionally, one or more fields of type scalar or propertybase can be declared. Such fields may include data associated with the relationship.
Relationship instances are stored in a global relationship table.
All relationship instances are uniquely identified by a combination (source ItemID, relationship ID). A relation ID is unique for a given source ItemID for all relations that are sourced from a given "item", regardless of the type of relation.

  The source “item” is the owner of the relationship. The “item” designated as the owner controls the lifetime of the relationship, but the relationship itself is separate from the items related by the relationship. The storage platform API 322 provides a mechanism for publishing relationships associated with “items”.

  An example of a relationship declaration is shown below.

  This example is an example of a “reference” relationship. This relationship cannot be created if there is no “item” of the person referenced by the source reference. Further, when the “item” of the person 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 the state is unstable.

b) Retention Relationship The retention relationship is used to model the lifetime management of the target “item” based on the reference count.

  An “item” can be a source endpoint for zero or more relationships to an “item”. An “item” that is not an “embedded” item can be the target of one or more holding relationships.

  The target endpoint reference type must be ItemIDReference and must refer to an “item” in the same store as a relation instance.

  The retention relationship enforces the lifetime management of the target endpoint. Creation of a holding relationship instance and the “item” targeted by this instance is an atomic operation. Additional retention relationship instances targeting the same “item” can be created. When the last holding relationship instance with a given “item” as a target endpoint is deleted, the target “item” is also deleted.

  The type of endpoint “item” specified in the relationship declaration is generally enforced when an instance of the relationship is created. The type of the endpoint “item” cannot be changed once the relationship is established.

  Retention relationships play an important role in the formation of the “item” namespace. The retention relationship includes a “name” property that defines the name of the target “item” relative to the source “item”. This relative name is unique for all retention relationships arising from a given “item”. This ordered list of relative names, starting from the root “item” to the given “item”, forms the full name for “item”.

  The holding relationship forms a directed acyclic graph (DAG). When a retention relationship is created, the system ensures that no cycles are created, thus ensuring that the “item” namespace forms a DAG.

  The retention relationship controls the lifetime of the target “item” but not the consistency of the behavior of the target endpoint “item”. The target “item” is operationally independent of the “item” it owns through the holding relationship. Copy, move, backup, and other operations on the “item” that is the source of the retention relationship do not affect the “item” that is the target of the same relationship. That is, for example, even if a backup of “folder item” is taken, all “items” in the folder (targets related to FolderMember) are not automatically backed up.

  The following are examples of retention relationships.

  The FolderMembers relationship enables the concept of “folders” as a general collection of “items”.

c) Embedding relations Embedding relations model the concept of exclusive control of the lifetime of a target “item”. Embedding relationships allow the concept of synthetic “items”.

  The creation of an embedded relationship instance and the “item” targeted by this instance is an atomic operation. An “item” can be a source of zero or more embedded relationships. However, an “item” can be the only embed target. The “item” that is the target of the embedded relationship cannot be the target of the holding relationship.

  The target endpoint reference type must be ItemIDReference and must refer to an “item” in the same store as a relation instance.

  The type of endpoint “item” specified in the relationship declaration is generally enforced when an instance of the relationship is created. The type of the endpoint “item” cannot be changed once the relationship is established.

  The embedded relationship controls the consistency of the operation of the target endpoint. For example, reordering an “item” may include serialization of all embedded relationships that originate from that “item” as well as all of the relationship's targets. Copying an "item" also copies all its embedded "items".

  The following is an example declaration:

d) Reference relationship A reference relationship does not control the lifetime of the “item” it references. Furthermore, a reference relationship does not guarantee the existence of a target, nor does it guarantee the target type specified in the relationship declaration. This means that the reference relationship can be unstable. The reference relationship can refer to “items” in other data stores. Reference relationships can be viewed as a concept similar to links in web pages.

  An example of a reference relationship declaration is as follows.

  Any reference type is allowed at the target endpoint. The “item” involved in the reference relationship may be any “item” type.

  Reference relationships are used to model most non-lifetime management relationships between “items”. Since the presence of a target is not mandatory, a reference relationship is convenient for modeling a loosely coupled relationship. Reference relationships can be used to target “items” in other data stores, including stores on other computers.

e) Rules and constraints The following additional rules and constraints apply to relationships.
“Item” must be the target of (only one embedded relationship) or (one or more holding relationships). The only exception is the root “item”. An “item” can be a 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. Can be a source of reference relationships.
“Items” cannot be the source of retention relationships when promoted from a file. Can be the source of embedded and reference relationships.
• An “item” promoted from a file cannot be an embedded target.

f) Relationship Ordering In at least one embodiment, the storage platform of the present invention supports relationship ordering. The ordering is accomplished by a property named “Order” in the basic relationship definition. There are no restrictions on uniqueness for the Order field. The order of relationships with the same “order” property value is not guaranteed, but it is guaranteed that it can be ordered after a lower “order” value relationship and before a higher “order” field value relationship.

  The application can place the relationships in a default order by ordering based on the combination (SourceItemID, RelationshipID, Order). All relationship instances arising from a given “item” are ordered as a single collection, regardless of the type of relationship in the collection. However, this ordering ensures that all relationships of a given type (eg, FolderMembers) are an ordered subset of the relationship collection for a given “item”.

The data store API 312 that handles relationships implements a set of operations that support ordering of relationships. The following terms are introduced to help explain the operation.
RelFirst is the first relationship in the numbered collection with the order value OrdFirst.
RelLast is the last relationship in the numbered collection with the order value OrdLast.
RelX is a given relationship in the collection with the order value OrdX.
RelPrev is the relationship in the collection that is closest to RelX that has an order value OrdPrev less than OrdX.
RelNext is the relationship in the collection closest to RelX that has an order value OrdNext greater than OrdX.

Operations include, but are not limited to:
InsertBeforeFirst (SourceItemID, Relation) inserts the relationship as the first relationship in the collection. The “Order” property value of the new relationship may be less than OrdFirst.
InsertAfterLast (SourceItemID, Relation) inserts the relationship as the last relationship in the collection. The “Order” property value of the new relationship may be greater than OrdLast.
InsertAt (SourceItemID, ord, Relation) inserts a relationship with the specified value of the “Order” property.
InsertBefore (SourceItemID, ord, Relation) inserts a relationship before a relationship with a given order value. The new relationship can be assigned an “Order” value between OrdPrev and ord and not including the boundary.
InsertAfter (SourceItemID, ord, Relation) inserts a relationship after a relationship with a given order value. The new relationship can be assigned an “Order” value that is between ord and OrdNext and does not include a boundary.
MoveBefore (SourceItemID, ord, RelationshipID) moves the relationship with the given relationship ID before the relationship with the specified “Order” value. The relationship can be assigned a new “Order” value between OrdPrev and ord and not including the boundary.
MoveAfter (SourceItemID, ord, RelationshipID) moves the relationship with the given relationship ID after the relationship with the specified “Order” value. The relationship can be assigned a new order value that is between ord and OrdNext and does not include a boundary.

  As described above, all “items” must be members of an “item folder”. Regarding “relationships”, all “items” must have a relationship with “item folders”. In some embodiments of the invention, a particular relationship is represented by a “relationship” that exists between “items”.

  As implemented for various embodiments of the present invention, a “relation” provides a directed binary relationship that is “extended” by one “item” (source) to another “item” (target). . “Relationships” are owned by the source “item” (an “item” that extends the relationship), so when the source is deleted, the “relationship” is deleted (for example, when the source “item” is deleted, "Relationship" is deleted). Further, in certain examples, “relationships” may share (co-own) ownership of the target “item”, such ownership being the IsOwned property of “relationship” (or its equivalent) (As shown in FIG. 7 showing the “relation” property type). In such embodiments, creating a new IsOwned “relationship” automatically increments the reference count for the target “item”, and deleting such a “relationship” may decrement the reference count for the target “item”. . In these specific embodiments, the “item” continues to exist if the reference count is greater than zero and is automatically cleared when the count reaches zero. Again, an “item folder” is an “item” that has (or can have) a set of “relationships” with other “items”, and these other “items” are “items” Includes “folder” attribution. Other actual implementations of “relationships” are possible and are expected to implement the functionality described herein with the present invention.

  Regardless of the actual implementation, a “relationship” is a selectable connection from one object to another. An "item" can belong to multiple "item folders", as well as one or more "categories", and these "items", "folders", and "categories" are public or private This is determined by the meaning given to presence (or non-existence) in the “item” based structure. These logical “relationships” are meanings assigned to a set of “relationships” regardless of the physical implementation, and are used in particular to implement the functions described herein. In essence, “item folder” and “category” are each a special type of “item”, so the logical relationship between “item” and its “item folder (s)” or “category” (and its The opposite). As a result, the “item folder” and “category” can be affected in the same manner as any other “item”. That is, it is copied, added to an email message, and incorporated into a document, but is not limited thereto. The “item folder” and “category” can be serialized and deserialized (imported and exported) using the same mechanism as that of other “items”. (For example, in XML, every “item” can have a serialization format, which applies equally to “item folders”, “categories”, and “items”).

  The above-mentioned “relationship” representing the relationship between “item” and its “item folder (s)” is from “item” to “item folder”, from “item folder” to “item”, or in both directions. Can be logically expanded. The “relationship” that logically expands from “item” to “item folder” indicates that the “item folder” is public to the “item” and shares its attribution information with the “item”. Conversely, the absence of a logical “relation” from “item” to “item folder” means that “item folder” is private to that “item” and does not share its attribution information with that “item”. Indicates. Similarly, a “relation” that logically expands from “item folder” to “item” indicates that “item” is public and can be shared to “that item folder”, and from “item folder” to “ The absence of a logical “relation” to “item” indicates that “item” is private and cannot be shared. As a result, when an “item folder” is exported to another system, it becomes a “public” “item” that is shared in a new context, and “items” are searched for other shareable “items”. When searching for an “item folder”, it is a “public” “item folder” that provides information to the “item” regarding the sharable “item” that belongs to it.

  FIG. 9 is a block diagram illustrating an “item folder” (which is itself an item), its member “item”, and the “relationship” of the interconnection between the “item folder” and its member “item”. The “item folder” 900 has a plurality of “items” 902, 904, and 906 as members. The “item folder” 900 is “public” and the “item folder” 900, its members 904 and 906, and other “item folders”, “categories”, Or, it has a “relation” 912 from an “item folder” 900 to an “item” 902 indicating that the “item” (not shown) can be shared. However, there is no “relation” from “item” 902 to “item folder” 900, which means that “item folder” 900 is private to “item” 902 and its attribution information is “item” 902. Indicates not to share with. On the other hand, the “item” 904 indicates that the “item folder” 900 is public and that the attribution information is shared with the “item” 904, and the “relation” 924 from the “item” 904 to the “item folder” 900 indicates Have However, there is no relationship from “item folder” 900 to “item” 904, which means that “item” 904 is private and “item folder” 900, other members 902 and 906 of the folder, and “ Indicates that it cannot be shared with any other item folder, category, or item (not shown) that can access the item folder 900. In contrast to the relationship to “items” 902 and 904 (or the absence of a relationship), “item folder” 900 has a “relation” 916 from “item folder” 900 to “item” 906, “ “Item” 906 conversely has a “relation” 926 to “item folder” 900, and the two relationships are joint, “item” 906 is public and “item folder” 900, folder members 902 and 904. As well as any other item folder, category or item (not shown) that has access to the “item folder” 900, and the “item folder” 900 is public and its attribution information Is shared with “item” 906.

  As described above, since the “item folder” is “not described”, the “item” in the “item folder” does not need to share commonality. On the other hand, a category is described by the commonality common to all of its member “items”. As a result, “category” attribution is essentially limited to “items” with the described commonality, and in certain embodiments, all “items” that meet the “category” description are automatically Is made a member of "Category". Thus, “item folder” allows a simple type structure to be represented by its membership, and “category” allows membership based on defined commonality.

  Of course, a “category” description is logical in nature, and thus a “category” can be described by any logical representation of a type, property, and / or value. For example, a logical representation of “category” may be its attribution so as to have an “item” having one or both of two properties. If these descriptive properties of “Category” are “A” and “B”, then “Category” attribution is “Item” with property A but no B, Property B but no A It may include “items” and “items” having both properties A and B. This logical representation of a property is described by the logical operator “OR”, where the set of members described by “category” is an “item” with a property A OR B. Those skilled in the art will appreciate that similar logic elements (including but not limited to only “AND”, “XOR”, and “NOT”, or combinations thereof) can also be used to describe the categories. Like.

  Regardless of the distinction between “item folder” (not described) and category (described), “category relationship” with “item” and “item relationship” with “category” are many implementations of the present invention. In form, it is essentially the same as disclosed herein for “item folder” and “item”.

  FIG. 10 is a block diagram illustrating a “category” (which is itself an “item”), its member “item”, and the “relationship” between the “category” and its member “item”. The “category” 1000 has a plurality of “items” 1002, 1004, and 1006 as members, all of which are described by the “category” 1000 (commonness description 1008 ′), common properties, values. Or some combination of type 1008. “Category” 1000 is “Category” 1000, its members 1004 and 1006, and other “Category”, “Item Folder”, or “Item” that can access “Category” 1000, as “Item” 1002 is public ”(Not shown) has a“ relation ”1012 from“ category ”1000 to“ item ”1002, which indicates that it can be shared. However, there is no “relationship” from “item” 1002 to “category” 1000, which means that “category” 1000 is private to “item” 1002 and its attribution information is shared with “item” 1002. Indicates not to. On the other hand, the “item” 1004 has a “relation” 1024 from the “item” 1004 to the “category” 1000 indicating that the “category” 1000 is public and the attribution information is shared with the “item” 1004. . However, there is no extended relationship from “category” 1000 to “item” 1004, which means that “item” 1004 is private and “category” 1000, other members 1002 and 1006 of the folder, and “ Indicates that it is not sharable to any other category, item folder, or item (not shown) that can access “Category” 1000. In contrast to the relationship to “items” 1002 and 1004 (or the absence of a relationship), “category” 1000 has a “relation” 1016 from “category” 1000 to “item” 1006, and “item” 1006 conversely has a “relation” 1026 to “category” 1000, the two relationships being joint, “item” 1006 being public and “category” 1000, folder “item” members 1002 and 1004, As well as any other category, item folder, or item (not shown) that has access to the “category” 1000, and the “category” 1000 is public and its attribution information is “item” ”Indicates sharing with 1006.

  Finally, “category” and “item folder” are “items” themselves, and “items” can have “relationships” with each other, and “category” can be called “item folder”. , And vice versa, “category”, “item folder”, and “item” are, in certain alternative embodiments, other “categories”, “item folders”, And “relationships” with “items”. However, in various embodiments, the “item folder” structure and / or “category” structure is prohibited from including cycles at the hardware / software interface system level. If the “item folder” and “category” structures are similar to a directed graph, the embodiment that prohibits cycles is a directed graph that does not start and end at the same vertex, as per the mathematical definition in the graph theory field. Similar to a directed acyclic graph (DAG).

6). Scalability The storage platform is intended to be provided with an initial set of schemas 340 as described above. However, in at least some embodiments, the storage platform further allows customers including independent software vendors (ISVs) to create new schemas 344 (ie, new “item” and “nested element” types). . This section deals with the mechanism for creating such a schema by extending the “item” and “nested element” types (or simply “element” types) defined in the initial set of schemas 340.

Preferably, the expansion of the initial set of “item” and “nested element” types is subject to the following constraints:
ISV is a new “item” type, ie sub-type Base. You are allowed to introduce Items.
ISV is a new “nested element” type, ie subtype Base. You are allowed to install a NecessaryElement.
ISV is a new extension, namely sub-type Base. You are allowed to install a NecessaryElement. But,
ISVs cannot subtype any type (“Item”, “Nested Element”, or “Extended” type) defined by the initial set of storage platform schema 340.

  Since the “item” type or “nested element” type defined by the initial set of storage platform schema cannot exactly match the requirements of the ISV application, it is necessary to let the ISV customize the type. Customization is allowed using the “extended” concept. An extension is a strongly typed instance, but (a) cannot exist independently of each other and (b) must be attached to an “item” or “nested element”.

  In addition to addressing the need for schema extensibility, the extension is also intended to address the “multi-type specification” problem. In some embodiments, the storage platform cannot support multiple inheritance or duplicate subtypes, so an application can be an instance of a duplicate type (eg, “document” is a legal document as well as a stored document) "Extension" can be used as a method for modeling.

a) Item Extension To provide “item” extensibility, the data model is based on Base. An abstract type named Extension is further defined. This abstract type is the root type for the extended type hierarchy. The application is Base. A specific extension type can be created by subtype designation of Extension.

  Base. The Extension type is defined as follows in the “basic schema”.

  The ItemID field contains the ItemID of the item with which the extension is associated. There must be an “item” with this ItemID. If no item with the given ItemID exists, the extension cannot be created. When “item” is deleted, all extensions with the same ItemID are deleted. The tuple (ItemID, ExtensionID) uniquely identifies the extension instance.

The extension type structure is similar to the item type structure.
-An extension type has a field.-A field may be a basic element or a nested element type.-An extension type can be subtyped.

The following restrictions apply to extension types: • Extensions cannot be the source and target of a relationship.
• Extended instances cannot exist independently of items.
-Extended 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, these instances are independent of each other in both structure and behavior.

  Extension instances are stored and accessed separately from items. All extended type instances are accessible from the global extended view. Regardless of what type of item an instance is associated with, an efficient query can be constructed that returns all instances of a given type of extension. The storage platform API provides a programming model that can store, retrieve, and modify extensions to items.

  An extended type can be a subtyped type 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. Like the “item” type, an “extended” type instance can be accessed directly through the view associated with the extended type. The extension's ItemID indicates which item it belongs to and can be used to obtain the corresponding “item” object from the global “item” view. Extensions are considered part of the item for consistency of operation. Copy / move, backup / restore, and other common operations defined by the storage platform can affect expansion as part of the item.

  Consider the following example: The Contact type is defined in the Windows (registered trademark) type set.

  CRM application developers want to add CRM application extensions to contacts stored on the storage platform. Application developers define CRM extensions that contain additional data structures that the application can manipulate.

  HR application developers may also want to add additional data using Contact. This data is independent of the CRM application data. Again, application developers can create extensions.

  CRMExtension and HRExtension are two independent extensions that can be attached to a Contact item. Each such extension is created and accessed independently.

  In the above example, CRMExtension type fields and methods cannot override any 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 acquired, the extension of this item is not automatically acquired. Given a Contact item, the extension of the related item 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 which item they belong to. All item extensions of an item share the same item id. In the above example, the Contact item instance and the appended CRMExtension and HRExtension instances share the same ItemID.

  The following table summarizes the similarities and differences between the “Item”, “Extension”, and NestedElement types.

b) Extension of the NestedElement type The “nested element” type is not extended using the same mechanism as the “item” type. Nested element extensions are stored and accessed using the same mechanism as nested element type fields.

  The data model defines a root for a nested element type named Element.

  The NecessaryElement type inherits from this type. The NestedElement element type further defines a field that is a multiple set of Elements.

NestedElement extension differs from item extension in the following respects.
-Nested element extension is not an extension type. Base. It does not belong to the extended type hierarchy whose root is the Extension type.
Nested element extensions are stored with the other fields of the item and are not globally accessible. That is, a query that retrieves all instances of a given extension type cannot be constructed.
Nested element extensions are stored in the same way as other nested elements (items) are stored. Like other nested tuples, NestedElement extensions are stored in the UDT. Accessible through the "extended" field of the nested element type.
The collection interface used to access multi-valued properties is also used for extended set access and iteration.

  The following table summarizes and compares "Item Extensions" and NestedElement extensions.

F. Database Engine As described above, the data store is implemented on the database engine. In this embodiment, the database engine comprises a relational database engine that implements an SQL query language, such as the Microsoft SQL server engine with object-relational extensions. This section describes the mapping of the data model that the data store implements for the relational store and provides information about the logical API consumed by the storage platform client according to this embodiment. However, it will be appreciated that different mappings can be used when different database engines are used. Indeed, in addition to implementing the storage platform conceptual data model on a relational database engine, the data model can also be implemented in other types of databases, such as object-oriented and XML databases.

  Object-oriented (OO) database systems provide persistence and transactions for programming language objects (eg, C ++, Java). The storage platform concept of “item” corresponds to “object” in an object-oriented system, but an embedded collection must be added to “object”. Other storage platform type concepts also map object oriented systems, like inheritance and nested element types. Object oriented systems generally already support object identification. Thus, item identification can be mapped to object identification. Item behaviors (actions) correspond to object methods. However, object-oriented systems generally lack organizational performance and search performance. Also, object oriented systems do not support unstructured and semi-structured data. In order to support the complete storage platform data model described herein, concepts such as relationships, folders, and extensions will need to be added to the object data model. In addition, mechanisms such as promotion, synchronization, notification, and security will need to be implemented.

  Similar to object-oriented systems, XML databases support a type system based on single inheritance, based on XSD (XML schema definition). The item type system of the present invention could be mapped to an XSD type model. XSD also does not support behaviors. The XSD for an item must be supplemented with the item's behavior. The XML database handles a single XSD document and does not have editing and extensive search capabilities. Similar to object-oriented databases to support the data model described herein, other concepts such as relationships and folders need to be incorporated into such XML databases. Also, mechanisms such as synchronization, notification, and security need not be implemented.

  In connection with the following subsections, some examples are provided to facilitate general information disclosure. FIG. 13 shows a notification mechanism. FIG. 14 is a diagram illustrating an example in which two transactions are both inserting a new record into the same B-tree. FIG. 15 illustrates the data change detection process. FIG. 16 shows an exemplary directory tree. FIG. 17 illustrates an example where an existing folder in a directory-based file system is moved to the storage platform data store.

1. Data Store Implementation Using UDT In one embodiment, a relational database engine 314 with a Microsoft SQL server engine supports a built-in scalar type in this embodiment. The built-in scalar type is “unique” and “simple”. Built-in scalar types are unique in the sense that users cannot define their own types, and are simple in that they cannot encapsulate composite structures. User-defined types (hereinafter UDT) provide a mechanism for type extensibility beyond the intrinsic scalar type system by allowing users to extend the type system by defining complex structured types. . Once defined by the user, UDT can be used anywhere in a type system that can use built-in scalar types.

  According to 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 “extended” type is the Base. From which all “extended” types are derived. Extension.

  UDT is a CLR class and has a state (ie, a data field) and a behavior (ie, a routine). UDT is a management language, ie, C #, VB. Defined using any of NET. UDT methods and operators can be invoked on instances of that type in T-SQL. The UDT may be the type of a column in a row, the type of a routine parameter in T-SQL, or the type of a variable in T-SQL.

  The mapping of storage platform schemas to UDT classes 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 reflects storage platform type inheritance, and storage platform properties are mapped to CLR class properties.

2. Item Mapping One possible implementation of "item" storage in the database store because "item" is searchable globally and support for inheritance and type substitutability in the relational database of this embodiment is desirable The form is Base. One would have stored all “items” in a single table with Item type columns. With type substitutability, all types of "items" can be stored, and Yukon's "is of (Type)" operator is used to filter the search by "item" type and subtype I can do it.

  However, due to problems with such techniques associated with overhead, in this embodiment, “items” are top-level so that “items” of each type “family” are stored in separate tables. Divided by level type. Under this division scheme, Base. A table is created for each “item” type that inherits directly from an Item. Types that inherit from subtypes are stored in the appropriate type family table using type substitution possibilities as described above. Base. Only the first level inheritance from Item is treated specially.

  For every “item”, a “shadow” table is used to store a globally searchable copy of the property. This table can be maintained by the Update () method of the storage platform API to make all data changes. Unlike the type family table, this global “item” table is not a full UDT “item” object, but only contains the top-level scalar properties of “item”. The global “item” table allows navigation to “item” objects stored in the type family table by exposing ItemID and TypeID. ItemID generally uniquely identifies an “item” in the data store. TypeID, which is not described here, can be mapped to type names and views that contain “items” using metadata. Finding an “item” by ItemID may be a common action, so in both the context of the global “item” table and the other contexts, given the ItemID of “item”, GetItem ( ) Function is provided.

  In order to hide as much access and implementation details as possible, all “Item” queries may be on views built on the “Item” table described above. Specifically, a view can be created for the appropriate type family table for each “item” type. These types of views can select all “items” of the associated type, including subtypes. For convenience, in addition to UDT objects, a view can expose columns for 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 root type that supports inheritance, “extensions” are the subject of many of the same considerations and trade-offs in memory. For this reason, a similar family mapping of types, rather than a single table approach, applies to “extension”. Of course, in other embodiments, a single table approach can be used. In the present embodiment, the “extension” includes an extension ID that is associated with only one “item” by ItemID and is unique in the context of “item”. As in the case of “item”, a function for obtaining “extended” can be provided when given an identification consisting of a pair of ItemID and extended ID. As with the “item” type view, a view is created for each “extended” type.

4). Nested Element Mapping Nested elements are types that can be incorporated into “items”, “extensions”, “relationships”, or other “nested elements” to form deeply nested structures. “Nested element” is implemented as UDT like “item” and “extension”, but is stored in “item” and “extension”. Thus, a “nested element” has no storage mapping beyond that of the element's “item” and “extended” containers. In other words, there is no table in the system that directly stores an instance of a nested element type, and there is no dedicated view for “nested elements”.

5). Object Identification Each entity in the data model, ie, each “item”, “extension”, and “relation”, has a unique key value. An “item” is uniquely identified by its ItemId. “Extension” is uniquely identified by a composite key consisting of (ItemId, ExtensionId). The “relationship” is identified by a composite key (Itemd, RelationshipId). ItemId, ExtensionId, and RelationshipId are GUID values.

6). SQL Object Naming All objects created in the data store can be stored in a SQL schema name derived from the storage platform schema name. For example, a storage platform's “base” schema (often referred to as “Base”) can 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 it is appropriate to do so, an exclamation point (!) Is used as a delimiter for each logical part of the name. The following table summarizes the naming convention used for objects in the data store. Each schema element (“item”, “extension”, “relation”, and “view”) is listed along with a decorative naming convention used to access instances in the data store.

7). Naming Columns When mapping any object model in the store, naming conflicts can arise due to additional information stored with the application object. To avoid naming conflicts, all columns that are not type-specific (columns that do not map directly to named properties in the type declaration) are prefixed with an underscore (_) character. In this embodiment, the underscore (_) character is not recognized as the first character of any identifier property. In addition, all properties of storage platform types or schema elements (such as relationships) should capitalize the first letter in order to unify naming between the CLR and the data store.

8). Search view A view that searches stored content is provided by the storage platform. A SQL view is provided for each “item” and “extended” type. In addition, views are provided to support “relationships” and “views” (defined by the data model). All SQL views and base tables in the storage platform are read-only. Data can be stored or modified using the Update () method of the storage platform API, as will be described in detail later.

  Each view that is 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! <View-name>] is accessible. For example, a view named “BookSales” in the schema “AcmePublisher.Books” can be accessed using the name “[AcmePublisher.Books]. [View! BookSales]”. Since the view output format is custom for each view (defined by any query given by the view definer), 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 the columns:

• Logical “key” column (s) of view results, such as ItemId, ElementId, RelationshipId, etc.
-Metadata information about result types such as TypeId-Change tracking columns such as CreateVersion and UpdateVersion-Type-specific columns (groups) (declared type properties)
• Type-specific views (family views) also contain object columns that return objects. Members of each type family can be searched using a series of “items” views, and the data store contains “item” types There is one view. FIG. 28 is a diagram showing the concept of the “item” search view.

a) Items Each “item” search view includes a row for each instance of “item” of the specific type or its subtype. For example, a “document” view may return an instance of a document, LegalDocument, and ReviewDocument. Given 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. For each “item” type property, this view provides a column describing the type of “item” and several columns 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-Specified 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 through the “_Item” column. Each type-designated item search view is [schemaName]. It is identified in the data store using the name [itemTypeName]. For example, [Acme Corp. Doc]. [OfficeDoc].

b) Item Extensions All item extensions in the WinFS store are also accessible using the search view.

(1) Master Extended Search View Each instance of the data store defines a special “extended” view called a “master extended view”. This view provides summary information about each “extension” in the data store. For each “extension” property, this view has one column describing the type of “extension” and several columns 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-Specified Extended Search View Each “Extended” type also has a search view. Similar to the master extension view, this view also provides access to the “Item” object through the “_Extension” column. Each type-specific extended search view is [schemaName]. [Extension! It is identified in the data store using the name extensionTypeName]. For example, [Acme Corp. Doc]. [Extension! OfficeDocExt].

c) Nested elements All nested elements are stored in "item", "extended", or "relation" instances. As such, nested elements are accessed by querying the appropriate “item”, “expansion”, or “relationship” search views.

d) Relationships As described above, “relationships” form the basic unit that links between “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 Search View Each declaration “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 relation instance search view has [schemaName]. [Relationship! It is identified in the data store using the name relationshipName]. 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, the storage platform API ProcessOperation or ProcessUpdategram method must be used. The ProcessOperation method is a single stored procedure defined by a data store that consumes “actions” detailing the actions to be performed. The ProcessUpdategram method is a stored procedure that performs an ordered set of operations known as “updategram” that details the set of actions performed as a whole.

  The behavior format is extensible and provides various behaviors for schema elements. Some common operations include:

1. Item action a. CreateItem (creates a new item in the context of an embedding or holding relationship)
b. UpdateItem (updates an existing “item”)
2. Related actions:
a. CreateRelationship (create a reference or retention relationship instance)
b. UpdateRelationship (update relationship instance)
c. DeleteRelationship (delete relationship instance)
3. Extended behavior:
a. CreateExtension (adds an extension to an existing “item”)
b. UpdateExtension (updates an existing extension)
c. DeleteExtension (delete extension)
10. Change Tracking and Deletion Indicator The change tracking and deletion indicator service is provided by the data store as will be discussed in more detail later. This section outlines 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. These columns are common across all “Item”, “Extended”, and “Relationship” views. The storage platform “schema view” explicitly defined by the schema designer does not automatically provide change tracking information. Such information is provided indirectly through a search view in which the view itself is built.

  For each element in the data store, change tracking information is available from two locations: a “master” element view and a “typed” element view. For example, Acme Corp. Document. The change tracking information for the “Item” type “Document” includes “Master Item View” “[System.Storage]. [Master! Item]” and Type-Specified “Item” Search View [AcmeCorp. Document]. Available from [Document].

(1) Change tracking in the “master” search view The change tracking information in the master search view includes information about the creation and update version of the element, information about which synchronization partner created the element, and which synchronization partner last added the element. Provide an updated version number from each partner who created and updated. A partner (described later) in the synchronization relationship is identified by a “partner key”. [System. Storage. Store]. A single UDT object named _ChangeTrackingInfo of type ChangeTrackingInfo contains all this information. This type is described in System. Defined in the Storage schema. _ChangeTrackingInfo is available for “items”, “extensions”, and “relationships” in all global search views. The type definition of ChangeTrackingInfo is as follows.

These properties include the following information:

(2) Change tracking in the “typed” search view In addition to providing the same information as the global search view, each typed search view provides additional information that records the synchronization status of each element in the synchronization topology.

b) Delete indicator The data store provides “items”, “extensions”, and “relationships”. The delete indicator view provides delete indicator information for both live and deleted indicators (items, extensions, and relationships) in one place. The item and extended delete indicator views do not provide access to the corresponding object, but the relationship delete indicator view provides access to the relationship object (the relationship object is NULL for relationships that have been deleted). provide.

(1) Item deletion indicator The item deletion indicator is a view [System. Storage]. [Tombstone! Item] from the system.

(2) Extended deletion indicator The extended deletion indicator is a view [System. Storage]. [Tombstone! Obtained from the system using Extension]. Extended change tracking information is similar to that provided for “Items”, and an ExtensionId property is added.

(3) Relationship deletion indicator The relationship deletion indicator is a view [System. Storage]. [Tombstone! Obtained from the system via Relationship. The relationship deletion indicator information is similar to that provided for “extension”. However, additional information about the target ItemRef of the related instance is provided. In addition, related objects are also selected.

(4) Cleanup of delete indicator In order to prevent the delete indicator information from increasing without limit, the data store provides a delete indicator cleanup task. This task determines when the deletion marker information may be discarded. The task calculates the limits for the local create / update version and then truncates the delete indicator information by discarding all previous delete indicator versions.

11. Helper APIs and functions The base mapping also provides several helper functions. Such functions are provided to assist common operations on the data model.

  a) Function [System. Storage]. GetItem

  b) Function [System. Storage]. GetExtension

  c) Function [System. Storage]. GetRelationship

12 Metadata Two types of metadata are represented in the “Store”: instance metadata (such as the type of “item”), 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 applications to query the type of “item” and finds the extension associated with “item”. Given an ItemId for “item”, the application queries the global item view to return the type of “item” and uses this value to set Meta. The Type view can be queried to return information about the declared type of “item”. Examples are given below.

G. Security In general, all objects that can be secure arrange their access rights using the access mask format shown in FIG. In this format, the lower 16 bits are for object-specific access rights, the next 7 bits are standard access rights that apply to most types of objects, and the 4 upper bits are one set for each object type. Used to specify universal access rights that can be mapped to standard and object specific rights. The ACCESS_SYSTEM_Security bit corresponds to the right to access the SACL of the object.

  In the access mask structure of FIG. 26, item specific rights are placed in the “object specific rights” section (lower 16 bits). In this embodiment, the storage platform exposes two sets of APIs for managing security, namely Win32 and the storage platform API. Therefore, in order to facilitate the design of the rights specific to the storage platform object, Must be considered.

  The security model for the storage platform of the present invention is described in detail in the related application incorporated herein by reference above. In this regard, FIG. 27 (parts a, b, and c) shows a new security area that is independently protected and separated from the existing security area, according to one embodiment of the security model.

H. Notification and Change Tracking According to another aspect of the present invention, the storage platform provides notification capabilities that allow applications to track data changes. This feature is primarily intended for applications that maintain a volatile state or perform business logic on data change events. The application registers for notifications about items, item extensions, and item relationships. The notification is delivered asynchronously after the data change is confirmed. Applications can filter notifications by item, extension, and relationship type as well as action type.

  According to one embodiment, the storage platform API 322 provides two types of interfaces for notification. First, the application registers for simple data change events that are triggered by changes to items, item extensions, and item relationships. Second, the application creates a “watcher” object to monitor item sets, 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 a long time. A single notification may reflect multiple updates.

  Further details regarding this function can be found in the related applications incorporated herein by reference above.

I. Synchronization According to another aspect of the present invention, the storage platform provides a synchronization service 330, which (i) provides a set of storage platforms to each instance (each having its own data store 302). Synchronize some of its content according to flexible rules, and (ii) provide an infrastructure for third parties to synchronize the storage platform data store of the present invention with other data sources that implement their own protocols .

  Synchronization between storage platforms occurs between groups of participating replicas. For example, referring to FIG. 3, synchronization between the data store 302 of the storage platform 300 and another remote data store 338 is controlled under the control of another instance of the storage platform, possibly running on a different computer system. It would be desirable to bring. The overall membership of this group is not always known to every replica.

  Different replicas can make changes independently (ie, simultaneously). The synchronization process is defined as making all replicas aware of changes made by other replicas. This synchronization performance is inherently multi-master.

The synchronization performance of the present invention allows a replica to:
Determine what changes another replica is aware of.
Request information about changes that this replica is not aware of.
Communicate information about changes that this other replica is not aware of.
Determine when two changes are in conflict.
• Apply changes locally.
-Tell the other replicas of the conflict resolution to converge.
Resolve conflicts based on the policy specified for conflict resolution.

1. Synchronization between Storage Platforms The main application of the storage platform synchronization service 330 of the present invention synchronizes multiple instances of the storage platform, each having its own data store. The synchronization service operates at the level of the storage platform schema (not the base table of the database engine 314). Thus, for example, a “scope” is used to define a synchronization set as discussed later.

  Synchronous services operate on the “pure change” principle. Rather than recording and sending individual actions (eg, with transactional replication), the synchronization service sends the final results of such actions, and thus often aggregates the results of multiple actions, resulting in a single change. .

  Synchronous services generally do not care about transaction boundaries. In other words, if two changes are made to the storage platform data store in a single transaction, there is no guarantee that these changes will be applied atomically on all other replicas. That is, one change can appear without the other. An exception to this principle is that if two changes are made to the same “item” in the same transaction, then such changes are guaranteed to be sent and applied atomically to the other replicas. Thus, an “item” is a consistency unit of the synchronization service.

a) Synchronization Control Application Any application can connect to the synchronization service and initiate a synchronization operation. Such an application provides all the parameters needed to perform synchronization (see the synchronization profile below). Such an application is referred to herein as a synchronous control application (SCA).

  When two storage platform instances are synchronized, the SCA initiates synchronization in one instance. This SCA informs the local synchronization service to synchronize with the remote partner. In the other instance, the synchronization service is invoked by a message sent from the originating machine by the synchronization service. The synchronization service responds based on persistent configuration information (see mapping below) on the destination machine. The synchronization service can be executed on schedule or in response to an event. In such a case, the synchronization service that implements the schedule is the SCA.

  In order to enable synchronization, two steps need to be taken. First, the schema designer must annotate the storage platform schema with the appropriate synchronization semantics (specifying the unit of change, as will be explained later). Second, synchronization must be correctly configured on all machines that have storage platform instances involved in synchronization (discussed later).

b) Schema annotation The basic concept of the synchronization service is the concept of change units. A change unit is the smallest part of a schema that is individually tracked by a storage platform. For all change units, the synchronization service may be able to determine whether the change unit has changed or has not changed since the last synchronization.

  Specifying change units in a schema serves several purposes. First, it is determined how much the synchronous service has a conversation on the wire by specifying the change unit. When a change is made in a 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, the accuracy of conflict detection is determined by specifying the change unit. If two simultaneous changes (these terms are defined in detail in the following sections) are made to the same change unit, the synchronization service causes a conflict. On the other hand, if simultaneous changes are made to different change units, there is no conflict and the changes are merged automatically. Third, the amount of metadata maintained by the system is strongly affected by the designation of the change unit. Much of the synchronization service metadata is kept for each change unit. Therefore, if the change unit is reduced, the synchronization overhead increases.

  To define the change unit, it is necessary to determine the appropriate trade-off. For this reason, the synchronization service involves the schema designer in the process.

  In one embodiment, the synchronization service does not support change units larger than the element. However, the synchronization service supports the ability of the schema designer to specify a change unit that is smaller than the element, that is, the ability to group multiple attributes of an element into separate change units. This capability is accomplished in the present embodiment using the following syntax.

ｃ）同期構成
データの特定の一部を同期させたままにしておくことを望むストレージプラットフォームパートナーのグループは、同期コミュニティと呼ばれる。コミュニティのメンバーは、同期している状態を望むが、必ずしも、データを全く同じように表すわけではない。言い換えると、同期パートナーは、同期しているデータを変換することができる。

c) Synchronous configuration A group of storage platform partners that wants to keep a specific piece of data synchronized is called a synchronization community. Community members want to be in sync, but not necessarily represent the data exactly the same. In other words, the synchronization partner can convert the data being synchronized.

  In a peer-to-peer scenario, it is not feasible for a peer to maintain a translation mapping for all partners. Instead, the synchronization service takes a technique of defining a “community folder”. A community folder is an abstraction that represents a hypothetical “shared folder” that is synchronized with all community members.

  This concept is best illustrated by an example. If Joe wants to keep my document folders on his or her computers synchronized, Joe defines a community folder called JoesDocuments, for example. Then, on all computers, Joe configures a mapping between the hypothetical Joe Documents and the local My Documents folder. From this point on, when Joe's computers synchronize with each other, they talk by documents in JoesDocuments, not by their local items. In this way, all Joe's computers understand each other without knowing who they are. That is, the “community folder” becomes a common language of the synchronous community.

  The configuration of the synchronization service consists of the following three steps. (1) Define a mapping between local folders and community folders, and (2) Sync to determine what has been synced (eg who synced, which subset to send, which subset to receive) Define a profile, (3) define a schedule for which synchronization profile to run, or run the synchronization profile manually.

(1) Community folder mapping Community folder mapping is stored in each machine as an XML configuration file. Each mapping has the following schema:
/ Mappings / cornunityFolder
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 after conversion by mapping. The name follows the folder syntax rules. The local folder must exist for the mapping to be valid. Items in this folder are considered synchronized for each mapping.
/ Mappings / transformations
This element defines how to convert an item from a community folder to a local folder and vice versa. If this element is not present or empty, no conversion is performed. Specifically, this means that no ID is mapped. This configuration is mainly useful for creating a folder cache.
/ Mappings / transformations / mapIDs
This element requires that a newly generated local ID be assigned to all items mapped from the community folder, rather than reusing the community ID. The sync runtime maintains an ID mapping for converting and returning items.
/ Mappings / transformations / localRoot
This element requires that all root items in the community folder be made children of the specified root.
/ Mappings / runAs
This element controls under which authority requests for this mapping are processed. If not present, a sender is assumed.
/ Mappings / runAs / sender
The presence of this element indicates that the sender of the message to this mapping must be impersonated and requires that it be processed under the sender's credentials.

(2) Profile A “synchronization profile” is the entire set of parameters required to initiate synchronization. The synchronization profile is supplied to the “synchronization runtime” by the SCA to initiate synchronization. A synchronization profile for synchronization between storage platforms includes the following information.
A local folder that serves as the source and destination of changes.
Remote folder name to synchronize: This folder must be published by the remote partner by the mapping defined above.
Direction: The synchronization service supports transmission only, reception only, and transmission / reception synchronization.
• Local filter: Select what local information is sent to the remote partner. Expressed as a storage platform query for local folders.
Remote filter: Select what remote information is obtained from the remote partner. Expressed as a storage platform query for community folders.
Conversion: Define how to convert between items and local formats.
Local security: Specifies whether changes obtained from the remote endpoint should be applied under the permission (spoofing) of the remote endpoint, or whether the user initiates synchronization locally.
Conflict resolution policy: Specifies whether conflicts should be rejected, logged, or resolved automatically. Specifies which competing resolver to use, as well as configuration parameters for the resolver if resolved automatically.

  The synchronization service provides runtime CLR classes that allow simple construction of “synchronization profiles”. Profiles can also be serialized to and from XML files for easy storage (often on schedule). However, there is no standard place on the storage platform where all profiles are stored. The SCA may be configured immediately and freely without persisting the profile. Note that local mapping does not need 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 scheduling infrastructure. Instead, the synchronization service relies on a commercially available Windows scheduler having another component, the Microsoft Windows operating system, to perform this task. 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 the Windows® scheduler to perform synchronization on schedule or in response to events such as user logons and logoffs.

d) Competing operation The competing operation in the synchronization service is divided into the following three stages. (1) Conflict detection that occurs when changes are applied: This step determines whether the changes can be safely applied. (2) Automatic conflict resolution and logging: During this step (which occurs immediately after a conflict is detected), the automatic conflict resolver is queried to see if the conflict can be resolved. If not resolved, the conflict can optionally be logged. (3) Conflict checking and resolution: This step occurs when several conflicts are 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 this embodiment, the synchronization service detects two types of conflicts, knowledge-based and constraint-based.

(A) Knowledge base conflict When two replicas make independent changes to the same change unit, knowledge base conflict occurs. Two changes are said to be independent if made without knowing each other. In other words, the version of the first change is not included in the knowledge of the second change, and vice versa. The synchronization service automatically detects all such conflicts based on the replica knowledge described above.

  It may be useful to consider conflicts as branch points in the version history of the change unit. If no conflict occurs during the life of the change unit, the version history of the change unit is a simple chain, with each change occurring after the previous change. In the case of knowledge base conflicts, the two changes occur in parallel and the chain is split into a version tree.

(B) Constraint-based conflicts Independent changes, when applied together, may violate integrity constraints. For example, two replicas that create a file with the same name in the same directory can cause such a conflict.

  Constraint-based conflicts involve two independent changes (similar to knowledge-based conflicts) but do not affect the same change unit. Rather, there are constraints in between, but different change units are affected.

  The synchronization service detects constraint violations when applying changes and automatically causes constraint-based conflicts. Constraint-based conflict resolution typically requires custom code that modifies changes without violating constraints. Synchronous services do not provide a general-purpose mechanism for doing so.

(2) Conflict processing When a conflict is detected, the synchronization service may perform one of three actions (selected by the synchronization initiator in the “synchronization profile”). (1) reject the change and return the change 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 replicas without a head (such as file servers) that are unlikely to have log recording conflicts. Instead, such replicas cause other replicas to handle the conflict by rejecting the conflict.

  The sync initiator configures conflict resolution in the “sync profile”. The synchronization service supports combining multiple competing resolvers into a single profile as follows. First, specify a list of contention resolvers to try until one succeeds, and second, associate contention resolvers with contention types. For example, direct update-to-update knowledge base conflicts to one resolver, but direct all other conflicts to logs.

(A) Automatic conflict resolution The synchronization service provides several default conflict resolvers. This list includes:
• Local preference: Ignore changes received if conflict with data stored locally.
• Remote priority: Ignore local data in case of conflict with received changes.
Prioritize the latest version: For each change unit, choose local or remote priority based on the timestamp of the change (note that synchronization services generally do not rely on clock values. This conflict resolver is , The only exception to that rule).
• Determinism: Choosing the winner in a way that is guaranteed to be the same for all replicas except the important ones. One embodiment of a synchronization service implements this feature by comparing partner IDs in a dictionary fashion.

  In addition, ISVs can implement and install their own competitive resolvers. The custom conflict resolver can accept the configuration parameters. Such parameters must be specified by the SCA in the conflict resolution section of the “sync profile”.

  When the conflict resolver handles the conflict, it returns a list of actions that need to be performed against the runtime (instead of conflicting changes). The synchronization service then applies these actions and adjusts the remote knowledge appropriately to include what the conflict handler considered.

  Another conflict may be detected while applying the solution. In such cases, the new conflict must 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 point of contact that combines the two branches to form a single point. Thus, conflict resolution changes the version history to DAG.

(B) Contention logging A special type of contention resolver is the “contention logger”. The synchronization service logs the conflict as a ConflictRecord type “item”. These records are inversely related to the competing item (unless the item itself has been erased). Each conflict record relates to the incoming change that caused the conflict, the type of conflict: update-to-update, update-to-delete, erase-to-update, insert-to-insert, or constraint, the version of the incoming change, and the replica that sent this incoming call. Including knowledge. Logged conflicts are available for inspection and resolution, as will be explained later.

(C) Conflict checking and resolution The synchronization service provides an API for applications to examine the contention log and propose resolution of contention in the log. This API allows the application to list all conflicts or conflicts associated with a given “item”. It also allows such applications to resolve conflicts recorded in the log in one of three ways: (1) Remote priority: Accept the changes recorded in the log and overwrite the conflicting local changes. (2) Local priority: Ignore conflicting parts of changes recorded in the log. (3) Submit new changes: The application, in its opinion, proposes a merge that resolves the conflict. When the conflict is resolved by the application, the synchronization service removes the conflict from the log.

(D) Replica Convergence and Conflict Resolution Propagation In a composite synchronization scenario, the same conflict may be detected by multiple replicas. When the same conflict is detected, the following can occur: (1) The conflict can be resolved in one replica and the resolution can be sent to the other. (2) Conflicts are automatically resolved in both replicas. Or (3) Conflicts are resolved manually (via a conflict checking API) in both replicas.

  To guarantee convergence, the synchronization service forwards the conflict resolution to other replicas. When a change that resolves a conflict arrives at the replica, the synchronization service automatically finds in the log any conflict records that are resolved by this update and eliminates the record. In this sense, contention resolution at one replica is tied to all other replicas.

  If different winners are chosen by different replicas for the same conflict, the synchronization service will automatically apply one of the two solutions that apply the binding conflict resolution principle and win against the other. The winner is chosen in a deterministic manner that is guaranteed to produce the same result at any time (in one embodiment, using a replica ID dictionary-based comparison).

  When different “new changes” are raised by different replicas for the same conflict, the sync service treats this new conflict as a special conflict and uses the “conflict logger” to propagate the conflict to other replicas. To prevent it. This situation typically occurs by using manual conflict resolution.

2. Synchronization with Non-Storage Platform Data Stores According to another aspect of the storage platform of the present invention, the storage platform is a “sync adapter” for ISVs to synchronize storage platforms to legacy systems such as Microsoft Exchange, AD, Hotmail, etc. Provide an architecture that implements. The “synchronization adapter” benefits from many “synchronization services” provided by the synchronization service, as will be described later.

  Regardless of name, the “synchronization adapter” does not need to be implemented in some storage platform architectures as a plug-in. If it is desired to do so, the “synchronization adapter” can simply be any application that uses the synchronization service runtime interface to obtain services such as enumerating and applying changes.

  In order to make it easier for others to configure and perform synchronization to a given backend, the “sync adapter” writer performs synchronization when given a “sync profile” as described above. It is recommended to expose a standard "sync adapter" interface. The profile provides configuration information to the adapter, and some of this information (eg, “folders” to be synchronized) goes to the “synchronization runtime” to control the runtime services.

a) Synchronization service The synchronization service provides several synchronization services to the adapter writer. For the remainder of this section, it is convenient to refer to the machine where the storage platform is synchronized as the “client” and the non-storage platform backend where the adapter is talking as the “server”.

(1) Change enumeration Based on the change tracking data maintained by the synchronization service, the sync adapter will cause a change store to occur for the data store “folder” since the last synchronization with this partner was attempted. It is possible to easily enumerate changes.

  Changes are listed based on the “anchor” concept, an opaque structure that represents information about the last synchronization. Anker takes the form of “knowledge” of the storage platform, as described in previous sections. “Synchronous adapters” that use the change enumeration service fall into two broad categories: That is, one that uses “stored anchor” and one that uses “given anchor”.

  The distinction is based on where information about the last synchronization is stored. The storage location is on the client or on the server. Often, it is easier for the adapter to store this information on the client, and the back end often cannot conveniently store this information. On the other hand, if multiple clients synchronize to the same backend, storing this information on the client is inefficient, and in some cases, changes that other clients have already pushed up to the server, It is not appropriate because some clients may not notice it. If the adapter wants to use an anchor stored on the server, it must return it to the storage platform when enumerating the changes.

  The storage platform needs to be aware of changes that have been successfully applied on the server in order to maintain the anchor (for local or remote storage). Only these changes can be included in the anchor. During change enumeration, the “synchronization adapter” uses the “acknowledge” interface to report which changes have been successfully applied. Once synchronized, adapters that use the supplied anchor must read the new anchor (which incorporates all changes applied without problems) and send this anchor to the backend.

  Often, adapters need to store adapter-specific data with items that are inserted into the storage platform data store. Examples common to such data are the 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 along with the returned changes. This eliminates the need for the adapter to requery the database in most cases.

(2) Applying changes Applying changes allows the "synchronous adapter" to apply changes received from the adapter backend to the local storage platform. The adapter is expected to translate changes into a storage platform schema. FIG. 24 illustrates a process for generating a storage platform API class from a storage platform “schema”.

  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 that occur without knowing each other. The adapter must specify an anchor as to which conflict detection is performed when using “Apply Changes”. If duplicate local changes that are not included in the adapter knowledge are detected, "Apply Changes" causes a conflict. Similar to “change enumeration”, the adapter can use either stored anchors or supplied anchors. “Apply changes” supports efficient storage of adapter-specific metadata. Such data could be added by the adapter to the applied changes and stored by the synchronization service. Data can be returned in the next change enumeration.

(3) Conflict Resolution The above-described conflict resolution mechanism (log recording and automatic resolution option) can also be used for a synchronous adapter. The “synchronization adapter” can specify a policy for conflict resolution when applying changes. If specified, the conflict is passed to the specified conflict handler and can be resolved (if possible). Conflicts can also be logged. The adapter may be able to detect a conflict when attempting to apply local changes to the backend. In such a case, the adapter can further pass to the “synchronization runtime” the conflict to be resolved according to the policy. In addition, the “synchronization adapter” can request that any conflict detected by the synchronization service be returned to the adapter for processing. This is particularly advantageous when the backend can store and resolve conflicts.

b) Adapter implementation Some "adapter" are just applications that use runtime interfaces, but adapters are recommended to implement standard adapter interfaces. With such an interface, the “synchronization control application” requests that the adapter perform synchronization according to a given “synchronization profile”, cancels ongoing synchronization, and reports progress on ongoing synchronization (percent complete) Will be able to receive.

3. The security synchronization service aims to minimize the introduction to the security model implemented by the storage platform. Rather than defining new rights for synchronization, existing rights 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.

  The sync service does not maintain secure author information. When a change is made at replica A by user U and transferred to replica B, the fact that the change was originally made at A (or by U) is lost. If B forwards this change to replica C, the transfer is under B's authority, not A's authority. As a result, it is limited as follows. If a replica is not trusted to make its own changes to an item, it cannot transfer changes made by other replicas.

  When the synchronization service is started, the synchronization service is performed by the “synchronization control application”. The synchronization service impersonates the identity of the SCA and performs all actions (both locally and remotely) under that identity. For example, consider the case where user U cannot initiate a local synchronization service from a remote storage platform to obtain changes to items for which user U does not have read access.

4). Manageability Monitoring a distributed community of replicas is a complex issue. The synchronization service can collect and distribute information about the status of replicas using a “sweep” algorithm. The properties of the sweep algorithm ensure that information about all constituent replicas is finally gathered and a failing (no response) replica is detected.

  This community-wide monitoring information is available to all replicas. The monitoring tool can be run on arbitrarily chosen replicas to examine this monitoring information and make administrative decisions. Any configuration changes must be made directly on the affected replica.

J. et al. Conventional File System Interoperability As mentioned above, the storage platform of the present invention is intended, at least in some embodiments, to be implemented as an integral part of a computer system hardware / software interface system. Yes. For example, the storage platform of the present invention can be implemented as an integral part of an operating system such as the Microsoft Windows® family of operating systems. As one of the capabilities, the storage platform API becomes part of the operating system API for an application program to interact with the operating system. Thus, the storage platform provides a means for application programs to store information in the operating system, and the storage platform's “item” based data model thus replaces the traditional file system of such operating systems. For example, the storage platform may replace the NTFS file system implemented in the operating system, as implemented in the Microsoft Windows® family of operating systems. Currently, an application program uses the NTFS file system service through the Win32 API published by the Windows (registered trademark) family of operating systems.

  However, to fully replace the NTFS file system with the storage platform of the present invention, it is necessary to recode existing Win32-based application programs, and recognize that such recoding may not be desirable. It would be beneficial for the storage platform of the present invention to provide some interoperability with existing file systems, such as NTFS. In one embodiment of the present invention, therefore, the storage platform relies on the Win32 programming model to allow application programs to access the contents of both the storage platform as well as the data store of the traditional NTFS file system. For this purpose, the storage platform uses a naming convention that is a superset of the Win32 naming convention to facilitate easy interoperability. In addition, the storage platform supports access to files and directories stored in the storage platform volume through the Win32 API.

  Further details regarding this function can be found in the related applications incorporated herein by reference above.

K. Storage platform API
The storage platform includes an API that allows application programs to take advantage of the storage platform features and capabilities described above and to access items stored in the data store. This section describes one embodiment of the storage platform API of the storage platform of the present invention. Details regarding this function can be found in the related applications incorporated herein by reference above, and for convenience, some of this information will be summarized later.

  Referring to FIG. 18, a “container folder” is an item that includes a holding relationship to another “item” and is equivalent to a common concept of a file system folder. Each “item” is “included” in at least one container folder.

  FIG. 19 shows the basic architecture of the storage platform API according to this embodiment. The storage platform API can also communicate with the local data store 302 using SQL Client 1900 and further communicate with a remote data store (eg, data store 340) using SQL Client 1900. The local store 302 may also communicate with the remote data store 340 using DQP (“distributed query processor”) or via the storage platform synchronization service (“synchronization”) described above. The storage platform API 322 also acts as a data store notification bridge API, as described above, passing application registrations to the notification engine 332 and routing notifications to applications (eg, applications 350a, 350b, or 350c). To do. In one embodiment, the storage platform API 322 may also define a limited “provider” architecture so that it can access data in Microsoft Exchange and AD.

  FIG. 20 schematically represents the various components of the storage platform API. The storage platform API includes (1) a data class 2002 representing storage platform elements and item types, (2) a runtime framework 2004 that manages object consistency and provides support classes 2006, and (3) from the storage platform schema. It consists of a component called tool 2008 that is used to generate a CLR class.

  The class hierarchy arising from a given schema directly reflects the type hierarchy in that schema. As an example, consider the “Item” type defined in the “Contact” schema shown in FIGS. 21A and 21B.

FIG. 22 shows the runtime framework in operation. The runtime framework works as follows.
1. An application 350a, 350b, or 350c binds to an item in the storage platform.
2. The framework 2004 creates an ItemContext object 2202 corresponding to the bind item and returns it to the application.
3. The application submits Find in this ItemContext to obtain a collection of “items”. The returned collection is conceptually an object graph 2204 (by relationship).
4). The application changes, erases, and inserts data.
5). An application saves changes by calling the Update () method.

  FIG. 23 shows execution of the “FindAll” operation.

  FIG. 24 illustrates a process for generating a storage platform API class from a storage platform “schema”.

  FIG. 25 shows the schema on which the “File” API is based. The storage platform API includes a namespace that handles file objects. This namespace is System. Storage. Called Files. System. Storage. The data members of the class in Files directly reflect the information stored in the storage platform store. This information can be “promoted” from the file system object or it can be created inherently using the Win32 API. System. Storage. The Files namespace has two classes, FileItem and DirectoryItem. These class members and their methods can be easily identified by looking at the schema diagram of FIG. FileItem and DirectoryItem are read-only from the storage platform API. To modify such items, either Win32 API or System. You must use the class in IO.

  With respect to an API, a programming interface (or more simply, an interface) communicates with a function where one or more segments (s) of code are provided by one or more other segments (s) of code. Or any mechanism, process, or protocol that allows access to a function. Alternatively, the programming interface can be communicatively coupled to one or more mechanisms (group), methods (group), function calls (group), modules (group), etc. of other component (s) of the system It can be viewed as one or more mechanisms (group), methods (group), function calls (group), modules (group), objects (group), etc. of a component. The term “code segment” in the above sentence is provided as source code, intermediate code, or object code regardless of the scope of application and whether the code segment is compiled separately. Whether the code segment is used in a runtime system or process, the code segment is located on the same or different machines, or distributed across multiple machines, or the function represented by the segment of code is fully Includes one or more lines of instructions or code, whether implemented as software, entirely as hardware, or as a combination of hardware and software, eg, code modules, objects, subroutines Emissions, it should be noted that it is intended to include such functions.

  Conceptually, the programming interface can be viewed comprehensively as shown in FIG. 30A or FIG. 30B. FIG. 30A shows an interface called interface 1 as a conduit for the first and second code segments to communicate. FIG. 30B shows the interface as comprising interface objects I1 and I2 (which may or may not be part of the first and second code segments), and these interface objects are the first in the system. And the second code segment allows communication via the medium M. Looking at FIG. 30B, there may be a person who views interface objects I1 and I2 as separate interfaces of the same system, a person who views objects I1 and I2 and medium M as constituting an interface. Although FIGS. 30A and 30B show a bi-directional flow and interfaces at both ends of the flow, certain implementations have only one direction of information flow (or information as described later). It may have no flow) or it may have only an interface object at one end. By way of example, and not limitation, terms such as API (application programming interface), entry point, method, function, subroutine, remote procedure call, and COM (component object model) interface are encompassed within the definition of a programming interface.

  A feature of such a programming interface is that the first code segment sends information to the second code segment (in this case, “information” is used in a broad sense and includes data, commands, requests, etc.). And the second code segment may include a method for receiving the information, and a structure, sequence, syntax, organization, schema, timing, and content of the information. In this regard, as long as information is transported in a manner defined by the interface, the underlying transport medium itself, whether wired or wireless, or a combination of wired and wireless, may not be critical to the operation of the interface. . In certain situations, information cannot be passed in one or both directions in the conventional sense. This is because the transfer of information is different from another mechanism (e.g., apart from the flow of information between code segments, such as when one code segment simply accesses the function performed by the second code segment, Because the information may or may not exist via a buffer, a file, etc. Any or all of these features may be important depending on a given situation, for example, whether the code segment is part of a loosely coupled or tightly coupled system. The list should be considered illustrative and not limiting.

  This programming interface concept is well known and is apparent from the above detailed description of the invention. However, there are other ways of implementing the programming interface, and unless expressly excluded, such methods are also intended to be encompassed by the claims appended hereto. Such other methods may seem more sophisticated or complex than the simplified overview of FIGS. 30A and 30B, but nevertheless perform similar functions that achieve the same result overall. Several exemplary alternative implementations of the programming interface will now be briefly described.

  Factorization: Communication from one code segment to another can be accomplished indirectly by dividing the communication into multiple separate communications. This is shown schematically in FIGS. 31A and 31B. As shown, some interfaces can be described as a separable set of functions. Thus, the interface functions of FIGS. 30A and 30B can be factored to obtain the same result so that 24 or 2 × 2 × 3 × 2 can be mathematically produced. Therefore, as shown in FIG. 31A, the function provided by the interface called interface 1 is subdivided to convert the communication of the interface into a plurality of interfaces such as interface 1A, interface 1B, interface 1C, etc., and the same result is obtained. Obtainable. As shown in FIG. 31B, the function provided by the interface I1 is subdivided into a plurality of interfaces I1a, I1b, I1c, etc., and the same result can be obtained. Similarly, the interface I2 of the second code segment that receives information from the first code segment can be factored into a plurality of interfaces I2a, I2b, I2c, etc. When factoring, the number of interfaces included in the first code segment may not match the number of interfaces included in the second code segment. In either case of FIGS. 31A and 31B, the functional intent of the interfaces 1 and I1 remains the same as in FIGS. 30A and 30B, respectively. Interface factorization can also occur after joint, commutative, and other mathematical properties so that factorization can be difficult to recognize. For example, the order of operations may not be important, so functions implemented by an interface may be implemented by another component of the system, even if implemented by another code portion or interface, prior to performing the interface. Also good. Furthermore, those skilled in the programming arts will appreciate that there are various ways to make different function calls that achieve the same result.

  Redefinition: In some cases, it may be possible to ignore, add, or redefine certain features (eg, parameters) of the programming interface and still get the intended result. This is illustrated in FIGS. 32A and 32B. For example, interface 1 in FIG. 30A includes a function call of Square (input, precision, output), which includes three parameters: input, precision, and output, from the first code segment to the second. Assume that it is issued to a code segment. The central parameter precision, as shown in FIG. 32A, could be properly ignored or replaced (in this situation) with a meaningless parameter if it is not relevant to a given scenario. Irrelevant additive parameters can also be added. In either case, the squaring function can be achieved as long as the output is returned after the input is squared by the second code segment. The precision may be a significant parameter for some downstream or other part of the computer system. However, the precision can be replaced or ignored if it is recognized that it is not necessary for the narrow purpose of square calculation. For example, rather than passing a valid precision value, a meaningless value such as a birthday could be passed without adversely affecting the result. Similarly, as shown in FIG. 32B, interface I1 is replaced with interface I1 'and redefined to ignore or add parameters to the interface. Interface I2 can similarly be redefined as interface I2 'and is redefined to ignore unnecessary parameters or parameters that can be processed elsewhere. The point here is that in some cases the programming interface may include features such as parameters that are not needed for some purpose, so these features may be ignored or redefined, or for other purposes. In order to be processed elsewhere.

  Inline coding: It may also be possible to merge some or all of these functions so that the “interface” between the functions of two separate code modules changes shape. 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 a module containing both. In this case, the code segments may still be in communication 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 may be unnecessary, but similar processing or response (s) in line with the interface 1 interface may still be valid. Similarly, although shown in FIG. 33B, a portion (or all) of interface I2 of FIG. 30B can be written inline to interface I1 to form interface I1 ″. Interface I2 is divided into I2a and I2b, and interface portion I2a is coded inline with interface I1 to form interface I1 ″. As a specific example, interface I1 of FIG. 30B performs a function call square (input, output), which is received by interface I2, which was passed along with input by the second code segment. Consider a case in which, after processing a value (for squaring input), the squared result is returned with output. In such a case, the processing performed by the second code segment (square input) can be performed by the first code segment without a call to the interface.

  Separation: Communication from one code segment to another can be accomplished indirectly by dividing the communication into multiple separate communications. This is schematically illustrated in FIGS. 34A and 34B. As shown in FIG. 34A, one or more pieces (groups) of middleware (separating interface (s) separating all functions and / or interface functions from the original interface) is the first interface, ie interface 1 is provided to convert communications on 1 to conform to different interfaces, in this case interfaces 2A, 2B, and 2C. This is for example installed on a base of an application designed to communicate with the operating system according to the protocol of interface 1, but then the operating system has different interfaces, in this case interface 2A, interface 2B, and interface 2C. This can be done if it is changed to use the interface. Importantly, the original interface used for the second code segment has been changed to be incompatible with the interface used by the first code segment, thus intervening to make the old and new interfaces compatible. Is used. Similarly, as shown in FIG. 34B, a separate interface DI1 for receiving communications from interface I1, which has been redesigned to work in cooperation with DI2, but provides the same functional results, and for example interface I2a and A third code segment can be introduced with a separate interface DI2 for sending interface functions to I2b. Similarly, DI1 and DI2 can work together to translate the functions of interfaces I1 and I2 of FIG. 30B into a new operating system with the same or similar functional results.

  Rewriting: Yet another variant is possible that replaces the interface functionality with another but dynamically rewrites the code to achieve the same overall result. For example, in an execution environment (such as that provided by the .Net framework, Java® runtime environment, or other similar runtime type environment), an intermediate language (eg, Microsoft IL, Java® There may be a system in which code segments shown in the form of)) are provided to a JIT (just-in-time) compiler or interpreter. The JIT compiler can request to dynamically convert the communication from the first code segment to the second code segment, i.e. by the second code segment (either the original or a different second code segment) It can be written to make the communication conform to different interfaces. This is illustrated in FIGS. 35A and 35B. As can be seen in FIG. 35A, this approach is similar to the separation configuration described above. This can be done, for example, when the base of an installed application designed to communicate with the operating system according to the protocol of interface 1 is then changed to use a different interface. I will. The JIT compiler could be used to make on-the-fly communication from install-based applications compliant with the new operating system interface. As shown in FIG. 35B, this technique of dynamically rewriting the interface (s) can be applied to dynamically factoring or recreating the interface (s).

  It should also be noted that, according to alternative embodiments, the above-described scenario that obtains the same or similar results as the interface may be combined in various ways, ie in series and / or in parallel, or with other intervening code. Thus, the alternative embodiments presented above are not mutually exclusive and may be mixed, harmonized and combined to create the same or equivalent scenario as the generic scenario shown in FIGS. 30A and 30B. Good. As with most programming configurations, there are other similar methods that are not described herein, but nevertheless achieve the same or similar functions of the interface represented by the spirit and scope of the present invention. Please also note. That is, it is noted that determining the value of an interface is at least in part the function represented by the interface and the advantageous results enabled by the interface.

III. Extensions and Inheritance The basic concepts of the present invention are “items” that model, to some extent, real-world application objects using complex structures, behaviors, and behaviors described by schemas and enforced by hardware / software interface systems. ". In order to provide rich sub-type specification functionality, in various embodiments of the present invention, a hardware / software interface system (for convenience, hereinafter simply referred to as “WinFS”) uses an “extension”. A mechanism can be provided to allow expansion of “items” (and “item” types). The extension provides additional data structures (properties, relationships, etc.) to the existing “item” type structure.

  As described herein above (and specifically discussed in Sections II.E.6. (A) and II.F.3), the storage platform is intended to be provided with an initial set of schemas. However, in at least some embodiments, the storage platform allows customers including independent software vendors (ISVs) to create new schemas (ie, new “item” and “nested element” types). To do. Since the “item” type or “nested element” type defined by the initial set of storage platform schema cannot exactly match the requirements of the ISV application, it is necessary to let the ISV customize the type. Customization is allowed using the “extended” concept. An extension is a strongly typed instance, but (a) cannot exist independently of each other and (b) must be attached to an “item” or “nested element”. In addition to addressing the need for schema extensibility, extensions are also intended to address the “multi-type designation” problem. In some embodiments, the storage platform cannot support multiple inheritance or duplicate subtypes, so an application can be an instance of a duplicate type (eg, “document” can be a legal document as well as a stored document). ) Can be used as a method of modeling.

A. Type System In various embodiments of the present invention, the WinFS type system provides a mechanism for defining the structure of data. The type system is used to represent data stored in WinFS. The WinFS type is declared in the WinFS schema. The WinFS schema defines a namespace that serves as a logical grouping for a set of types and other WinFS schema elements. The WinFS schema can be declared using the WinFS schema definition language (SDL), which can use the XML format. The following are examples of possible schema declarations.

  The WinFS schema also serves as a unit for type versioning. WinFS defines several system schemas that boot the system. Such a schema is a System.com that includes a type declaration for the root type in the system. Storage schema namespace and System.declares all basic element scalar types in the system. Storage. WinFS schema namespace.

  The WinFS type system declares a set of simple scalar types. These types are used in the WinFS type system as the most basic element building block for all other types. These types are represented in the schema namespace System. Storage. Declared in WinFS. The following table defines a set of basic element types.

  WinFS enumeration is a scalar type that declares a set of named constants called a value list. Enums can be used anywhere that scalar types can be used. Here are some examples of enumeration declarations:

The enumeration values are based on zero. In the above example, Gender. Male represents the value 0, and Gender. Female represents the value 1.

  A complex type is defined by a name and a set of properties. A “property” is a member field of a type and is defined by a name and a type. The “property” type may be a scalar (including enumerations) or other complex types. A WinFS type that can be used as a “property” type is called a nested type. An instance of a nested type can only exist as a “property” value of a composite WinFS type, and the instance is nested in an instance of the composite type. Nested types are declared using the NestedType schema element. Here are some examples of valid type declarations:

  A “size” attribute must be specified for properties of type “string” and “binary”. This attribute specifies the maximum size of the value included in the “property”. The “property” can optionally be declared to be null using the “Nullable” attribute. The value “false” for this attribute indicates that the application must provide a value when creating an instance of the type. Another optional “property” attribute is a “default” attribute that specifies a default value for “property”. This value is assigned to the “property” at instance creation time if the application does not provide a value.

  The Address property in the above example is of the MultiSet type. MultiSet type properties are also called multi-valued properties. In this example, the MultiSet includes a set of instances of the Address type. MultiSet is similar to a collection. A MultiSet may contain zero or more instances of a composite type. The type of the instance in the MultiSet must be a complex nested type. The MultiSet type does not support instances of WinFS scalar types (including enumerated types). A MultiSet type “property” cannot be null and cannot have a default value.

  WinFS supports single inheritance of types. All types in WinFS must inherit from a unique WinFS type. An inherited type is called a derived type, and a type derived from this type is called a base type. The basic type in BaseType is created by the WinFS type declaration element. Suppose that type A is derived from base type B and type B is derived from type C. Type C is an ancestor type of types A and B. Type A is a descendant type of types B and C. A data instance stored in WinFS is always a single type of instance. However, the data instance can be treated as an instance of a set of types including the type and all its ancestor types. For a data instance that is an instance of such a set of types, a type that is not an ancestor of any other type in the set is called a final derived type. A single typed data instance is an instance of only one final derived type. In general, the final derived type of a single typed element is called the type of that element. A derived type inherits all properties declared in its base type. Derived types can declare new properties, but cannot override properties defined in base types. A property declared in a derived type must not use the same name as a property of the base type.

  The main advantage of inheritance in the data model stems from the substitutability of inheritance types. Consider the following example:

In the above example, the Person type has a “Property” RealName of Name type and a “Property” OtherNames that is a set of Name types. Normally, a “Property” called RealName is required to have only an instance of a name type. However, with inheritance, a single value instance can have a RealName value as long as the Name type is one of the ancestors of the final derived type of the element. Therefore, an instance of NameWithMiddleInitial can be a RealName “property” value.

  The same rule is extended to set properties. The OtherNames “property” includes a set of elements. For each instance of a single type that is a member of the set, the final derived type of that instance must have Name as one of its ancestors. Thus, some instances in the OtherNames set may be Name type instances and other instances may be NameWithMiddleInitial type instances.

  Inheritance also allows convenient queries in that it is possible to find all instances of a particular type in the WinFS system. When looking for all instances of a type, the query engine also returns all instances whose final derived type is a descendant of this type. However, these behaviors are only supported for “item”, “extension”, and “relation” types (not “property” types). For nested types (also known as “nested elements”, “properties”, or complex property types), the behavior is supported only for instances that are contained in a single multiset “property”.

B. Type Family In short, the WinFS type system defines four special type families.
-"Nested element" type (also known as "nested" type or "property" type)
• “Item” type • “Relation” type • “Extended” type Each type family has a different set of properties and usage in the WinFS type system. System. The Storage schema namespace declares four types that serve as root types for each type family. The following section describes the type family in detail.

1. Nested Element Types Unlike other WinFS type families, nested types can be used as property types of composite WinFS types. A nested instance can only be nested inside another complex type instance. However, nested instances cannot be queried globally. That is, the application cannot construct a simple query that returns all instances of a given nested type in the WinFS store.

2. Item type WinFS "item" means that the ancestor is System. Storage. An instance of a type that is an Item type. This type is a composite type that is the root of the “item” type family. System. Storage. Item declares a “property” of Guid type name ItemId. This property is a special property of “item” that serves as a primary key for “item”. The value of this “property” is guaranteed to be unique for “item” in a given WinFS store. This property cannot be null and must be assigned by the application when creating an instance of the “item” type. The ItemId “property” is also immutable and can never be changed and should not be reused.

  The query engine can return an instance of a given “item” type in the WinFS store. This query can return all instances of that type and all descendant types of that type. Later in this specification, the central role of “items” in WinFS system operational semantics will be described.

3. Relational types Relational types allow “relationships” to exist between “items”. The WinFS “relation” type describes a binary “relation” in which one “item” is specified as a source and another “item” is specified as a target. “Relationship” means that the ancestor is System. Storage. An instance of a type that is a Relationship type. This type is the root of the “relation” type hierarchy. System. Storage. The Relationship type declares the following properties:
SourceItemId: ItemId of “item” that is source of “relation” instance
RelationshipId: relative to the source “item”. The pair (SourceItemId, RelationshipId) forms the primary key for the “Relation” type in WinFS. TargetItemId: ItemId of the target of “Relation”
• Mode: One of the three possible “Relation” instance modes, ie “Retain”, “Embed”, or “Reference” • Name: Contains the name of “Relation” for the retention “Relation” • IsHidden: Boolean attributes SourceItemId, RelationshipId, TargetItemId, and Mode “property” values that can optionally be used to filter “relationships” that do not need to be displayed are immutable. These values are assigned when the “relation” instance is created and cannot be changed.

A “relation” type is declared as a complex type with the following additional constraints:
Specification of source and target endpoints: Each endpoint specifies the name and type of the reference “item”.
Allowed modes for instances of type “Relation”: “Relation” instances cannot have Mode “property” values not allowed in “Relation” declarations The following is an example of a “Relation” declaration.

A DocumentAuthor “relationship” is declared with the instance limited to “hold” or “reference” mode. This declaration means that an instance of the DocumentAuthor “relation” can have an instance with the value Mode = “Reference” or Mode = “Holding”. Instances with the value Mode = “Embedding” are not allowed.

  “Relationship” declares a source endpoint named “document” of “item” type “Core.Document” and a target endpoint of type “Core.Contact”. The relationship also declares two additional properties. “Relationship” instances are stored and accessed separately from items. All “Relationship” type instances are accessible from the Global “Relationship” view. A query can be constructed that returns all instances of a given type of "relation".

  Given “item”, all “relationships” that are sourced from “item” can be listed based on the SourceItemId “property” of “relationship”. Similarly, for a given “item”, all the “relationships” in the same store that are targeted by “item” can be listed based on the “Target” TargetItemId “property” of “relationship”.

a) Relationship Semantics The following sections describe the semantics of the various “Relationship” instance modes.

  Retention relationships: Retention relationships are used to model the lifetime management of a target “item” based on a reference count. An “item” can be a source endpoint for zero or more relationships to an “item”. An “item” that is not an “embedded” item can be the target of one or more holding relationships. The target “item” must be in the same store as the “relation” instance.

  The retention relationship enforces the lifetime management of the target endpoint. Creation of a holding relationship instance and the “item” targeted by this instance is an atomic operation. Additional retention relationship instances targeting the same “item” can be created. When the last holding relationship instance with a given “item” as a target endpoint is deleted, the target “item” is also deleted.

  The type of the endpoint “item” specified in the “relation” declaration is forced when an instance of that “relation” is created. The type of the endpoint “item” cannot be changed after the “relationship” is established.

  Retention “relationships” play an important role in the formation of the WinFS “item” namespace. All retained "relationships" are in the namespace declaration. The “name” property in the “relation” declaration defines the name of the target “item” relative to the source “item”. This relative name is unique for all retention relationships arising from a given “item” and cannot be null. This ordered list of relative names starting from the root “item” and going to the given “item” forms the complete name for “item”.

  The holding relationship forms a directed acyclic graph (DAG). When a retention relationship is created, the system ensures that no cycles are created, thus ensuring that the WinFS “item” namespace forms a DAG. For more information on the WinFS namespace and “item” path, please refer to the “WinFS Namespace” specification.

  Embedded “Relationships”: Embedded “relationships” model the concept of exclusive control of the lifetime of a target “item”. Embedding relationships allow the concept of synthetic “items”. The creation of an embedded “relation” instance and the “item” targeted by this instance is an atomic operation. An “item” can be a source of zero or more embedded “relationships”. However, an “item” can be the only target of an embedded “relationship”. The “item” that is the target of the embedded “relation” cannot be the target of the retention “relation”. The target “item” must be in the same store as the “relation” instance.

  The type of the endpoint “item” specified in the “relation” declaration is forced when an instance of that “relation” is created. The type of the endpoint “item” cannot be changed after the “relationship” is established. Embedded “relationships” are not in the WinFS namespace. The value of the “name property” of the embedded “relation” must be null.

  Reference “Relationship”: A reference “relationship” does not control the lifetime of the “item” it references. Furthermore, the reference “relationship” does not guarantee the existence of the target, nor does it guarantee the target type specified in the “relationship” declaration. This means that the reference “relationship” can be in an unstable state. The reference “relationship” can refer to “items” in other WinFS stores.

  In WinFS, the reference “relationship” is used to model most non-lifetime management “relationships” between “items”. Since the presence of the target is not mandatory, the reference “relationship” is convenient for modeling loosely coupled “relationships”. The reference “relationship” can be used to target “items” in other WinFS stores, including stores on other machines. Embedded “relationships” are not in the WinFS namespace. The value of the “name property” of the embedded “relation” must be null.

b) Relationship rules and constraints The following additional rules and constraints apply to “relationships”.
"Item" must be the target of (only one embedded "relation") or (one or more holding "relations"). The only exception is the root “item”. An “item” can be the target of zero or more reference “relationships”.
• The “item” that is the target of the embedded “relation” cannot be the source of the retained “relation”. Can be the source of a reference “relationship”.
“Items” cannot be the source of retention “relationships” when promoted from a file. Can be a source of embedded “relationships” and reference “relationships”.
“Items” promoted from a file cannot be targets of embedded “relationships”.

When "Relation" type A is derived from basic "Relation" type B, the following rules apply:
“Relationship” type A can further limit the endpoint type. The endpoint type must be a subtype of the corresponding endpoint type in the basic “Relationship” B. If the endpoint is further restricted, a new name for the endpoint must be declared. If the endpoint is not restricted, the endpoint designation is optional.
“Relationship” type A can further restrict the allowed instance modes declared in the basic “relationship”. The restricted set of instance modes must be a subset of the basic set of allowed instance types.
• The name of the endpoint is treated as a “property” name. That is, it cannot be the same as the name of the “property” nor the name of the endpoint of the type or its basic type.
“Source” and “Target” elements are optional if the corresponding endpoint type is not further restricted by the derived “Relationship”.
An example declaration of a “relation” type derived from the DocumentAuthor “relation” defined above in this specification is given below.

The LegalDocumentAuthor “relationship” further restricts the source endpoint, but not the target endpoint. The source endpoint type is Core. Legal. Derived from Document. Document. Since the target endpoint is not further restricted in this case, the target element is omitted. “Relationship” also further restricts the allowed instance modes. “Relationship” does not allow “hold” mode, the only allowed mode remaining is “reference”.

4). Extended WinFS “Extended” means that the ancestor is System. Storage. An instance of a type that is an Extension type. This type is a composite type that is the root of the “extended” type family.
System. Storage. Extension defines the following two properties.
ItemId: ItemId of “item” associated with “extension”
ExtensionId: a unique identifier of “extension” relative to ItemId. The pair (ItemId, ExtensionId) uniquely identifies an “extended” instance.

The following restrictions apply to the “extended” type:
An extended instance cannot exist independently of an “item”. An “item” type instance with the same ItemId as an “extended” ItemId must exist in the store before the “extended” type instance is created. If an “item” with a given ItemId does not exist, an “extension” cannot be created. When “items” are deleted, all “extensions” having the same ItemID are deleted.
At most one instance of a given final derived “extension” type can be associated with an individual “item”.
Extensions cannot be the source and target of “relationships”.

  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 instances of different “extension” types are added to an “item”, these instances are independent of each other in both structure and behavior. “Extended” instances are stored and accessed separately from “items”. All “extended” type instances are accessible from the global “extended” view. Regardless of what type of “item” an instance is associated with, a query can be constructed that returns all instances of a given type of “extension”. The “Extension” ItemId indicates which item the extension belongs to and can be used to obtain the corresponding “Item” object from the global “Item” view. Also, given an “item”, the “extension” ItemId “property” can be used to enumerate all “extension” instances associated with the “item”.

C. Extensions In some embodiments of the present invention, the hardware / software interface system has the ability to query multiple “items” by defining and doing so the relationship between the various “items”. Use “extensions” and “inheritance” to improve.

1. Inheritance FIG. 36 shows a series of interrelated “items” and their “relationship” subsets. The “document item” 3602 and the “contact item” 3604 are directly related by the designated relationship 3606, which in this case is the “author relationship”. That is, “Contact” 3604 is the “author” of “Document” 3602. In this example, since each “item” type is a sub-type of “document item” type, “picture item” 3622, “music item” 3624, and “special item” 3626 all inherit from “document item” 3604. Do. Similarly, “item” 3642 and “organization item” 3644 “person” inherit from “contact item” 3604. In some embodiments of the invention, such inheritance of “items” (“pictures” 3622, “music” 3624, “specials” 3626, “people” 3642, and “organizations” 3644) may be associated with their respective parent “items”. ”(“ Document ”3602 and“ Contact ”3604) as well as the specified“ Relationship ”between these two parent“ Items ”. For example, “Picture” 3622 inherits a relationship 3652 to “Contact” 3604, a relationship 3664 to “People” 3642, and a relationship 3666 to “Organization” 3644. A similar set of “relationships” is also inherited by each of the other “items” shown in the figure.

  Note that relationship inheritance is not automatic and does not occur in all contexts. For example, attributes that describe when a type can be inherited (ie, inheritance controls) themselves are not inheritable. Inheritance parameters are maintained and regulated by the hardware / software interface system.

2. Extension FIG. 37A illustrates the shortcomings of the standard “item” subtyping for application specific purposes. In this figure, “Contact” is accessible by four applications, APP1, APP2, APPX, and APPY. APP1 and APP2 have access to the standard “Contact”, but APPX and APPY each require an extended contact object (add an additional field), so “Contact” inherits from “Contact” respectively. ”And“ Contact ””. However, the problem is that at this point, three different instances of the basic “contact item” are: one “contact”, one “contact”, and one “contact”. It exists as

  A partial solution to this problem, shown in FIG. 37B, is to extend the “Contact” property to include the fields required for applications that require such a property. In this case, “Contact” is expanded to include additional fields required by APPX. However, since the direct extension of the “item” field such as “contact” can be performed only once, APPY cannot use this method.

  In one embodiment of the present invention, a more comprehensive solution is to extend the “contact” with an “extension” that is separate from the “contact” itself, as shown in FIG. 37C. In this way, APPX can extend “Contacts” to include APPX “Additional Fields”, and APPY can also extend “Contacts” separately to include APPY “Additional Fields”. it can. Since these “extensions” are then searchable and queryable themselves, such “extensions” allow for a form of multiple typing for a hardware / software interface system.

IV. CONCLUSION As described above, the present invention is directed to a storage platform that organizes, retrieves, and shares data. The storage platform of the present invention extends and expands the data platform to exceed existing file and database systems, including structured, unstructured, such as relational (table format) data, XML, and new forms of data called items. Designed to be a store for any type of data, including structured or semi-structured data. With a common storage infrastructure and data organization, the storage platform of the present invention enables more efficient application development for consumers, knowledge workers, and businesses. The storage platform of the present invention provides a rich and extensible application programming interface that not only makes available the performance inherited in the data model, but also encompasses and extends existing file systems and database access methods. It should be understood that modifications can be made to the embodiments described above without departing from the broad concepts of the present invention. Accordingly, the invention is not limited to the specific embodiments disclosed, but is intended to embrace all modifications that are within the spirit and scope of the invention as defined by the appended claims. .

  As is apparent from the above, the various systems, methods, and aspects of the present invention can be implemented in the form of program code (ie, instructions). This program code includes, but is not limited to, floppy diskette, CD-ROM, CD-RW, DVD-ROM, DVD-RAM, magnetic tape, flash memory, hard disk drive, or any other machine-readable storage medium. Can be stored in a computer readable medium such as a magnetic, electrical, or optical storage medium, and when the program code is loaded into and executed by a machine such as a computer or server, the machine implements the invention It becomes. The present invention is realized in the form of program code transmitted over any transmission medium which may be, for example, an electrical connection or cabling, optical fiber, a network including the Internet or an intranet, or any other transmission form. When the program code is received and loaded into and executed by a machine such as a computer, the machine becomes an apparatus for implementing the present invention. When implemented on a general-purpose processor, the program code combines with the processor to provide a unique apparatus that operates analogously to specific logic circuits.

FIG. 6 is a block diagram representing a computer system that may incorporate aspects of the invention. FIG. 2 is a block diagram illustrating a computer system that is divided into three component groups: a hardware component, a hardware / software interface system component, and an application program component. FIG. 2 is a diagram showing a conventional tree-based hierarchical structure for files grouped into a plurality of folders in one directory in a file-based operating system. It is a block diagram which shows a storage platform. It is a figure which shows the structural relationship between an "item", an "item folder", and a "category". It is a block diagram which shows the structure of "item". FIG. 5B is a block diagram illustrating a composite property type of “item” in FIG. 5A. FIG. 3 is a block diagram showing a “place” item and further describing (explicitly enumerating) its complex type. It is a figure which shows "item" as a subtype of "item" found in "basic schema." FIG. 6B is a block diagram illustrating the subtype “item” of FIG. 6A and explicitly enumerating its inherited types (in addition to its direct properties). FIG. 4 is a block diagram showing two top level class types, a “base schema” that includes “item” and PropertyBase, and an additional “base schema” type derived therefrom. It is a block diagram which shows "item" in "core schema". It is a block diagram which shows the property type in "core schema". FIG. 5 is a block diagram illustrating an “item folder”, its members “items”, and “relationships” between the “item folder” and its members “items”. FIG. 4 is a block diagram showing a “category” (which is itself an “item”), its members “items”, and the “relationships” between the “category” and its member “items”. It is a figure which shows the reference type hierarchy of the data model of a storage platform. It is a figure which shows how a relationship is classified. It is a figure which shows a notification mechanism. It is a figure which shows the example which both two transactions are inserting the new record in the same B-tree. FIG. 6 illustrates a data change detection process. FIG. 3 illustrates an example directory tree. FIG. 4 is a diagram illustrating an example of moving an existing folder of a directory-based file system to a storage platform data store. It is a figure which shows the concept of a "container folder." It is a figure which shows the basic architecture of a storage platform API. FIG. 2 schematically represents various components of a storage platform API stack. FIG. 6 is a pictorial diagram illustrating an exemplary “contact item” schema. FIG. 21B is a pictorial diagram illustrating “elements” of the example “contact item” schema of FIG. 21A. It is a figure which shows the runtime framework of storage platform API. It is a figure which shows execution of "FindAll" operation | movement. FIG. 6 illustrates a process for generating a storage platform API class from a storage platform “schema”. FIG. 4 is a diagram illustrating a schema on which a “file” API is based. It is a figure which shows the access mask format used for data security. FIG. 6 shows (part a, b, and c) a new security area that is isolated from the existing security area and that is independently protected. It is a figure which shows the concept of an "item" search view. FIG. 4 illustrates an exemplary “item” hierarchy. FIG. 2 shows an interface called interface 1 as a conduit for communicating first and second code segments. FIG. 2 shows an interface comprising interface objects I1 and I2 and allowing the first and second code segments of the system to communicate via the medium M. It is a figure which shows how the function provided by the interface called the interface 1 is subdivided so that the communication of an interface may be converted into the some interface of the interface 1A, the interface 1B, and the interface 1C. It is a figure which shows how the function provided by the interface I1 is subdivided into several interface I1a, I1b, I1c. It is a figure which shows the scenario which can ignore a meaningless precision parameter and can replace it with arbitrary parameters. FIG. 6 illustrates a scenario where an interface is replaced with a substitute interface defined to ignore parameters or add to the interface. FIG. 6 illustrates a scenario where first and second “code segments” are merged into a module that includes both. FIG. 6 illustrates a scenario where some or all of an interface can be written inline to another interface to form a merged interface. FIG. 6 illustrates how one or more portions of middleware can be converted to conform communications on a first interface to one or more different interfaces. FIG. 4 illustrates how a code segment can be introduced with an interface for receiving communication from one interface but transmitting functions to a second and third interface. FIG. 3 illustrates how a just-in-time compiler (JIT) can convert communications from one code segment to another. FIG. 3 is a diagram illustrating a JIT method for dynamically rewriting one or more interfaces that can be dynamically applied to factors and can also change the interface. FIG. 5 is a diagram showing a series of mutually related “items” and their “relationship” subsets. FIG. 6 illustrates the disadvantages of standard “item” subtyping for application specific purposes. FIG. 4 shows a partial solution to the standard sub-type specification problem. FIG. 6 is an illustration of an embodiment of the present invention for extending an “item” with an “extension” that is entirely separate from the “contact” itself and thus allows for a multiple type designation function.

Claims (42)

  A method of extending an "item" that constitutes a separate storable unit of information that can be handled by a hardware / software interface system, wherein a strongly typed instance (" Using the "extension"), wherein the "extension" constitutes a separate storable information unit that can be handled by the hardware / software interface system.   The method according to claim 1, wherein the “extension” is added to the “item”.   2. The “extension” cannot exist separately from the “item”, and if the “item” does not exist, the “extension” does not exist. the method of.   The method according to claim 1, wherein the “item” is expanded by a plurality of “extensions”.   The method of claim 4, wherein the plurality of "extensions" are used to model overlapping type instances.   A method of extending a "property" that constitutes a composite property type that can be handled by a hardware / software interface system, wherein a strongly typed instance ("extension") for extending said "property" The extension comprises a separate storable unit of information that can be handled by the hardware / software interface system and is associated with the “property”.   The method according to claim 6, wherein the “extension” is added to the “property”.   The “extension” cannot exist separately from the “property”, and when the “property” does not exist, the “extension” does not exist. the method of.   The method according to claim 6, wherein the “property” is extended by a plurality of “extensions”.   The method of claim 9, wherein the plurality of "extensions" are used to model overlapping type instances.   A method by which a hardware / software interface system organizes and efficiently queries a plurality of “items”, said “items” being individually storable information that can be handled by the hardware / software interface system The plurality of “items” comprises a first “relation” that relates a first “item” and a second “item”, and the method includes the first “item”. For the instantiation of a third “item” that is a subtyped instance, the third “item” has a “relationship” from the first “item” to the second “item”. Including automatically inheriting.   For an instantiation of a fourth “item” that is a subtyped instance of the second “item”, the fourth “item” is changed from the second “item” to the first The method of claim 11, comprising automatically inheriting a “relationship” with an “item”.   13. The fourth “item” includes automatically inheriting a “relationship” with the third “item” from the second “item”. Method.   For each of the first plurality of subtyped instances of the first “item”, each of the first plurality of subtyped instances includes the first item from the first “item”. The method according to claim 11, wherein the “relationship” between the two “items” is automatically inherited.   For each of the second sub-typed instances of the second “item”, each of the second plurality of sub-typed instances is further from the second “item”, and 15. The method according to claim 14, wherein the "relationship" with the first "item" is automatically inherited.   Each of the first plurality of subtyped instances automatically inherits a "relationship" from the first "item" to the second plurality of subtyped instances. The method according to claim 15.   Each of the second plurality of subtyped instances automatically inherits a “relationship” from the second “item” to each of the first plurality of subtyped instances. The method according to claim 16.   A hardware / software interface system that handles multiple “items”, wherein “items” constitute separate storable information units that can be handled by the hardware / software interface system, A subsystem that extends an “item” using a typed instance (“extension”), the “extension” being a separate storable information unit that can be handled by the hardware / software interface system The system characterized by comprising.   The system according to claim 18, wherein the “extension” is added to the “item”.   19. The “extension” cannot exist separately from the “item”, and when the “item” does not exist, the “extension” does not exist. System.   The system of claim 18, wherein the “item” is expanded by a plurality of “extensions”.   A hardware / software interface system that handles multiple “properties”, said “properties” comprising a composite property type that can be handled by a hardware / software interface system, said system being strongly typed A subsystem that extends a “property” using a separate instance (“extension”), wherein the “extension” constitutes a separate storable information unit that can be handled by the hardware / software interface system A system characterized by   The system according to claim 22, wherein the "extension" is added to the "property".   23. The “extension” cannot exist separately from the “property”, and when the “property” does not exist, the “extension” does not exist. System.   The system of claim 22, wherein the "property" is extended by a plurality of "extensions". A hardware / software interface system that handles a plurality of “items”, wherein the “items” constitute separate storable information units that can be handled by the hardware / software interface system, the system comprising: Comprising a subsystem for organizing and efficiently querying a plurality of “items”, wherein the plurality of “items” includes a first relationship relating a first “item” and a second “item”; The subsystem is
Automatically automating the relationship between the third “item” and the second “item” for the instantiation of a third “item” that is a subtyped instance of the first “item” Established
Auto-relationship between the fourth “item” and the first “item” for the instantiation of the fourth “item”, which is a subtyped instance of the second “item” And automatically establishing a relationship between the fourth “item” and the first “item”. For each of the first plurality of subtyped instances of the first “item” and for each of the second plurality of subtyped instances of the second “item” The subsystem is
Automatically establishing a relationship with the second “item” for each of the first plurality of subtyped instances;
Automatically establishing a relationship with the first "item" for each of the second plurality of subtyped instances, and for each of the first plurality of subtyped instances 27. The system of claim 26, automatically establishing a relationship with each of the second plurality of subtyped instances.   A hardware / software interface system that handles multiple “items”, wherein “items” constitute separate storable information units that can be handled by the hardware / software interface system, A subsystem that extends an “item” using a typed instance (“extension”), the “extension” being a separate storable information unit that can be handled by the hardware / software interface system The system characterized by comprising.   30. The system of claim 28, wherein the "extension" is added to the "item".   29. The “extension” cannot exist separately from the “item”, and when the “item” does not exist, the “extension” does not exist. System.   30. The system of claim 28, wherein the "item" is extended by a plurality of "extensions".   A hardware / software interface system that handles multiple “properties”, said “properties” comprising a composite property type that can be handled by a hardware / software interface system, said system being strongly typed A subsystem that extends a “property” using a separate instance (“extension”), wherein the “extension” constitutes a separate storable information unit that can be handled by the hardware / software interface system A system characterized by   The system of claim 32, wherein the "extension" is added to the "property".   The “extension” cannot exist separately from the “property”, and when the “property” does not exist, the “extension” does not exist. System.   The system of claim 32, wherein the "property" is extended by a plurality of "extensions". A hardware / software interface system that handles a plurality of “items”, wherein the “items” constitute separate storable information units that can be handled by the hardware / software interface system, the system comprising: Comprising a subsystem for organizing and efficiently querying a plurality of “items”, wherein the plurality of “items” includes a first relationship relating a first “item” and a second “item”; The subsystem is
Automatically automating the relationship between the third “item” and the second “item” for the instantiation of a third “item” that is a subtyped instance of the first “item” Established
Auto-relationship between the fourth “item” and the first “item” for the instantiation of the fourth “item”, which is a subtyped instance of the second “item” And automatically establishing a relationship between the fourth “item” and the first “item”. For each of the first plurality of subtyped instances of the first “item” and for each of the second plurality of subtyped instances of the second “item” The subsystem is
Automatically establishing a relationship with the second “item” for each of the first plurality of subtyped instances;
Automatically establishing a relationship with the first "item" for each of the second plurality of subtyped instances, and for each of the first plurality of subtyped instances 37. The system of claim 36, wherein the system automatically establishes a relationship with each of the second plurality of subtyped instances.   A computer readable medium comprising computer readable instructions for extending an "item" that constitutes a separate storable unit of information that can be handled by a hardware / software interface system, the strict for extending said "item" Instructions relating to the use of typed instances (“extensions”), wherein the “extensions” constitute separate storable information units that can be handled by the hardware / software interface system, "Is added to the" item ", and when the" item "does not exist, the" extension "does not exist.   A computer readable medium comprising computer readable instructions that extend a "property" that constitutes a composite property type that can be handled by a hardware / software interface system, the strongly typed for extending said "property" Instructions relating to the use of a separate instance ("extension"), wherein said "extension" constitutes a separate storable information unit that can be handled by said hardware / software interface system, said "extension" A computer-readable medium that is added to a “property” so that when the “property” does not exist, the “extension” does not exist. A computer readable medium comprising computer readable instructions for organizing and efficiently querying "items" comprising separate storable units of information that can be handled by a hardware / software interface system, the computer readable instructions comprising:
Instantiating a first “item”, a second item, and a first “relation” relating the first “item” and the second “item”;
Instantiating a third “item” that is a subtyped instance of the first “item”;
A computer readable medium comprising instructions for automatically establishing an inherited "relationship" between the third "item" and the second "item". Instantiating a fourth “item” which is a subtyped instance of the second “item”;
41. The computer-readable medium of claim 40, further comprising instructions for automatically establishing an inherited "relationship" between the fourth "item" and the first "item". 42. The computer-readable medium of claim 41, further comprising instructions for automatically establishing an inherited "relationship" between the third "item" and the fourth "item".

Images