RU2412475C2 - Systems and methods for extensions and inheritance for units of information managed by hardware/software interface system - Google Patents

Abstract

FIELD: information technology.

SUBSTANCE: extensions are strongly typed instances which cannot exist independently and must be attached to an Article or Nested element. Extensions are also intended to address "multi-typing" issues by enabling the overlap of type instances (e.g., a Document may be a "legal document" as well a "secure document").

EFFECT: broader functionalities for selecting subtypes by extending Articles and types of Articles using Extensions which provide additional data structures for already existing structures of types of Articles.

16 cl, 49 dwg

Description

Cross references to related applications

This application claims the priority of US patent application No. 10 / 693,574 (attorney registry No. MSFT-2847), filed October 24, 2003, on “SYSTEMS AND METHODS FOR EXTENSIONS AND INHERITIES FOR INFORMATION UNITS CONTROLLED BY A HARDWARE-SOFTWARE SYSTEM”; US patent application No. 10 / 646,580 (attorney registry No. MSFT-2735), filed August 21, 2003, for “SYSTEMS AND METHODS FOR MODELING DATA IN A STORAGE PLATFORM BASED ON DATA ELEMENTS”; and International Patent Application No. PCT / US 03/26144 (Attorney Register No. MSFT-2779), filed August 21, 2003, for “SYSTEMS AND METHODS FOR MODELING DATA IN A STORAGE PLATFORM BASED ON DATA ELEMENTS”; the contents of which are incorporated into this description by reference.

The application relates to the essence of the inventions disclosed in the following jointly assigned applications, the contents of which are incorporated by reference into this application in its entirety (and partially summarized here for convenience): US patent application No. 10 / 647,058 (attorney registry No. MSFT-1748), filed August 21, 2003, on “SYSTEMS AND METHODS FOR PRESENTING INFORMATION UNITS UNDER CONTROL OF THE HARDWARE / SOFTWARE INTERFACE, BUT INDEPENDENTLY ON THE PHYSICAL PRESENTATION”; US patent application No. 10 / 646,941 (attorney registry No. MSFT-1749), filed August 21, 2003, for “SYSTEMS AND METHODS FOR SEPARATING INFORMATION UNITS MANAGED BY THE HARDWARE / SOFTWARE INTERFACE FROM THEIR PHYSICAL ORGANIZATION”; US patent application No. 10 / 646,940 (attorney registry No. MSFT-1750), filed August 21, 2003, for “SYSTEMS AND METHODS FOR IMPLEMENTING A BASIC SCHEME FOR ORGANIZING INFORMATION UNITS CONTROLLED BY A HARDWARE / SOFTWARE INTERFACE”; US patent application No. 10 / 646,632 (attorney registry No. MSFT-1751), filed August 21, 2003, for “SYSTEMS AND METHODS FOR IMPLEMENTING A KEY SCHEME FOR SUPPORTING A TOP-LEVEL STRUCTURE FOR ORGANIZING AN OPERATING CHART; US patent application No. 10 / 646,645 (attorney registry No. MSFT-1752), filed August 21, 2003, for “SYSTEMS AND METHOD FOR SUBMITTING RELATIONSHIP BETWEEN INFORMATION UNITS MANAGED BY THE HARDWARE / SOFTWARE INTERFACE”; US patent application No. 10 / 646,575 (attorney registry No. MSFT-2733), filed August 21, 2003, for “SYSTEMS AND METHODS FOR INTERACTION OF APPLIED PROGRAMS WITH A STORAGE PLATFORM BASED ON DATA ELEMENTS”; US Patent Application No. 10 / 646,646 (Attorney Register No. MSFT-2734), filed August 21, 2003, for “STORAGE PLATFORM FOR ORGANIZING, SEARCHING AND JOINT USE OF DATA”; US patent application No. 10 / 692,779 (attorney registry No. MSFT-2829), filed October 24, 2003, for “SYSTEMS AND METHODS FOR IMPLEMENTING DIGITAL IMAGES FOR ORGANIZING INFORMATION UNITS MANAGED BY THE APPARAMETO SYSTEM; US Patent Application No. 10 / 692,515 (Attorney Register No. MSFT-2844), filed October 24, 2003, for “SYSTEMS AND METHODS FOR PROVIDING SYNCHRONIZATION SERVICES FOR INFORMATION UNITS MANAGED BY THE HARDWARE / SOFTWARE SYSTEM” INTERFACE); US patent application No. 10 / 692,508 (attorney register No. MSFT-2845), filed simultaneously with this on “SYSTEMS AND METHODS FOR PROVIDING RELAY AND HIERARCHICAL SERVICES FOR INFORMATION UNITS MANAGED BY THE APPARAMETO SYSTEM /; and US Patent Application No. 10 / 693,362 (Attorney Register No. MSFT-2846), filed October 24, 2003, for “SYSTEMS AND METHODS FOR IMPLEMENTING SYNCHRONOUS SCHEMES FOR INFORMATION UNITS MANAGED BY THE HARDWARE / SOFTWARE INTERFACE.”

Technical field

The present invention relates to the field of storage and retrieval of information and, in particular, to an active storage platform for organizing, searching and sharing various types of data in a computerized system. Various embodiments of the present invention are directed to the use of extension and inheritance methods used by a hardware-software interface system for managing data.

State of the art

Over the past decade, the capacity of an individual disk has grown by about seventy percent (70%) per year. Moore's law accurately predicted a significant increase in the power of central processing units (CPUs) that has occurred in recent years. Wired and wireless technologies have provided significant connectivity and bandwidth capabilities. Assuming that current trends continue, in a few years the average portable computer will have a storage capacity of about one terabyte and contain millions of files, and 500 gigabyte hard drives will be in order.

Consumers use their computers mainly for the transfer and organization of personal information, whether it be electronic note book (EZK) data or multimedia data such as digital music or photographs. The volume of digital content and the ability to store raw bytes have increased significantly; however, ways to organize and unify this data that are accessible to consumers have not been properly developed. Information technology specialists spend a lot of time managing and sharing information and, according to a number of studies, information technology experts spend 15-25% of their time on non-productive activities related to information. According to other studies, an IT specialist spends about 2.5 hours a day searching for information.

Developers and departments of information technology (IT) spend a lot of time and money building their own data warehouses for ordinary storage abstractions to represent people, places, times and events. This not only leads to double work, but also creates islands of common data without any mechanisms for a common search or sharing of this data. See how many address books can exist today on the computer where the Microsoft Windows operating system is installed. Many applications, such as email clients and personal financial programs, support individual address books, and few applications share the address book data that each such program individually supports, so a financial program (for example, Microsoft Money) does not share recipient addresses with the addresses supported in the email contacts folder (for example, in Microsoft Outlook). Indeed, many users have many devices and logically must synchronize their personal data between them and for a large number of additional sources, including cell phones with commercial services, such as MSN and AOL; however, the interaction of shared documents is mainly achieved by attaching documents to e-mail messages, i.e. manually and inefficiently.

One of the reasons for this lack of interaction is that traditional approaches to organizing information in computer systems focus on the use of file / folder based systems and directories (“file systems”) to organize multiple files in a folder directory hierarchy based on abstracting from physical organization storage medium used to store files. The Multics operating system, developed in the 1960s, can rightfully be considered a pioneer in the use of files, folders, and directories for managing stored data blocks at the operating system level. In particular, Multics used symbolic addresses in the file hierarchy (thereby representing the idea of a file path), where the physical addresses of the files were opaque to the user (applications and end users). This file system did not fully take into account the file format for any single file, and the relationship between the files was not considered at the operating system level (i.e., other than the place of the file in the hierarchy). With the advent of Multics, the stored data was organized into files, folders and directories at the operating system level. These files, in general, include the file hierarchy itself (the “directory”) embodied in a special file supported by the file system. This directory, in turn, maintains a list of elements corresponding to all other files in the directory and the nodal point of such files in the directory (hereinafter referred to as folders). This level of technology has been around for about forty years.

However, providing a rational presentation of the information placed in the physical storage system, the file system is nevertheless an abstraction of this physical storage system, and therefore the use of files requires a level of conversion of logical addresses into physical (interpretations) between what the user manipulates (blocks that have context, signs and relations with other blocks), and what the operating system provides (files, folders, and directories). Therefore, users (applications and / or end users) have no choice but to place blocks of information in the structure of the file system, even if it is inefficient, inconvenient, or for some other reason undesirable. In addition, existing file systems know little about the structure of data stored in separate files, and therefore most of the information remains locked in files that can be accessed (and understood) only for applications that recorded them. Therefore, this drawback of the schematic description of information and information management mechanisms leads to the creation of “silos” of data with little data sharing between the individual “silos”. For example, many users of personal computers (PCs) have more than five different repositories that contain information about the people with whom they interact, at some level, for example, Outlook contacts list (Outlook Contacts), addresses of online accounts, Windows address book ( Windows Address Book), Quicken Payees, and Instant Messaging (IM) friend lists, as file organization poses a significant problem to these PC users. Since most existing file systems use the model of subfolders to organize files and folders, as the number of files increases, the effort required to maintain a flexible and efficient organizational structure becomes just awesome. In such situations, it would be very useful to have several classifications of a single file; however, using hardware or software links in existing file systems is cumbersome and difficult to maintain.

Earlier, several unsuccessful attempts were made to overcome the shortcomings of file systems. Some of these previous attempts included the use of memory addressing by content to provide a mechanism that allows access to data by content rather than by physical address. However, these attempts were unsuccessful, because although content-addressing memory has been shown to be useful for small-scale use by devices such as cache blocks and memory management blocks, large-scale use for devices such as physical storage media is not possible for various reasons and therefore, such a solution simply does not exist. Other attempts were made using object-oriented database systems (OBD), but these attempts, although showing the strengths of the database and good non-file representations, were not effective in processing file representations and could not compete in speed, efficiency and simplicity with hierarchical structure based on files and folders at the system-level hardware-software interface. Other attempts, for example using SmallTalk (and other derivatives), proved to be very effective in processing file and non-file representations, however, they did not have the database characteristics necessary for the efficient organization and use of relationships existing between different data files, and therefore the overall efficiency of such systems was unacceptable. Other attempts related to the use of BeOS and other similar studies of operating systems have proven inadequate in processing non-file representations, which is a key drawback of traditional file systems, despite the ability to adequately represent files, while providing some necessary database features.

Database technology is another area of technology in which similar problems exist. For example, although the relational database model has gained great commercial success, true independent software vendors (NPPs) typically use a small fraction of the functionality of relational database software products (such as Microsoft SQL Server). Instead, the application interacts with such a product in the form of simple “take” and “put” operations. Despite a number of obvious reasons for this, such as a skepticism about the platform or the database, the most important reason that is often ignored is that the database does not always provide the abstractions that most business application vendors really need. For example, the real world is designated by such “data elements” as “customers” or “orders” (together with “linear data elements” embedded in the order as data elements in them or themselves), relational databases speak only the language of tables and lines. Therefore, although aspects like consistency, locking, security, and / or triggering at the data element level may be desirable, in the general case, databases provide these features only at the table / row level. Although this may work well if each data item is displayed in a single row in some table in the database, in the case of an order with many linear data items there may be reasons why the data item is actually mapped to many tables, in which case a simple relational system databases simply do not provide the correct abstractions. Therefore, the application must build logic on top of the database to provide its basic abstractions. In other words, the basic relational model does not provide a sufficient platform for storing data on which higher-level applications can be easily developed, since the basic relational model requires a level of conversion of logical addresses to physical between the application and the storage system, where the semantic data structure can be visible in the application only in certain cases. Although some database vendors integrate higher-level functionality into their products, for example, provide object relational capabilities, new organizational models, etc., none have yet provided some necessary universal solution, where a truly universal solution is one that provides both useful abstractions of the data model (for example, “data elements”, “extensions”, “relationships”, etc.) for useful abstractions of a region (for example, “faces”, “locations”, “events”, etc.).

In view of the aforementioned shortcomings of existing technologies for storing data and databases, a new storage platform is needed that provides increased ability to organize, search and share all types of data in a computer system - a storage platform that extends and extends the data platform beyond existing file systems and database systems , and which is designed to store all types of data. The present invention, together with related inventions previously incorporated herein by reference, satisfies this need. In particular, the present invention provides methods for expanding and inheriting objects manipulated by a hardware-software interface system.

SUMMARY OF THE INVENTION

The following summary provides an overview of various aspects of the invention described in connection with related inventions previously incorporated herein by reference. This essence is not intended to provide an exhaustive description of all important aspects of the invention, nor to specify the scope of the invention. On the contrary, this entity is intended to serve as an introduction to the following detailed description and drawings.

The present invention, as well as related inventions, relates to a storage platform for organizing, retrieving and sharing data. The storage platform of the present invention extends and extends the concept of storing data beyond existing file systems and database systems and is designed to store all types of data, including structured, unstructured or partially structured data.

The storage platform of the present invention comprises a data warehouse implemented as a database machine. The database engine contains a relational database engine with object relational extensions. The data warehouse implements a data model that supports the organization, search, sharing, synchronization and data security. Specific data types are described in the diagrams, and the platform provides a mechanism for expanding a plurality of diagrams to define new data types (especially the subtypes of the basic types provided by the diagrams). The synchronization feature facilitates the sharing of data among users or systems. Functions such as a file system are provided that provide the ability of a data warehouse to interact with existing file systems, but are not limited to such traditional file systems. The change tracking mechanism provides the ability to track changes to the data warehouse. The storage platform additionally contains many application programming interfaces that allow applications to access all of the above features of the storage platform and access the data described in the diagrams.

The data model implemented by the data warehouse defines the data storage blocks in terms of data elements (articles), elements and relationships. An article is a block of data stored in a data warehouse that can contain one or more elements and relationships. An element is an instance of a type containing one or more fields (also referred to as a property here). A relationship is a connection between two articles. (These and other specific terms used here may be capitalized to distinguish them from other terms used side by side; however, this does not mean that there is any difference between a capitalized term such as “Article” and the same term in lowercase letters, such as “article”, and no distinction should be made or implied between them.)

The computer system additionally contains a set of Articles, where each Article forms a discrete stored block of information that can be manipulated by a hardware-software interface system; the totality of the Folders of articles that form the organizational structure of the said Articles; and a hardware-software interface system for manipulating a collection of Articles, each Article belonging to at least one Article Folder and may belong to more than one Article Folder.

An article or some property values Articles can be calculated dynamically instead of being retrieved from persistent storage. In other words, the hardware-software interface system does not require storing the Article, and certain operations are supported, for example, the ability to list the current set of Articles or the ability to retrieve the Article by its identifier (which is described in more detail in the sections describing the application programming interface or API) of the storage platform, for example An article can be the current location of a cell phone or a temperature reading on a temperature sensor. A hardware-software interface system may manipulate a variety of Articles and may additionally contain Articles interconnected through a variety of Relations under the control of a hardware-software interface system.

The hardware-software interface system for a computer system further comprises a kernel circuit for defining a plurality of Core Articles that the hardware-software interface system understands and can directly process in a predetermined and predicted manner. To manipulate multiple Articles, a computer system links Articles through multiple Relations and manages Relations at the system-level hardware-software interface.

The storage platform API provides the data classes for each article, the extension of the article, and the relation defined in the storage platform schema set. In addition, the application programming interface provides a set of construction classes that define a common set of behaviors for data classes and which, together with data classes, provide a basic programming model for the storage platform API. The storage platform API provides a simplified query model that allows application developers to generate queries based on various properties of articles in the data warehouse so that the application developer does not need to delve into the details of the query language of the corresponding database machine. The storage platform API also collects the changes to the article made by the application program and then organizes them into the correct updates needed by the database machine (or storage machine of any kind) on which the data warehouse is implemented. This allows application developers to make changes to the article in memory, while leaving the complex work of changing the data warehouse to the share of the API.

Through its common storage framework and schematized data, the storage platform of the present invention provides more efficient application development for consumers, IT professionals and enterprises. It provides an enriched and extensible application programming interface that not only makes available the capabilities inherent in its data model, but also extends and extends the existing file system and database access methods.

In accordance with this unifying structure of related inventions (described in detail in Section II of the Detailed Description), the present invention, in particular, is focused on the use of Extensions to expand the functionality of the types of Articles and Properties, as well as on the use of Inheritance to facilitate the efficient search and organization among related Articles (described in detail in Section III of the Detailed Description). Other features and advantages of the invention will be apparent from the following detailed description of the invention and the accompanying drawings.

Brief Description of the Drawings

The foregoing summary, as well as the following detailed description of the invention, is easier to understand by considering them in conjunction with the accompanying drawings. To illustrate the invention, illustrative embodiments of various aspects of the invention are shown in the drawings; however, the invention is not limited to the specific methods and means disclosed.

In the drawings

figure 1 is a block diagram representing a computer system in which aspects of the present invention can be implemented;

2 is a block diagram illustrating a computer system divided into three groups of components: a hardware component, a component of a hardware-software interface system, and an application program component;

figa - illustrates a traditional tree-like hierarchical structure of files grouped into folders in a directory in a file operating system;

3 is a block diagram illustrating a storage platform;

4 illustrates the structural relationship between Articles, Article Folders, and Categories;

figa is a block diagram illustrating the structure of the Article;

5B is a block diagram illustrating complex types of properties of the Article shown in FIG. 5A;

figs is a block diagram illustrating the Article "Location", which further describes its complex types (listed explicitly);

figa - illustrates the Article as a subtype of the Article found in the Basic scheme;

FIG. 6B is a block diagram illustrating a subtype of the Article shown in FIG. 6A, in which its inherited types are listed explicitly (in addition to its immediate properties);

7 is a block diagram illustrating the Basic scheme, including its two types of top-level classes, Item and PropertyBase, and additional types of the Basic scheme derived from them;

figa is a block diagram illustrating Articles in the kernel;

Fig. 8B is a block diagram illustrating property types in a kernel diagram;

Fig.9 is a block diagram illustrating the Folder of articles, its constituent Articles and Relationships between the Folder of articles and its constituent Articles;

10 is a block diagram illustrating a Category (which, again, is an Article itself), the Articles included in it, and the Relationship relationship between the Category and Articles included in it;

11 is a diagram illustrating a hierarchy of link types in a data model of a storage platform;

12 is a diagram illustrating a classification of relationships;

13 is a diagram illustrating a notification mechanism;

Fig. 14 is a diagram illustrating an example in which two transactions insert a new record into the same B-tree;

Fig. 15 illustrates a data change detection process;

Fig. 16 illustrates an illustrative directory tree;

FIG. 17 shows an example in which an existing directory-based file system folder is moved to a storage platform data store; FIG.

Fig. 18 illustrates the concept of Include folders;

FIG. 19 illustrates a basic architecture of a storage platform API; FIG.

FIG. 20 schematically represents various components of a storage platform API stack;

figa is a graphical representation of an illustrative diagram of the Article "Contacts";

figv is a graphical representation of the Elements for an illustrative diagram of the Article "Contacts" shown in figa;

FIG. 22 illustrates the design of a storage platform API runtime;

Fig.23 illustrates the execution of the operation "find all";

24 illustrates a process by which storage platform API classes are generated from a storage platform diagram;

Fig. 25 illustrates a diagram on which the File API is based;

26 is a diagram illustrating an access mask format used to protect data;

Fig. 27 - (parts a, b, and c) denote a new identically protected security area cut from an existing security area;

28 is a diagram illustrating a concept of a search view of an Article;

29 is a diagram illustrating an illustrative hierarchy of an Article;

figa - illustrates the interface Interface1 as a communication channel between the first and second code segments;

figv - illustrates the interface as containing interface objects I1 and I2, which provide communication between the first and second segments of the system code through the medium M;

figa - illustrates how the function provided by the interface Interface 1 can be divided to convert the interface connections into multiple interfaces Interface 1A, Interface 1B, Interface 1C;

figv - illustrates how the function provided by the interface I1 can be divided into many interfaces I1a, I1b, I1c;

figa - illustrates a scenario where the accuracy of a non-essential parameter can be ignored or replaced with an arbitrary parameter;

figv - illustrates a scenario where the interface is replaced by a wildcard interface, which is set to ignore or add parameters to the interface;

figa - illustrates a scenario where the 1st and 2nd code segments are combined into a module containing both of them;

figv - illustrates a scenario where the interface can be fully or partially written in one line to another interface to form a unified interface;

FIG. 34A illustrates how one or more pieces of middleware can transform communications on a first interface to align them with one or more other interfaces; FIG.

figv - illustrates how you can enter a code segment using the interface to receive transmissions from one interface, but to transmit functionality to the second and third interfaces;

figa - illustrates how the timely activation compiler (JIT) can convert transfers from one code segment to another code segment;

Fig. 35B illustrates how the JIT method for dynamically rewriting one or more interfaces can be used to dynamically factorize or otherwise change an interface;

Fig. 36 illustrates a number of interrelated Articles and a subset of their Relations;

figa - illustrates the disadvantages of the standard allocation of subtypes of Articles for a specific application;

figv - illustrates a partial solution to the problems of standard allocation of subtypes; and

FIG. 37C illustrates one embodiment of the present invention for expanding an Article using an Extension that is different and separate from the Contact itself, and thus provides a multi-type highlighting function.

Detailed description

Table of contents I. Introduction A. Illustrative computing environment B. Traditional file-based storage II.WINFS storage platform for organizing, searching
and data sharing C. Glossary D. Storage Platform Overview E. Data Model 1. Articles 2. Article Identification 3. Article folders and Categories 4. Schemes a) Basic scheme b) Kernel layout 5. Relations a) Declaration of relationship b) Maintenance ratio c) Implementation Relations d) Link relationships e) Rules and restrictions f) Streamlining relationships 6. Extensibility a) Extension of the article b) Extension of Nested Element Types F. Database Machine 1. Implementation of data storage using TOP 2. Article Display 3. Display extensions 4. Display of nested elements 5. Identification of objects 6. Naming SQL Objects 7. Naming Columns 8. Search Views a) Article (1) Main search article type (2) Typed Search Types Articles b) Extension of the article (1) Main search extension type (2) Typed Search Extensions c) Nested elements d) Relationships (1) Main search relationship type (2) Search types of relationship instance 9. Updates 10. Change Tracking and Burial a) Change tracking (1) Tracking changes to the “Principal”
search types (2) Tracking changes in typed
search types b) Burial (1) Burial articles (2) Burial extensions (3) Burial relationship (4) Landfill cleaning 11. API and helper 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. Notifications and change tracking I. Sync 1. Synchronization between storage platforms a) Sync management applications b) Annotation of the scheme c) Sync configuration (1) Community Folder Mappings (2) Profiles (3) Schedules d) Conflict handling (1) Conflict Detection (a) Knowledge-based conflicts (b) Conflict based conflicts (2) Conflict Handling (a) Automatic conflict resolution (b) Conflict Records (c) Inspection and resolution of conflicts (d) Duplicate Convergence and Distribution
conflict resolution 2. Synchronization with platform data warehouses
without storage a) Synchronization services (1) Listing Changes (2) Application of changes (3) Conflict Resolution b) adapter implementation 3. Security 4. Manageability J. Interoperability (with traditional file
System) K. Storage Platform API III. Extensions and Inheritance A. Type system B. Type families 1. Types of nested element 2. Article types 3. Relationship types a) semantics of the relationship b) Rules and restrictions for relations 4. Extension types C. Advanced Features 1. Inheritance 2. Extensions IV. Conclusion

I. Introduction

The subject of the present invention is described with the degree of specification that meets the established requirements. However, the description itself is not intended to limit the scope of this patent. On the contrary, the inventors assumed that the essence of the claimed invention can be embodied in other ways, including various steps or combinations of steps, similar to those described in this document, in combination with other current or future technologies. In addition, although the term “step” can be used here to refer to the various elements of the method used, the term should not be interpreted as providing any particular order among the various steps disclosed herein, unless the order of the individual steps is explicitly described.

A. Illustrative computing environment

Numerous embodiments of the present invention can be performed on a computer. Figure 1 and the following discussion are intended to provide a general description of a suitable computing environment in which the invention may be implemented. Although not required, various aspects of the invention can be described in the general context of computer-executable instructions, such as program modules, executed by a computer, such as a client workstation or server. In general, program modules include procedures, programs, objects, components, data structures, and the like that perform specific tasks or implement certain abstract data types. In addition, the invention can be practiced using other computer system configurations, including handheld devices, multiprocessor systems, microprocessor-based programmable consumer electronics, network PCs, mini-computers, universal computers, etc. The invention can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected to each other via a computer network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

1, an exemplary general-purpose computing system includes a traditional personal computer 20 and the like, including a processing unit 21, a system memory 22, and a system bus 23 that connects various components of the system, including the system memory, to the unit 21 treatments. The system bus 23 may be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. System memory includes read-only memory (ROM) 24 and random access memory (RAM) 25. Basic input / output system 26 (BIOS), which contains basic procedures that help transfer information between elements of personal computer 20, for example, at startup, is stored in ROM 24. The personal computer 20 may further include a hard disk drive 27 for reading from a hard disk and writing to a hard disk that is not shown, a magnetic disk drive 28 for reading from a removable magnetic disk or writing to a removable magnetic disk 29, and optical disk drive 30 for reading from removable optical disk or writing to a removable optical disk, such as CD-ROM or other optical media. The hard disk drive 27, the magnetic disk drive 28, and the optical disk drive 30 are connected to the system bus 23 via the hard disk drive interface 32, the magnetic disk drive interface 33, and the optical disk drive interface 34, respectively. Drives and related computer-readable media provide non-volatile storage of computer-readable instructions, data structures, program modules and other data for a personal computer 20. Although the illustrative environment described here uses a hard disk, a removable magnetic disk 29, and a removable optical disk 31, It will be apparent to those skilled in the art that other types of computer-readable media can be used in an illustrative operating environment in which data accessible to mpyuteru, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memories (RAM), permanent memories (ROM), etc. Similarly, an illustrative environment may also include many types of tracking devices, such as thermal sensors and security and fire systems and other information sources.

A number of program modules may be stored on a hard disk, magnetic disk 29, optical disk 31, ROM 24 or RAM 25, including an operating system 35, one or more application programs 36, other program modules 37, and program data 38. A user can enter commands and information to the personal computer 20 through input devices, such as a keyboard 40 and pointing device 42. Other input devices (not shown) may include a microphone, joystick, satellite dish, scanner, or the like. These and other input devices are often connected to processing unit 21 via a serial port interface 46 that is connected to the system bus, but can be connected via other interfaces, such as a parallel port, game port, or universal serial bus (USB). A monitor 47 or other type of display device is also connected to the system bus 23 through 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 illustrative system shown in FIG. 1 also includes a host adapter 55, a “Small Computer Systems Interface” (SCSI) bus, and an external storage device 62 connected to the SCSI bus 56.

The personal computer 20 may operate in a network environment using local connections with one or more remote computers, such as a 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 with respect to the personal computer 20, although only memory device 50 is illustrated in FIG. 1. Logical connections started in figure 1, include a local area network (LAN) 51 and a global network (WAN) 52. Such network environments usually occur in office networks, computer networks across the enterprise, 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 LAN network environment, the personal computer 20 typically includes a modem 54 or other means of establishing communication channels over a wide area network 52, such as the Internet. The modem 54, which may be internal or external, is connected to the system bus 23 via the serial port interface 46. In a networked environment, program modules described with respect to personal computer 20, or some of them, may be stored in a remote storage device. Obviously, the network connections shown are illustrative, and other means of establishing communication channels between computers can be used.

2, the computer system 200 can be roughly divided into three groups of components: hardware component 202, hardware-software interface system component 204, and application component 206 (also referred to in some contexts as a “user component” or “ software component ”).

In various embodiments of the computer system 200 of FIG. 1, the hardware component 202 may comprise a central processing unit (CPU) 21, memory (ROM 24 and RAM 25), a basic input / output system (BIOS) 26, and various input / output devices, for example, a keyboard 40, a mouse 42, a monitor 47, and / or a printer (not shown), etc. The hardware component 202 contains the basic physical infrastructure of a computer system 200.

The application component 206 contains various programs, including, but not limited to, database systems, text editors, business programs, video games, and the like. Application programs provide tools for using computer resources for solving problems, providing solutions and processing data for various users (machines, other computer systems and / or end users).

Component 204 of the system hardware-software interface contains and in some embodiments, the implementation may consist solely of the operating system, which itself contains in most cases the shell and the kernel. An "operating system" (OS) is a special program that acts as an intermediary between application programs and computer hardware. A component of the hardware-software interface system 204 may also include a virtual machine administrator (AVM), a common language runtime (CLR) or its functional equivalent, a Java virtual machine (JVM) or its functional equivalent, or other similar software components instead of or in addition to the operating system in a computer system. The purpose of a hardware-software interface system is to provide an environment in which a user can execute application programs. The purpose of any system hardware-software interface is to make the computer system easy to use, as well as to effectively use the equipment of the computer.

The hardware-software interface system, in general, is loaded into the computer system at startup, after which it controls all application programs in the computer system. Application programs interact with the system hardware-software interface, requesting services through the application programming interface (API). Some applications allow end users to interact with a hardware-software interface system through a user interface, such as a command language or graphical user interface (GUI).

The hardware-software interface system traditionally provides various services for applications. In a multi-tasking system of a hardware-software interface, where many programs can be executed simultaneously, the system of a hardware-software interface determines in which order the applications should operate and how much time should be allocated to each application before switching to another application. A hardware-software interface system also manages the sharing of internal memory among multiple applications and processes input and output to and from attached hardware devices, such as hard drives, printers, and switched ports. The hardware-software interface system also sends messages to each application (and in a specific case to the end user) regarding the status of operations and any errors that may occur. The hardware-software interface system can also take control of batch jobs (for example, printing), as a result of which the initiating application is freed from this work and can resume other processing and / or operations. On computers that can provide parallel processing, the hardware-software interface system also controls the separation of the program so that it runs simultaneously on more than one processor.

A shell of a hardware-software interface system (hereinafter referred to simply as a “shell”) is an interactive end-user interface to a hardware-software interface system. (A shell can also be called a “command interpreter” or, in an operating system, a “shell of an operating system”). A shell is an external layer of a hardware-software interface system to which application programs and / or end users can directly access.

Although it is contemplated that numerous embodiments of the present invention are particularly well suited for computerized systems, nothing in this document is intended to limit the invention to such embodiments. On the contrary, the term “computer system” used here is intended to encompass any and all devices capable of storing and processing information and / or capable of using stored information to control the behavior of the device itself, regardless of whether this device is electronic, mechanical, logical in nature or virtual.

B. Traditional file-based storage

In most modern computer systems, “files” are blocks of stored information that may include a hardware-software interface system, as well as application programs, data sets, etc. In all modern systems of hardware-software interface (Windows, Unix, Linux, Mac OS, virtual machine systems, etc.) files are basic discrete (stored and retrieved) blocks of information (for example, data, programs, etc.) which can be manipulated by a system of a hardware-software interface. File groups are usually organized in “folders”. In Microsoft Windows, Macintosh OS, and other hardware-software interface systems, a folder is a collection of files that can be retrieved, moved, and otherwise manipulated as single blocks of information. These folders, in turn, are organized into a tree-like hierarchical structure called the “directory” (discussed in more detail below). On some other hardware-software interface systems, such as DOS, z / OS, and on most Unix-based operating systems, the terms “directory” and / or “folder” are used interchangeably, and earlier Apple computer systems (such as Apple IIe) used the term "Directory" instead of a directory; however, when used here, all these terms are considered synonymous and interchangeable and are intended to additionally include all other equivalent terms that denote and refer to hierarchical structures of information storage and their components of folders and files.

Traditionally, a directory (also called a directory of folders) is a tree-like hierarchical structure in which files are grouped into folders, and folders, in turn, are organized according to the relative nodal points that make up the directory tree. For example, according to FIG. 2A, the base folder of a DOS-based file system (or “root directory”) 212 may comprise a plurality of folders 214, each of which may further comprise additional folders (as “subfolders” of this particular folder) 216, and each of They may also contain additional folders 218 to infinity. Each of these folders can have one or several files 220, although at the system-hardware interface level, the individual files in the folder have nothing in common with each other, except for their position in the tree hierarchy. Not surprisingly, this approach to organizing files in a folder hierarchy indirectly reflects the physical organization of typical storage environments used to store these files (for example, hard disks, floppy disks, CD-ROMs, etc.).

In addition to the above, each folder is a container for its subfolders and their files, i.e. each folder owns its subfolders and files. For example, when the firmware system deletes a folder, the subfolders and files of this folder are also deleted (which is recursive in the case of each subfolder, additionally refers to its own subfolders and files). Similarly, each file generally belongs to only one folder, and although you can copy the file and put the copy in another folder, the copy of the file itself is a distinct and separate unit that does not have a direct connection with the original (for example, changing the original file do not affect the copy file at the system-level hardware-software interface). It follows that files and folders are typically “physical” in nature, since folders are considered as physical containers, and files are considered as discrete and separate physical elements in these containers.

II. WINFS storage platform for organization,

data search and sharing

The present invention, together with related inventions, incorporated by reference, as described above, is devoted to a storage platform for organizing, searching and sharing data. The storage platform of the present invention extends and extends the data platform beyond the types of existing file systems and database systems discussed above, and is intended to store all types of data, including a new form of data called the Articles.

C. Glossary

The following terms used here and in the claims have the following meanings:

“An“ article ”is a block of stored information available to a system of a hardware-software interface, which, unlike a simple file, is an object that has a basic set of properties that are generally supported for all objects presented to the end user by a shell of a system of a hardware-software interface. Articles also have properties and relationships, which are generally maintained for all types of Articles, including features that allow you to enter new properties and relationships (which is described in more detail below).

- “Operating System” (OS) is a special program that acts as an intermediary between application programs and computer hardware. The operating system contains in most cases 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 respective hardware components of a computer system and applications running on a computer system. A hardware-software interface system typically comprises (and in some embodiments may solely comprise) an operating system. The hardware-software interface system may also comprise a virtual machine administrator (AVM), a common language runtime (CLR) or its functional equivalent, a Java virtual machine (JVM) or its functional equivalent, or any similar software components instead of or in addition to the operating system in a computer system. The purpose of a hardware-software interface system is to provide an environment in which a user can execute application programs. The purpose of any system hardware-software interface is to make the computer system easy to use, as well as to effectively use the hardware of the computer.

D. Storage Platform Overview

3, storage platform 300 includes data storage 302 implemented in database engine 314. According to one embodiment, the database engine comprises a relational database machine with object relational extensions. According to one embodiment, the relational database engine 314 comprises a Microsoft SQL Server relational database machine. Data warehouse 302 implements a data model 304 that supports the organization, search, sharing, synchronization, and data protection. Specific data types are described in diagrams, for example diagrams 340, and the storage platform 300 provides tools 346 for deploying these schemes as well as for expanding these schemes, which are described in more detail below.

The change tracking engine 306 implemented in the data warehouse 302 provides the ability to track changes in the data warehouse. Data storage 302 also provides security functions 308 and promotion / cancellation function 310, which are discussed in more detail below. The data store 302 also provides a variety of application programming interfaces 312 for presenting the capabilities of the data store 302 to other storage platform components and applications (eg, application programs 350a, 350b, and 350c) that use the storage platform. The storage platform of the present invention also contains application programming interfaces (APIs) 322 that allow application programs, such as application programs 350a, 350b, and 350c, to access all of the above capabilities of the storage platform and access data described in the diagrams. Storage platform API 322 can be used by applications together with other APIs, such as OLE DB API 324 and Microsoft Windows API 326 Win32.

The storage platform 300 of the present invention can provide various application services 328, including a synchronization service 330, which facilitates data sharing among users or systems. For example, synchronization service 330 may provide interoperability with other data stores 340 having the same format as data store 302, as well as access to data stores 342 having other formats. Storage platform 300 also provides file system functions that allow data storage 302 to interoperate with existing file systems, such as Windows NTFS file system 318. According to at least some embodiments, the storage platform 320 may also provide application programs with additional capabilities that can act on data and enable interaction with other systems. These capabilities can be implemented in the form of additional services 328, for example, the 334 Info Agent service and the notification service 332, as well as other utilities 336.

According to at least some embodiments, the storage platform is embodied in or forms an integral part of the hardware-software interface of a computer system. For example, and without limitation, the storage platform of the present invention can be implemented in the operating system, virtual machine administrator (AVM), common language runtime (CLR) or its functional equivalent, or Java virtual machine (JVM), or its functional equivalent or may form an integral part thereof. Through its common storage foundation and schematized data, the storage platform of the present invention allows more efficient development of applications for consumers, information technology professionals and enterprises. It provides an extensive and expandable programming area that not only makes available the capabilities inherent in its data model, but also extends and extends the existing file system 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, this name is used to designate a storage platform for convenience of description only and does not imply any restrictions.

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, and protection of data stored in the store. In a data model consistent with the present invention, an “Article” is the main unit of stored information. The data model provides a mechanism for declaring Articles and Extensions of articles and establishing relationships between Articles and organizing Articles in Article Folders and Categories, as described in more detail below.

The data model relies on two primitive mechanisms - Types and Relations. Types are structures that provide a format that controls the shape of an instance of a Type. The format is expressed as an ordered set of Properties. A property is the name of a value or set of values of a given Type. For example, the type "US mailing address" can have the properties "street", "city", "zip code", "state", in which "street", "city" "state" are of type String (string), and the index is of type Int32 (32-bit integer). A “street” can be a multi-valued property (that is, have multiple values), which allows the address to have more than one value for the “street” property. The system defines certain primitive types that can be used to build other types: they include String, Binary, Boolean, Int16, Int32, Int64, Single, Double, Byte, DateTime, Decimal and GUID. Type properties can be set using any primitive types or (with some restrictions listed below) any constructed types. For example, you can specify the Type “location”, which has the “Coordinate” and “Address” properties, where the “Address” property has the above-described type “US mailing address”. Properties may also be required or optional.

Relationships can be declared and represent a mapping between sets of instances of two types. For example, you can declare the Relationship between the Type “person” and the Type “location”, called “resides in”, which determines who lives where. The relationship has a name, two endpoints, namely, the source endpoint and the target endpoint. Relations also have an ordered set of properties. Source and destination endpoints have a Name and a Type. For example, the “lives in” relationship has a source endpoint called a “tenant” of type “face” and a target endpoint called a “place of residence” of type “location” and, in addition, has the properties “start date” and “end date”, indicating the period of time during which the tenant lived in the place of residence. Note that a “person” can reside in several places for some time, and a place of residence can have several residents, so it is most likely that the information “start date” and “end date” will be placed in the relation itself.

Relationships define a mapping between instances that is limited to types defined as endpoint types. For example, the relationship “resides in” cannot be a relationship in which the “tenant” is “vehicle”, since “vehicle” is not “person”.

The data model allows you to specify a subtype-supertype relationship between types. The subtype-supertype relationship, also called the "base type" relationship, is defined in such a way that if Type A is the Base type for Type B, it must be true that each instance of B is always an instance of A. This relationship can be expressed differently, namely : each instance corresponding to B must also correspond to A. If, for example, A has the property “name” of the Type “string” and B has the property “age” of the Type Int16, then B must have both “name” and “age” ". The type hierarchy can be represented as a tree with a single supertype as the root. Branches from the root provide subtypes of the first level, branches at this level provide subtypes of the second level, etc. to end subtypes that themselves do not have subtypes. A tree is not limited to uniform depth, but cannot contain cycles. This Type may have zero or many subtypes and zero one supertype (s). This instance can correspond to a maximum of one type together with supertypes of this type. In other words, for a given instance at any level of the tree, an instance can correspond to a maximum of one subtype at that level. A type is called abstract if instances of the type must also be instances of a subtype of that type.

1. Articles

An article is a block of information that is stored, which, unlike a simple file, is an object that has a basic set of properties that are generally supported for all objects presented to the end user by the shell of the hardware-software interface system. Articles also have properties and relationships that are generally maintained across all types of Articles, including features that allow you to introduce new properties and relationships, which are discussed below.

Articles are objects of common operations, such as copying, deleting, moving, opening, printing, backing up, restoring, duplicating, etc. Articles are blocks that can be saved and retrieved, and all forms of stored information that the storage platform manipulates exist in the form of Articles, article properties, or relations between articles, each of which is discussed in more detail below.

Articles are designed to represent real-world and intuitive data blocks, such as Contacts, People, Services, Places, Documents (of various types), etc. 5A is a block diagram illustrating the structure of an Article. The unqualified name of the Article is “domicile”. The qualified name of the Article is “Core.Location”, which indicates that this Article structure is specified as a specific type of Article in the Kernel Scheme. (The kernel layout is discussed in more detail below.)

The “domicile” article has a combination of properties, including EAddresses, Metropolitan Region, Neighborhood, and PostalAddresses. The specific type of each property is indicated immediately after the property name and separated by a colon (:) from the property name. To the right of the type name, the number of values allowed for this type of property is indicated in square brackets ([]), where the asterisk (*) to the right of the colon (:) indicates an unspecified and / or unlimited number ("many"). The number “1” to the right of the colon indicates that there can be a maximum of one value. A zero (0) to the left of the colon indicates that the property is optional (there may be no values at all). A “1” to the left of the colon indicates that there must be at least one value (the property is required). Both Neighborhood and MetropolitanRegion properties are of type “nvarchar” (or equivalent), which is a predefined data type or “simple type” (and is indicated without a capital letter). However, EAddresses and PostalAddresses are properties of the specified types or “complex types” (indicated by the capital letter) of EAddress and PostalAddress, respectively. A complex type is a type that is inferred from one or more simple data types and / or from other complex types. Complex types for properties of Articles also form “nested elements”, since details of a complex type are embedded in the immediate Article to specify its properties, and information regarding these complex types is supported in the Article that has these properties (in the border of the Article, which is discussed below) . These typing concepts are well known and obvious to those skilled in the art.

5B is a block diagram illustrating the complex property types PostalAddress and EAddress. The property type of PostalAddress determines that, presumably, an Article having a property of type PostalAddress has zero or one City value, zero or one CountryCode value, zero or one MailStop value, and any number (from zero to many) PostalAddressType values, etc. etc. Thus, the data form for a particular property is specified in the Article. The property type EAddress is set in the same way as shown. Although this application is optionally used in this application, another way of representing complex types in the “Residence” Article is to depict an article with the individual properties of each of the complex types listed here. On figs shows a block diagram illustrating the Article "residence", which further describes its complex types. It should be understood, however, that this is an alternative representation of the “Residence” Article in this FIG. 5C exactly corresponds to the Article illustrated in FIG. 5A. The storage platform of the present invention also allows subtypes to be distinguished, so that one type of property can be a subtype of another (where one type of property inherits the properties of another, parent type of property).

Similarly, but not identical to properties and their types of properties, Articles by their nature present their own Types of articles, which can also be subtyped. In other words, the storage platform in several embodiments of the present invention allows the Article to be a subtype of another Article (so that one Article inherits the properties of the other, parent Article). In addition, for various embodiments of the present invention, each Article is a subtype of the type of Article "Article", which is the first and main type of Article found in the Basic Scheme. (The Basic Scheme will also be discussed in more detail below.) Fig. 6A illustrates the Article, in this example the Article “place of residence”, as a subtype of the type of the Article “Article” found in the Basic scheme. In this drawing, the arrow indicates that the Article "place of residence" (like all other Articles) is a subtype of the type of Article "Article". The type of Article “Article”, as the main Article, from which all other Articles are derived, has a number of important properties, for example, ItemId and various timestamps, and thus sets the standard properties of all Articles in the operating system. In this drawing, these properties of the type of the “Article” Article are inherited by “domicile” and thus become the properties of “domicile”.

Another way of representing properties in the “Residence” Article inherited from the type of the “Article” Article is to depict the “residence” with the individual properties of each property type from the parent Article listed here. FIG. 6B is a block diagram illustrating the “Residence” Article, in which, in addition to its immediate properties, its inherited types are described. It should be noted and understood that this Article is identical to the Article shown in FIG. 5A, although in this drawing the “place of residence” is illustrated with all its properties, both direct, shown in this drawing and in FIG. 5A, and inherited, shown in this in the drawing, but not in FIG. 5A (whereas in FIG. 5A, these properties are indicated by reference with an arrow indicating that the “Residence” Article is a subtype of the “Article” type).

Articles are independent objects, so if an Article is deleted, then all the immediate and inherited properties of the Article are also deleted. Similarly, when retrieving Articles, they receive the Article and all its immediate and inherited properties (including information regarding its complex property types). Certain embodiments of the present invention may include requesting a subset of the properties when retrieving a particular Article; however, by default, in many such embodiments, upon retrieval, the Article is provided with all its immediate and inherited properties. In addition, Article properties can also be expanded by adding new properties to existing properties such as this Article. Therefore, these “extensions” are the true properties of the Article, and subtypes of this type of Article can automatically include the properties of the extension.

The “border” of an Article is represented by its properties (including complex types of properties, extensions, etc.). The border of the Article also represents the limit of operations carried out in relation to the Article, such as copying, deleting, moving, creating, etc. For example, in several embodiments of the present invention, when copying the Article, everything that is inside this border of the Article is also copied. For each Article, the boundary covers the following:

- The Article Type for the Article and, if the Article is a subtype of another Article (which occurs in several embodiments of the present invention, when all Articles are derived from the same Article and Article Type in the Basic Scheme), any applicable subtype information (i.e. information, regarding parent Article Type). If the original source Article is a subtype of another Article, the copy may also be a subtype of the same Article;

- Properties and extensions of a complex type Articles, if any. If the original Article has properties of complex types (native or advanced), the copy may also have the same complex types;

- Entries of the Article on the “relationship of ownership”, i.e. own list of Articles, which lists which other Articles (“target articles”) belong to this Article (“owning Article”). This is especially important in connection with the Article Folders discussed in more detail below and the rule set out below that all articles must belong to at least one Article Folder. In addition, with regard to embedded articles, discussed in more detail below, an embedded article is considered part of the Article in which it is embedded for operations such as copying, deleting, etc.

2. Article identification

Articles are uniquely identified in the global article space through the ItemID. The Base.Item type defines the ItemID field of the GUID type in which the identification of the Article is stored. An article must have one and only one identification in the data warehouse 302.

An article link is a data structure that contains information for locating and identifying an Article. The data model defines an abstract type called ItemReference, from which all types of article links are derived. The ItemReference type defines a virtual method called Resolve. The Resolve method resolves the ItemReference and returns the Article. This method is replaced by specific subtypes of ItemReference, which implement a function that retrieves an Article by reference. The Resolve method is used as part of the storage platform API 322.

ItemIDReference is a subtype of ItemReference. It sets the Locator and ItemID fields. The Locator field assigns the name (i.e., identifies) the article area. It is processed by the locator resolution method, which can resolve the Locator value to the article area. The ItemID field is of type ItemID.

ItemPathReference is a special case of ItemReference, which defines the Locator and Path fields. The Locator field identifies the article area. It is processed by the locator resolution method, which can resolve the Locator value to the article area. The Path field contains the (relative) path in the storage platform namespace with the root in the article area provided by Latitude.

This type of link can be used in multiple operations. In general, a link should be resolved through a path resolution process. The Resolve API 322 method of the storage platform provides this feature.

The link forms discussed above are represented by the link type hierarchy illustrated in FIG. Additional link types that inherit from these types can be defined in schemas. They can be used in the relationship declaration as a type of target field.

3. Article folders and categories

As discussed in more detail below, Article groups can be organized into special Articles called Article Folders (which should not be confused with file folders). However, unlike most file systems, an Article can belong to more than one Article Folder, so when accessing an Article and revising it in one Article Folder, this revised Article can then be accessed directly from another Article Folder. In essence, although access to an article may be from different Article Folders, access is actually made to the same Article. However, the Article Folder is not required to own all the Articles included in it, or may simply own the Articles along with other folders, so deleting the Article Folder does not necessarily delete the Article. However, in several embodiments of the present invention, the Article must belong to at least one Article Folder, so if you delete a single Article Folder for a specific Article in some embodiments, the Article is automatically deleted or in alternative embodiments, the Article automatically becomes a member of the Article Folder the default (for example, Article Folders "recycle bin", is conceptually similar to folders with similar names used in various file-based systems pok).

As discussed in more detail below, Articles may also belong to Categories based on common characteristics described, for example (a) the type (or types) of an article, (b) a specific immediate or inherited property (or properties), or (c) a specific value (or values) ) corresponding to the property of the Article. For example, an Article containing specific properties for personal contact information may automatically belong to the Contact category, and any article having contact information properties will likewise automatically belong to this Category. Similarly, any Article that has a domicile with the value “New York City” may automatically belong to the “New York City” Category.

Categories are fundamentally different from Article Folders in that Article Folders can contain Articles that are not related to each other (that is, without a common characteristic described), and each Article in the Category has a common type, common property or value (“community”) described / th for this Category, and this is the community that forms the basis for its relationship to and between other Articles in the Category. In addition, the membership of an Article in a particular Folder is not necessarily based on any particular aspect of this Article; for certain embodiments, all Articles that have a community categorically associated with a category can automatically become members of the Category at the system-hardware interface level. In principle, Categories can also be considered as virtual Article Folders, the membership of which is based on the results of a particular request (for example, in the context of a database), and Articles that meet the conditions of this request (specified by the Community of Categories) will contain membership in the Category.

Figure 4 illustrates the structural relationship between Articles, Article Folders, and Categories. The set of Articles 402, 404, 406, 408, 410, 412, 414, 416, 418 and 420 are members of different Folders of Articles 422, 424, 426, 428 and 430. Some Articles may belong to more than one Article Folder, for example, Article 402 belongs to the Folders Articles 422 and 424. Some Articles, for example Articles 402, 404, 406, 408, 410 and 412, are also members of one or more Categories 432, 434 and 436, while other articles, for example Articles 414, 416, 418 and 420, may not belong to any of the Categories (although this is highly unlikely in certain embodiments where the possession of any property automatically even membership in the Category, and thus, in such an embodiment, the Article should not have any signs, so as not to be a member of any of the categories). In contrast to the hierarchical structure of the folders, Categories and Article Folders have structures more similar to oriented graphs, as shown. In any case, Articles, Article Folders and Categories are Articles (although they relate to different types of articles).

Unlike files, folders, and directories, Articles, Article Folders, and Categories that meet the present invention are not typically “physical” in nature, since they do not have conceptual equivalents of physical containers, and therefore Articles can exist in more than one such place. The possibility of the existence of Articles in more than one Article Folder, as well as the possibility of organizing them in the Category, provides an expanded and enriched degree of data manipulation and storage structure capabilities at the level of the hardware-software interface, beyond what is available in the prior art.

4. Schemes

a) Basic scheme

To provide a universal basis for the construction and use of Articles, various embodiments of a storage platform in accordance with the present invention contain a basic scheme that establishes a conceptual design for creating and organizing Articles and properties. The basic schema defines certain special types of Articles and properties and features of these special basic types from which subtypes can be additionally derived. Using this basic scheme allows a programmer to conceptually distinguish between articles (and their respective types) from properties (and their respective types). In addition, the basic scheme defines the basic set of properties that all Articles may possess, since all Articles (and their respective Article Types) are derived from this basic article in the basic scheme (and its corresponding Article Type).

7, and in connection with several embodiments of the present invention, the base schema defines three types of top-level: Item (article), Extension (extension) and PropertyBase (base property). It is shown that the type of an Article is defined by the properties of this main type of Article “Item”. In contrast, the top-level PropertyBase property type does not have predefined properties and is just a pointer from which all other property types are derived and through which all derived property types are related (being, in general order, derived from a single property type) . Extension type properties specify which Article extends the extension, as well as identification to distinguish one extension from another, since the Article may have multiple extensions.

An ItemFolder is a subtype of the type of an Item Item that, in addition to properties inherited from an “article,” characterizes a “relationship” for establishing links with its members (if any), while IdentityKey and Property are subtypes of PropertyBase. CategoryRef, in turn, is a subtype of IdentityKey.

b) Kernel layout

Various embodiments of the storage platform of the present invention also comprise a kernel circuitry that provides a conceptual design for the top-level Article type structures. FIG. 8A is a block diagram illustrating articles in a kernel diagram, and FIG. 8B is a block diagram illustrating property types in a kernel diagram. Differences between files based on different extensions (* .com, * .exe, * .bat, * .sys, etc.) and other criteria in file and folder based systems are similar to the kernel circuit function. In a system of hardware-software interface based on articles, the kernel scheme defines many types of kernel articles that directly (by the type of Articles) or indirectly (by the subtype of the Article) characterize all articles in one or more types of Articles of the kernel scheme, which are the system of the hardware-software interface on the basis of the articles understands and can directly process in a predetermined and predictable way. The predefined types of Articles reflect the most common Articles in the article-based hardware-software interface system, and thus the article-based hardware-software interface system, which understands these predefined types of Articles that form the core scheme, increases the level of efficiency.

In certain embodiments, the core design is not extensible, i.e. no additional types of Articles can be distinguished as subtypes from the type of Articles in the basic scheme, with the exception of special predetermined derived types of Articles that are part of the kernel scheme. By preventing extensions to the kernel schema (i.e., preventing the addition of new entries to the kernel schema), the storage platform gives the exclusive right to use the types of the kernel schema articles, since each subsequent type of the Article is a subtype of the type of the kernel schema type. This structure provides a reasonable degree of flexibility in determining additional types of Articles, while taking advantage of the presence of a predefined set of types of core articles.

For various embodiments of the present invention, and as shown in FIG. 8A, specific types of Articles supported by a kernel framework may include one or more of the following:

- Categories: Articles of this type. Articles (and subtypes derived from it) represent valid Categories in the hardware-software interface system based on the articles;

- Commodities: Articles that are identifiable values;

- Devices: Articles that have a logical structure that supports the processing of information;

- Documents: Articles whose contents are not interpreted by the system of hardware-software interface based on articles, but are interpreted by an application program corresponding to the type of document;

- Events: Articles in which certain incidents in the environment are recorded;

- Provisions: Articles representing physical locations (e.g., geographical locations);

- Messages: Articles of information exchange between two principals (described below);

- Principals: Articles with at least one definitively proven identification other than ItemId (for example, identification of an individual, organization, group, family, institution, service, etc.);

- Affirmations: Articles with specific information regarding the environment, including without limitation policies, subscriptions, mandates, etc.

Similarly, as shown in FIG. 8B, the specific property types supported by the kernel circuitry may include one or more of the following:

- Certificates (derived from the main type PropertyBase in the base scheme);

- Identification keys of principals (derived from the type IdentityKey in the base scheme);

- Mailing address (derived from the Property Type in the base scheme);

- Rich text (derived from the Property Type in the base schema);

- EAddress (derived from the Property Type in the base schema);

- IdentitySecurityPackage (derived from the Relationship Type in the base schema);

- RoleOccupancy (derived from the Relationship Type in the base schema);

- BasicPresence (derived from Relation Type in the base schema).

These Articles and Properties are further described with respect to their respective properties shown in FIGS. 8A and 8B.

5. Relations

Relations are binary relations, where one Article acts as a source and another Article as a target. The source article and the target article are related. The original article, in the general case, controls the relationship's lifetime. Those. when you delete the original article, the relationship between the articles is also deleted.

Relationships are divided into inclusion relationships and link relationships. Inclusion relationships control the lifetime of targeted articles, and linking relationships do not provide any semantics for managing lifetimes. 12 illustrates a classification of relationships.

The types of inclusion relationships are further subdivided into maintenance and implementation relationships. If you delete all maintenance relationships for an article, the article is deleted. The maintenance relation controls the lifetime of the target through a link-counting mechanism. Embedding relationships allow you to model compound articles and can be considered as exceptional maintenance relationships. An article that is the goal of an implementation relationship may not be the goal of any other maintenance or implementation relationship.

Link relationships do not control the lifetime of the target article. They may be hanging - the target article may not exist. Link relationships can be used to model links to Articles elsewhere in the article’s global namespace (that is, including remote data stores).

Extracting an article does not automatically retrieve its relationship. Applications must explicitly request Article relations. In addition, a change in attitude does not change the source or target article; likewise, adding a relationship does not affect the source / target article.

a) Declaration of relationship

Explicit relationship types are defined by the following elements:

- The name of the relationship is defined in the Name attribute;

- Type of relationship, one of the following: maintenance, implementation, link. This is defined in the Type attribute;

- Source and target endpoints. Each endpoint defines the name and type of article referred to;

- The field "source endpoint" in the general case is of the type ItemID (not declared) and it should refer to the Article in the same data warehouse as the instance of the relationship;

- For the maintenance and implementation relationship, the “target endpoint” field must be of the type ItemIDReference and it must refer to the Article in the same store as the instance of the relationship. For link relationships, the target endpoint can be of any type of ItemReference and can link to Articles in other storage platforms data warehouses;

- Optionally, you can declare one or more fields of a scalar type or PropertyBase type. These fields may contain data related to the relation;

- Relationship instances are stored in the global relationship table;

- Each instance of a relationship is uniquely identified by a combination (ID of the source article, ID of the relationship). Relationship ID is unique in this ID of the source article for all relationships the source of this Article is, regardless of their types.

The original article is the owner of the relationship. Although the article, designated as the owner, controls the life time of the relationship, the relationship itself exists separately from the Articles that it links. Storage platform API 322 provides a mechanism for representing the relationship of an article.

The following is an example of declaring a relationship:

<Relationship Name = "Employment" BaseType = "Reference">

<Source Name = "Employee" ItemType = "Contact.Person" />

<Target Name = "Employer" ItemType = "Contact.Organization"

ReferenceType = "ItemIDReference" />

<Property Name = "StartDate" Type = "the storage

platformTypes.DateTime "/>

<Property Name = "EndDate" Type = "the storage

platformTypes.DateTime "/>

<Property Name = "Office" Type = "the storage

platformTypes.DateTime "/>

</Relationship>

This is an example of a link relationship. A relationship cannot be created if the Article “person” to which the source link refers does not exist. In addition, when deleting the “Person” Article, copies of the relationship between the person and the organization are deleted. However, when deleting the Article “Organization”, the relationship is not deleted, but freezes.

b) Maintenance ratio

Maintenance relationships are used to model the reference count based on the life time management of the targeted articles.

An article can be a starting endpoint for zero or more relationships for Articles. An article that is not an embedded article may be the goal of one or more maintenance relationships.

The reference to the target endpoint must be of the type ItemIDReference and must indicate the Article in the same store as the instance of the relationship.

Maintenance relationships implement life-time management of the target endpoint. Creating an instance of the maintenance relationship and the article for which it is the goal is an atomic operation. You can create additional instances of a maintenance relationship that target the same article. When you delete the last instance of a maintenance relationship for which this Article is the target endpoint, the target article is also deleted.

The types of endpoint entries defined in the relationship declaration are generally implemented when the relationship instance is created. The types of endpoint articles cannot be changed after the relationship is established.

Maintaining relationships play a key role in shaping the article namespace. They contain a “name” property that defines the name of the target article in relation to the original article. This relative name is unique to all maintenance relationships for which this Article is a source. An ordered list of these relative names, from the root Article to this Article, forms the full name of the Article.

Maintenance relationships form an oriented acyclic graph (OAS). When creating a maintenance relationship, the system ensures that the loop is not created, thereby ensuring that the article namespace forms the OAS.

Although the maintenance relation controls the lifetime of the target article, it does not control the operational consistency of the Article-target endpoint. The target Article is operationally independent of the Article that owns it through a maintenance relationship. Copying, moving, reserving and other operations on an Article that is the source of the maintenance relationship does not affect the Article that is the goal of the same relationship, for example, backing up a Folder Article does not automatically backup all Articles in a folder (goals of the FolderMember relation (member folders)).

The following is an example of a maintenance relationship:

<Relationship Name = "FolderMembers" BaseType = "Holding”>

<Source Name = "Folder" ItemType = "Base.Folder" />

<Target Name = "Item" ItemType = "Base.Item"

ReferenceType = "ItemIDReference" />

</Relationship>

The FolderMembers relationship (folder members) provides the concept of Folders as a general collection of Articles.

c) Implementation Relations

Implementation relationships model the concept of exceptional time management of the target article. They provide the concept of composite articles.

Creating an instance of the implementation relationship and the Article, which is its purpose, is an atomic operation. An article can be a source of zero or more embedding relationships. However, an Article may be the goal of one and only one implementation relationship. An article that is the goal of an implementation relationship cannot be the goal of a maintenance relationship.

The reference to the target endpoint must be of the type ItemIDReference and must indicate the Article in the same data store as the instance of the relationship.

The types of Endpoint Articles defined in the declaration of a relationship are generally implemented when an instance of the relationship is created. The types of Endpoint Articles cannot be changed after the relationship is established.

Deployment relationships drive the operational consistency of the target endpoint. For example, the operation of serializing an Article may include the serialization of all implementation relationships for which the Article is the source, as well as all their goals; copying Articles will also lead to copying all its embedded articles.

The following is an example declaration:

<Relationship Name = "ArchiveMembers" BaseType = "Embedding”>

<Source Name = "Archive" ItemType = "Zip.Archive" />

<Target Name = "Member" ItemType = "Base.Item"

ReferenceType = "ItemIDReference" />

<Property Name = "ZipSize" Type = "the storage

platformTypes.bigint "/>

<Property Name = "SizeReduction" Type = "the storage

platformTypes.float "/>

</Relationship>

d) Link relationships

The link relation does not control the lifetime of the Article to which it refers. In addition, the relationship of the link does not guarantee the existence of the goal, nor does it guarantee the type of goal, as defined in the declaration of relationship. This means that link relationships can freeze. In addition, Articles in other data warehouses may indicate a link relationship. Link relationships can be thought of as a concept similar to links on web pages.

The following is an example of declaring a link relationship:

<Relationship Name = "DocumentAuthor" BaseType = "Reference">

<Source ItemType = "Document" ItemType = "Base.Document" />

<Target ItemType = "Author" ItemType = "Base.Author"

ReferenceType = "ItemIDReference" />

<Property Type = "Role" Type = "Core.CategoryRef" />

<Property Type = "DisplayName" Type = "the storage

platformTypes.nvarchar (256) "/>

</Relationship>

Any type of link is allowed at the target endpoint. Articles involved in a link may be of any type of Article.

Link relationships are used to model most of the relationships between Articles without life time management. Since the existence of a goal is not necessary, a link relationship is convenient for modeling loosely coupled relationships. The link relationship can be used to specify Articles in other data warehouses, including storages on other computers.

e) Rules and restrictions

The following additional rules and restrictions apply to relationships:

- The article should be the goal of (strictly one implementation relationship) or (one or more maintenance relationships). One exception is the root Article. An article may be the goal of zero or more link relationships;

- An article that is the goal of an implementation relationship cannot be the source of a maintenance relationship. It can be a source of link relationships;

- An article cannot be a source of a maintenance relationship if it is promoted from a file. It can be a source of embedding relationships and link relationships;

- An article that is promoted from a file cannot be the target of an embedding relationship.

f) Streamlining relationships

According to at least one embodiment, the storage platform of the present invention supports ordering of relationships. Ordering is achieved using a property called “Order” in the definition of the base relationship. There is no uniqueness constraint on the Order field. The order of relations with the same value of the property “order” is not guaranteed, however, it is guaranteed that they can be ordered after relations with a lower value of “order” and before relations with a higher value of the field “order”.

Applications can receive relationships in the default order by ordering by combination (SourceItemID, RelationshipID, Order). All instances of the relationship for which this Article is the source are ordered as a single collection, regardless of the type of relationship in the collection. This, however, ensures that all relationships of a given type (for example, “folder members”) are an ordered subset of the relationship collection for this Article.

Relationship manipulation data warehouse API 312 implements many operations that support ordering of relationships. To better explain the operations, we introduce the following terms:

- RelFirst - the first relation in an ordered collection with an ordinal value of OrdFirst;

- RelLast - the last relation in an ordered collection with an ordinal value of OrdLast;

- RelX - this relation in the collection with ordinal value OrdX;

- RelPrev - the closest relation to RelX in the collection with an ordinal value of OrdPrev less than OrdX;

- RelNext - the closest relation to RelX in the collection with an ordinal value of OrdPrev greater than OrdX.

Operations include, but are not limited to:

- InsertBeforeFirst (SourceItemID, Relationship) - inserts a relation as the first relation in the collection. The value of the “order” property of the new relationship may be less than OrdFirst;

- InsertAfterLast (SourceItemID, Relationship) - inserts a relation as the last relation in the collection. The value of the “order” property of the new relationship may be greater than OrdLast;

- InsertAt (SourceItemID, ord, Relationship) - inserts a relation with a specific value for the "order" property;

- InsertBefore (SourceItemID, ord, Relationship) - inserts a relation before a relation with a given ordinal value. The new relation may be assigned the value “order” between OrdPrev and ord, non-exclusive;

- InsertAfter (SourceItemID, ord, Relationship) - inserts a relation after a relationship with a given ordinal value. The new relation may be assigned the value "order" between ord and OrdNext, non-exclusively;

- MoveBefore (SourceItemID, ord, RelationshipID) - moves the relationship with the given relationship ID before the relationship with the specified order value. A relationship can be assigned a new value, “order,” between OrdPrev and ord, non-exclusively;

- MoveAfter (SourceItemID, ord, RelationshipID) - moves the relationship with the given relationship ID after the relationship with the specified order value. A relationship can be assigned a new value, “order,” between ord and OrdNext, non-exclusively.

As noted above, each Article must be a member of the Article Folder. In relation to Relations, each Article should be related in the Article Folder. In several embodiments of the present invention, certain relationships are represented by Relationships Existing Between Articles.

In the implementations contemplated by various embodiments of the present invention, the Relationship provides a directional binary relation that “passes” from one Article (source) to another Article (purpose). The relation is the property of the original article (the article from which it passes) and thus is deleted when the source is deleted (for example, the Relationship is deleted when the original article is deleted). In addition, in some cases, the Relationship can simultaneously be owned by the (co-owned) target article, and such ownership can be reflected in the IsOwned property (or equivalent) of the Relationship (as shown in Fig. 7 for the type of the Relationship property). In these embodiments, creating a new IsOwned Relationship automatically increases the reference count of the target article, and deleting such a Relationship may decrease the reference count of the target article. For these specific embodiments, Articles continue to exist if they have a reference count greater than zero, and are automatically deleted if the count reaches zero. Again, the Article Folder is an Article that has (or is able to have) many Relations with other Articles, and these other Articles have membership in the Article Folder. Other actual implementations of the Relationships are possible and contemplated by the present invention to provide the functions described herein.

Regardless of actual implementation, a Relationship is a selective connection from one object to another. The ability of an Article to belong to more than one Article Folder, as well as one or more Categories, regardless of whether these Articles, Folders and Categories are public or private, is determined by the semantic values of the existence (or absence) in the structure based on Articles. These logical Relations are semantic values assigned to a variety of Relations, regardless of physical implementation, which are specifically used to achieve the functionality described here. Logical Relationships are established between the Article and its Folder (s) of articles or Categories (and vice versa), because, in essence, Folders of articles and Categories are a special type of Article. Consequently, you can perform the same actions on Article Folders and Categories as on any other Articles - copying, adding to an e-mail message, embedding in a document, etc. without limitation, both Article Folders and Categories can be serialized and deserialized (imported and exported) using the same mechanisms as for other Articles. (For example, in XML, all Articles may have a serialization format, and this format applies equally to Article Folders, Categories, and Articles.)

The aforementioned Relationships, which represent the relationship between the Article and its Folder (s) of articles, may logically continue from Article to Folder of articles, from Folder of articles to Article or in both directions. The relationship, which logically continues from the article to the Article Folder, indicates that the Article Folder is publicly available in relation to this Article and, together with this Article, uses its membership information; on the contrary, the absence of a logical Relationship from an Article to an Article Folder indicates that the Article Folder is private with respect to this Article and does not share its membership information with this Article. Similarly, the relationship that logically continues from the Article Folder to the Article indicates that the article is publicly available and shared with respect to this Article Folder, while the absence of a logical Relationship from the Article Folder to the article indicates that the Article is private and not shared. Therefore, when the Article Folder is exported to another system, it is the “publicly available” Articles that are shared in a new context, and when the Article searches for articles of other shared Articles in its Mailboxes, it’s the “public” Article Folders that provide the Article with information related to their joint ownership Articles used.

Fig. 9 is a block diagram illustrating an Article Folder (which again is an Article itself), Articles included in it, and Relationships linking the Article Folder and Articles included in it. A folder of 900 articles has as members a set of Articles 902, 904 and 906. A folder of 900 articles has a Relationship of 912 from itself to Article 902, which indicates that Article 902 is public and shared with respect to the Folder of 900 articles, its members 904 and 906 and any other Article Folders, Categories or Articles (not shown) that may access the 900 Article Folder. However, there is no Relationship from Article 902 to the Folder of 900 articles, and this indicates that the Folder of 900 articles is private with respect to Article 902 and does not share its membership information with Article 902. On the other hand, Article 904 has a ratio of 924 from itself to There are 900 articles in the Folder, and this indicates that the 900 Article Folder is publicly available and shares its membership information with Article 904. However, there is no Relationship from the 900 Article Folder to Article 904, and this indicates that Article 904 is private and not shared by the relation NIJ to Folder 900 articles to its members 902 and 906, and any other folders of articles, category or articles (not shown) that might access Item Folder 900 articles. In contrast to the Relationship (or lack thereof) of Articles 902 and 904, the Folder 900 of the Articles has a Relationship of 916 from itself to Article 906, and Article 906 has a Ratio of 926 to the Folder of 900 Articles that together indicate that Article 906 is public and shared in relation to the 900 Article Folder, its members 902 and 904, and any other Article Folders, Categories or Articles (not shown) that may access the 900 Article Folder, and that the 900 Article Folder is publicly available and shares its membership information with Article 906 .

As previously discussed, Articles in an Article Folder are not required to share a commonality, since Article Folders are not “described”. On the other hand, Categories are described by a commonality that is common to all Articles included in it. Therefore, membership in the Category is internally limited by Articles having the described generality, and in some embodiments, all Articles meeting the description of the Category automatically become members of the Category. Thus, while Article Folders allow the representation of trivial type structures through their membership, Categories allow membership based on a certain generality.

Of course, the descriptions of the Categories are logical in nature and therefore the Category can be described using any logical representation of types, properties and / or values. For example, a logical representation for a Category can be a condition of membership in it, according to which an Article must have one of two properties or both. If these described properties for the Category are designated "A" and "B", then the members of the Category can be Articles that have property A, but not B, Articles that have property B, but not A, and Articles that have both properties A and B. This logical representation of properties is described by the logical operator OR, where the set of members described by the Category is Articles that have property A or B. Similar logical operators (including without limitation AND, EXCLUSIVE OR, and NOT individually or in combination) can also be used to describe the category, h it is obvious to experts in this field.

Despite the difference between Article Folders (undescribed) and Categories (described), the Attitude from Categories to Articles and the Attitude from Articles to Categories is essentially the same as described above for Folders of Articles and Articles in many embodiments of the present invention.

Figure 10 shows a block diagram illustrating the Category (which, again, is an Article itself), the Articles included in it and the Relationships that link the Category and the Articles included in it. Category 1000 has as members a set of Articles 1002, 1004 and 1006, which all share some combination of common properties, values or types 1008 that are described (generality description 1008 ') by Category 1000. Category 1000 has a Relationship of 1012 from itself to Article 1002, which indicates that Article 1002 is publicly available and shared with respect to Category 1000, its members 1004 and 1006 and any other Categories, Article Folders or Articles (not shown) that may refer to Category 1000. However, there is no Relationship from Article 100 2 to Category 1000, and this indicates that Category 1000 is private with respect to Article 1002 and does not share its membership information with Article 1002. On the other hand, Article 1004 has a Relationship of 1,024 from itself to Category 1000, and this indicates that Category 1000 is publicly available and shares its membership information with Article 1004. However, there is no Relationship continuing from Category 1000 to Article 1004, and this indicates that Article 1004 is private and not shared with respect to Category 1000, its other members us 1002 and 1006 and any other Categories, Article Folders or Articles (not shown) that may refer to Category 1000. Unlike its Relations (or lack thereof) with Articles 1002 and 1004, Category 1000 has a Relationship of 1016 from itself to Article 1006 , and Article 1006 has a Ratio of 1026 back to Category 1000, which together indicates that Article 1006 is publicly available and shared with respect to Category 1000, its member Articles and any other Categories, Article Folders or Articles (not shown) that may refer to Category 1000, and that K 1000 is a category of public and shares its membership information with Article 1006.

Finally, since Categories and Article Folders themselves are Articles, and Articles can have Relations to each other, Categories can have Relations to Article Folders and vice versa, and Categories, Article Folders and Articles can have Relations with other Categories, Article Folders and Articles respectively certain alternative embodiments. However, in various embodiments, loops at the system level of the hardware-software interface are prohibited in the structures of Article Folders and / or in the structures of Categories. When the structures of Article Folders and Categories are akin to oriented graphs, embodiments that prohibit cycles are akin to oriented acyclic graphs (OAS), which, according to a mathematical definition in the field of graph theory, are directed graphs in which no path can begin and end in one and the same peak.

6. Extensibility

The storage platform should be provided with an initial set of circuits 340, which are described above. In addition, according to at least some embodiments, the storage platform allows consumers, including independent software vendors (NPPs), to create new schemes 344 (i.e., new types of Articles and Nested Elements). This section discusses the mechanism for creating such schemes by expanding the types of Articles and types of Nested element (or simply types of "element") defined in the initial set of schemes 340.

Preferably, the expansion of the initial set of types of Articles and Nested elements is limited as follows:

- NPP is allowed to introduce new types of Articles, i.e. subtype of Base.Item;

- NPP is allowed to introduce new extensions, i.e. subtype of Base.NestedElement; but

- NPP cannot distinguish subtypes in any types (types of Articles, Nested element or extension) defined by the initial set of storage platform schemes 340.

Since the type of the Article or the type of the Nested element, defined by the initial set of storage platform schemes, may not fully meet the needs of the application of the NPP, it is necessary that the NPP can remodel the type. This is possible using the concept of Extensions. Extensions are strongly typed instances, but (a) they cannot exist independently and (b) they must be attached to an Article or Attached Element.

In addition to addressing the issue of extensibility, schemes Extensions are also designed to address the issue of “multiplicity”. Since in some embodiments, the storage platform may not support multiple inheritance or overlapping subtypes, applications can use Extensions as a way to model overlapping type instances (for example, a Document is a legal document and is at the same time a protected document).

a) Extensions of the article

To ensure the extensibility of the Article, the data model additionally defines an abstract type named Base.Extension. This is the root type for the extension type hierarchy. Applications can highlight subtypes in Base.Extension to create custom extension types.

The Base.Extension type is defined in the Base schema as follows:

<Type Name = "Base.Extension" IsAbstract = "True">

<Propety Name = "ItemID"

Type = "the storage

platformTypes.uniqueidentified "

Nullable = "false"

MultiValued = "false" />

<Property Name = "ExtensionID"

Type = "the storage

platformTypes.uniqueidentified "

Nullable = "false"

MultiValued = "false" />

</Type>

The ItemID field contains the article ID for the article with which the extension is associated. An article with this article ID must exist. An extension cannot be created if an article with the given article ID does not exist. When you delete an Article, all extensions with the same article ID are deleted. A tuple (ItemID, ExtensionID) uniquely identifies an extension instance.

An extension type structure is similar to an article type structure:

- Extension types have fields;

- Fields can be primitive types or types of a nested element;

- Extension types can be divided into subtypes.

The following restrictions apply to extension types:

- Extensions cannot be sources and goals of relationships;

- Instances of the extension type cannot exist regardless of the article;

- Extension types cannot be used as field types in storage platform type definitions.

There are no restrictions on the types of extensions that can be associated with this type of Article. Any type of extension can expand any type of article. When several instances of an extension are attached to an article, they are independent of each other in structure and behavior.

Saving instances of the extension and access to them is carried out regardless of the article. All instances of the extension type are accessible from the global extension view. You can create an effective query that will return all instances of this type of extension regardless of the type of article with which they are associated. The storage platform API provides a programming model that can save, retrieve, and modify extensions on articles.

Extension types can be obtained by distinguishing subtypes using a single platform inheritance model. Deriving an extension type creates a new extension type. The structure or behavior of an extension cannot replace or replace the structure or behavior of an article type hierarchy. By analogy with Article types, Instances of extension type can be directly accessed through the view associated with the extension type. The article ID for the extension indicates which article they belong to and which article can be used to retrieve the corresponding Article object from the global Article view. Extensions are considered part of the article for operational consistency. Copying / moving, backing up / restoring and other general operations that the storage platform defines can act on extensions as part of an article.

Consider the following example. Many types of Windows have a Contact type.

<Type Name = "Contact" BaseType = “Base.Item”>

<Property Name = "Name"

Type = "String"

Nullable = "false"

MultiValued = "false" />

<Property Name = "Address"

Type = "Address"

Nullable = "true"

MultiValued = "false" />

</Type>

A CRM application developer [customer interaction management] may need to attach a CRM application extension to contacts stored in the storage platform. The application developer defines a CRM extension that contains an additional data structure that the application can manipulate.

<Type Name = "CRMExtension" BaseType = "Base.Extension">

<Property Name = "CustomerID"

Type = "String"

Nullable = "false"

MultiValued = "false" />

...

</Type>

The HR application developer may also wish to add additional data to the “contact”. This data is independent of CRM application data. The application developer can again create the extension.

<Type Name = "HRExtension" EBaseType = "Base.Extension">

<Property Name = "EmployeeID"

Type = "String"

Nullable = "false"

MultiValued = "false" />

...

</Type>

CRMExtension and HRExtension are two independent extensions that you can add to your contact articles. Their creation and access to them is carried out independently of each other.

In the above example, fields and methods of the CRMExtension type cannot replace the fields or methods of the “contact” hierarchy. It should be noted that instances of type CRMExtension can be attached to Article types other than “contact”.

When you extract the article “contact”, its extension is automatically extracted. For this “contact” article, you can access the related article extensions by requesting a global extension type for extensions with the same article ID.

All CRMExtension extensions in the system can be accessed through the type of CRMExtension types, regardless of which article they belong to. All article extensions for an article share the same article ID. In the above example, a copy of the contact article and the attached CRMExtension and HRExtension all refer to the same article ID.

The table below shows the similarities and differences between the types of Articles, Extensions and Nested Element:

Article Article Extension Nested element Article id Has its own article ID Shares article ID for article Does not have its own article ID. The nested element is part of the article. Storage The article hierarchy is stored in its own tables. The article extension hierarchy is stored in its own tables. Stored with article Query / Search May query article tables May query article extension tables It can, in general, be requested only in the context of the containing article Request / Search Scope Can search all instances of an article type Can search across all instances of an article extension type It can, in the general case, search only among instances of the type of a nested element of a single (containing) article Relationship semantics May Have Relationships with Articles No Relationships with Article Extensions No Relations with Nested Elements Link to Articles May be related to other articles through Relationships of maintenance, implementation and soft Relationships In general, it can only be connected through extensions. Extension semantics are similar to embedded article semantics Associated with the article through the fields. Nested elements are part of the article.

b) Extension of Nested Element Types

Nested item types are not expanded using the same mechanism as Article types. Saving extensions of nested elements and accessing them is carried out using the same mechanisms as for type fields of a nested element.

The data model defines the root for the types of the nested element named Element:

<Type Name = "Element"

IsAbstract = "True">

<Property Name = "ElementID"

Type = "the storage

platformTypes.uniqueidentifier "

Nullable = "false"

MultiValued = "false" />

</Type>

The type NestedElement inherits from this type. The element type “nested element” additionally defines a field, which is a multiset of Elements.

<Type Name = "NestedElement" BaseType = "Base.Element"

IsAbstract = "True">

<Property Name = "Extensions"

Type = "Base.Element"

Nullable = "false"

MultiValued = "true" />

</Type>

Extensions of the Nested element differ from the extensions of the article in the following ways:

- Nested item extensions are not extension types. They do not belong to the extension type hierarchy whose root is the Base.Extension type;

- Extensions of the embedded element are stored together with other fields of the article and are not globally accessible - you cannot create a query that retrieves all instances of this type of extension;

- These extensions are saved in the same way as other nested elements (articles). Like other nested sets, NestedElement extensions are stored in TOP. They are available through the Extensions field of the nested item type.

- The collection of interfaces used to access multi-valued properties is also used to access and iterate over many type extensions.

The following table summarizes the significant characteristics and differences of the Article Extensions and Nested Element Extensions.

Article Extension Nesting Extension Storage The hierarchy of article extensions is stored in its own tables. Stored like nested items Query / Search May query article extension tables It can, in general, be requested only in the context of the containing article Request / Search Scope Can search across all instances of an article extension type In the general case, it can search only in instances of the type of a nested element of a single (containing) article Programmability Need special extension APIs and special query in extension tables Extensions of a nested element are similar to any other multivalued fields of a nested element; normal nested element type APIs are used Behavior May associate behavior No behavior allowed (?) Relationship semantics No Relationships with Article Extensions No Relations with Attachment Extensions ID Articles Shares article ID for article Does not have its own ID. Extension of the Nested element is part of the article

F. Database Machine

As noted above, the data warehouse is implemented on a database machine. In this embodiment, the database engine comprises a relational database machine that implements an SQL query language, such as a Microsoft SQL Server machine, with object relational extensions. This section describes the mapping of the data model that the data warehouse implements into relational storage and provides information about the logical API consumed by the clients of the storage platform according to this embodiment. However, it is understood that when using different database machines, different mappings can be used. Indeed, in addition to implementing the conceptual data model of the storage platform on a relational database machine, it can also be implemented on other types of databases, such as object-oriented databases or XML databases.

An object-oriented (OO) database system provides persistence and transactions for objects in a programming language (for example, C ++, Java). The concept of an “article” of a storage platform is well displayed as an “object” in object-oriented systems, although embedded collections will have to be added to Objects. Other storage platform type concepts, such as inheritance and nested element types, also map to object-oriented type systems. Object-oriented systems usually already support object identification. Behaviors (operations) of articles are well mapped into object methods. However, object-oriented systems are characterized by a lack of organizational capabilities and poor search tools. In addition, object-oriented systems do not provide support for unstructured or partially structured data. To support the complete storage platform data model described here, concepts such as relationships, folders, and extensions must be added to the data object model. In addition, mechanisms such as promotion, synchronization, notification, and security must be implemented.

By analogy with object-oriented systems, XML databases based on XSD (XML Schema Definition) support a single-inheritance type system. The article type system of the present invention can be mapped to an XSD type model. XSD also does not provide behavior support. XSD for articles should be complemented by article behaviors. XML databases deal with single XSD documents and lack organization and broad search capabilities. As with an object-oriented database, in order to support the data model described here, other concepts, such as relationships and folders, need to be embedded in such XML databases; In addition, mechanisms such as synchronization, notification and security should be implemented.

With respect to the following subsections, several illustrations are provided to facilitate the disclosure of general information: FIG. 13 is a diagram illustrating a notification mechanism. 14 is a diagram illustrating an example in which two transactions insert a new record into the same B-tree. Fig. 15 illustrates a data change detection process. On Fig shows an illustrative directory tree. 17 shows an example in which an existing directory-based file system folder is moved to a storage platform data store.

1. Implementation of data storage using TOP

In this embodiment, the relational database engine 314, which according to one embodiment comprises a Microsoft SQL Server machine, supports built-in scalar types. Built-in scalar types are "native" and "simple." They are proprietary in the sense that the user cannot set their own types, and simple in the sense that they cannot encapsulate a complex structure. User-defined types (below the TOP) provide a mechanism for expanding types beyond the scope of their own scalar type systems, allowing users to extend the type system by defining complex, structured types. Once defined by the user, TOPs can be used anywhere in the type system where built-in scalar types can be used.

According to an aspect of the present invention, storage platform schemes are mapped to TOP classes in the storage of a database machine. Data warehouse articles are mapped to TOP classes inferred from the Base.Item type. Like Articles, Extensions are also mapped to TOP classes and use inheritance. The root type of extension is Base.Extension, from which all extension types are derived.

TOP is a CLR class - it has state (i.e. data fields) and behavior (i.e. procedures). TOPs are specified using any managed language — C #, VB.NET, etc. The methods and operators of TOP can be invoked in T-SQL according to an instance of this type. A TOP can be a column type in a row, a procedure parameter type in T-SQL, or a variable type in T-SQL.

The mapping of storage platform schemas to TOP classes is pretty obvious at a high level. In general, a storage platform schema maps to the CLR namespace. The type of storage platform is mapped to the CLR class. Inheritance of the CLR class reflects the inheritance of the storage platform type, and the Storage Platform Property maps to the CLR class property.

2. Article display

If it is desirable to be able to perform a global search for Articles and support in a relational database that meets this embodiment, inheritance, and type substitution, then a possible implementation of the article repository in the database repository is to store all the Articles in a single table with a column of type Base.Item. Using the option of type substitution, you can save articles of all types, and searches can be filtered by type and subtype of the Article using the Yukon operator "refers to (type)".

However, due to the problem of overload associated with this approach, in this embodiment, the Articles are divided by the top-level type, so that the Articles of each “family” of types are stored in a separate table. In accordance with such a partitioning scheme, a table is created for each type of Article that inherits directly from Base.Item. Types that inherit below them are stored in the corresponding table of the type family using the type substitution feature described above. Only the first level of inheritance from Base.Item is specially processed.

The “shadow” table is used to store copies of globally sought properties for all Articles. This table can be supported by the Update () method of the storage platform API through which all data changes are made. Unlike the type family table, this global Article table contains only scalar properties of the top-level Articles, and not the full TOP Article object. The global Article table allows navigation to the Article object stored in the table of the type family, representing the Article ID and Type ID. An Article ID, in general, uniquely identifies an Article in a data warehouse. The Type ID may be displayed using metadata that is not described here, in the type name and view containing the Article. Since retrieving an Article by its Article ID can be a general operation, both in the context of the global Article table and otherwise, the GetItem () function is provided to retrieve the Article object for this Article ID for the Article.

For ease of access and hiding implementation details, to the extent possible, all requests for Articles can be made using views built on the Article tables described here. In particular, views can be created for each type of Article using the corresponding table of the type family. These types of types can be selected by all Articles of the corresponding type, including subtypes. For convenience, in addition to the TOP object, views can represent columns for all top-level fields of this type, including inherited fields.

3. Display extensions

Extensions are quite similar to Articles and have some of the same requirements. As the root type that supports inheritance, Extensions have many of the same considerations and trade-offs during storage. As a result, the Extensions apply a similar type family mapping, rather than a single table approach. Of course, in other embodiments, a single table approach can be used. In this embodiment, the Extension is associated strictly with one Article through an Article ID and contains an extension ID that is unique in the context of the Article. As with articles, a function can be provided to retrieve the Extension by its identification, which consists of a pair of article IDs and extension IDs. A view is created for each Extension Type, by analogy with the types of Article types.

4. Display of nested elements

Nested elements are types that can be embedded in Articles, Extensions, Relations or other Nested elements to form structures with deep nesting. Like Articles and Extensions Nested elements are implemented as TOP, but they are stored inside articles and extensions. Therefore, Nested elements do not have a storage mapping outside the containers of their Articles and Extensions. In other words, there are no tables in the system that directly store instances of types of Nested elements, and there are no views directly intended for Nested elements.

5. Identification of objects

Each entity in the data model, i.e. Each Article, Extension and Relationship has a unique key value. An article is uniquely identified by its article ID. An extension is uniquely identified by a compound key (article ID, extension ID). A relationship is identified by a compound key (article ID, relationship ID). Article ID, Extension ID, and Relationship ID are GUID values.

6. Naming SQL Objects

All objects created in the data warehouse can be stored in the SQL schema name derived from the storage platform schema name. For example, a Base Schema storage platform (often referred to as a “base”) can create types in the SQL schema “[System.Storage]”, for example, “[System.Storage] .Item”. Generated names have a qualifier as a prefix to exclude naming conflicts. If necessary, an exclamation mark (!) Is used as a separator for each logical part of the name. The following table describes the naming convention used for objects in the data warehouse. Each element of the schema (Article, Extension, Relationship, and View) is listed in conjunction with the decorated naming convention used to access instances in the data warehouse.

An object Decorated name Description Example The main search type of article Master! Item Provides a summary of articles in the current article area. [System.Storage]. [Master! Item] Typed Search Article Type Type of article Provides all property data from the article and any parent types [AcmeCorp.Doc]. [OfficeDoc] Main search extension type Master! Extension Provides a summary of all extensions in the current article area. [System.Storage]. [Master! Extension] Typed Search Extension Type Extension! Type of extension Provides all property data for extension. [AcmeCorp.Doc]. [Extension! StickyNote] The main kind of relationship Master! Relationship Provides a summary of all relationships in the current article area. [System.Storage]. [Master! Relationship] Relationship type Relationship! Name of relationship Provides all data associated with this relationship. [AcmeCorp.Doc]. [Relationship!
AuthorsFromDocument] View View! View name Provides columns / types based on schema view definition [AcmeCorp.Doc]. [View! DocumentTitles]

7. Naming Columns

When displaying any object model in the repository, the possibility of naming conflicts arises in connection with additional information stored in conjunction with the application object. To avoid naming conflicts, all columns that are independent of type (columns that do not map directly to the named Property in the type declaration) must be prefixed with an underscore (_). In this embodiment, the underscore (_) characters are not allowed as the starting character of any identifier property. In addition, to unify the naming between the CLR and the data warehouse, all properties of the types of the storage platform or schema element (relationships, etc.) must begin with a capital letter.

8. Search Views

Views are provided by the storage platform to search for stored content. An SQL view is provided for each Article and Extension Type. In addition, views are provided to support Relations and Views (defined in the Data Model). All kinds of SQL and underlying tables in the storage platform are read-only. Data can be saved or modified using the Update () method of the storage platform API, as described in more detail below.

Each view specified explicitly in the storage platform schema (specified by the developer of the schema and not generated automatically by the storage platform) is accessible through the named SQL view [<schema name>]. [View! <View name>]. For example, a view named “BookSales” in the “AcmePublisher.Books” schema is available using the name “[AcmePublisher.Books]. [View! BookSales]”. Since the output format of the view is customizable for each view (determined by an arbitrary request provided by the party determining the view), the columns are directly displayed based on the definition of the type of scheme.

All SQL lookups in the storage platform data warehouse use the following collation for columns:

- Logical (e) “key (s)” column (s) of the result of the form, such as the article ID, element ID, relationship ID, ...;

- Metadata information about the type of result, such as type ID;

- Columns of change tracking, for example, “create version”, “update version”, ...;

- Column (s) depending (e) on the type (Properties of the declared type);

- Type-specific views (family views) also contain a column of objects that returns an object.

Members of each type family can be searched using a sequence of Article types, and there is one type for each type of Article in the data warehouse. On Fig shows a diagram illustrating the concept of a search view Articles.

a) Article

Each search type of an Article contains a line for each instance of an Article of a certain type or its subtypes. For example, a view for a Document may return instances of a Document, a Legal Document, and a Survey Document. According to this example, the types of Articles can be conceptualized, as shown in Fig. 29.

(1) Main search view Articles

Each instance of the storage platform data warehouse defines a specific type of Article, referred to as the Main type of article. This view provides basic information about each Article in the data warehouse. The view provides one column for each property of the Article type, a column describing the Article type, and several columns that are used to provide change tracking and synchronization information. The main view of the article is identified in the data warehouse using the name “[System.Storage]. [Master! Item]”.

Column Type of Description ItemId ItemId Identification of Articles in the storage platform _TypeId Typeid Article type ID - identifies the exact type of the Article and can be used to retrieve type information using the Metadata Catalog. _RootItemId ItemId The article ID for the first non-embedded ancestor that controls the lifetime of this article. <global change tracking> ... Global Change Tracking Information <Article Properties> no One column per property of type Articles

(2) Typed Search Types Articles

Each type of Article also has a search view. Although it is similar to the root view of an Article, this view also provides access to the Article object through the “_Item” column. Each typed search type of an Article is identified in the data warehouse using the name [schema name]. [Article type name]. For example, [AcmeCorp.Doc]. [OfficeDoc].

Column Type of Description ItemId ItemId Identification of Articles in the storage platform <type change tracking> ... Type Change Tracking Information <parent properties> <depends on property> One column per parent property <article properties> <depends on property> One column for an exceptional property of this type _Item Type CLR Articles CLR object - type of declared Article

b) Article extensions

All article extensions in the WinFS repository are also available using search views.

(1) Main search extension type

Each instance of the data warehouse defines a specific type of Extension called the Primary Type of Extension. This view provides basic information about each Extension in the data warehouse. The view has one column for the Extensions property, a column describing the type of the Extension, and several columns that are used to provide change tracking and synchronization information. The main type of extension is identified in the data warehouse using the name “[System.Storage]. [Master! Extension]”.

Column Type of Description ItemId ItemId Identification of the Article in the storage platform this extension is associated with ExtensionId ExtensionId (GUID) ID of this extension instance _TypeId Typeid Extension type ID — Identifies the exact type of extension and can be used to retrieve extension information using the Metadata Catalog. <global change tracking> ... Global Change Tracking Information <extension properties> <depends on property> One column per Extension Type property

(2) Typed Search Extensions

Each type of extension also has a search view. Although it is similar to the main type of extension, this view also provides access to the Article object through the _Extension column. Each typed search extension type is identified in the data store using the name [schema name]. [Extension! Name of extension type]. For example, [AcmeCorp.Doc]. [Extension! OfficeDocExt].

Column Type of Description ItemId ItemId Identification of the Article in the storage platform this extension is associated with ExtensionId ExtensionId (GUID) ID of this extension instance <type change tracking> ... Type Change Tracking Information <parent properties> <depends on property> One column per parent property <extension properties> <depends on property> One column for an exceptional property of this type _Extension Extension Instance CLR Type CLR Object — Type of the declared Extension

c) Nested elements

All nested elements are stored in instances of Articles, Extensions or Relations. As such, they are available by querying the search form of the corresponding Article, Extension or Relationship.

d) Relationships

As described above, Relationships form the main unit of communication between Articles in the data warehouse of the storage platform.

(1) Main search relationship type

Each data warehouse provides the main view of the relationship. This view provides information about all instances of the relationship in the data warehouse. The main relationship type is identified in the data warehouse using the name “[System.Storage]. [Master! Relationship]”.

Column Type of Description ItemId ItemId Identification of the source endpoint (article ID) RelationshipId RelationshipId (GUID) Relationship instance id _RelTypeId RelationshipTypeId Relationship Type ID for Relationship — Identifies the instance type of the relationship using the Metadata Catalog. <global change tracking> ... Global change tracking information. TargetItemReference ItemReference Target Endpoint Identification _Relationship Relationship An instance of the relationship object for this instance.

(2) Search types of relationship instance

Each declared Relationship also has a search form that returns all instances of a particular relationship. Although it is similar to the main relation type, this view also provides named columns for each property of the relation data. Each search type of relationship instance is identified in the data store using the name [schema name]. [Relationship! Relationship name]. For example, [AcmeCorp.Doc]. [Relationship! DocumentAuthor].

Column Type of Description ItemId ItemId Identification of the source endpoint (article ID) RelationshipId RelationshipId (GUID) Relationship instance id <type change tracking> ... Type Change Tracking Information TargetItemReference ItemReference Target Endpoint Identification <source name> ItemId Named property for identifying the source endpoint (alias for the article ID) <target name> ItemReference or derived class Named property of identifying the target endpoint (alias and casting of the Link to the target article) <relationship property> <depends on property> One column per relationship definition property _Relationship Relationship Instance CLR Type CLR Object - Type of Declared Relationship

9. Updates

All views in the data warehouse storage platform are read-only. To create a new instance of a data model element (article, extension or relationship) or to update an existing instance, use the ProcessOperation or ProcessUpdategram API of the storage platform. The ProcessOperation method is a single stored procedure defined by a data warehouse that consumes an “operation” that details the action to be performed. The ProcessUpdategram method is a stored procedure that takes an ordered set of operations called an “updategram” that together detail the set of actions to be performed.

The operation format is extensible and provides various operations on circuit elements. Some common operations include:

1. Operations on articles:

but. CreateItem (creates a new article in the context of an implementation or maintenance relationship);

b. UpdateItem (updates an existing article).

2. Relationship operations:

a. CreateRelationship (creates an instance of a reference or maintain relationship);

b. UpdateRelationship (updates an instance of a relationship);

c. DeleteRelationship (deletes relationship instances).

3. Operations on extensions:

a. CreateExtension (adds an extension to an existing Article);

b. UpdateExtension (updates an existing extension);

c. DeleteExtension (removes the extension).

10. Change Tracking and Burial

Change tracking and disposal services are provided by the data warehouse, which will be discussed in more detail below. This section briefly describes the change tracking information provided in the data warehouse.

a) Change tracking

Each search view provided by the data warehouse contains columns used to provide change tracking information; columns are common to all kinds of Articles, Extensions, and Relationships. Types of storage platform diagrams set explicitly by the developers of the schemas do not automatically provide change tracking information - such information is provided indirectly through the search views on which the view itself is built.

For each item in the data warehouse, change tracking information is available from two places - the “main” view of the item and the “typed” view of the item. For example, change tracking information by type of AcmeCorp.Document.Document Article is available from the Main view of the article “[System.Storage]. [Master! Item]” and the typed search view of the Article [AcmeCorp.Document]. [Document].

(1) Track changes to the “Top” search types

Change tracking information in the main search types provides information about creating and updating versions of an element, information about the synchronization partner that created the element, about the synchronization partner that last updated the element, and version numbers from each partner for creating and updating. Partners in a synchronization relationship (described below) are identified by the partner key. A single TOP object named _ChangeTrackingInfo and type [System.Storage.Store] .ChangeTrackingInfo contains all this information. The type is specified in the System.Storage schema. _ChangeTrackingInfo is available in all global search views for Articles, Extensions, and Relationships. The following is a definition of the type ChangeTrackingInfo:

<Type Name = ”ChangeTrackingInfo” BaseType = ”Base.NestedElement”>

<FieldProperty Name = ”CreationLocalTS” Type = ”SqlTypes.SqlInt64”

Nullable = ”False” />

<FieldProperty Name = ”CreatingPartnerKey” Type = ”SqlTypes.SqlInt32”

Nullable = ”False” />

<FieldProperty Name = ”CreatingPartnerTS” Type = ”SqlTypes.SqlInt64”

Nullable = ”False” />

<FieldProperty Name = ”LastUpdateLocalTS” Type = ”SqlTypes.SqlInt64”

Nullable = ”False” />

<FieldProperty Name = ”LastUpdatingPartnerKey” Type = ”SqlTypes.SqlInt32”

Nullable = ”False” />

<FieldProperty Name = ”LastUpdatingPartnerTS” Type = ”SqlTypes.SqlInt64”

Nullable = ”False” />

</Type>

These properties contain the following information:

Column Description _CreationLocalTS Creating a Timestamp by a Local Machine _CreatingPartnerKey The partner key for the partner that created this entity. If the entity is created locally, this is the Partner Key for the local machine. _CreatingPartnerTS The timestamp for the time that this entity was created on the partner matching _CreatingPartnerKey. _LastUpdateLocalTS Local timestamp corresponding to the time point of the update on the local machine _LastUpdatingPartnerKey The partner key for the partner who last updated this entity. If the last update was made locally, this is the Partner Key for the local machine _LastUpdatingPartnerTS The timestamp for the point in time when this entity was updated on the partner matching _LastUpdatingPartnerKey.

(2) Tracking changes in typed search types

In addition to providing the same information that the global search view provides, each typed search view provides additional information regarding the synchronization status of each element in the synchronization topology.

Column Type of Description <global change tracking> ... Information from Global Change Tracking _ChangeUnitVersions MultiSet <ChangeUnitVersion> Description of version numbers of change blocks in a specific element ElementSyncMetadata ElementSyncMetadata Additional version-independent metadata about this article that is of interest only to the synchronization runtime. _VersionSyncMetadata VersionSyncMetadata Additional version-specific metadata about this article that is of interest only to the synchronization runtime.

b) Burial

The data warehouse provides burial information for Articles, Extensions and Relations. Types of burial provide information about both living and buried entities (articles, extensions and relationships) in one place. Burial types for articles and extensions do not provide access to the corresponding object, while a burial type for a relationship provides access to the relationship object (the relationship object is NULL in the case of a "buried" relationship).

(1) Burial Articles

Tombstones of Articles are retrieved from the system using the [System.Storage]. [Tombstone! Item] view.

Column Type of Description ItemId ItemId Article Identification _TypeID Typeid Type of article <Item properties> ... Properties set for all articles _RootItemId ItemId The article ID for the first non-embedding article that contains this article. _ChangeTrackingInfo CLR instance for type ChangeTrackingInfo Change Tracking Information for This Article _IsDeleted Bit This flag is 0 for live articles and 1 for buried articles. _DeletionWallclock Utcatetime Coordinated Universal Time (UTC) date / time according to the partner that deleted the article. Equals NULL if the article is alive.

(2) Burial extensions

Extension tombs are retrieved from the system using the [System.Storage]. [Tombstone! Extension] view. Extension change tracking information is similar to that provided for Articles, but supplemented by the extension ID property.

Column Type of Description ItemId ItemId Identification of Article Owning Extension ExtensionId ExtensionId Extension ID for Extension _TypeID Typeid Extension type _ChangeTrackingInfo CLR instance for type ChangeTrackingInfo Change tracking information for this extension _IsDeleted Bit This is a flag that is 0 for live articles and 1 for buried extensions. _DeletionWallclock Utcatetime Coordinated Universal Time (UTC) date / time according to the partner that removed the extension. Equals NULL if the extension is alive.

(3) Burial relations

Extension tombs are retrieved from the system using the [System.Storage]. [Tombstone! Relationship] view. Extension tombstone information is similar to that provided for Extensions. However, additional link information for the target article for the relationship instance is provided. In addition, a relationship object is selected.

Column Type of Description ItemId ItemId Identification of the Article that owned the relationship (identification of the source endpoint of the relationship) RelationshipId RelationshipId Relationship id for relationship _TypeID Typeid Relationship type _ChangeTrackingInfo CLR instance for type ChangeTrackingInfo Change tracking information for this relationship _IsDeleted Bit This is a flag that is 0 for live articles and 1 for buried extensions. _DeletionWallclock Utcatetime Coordinated Universal Time (UTC) date / time according to the partner that deleted the relationship. Equals NULL if the relation is alive. _Relationship CLR Instance for Relationship It is a relationship object for a living relationship. Equals NULL for buried relationships. TargetItemReference ItemReference Target Endpoint Identification

(4) Landfill cleaning

To avoid unlimited growth of burial information, the data warehouse provides the task of clearing the burial. This task determines when burial information can be canceled. The job calculates the boundary of local version creation / update, and then truncates the burial information, invalidating all earlier buried versions.

11. API and helper functions

Base mapping also provides a number of assistant functions. These features are provided to aid general operations on the data model.

a) Function [System.Storage] .GetItem

Returns the Article object for a given article ID

//

Item GetItem (ItemId ItemId)

b) Function [System.Storage] .GetExtension

// Returns the extension object for the given article ID and extension ID

//

Extension GetExtension (ItemId ItemId, ExtensionId ExtensionId)

c) Function [System.Storage] .GetRelationship

// Returns the relationship object for the given article ID and relationship ID

//

Relationship GetRelationship (ItemId ItemId, RelationshipId RelationshipId)

12. Metadata

The Repository contains two types of metadata: instance metadata (Article type, etc.) and type metadata.

a) Schema metadata

Schema metadata is stored in the data warehouse as instances of the types of Articles from the metadata schema.

b) Instance metadata

Instance metadata is used by the application to query the type of the Article and find the extensions associated with the Article. Given this Article ID for the Article, the application can request that the global view of the article return the type of the article, and use this value to request the view Meta.Type to return information about the declared type of the Article. For example,

// Return the metadata of the Article object for this instance of the Article

//

SELECT m._Item AS metadataInfoObj

FROM [System.Storage]. [Item] i INNER JOIN [Meta]. [Type] m ON i._TypeId = m.ItemId

WHERE i.ItemId = @ItemId

G. Security

In general, all protected objects organize their access rights using the access mask format shown in FIG. In this format, the 16 low-order bits are for object-specific access rights, the next 7 bits are for standard access rights that apply to most types of objects, and the 4 high-order bits are used to specify the general access rights that each type of object can map to multiple standard and object-specific rights. The “access to system security” bit corresponds to the access right to the SACL of the object.

In the structure of the access mask shown in FIG. 26, the rights dependent on the article are located in the section “rights dependent on the article” (16 least significant bits). Since in this embodiment, the storage platform represents two sets of APIs for administering the security of the Win32 API and the storage platform, object-specific rights of the file system should be considered in order to motivate the construction of object-specific rights, the storage platform.

The security model for the storage platform of the present invention is fully described in the related applications, incorporated herein by reference. In this regard, FIG. 27 (parts a, b, and c) depicts a new identically protected security region cut from an existing security region according to one embodiment of a security model.

H. Notifications and change tracking

According to another aspect of the present invention, the storage platform provides a notification function that allows applications to track data changes. This feature is mainly intended for applications that support temporary states or execute business logic on data change events. Applications are registered for notifications on articles, article extensions, and article relations. Notifications are delivered asynchronously after making data changes. Applications can filter notifications by article, extension and type of relationship, as well as type of operation.

According to one embodiment, storage platform API 322 provides two kinds of notification interfaces. First, applications record simple data change events caused by changes in articles, article extensions, and article relationships. Secondly, applications create observer objects to track sets of articles, article extensions, and article relationships. The state of the observer object can be saved and re-created after a system error or after the system has been offline for an extended period of time. A single notification can reflect many updates.

Further details regarding this feature are described in related applications, incorporated herein by reference.

I. Sync

According to yet another aspect of the present invention, the storage platform provides a synchronization service 330 that (i) allows multiple instances of the storage platform (each has its own data store 302) to synchronize parts of its content according to a flexible set of rules and (ii) provides third-party infrastructure for synchronizing storage data of a storage platform of the present invention with other data sources that implement ownership protocols.

Synchronization between storage platforms occurs among a group of participating duplicates. For example, as shown in FIG. 3, it may be necessary to provide synchronization between the data store 302 of the storage platform 300 and another remote data store 338 under the control of another instance of the storage platform, possibly operating in a different computer system. The full membership of this group is not necessarily known to any given duplicate at any given time.

Different duplicates can make changes independently (i.e. in parallel). This synchronization process, by definition, is that each duplicate becomes aware of the changes made by other duplicates. This synchronization function, by its nature, provides many master elements.

The synchronization function according to the present invention allows duplicates:

- Determine what changes another duplicate is aware of;

- Request information about changes that this duplicate does not know about;

- Transfer information about changes that another duplicate does not know about;

- Determine when two changes conflict with each other;

- Apply changes locally;

- Transfer conflict resolution to other duplicates to ensure convergence; and

- Resolve conflicts based on predefined policies to resolve conflicts.

1. Synchronization between storage platforms

The main application of the storage platform synchronization service 330 of the present invention is to synchronize multiple instances of the storage platform (each of which has its own data store). The synchronization service operates at the level of the storage platform schemas (and not at the lower level of the tables of the database engine 314). So, for example, “Boundaries” are used to define synchronization sets, which is discussed below.

The synchronization service operates on the basis of the “net change” principle. Instead of recording and sending individual operations (for example, with transactional duplication), the synchronization service sends the final result of these operations, thus often combining the results of many operations into a single resultant change.

The synchronization service, in general, does not take into account transaction boundaries. In other words, if two changes are made to the storage platform data warehouse in one transaction, there is no guarantee that these changes apply to all other duplicates atomically - one can happen without the other. An exception to this principle is that if two changes are made to the same Article in the same transaction, then these changes are guaranteed to be sent and applied to other duplicates atomically. Thus, Articles are consistency blocks for a synchronization service.

a) Sync management applications

Any application can connect to a synchronization service and initiate a synchronization operation. Such an application provides all the parameters necessary for synchronization (see the synchronization profile below). Such applications will be referred to as synchronization management applications.

When two instances of the storage platform are synchronized, synchronization is initiated, on the one hand, by the CCP. This CCP instructs the local synchronization service to synchronize with the remote partner. On the other hand, the synchronization service is activated by messages sent by the synchronization service from the sending machine. It responds based on persistent configuration information (see mappings below) available on the receiving machine. The synchronization service can be launched on schedule or in response to events. In these cases, the synchronization service that implements the schedule becomes the CCP.

To ensure synchronization, you need to perform two steps. First, the schema designer must annotate the storage platform schema with the appropriate synchronization semantics (indicating change units, as described below). Secondly, synchronization must be correctly configured on all machines that have a storage platform instance that must participate in synchronization (as described below).

b) Annotation of the scheme

The main concept of the synchronization service is the concept of the Change Block. A change block is the smallest fragment of a circuit that is individually monitored by the storage platform. For each Change Unit, the synchronization service may be able to determine whether it has changed since the last synchronization.

Indication of Change Blocks in a schema serves several purposes. Firstly, it determines the extent to which the synchronization service exchanges information. When a change is made in the Change Block, the entire Change Block is sent to other duplicates, because the synchronization service does not know which part of the Change Block has changed. Secondly, it determines the degree of discretization of conflict detection. When two parallel changes (these terms are described in detail in the following sections) are made in the same change block, the synchronization service creates a conflict; on the other hand, if parallel changes are made in different blocks of change, no conflict is created, and the changes are automatically merged. Thirdly, it greatly affects the amount of metadata supported by the system. Most of the synchronization service metadata is supported for each Change Block; thus, the smaller the blocks of change, the greater the synchronization overhead.

Defining Change Blocks requires finding the right compromises. For this reason, the synchronization service allows circuit developers to participate in this process.

In one embodiment, the synchronization service does not support Change Blocks that are larger than an element. However, it does support the ability for schema developers to specify change blocks that are smaller than the element, namely to group the set of element attributes into a separate Change Block. In this embodiment, this is done using the following syntax:

<Type Name = "Appointment" MajorVersion = "1" MinorVersion = "0" ExtendsType = "Base.Item"

ExtendsVersion = "1">

<Field Name = "MeetingStatus“ Type = "the storageplatformTypes.uniqueidentifier Nullable =" False "/>

<Field Name = "OrganizerName“ Type = "the storageplatformTypes.nvarchar (512)" Nullable = "False" />

<Field Name = "OrganizerEmail“ Type = "the storageplatformTypes.nvarchar (512)"

TypeMajorVersion = "1“ MultiValued = "True" />

...

<ChangeUnit Name = ”CU_Status”>

<Field Name = ”MeetingStatus” />

</ChangeUnit>

<ChangeUnit Name = ”CU_Organizer” />

<Field Name = ”OrganizerName” />

<Field Name = ”OrganizerEmail” />

</ChangeUnit>

...

</Type>

c) Sync configuration

A group of storage platform partners who want to keep certain parts of their data in sync are called the synchronization community. Although community members want to stay in sync, they don't have to present the data in exactly the same way; in other words, synchronization partners can convert the data that they synchronize.

In a peer entity interaction scenario, it is not practical for peer entities to support transform mappings for all their partners. Instead, the synchronization service takes the approach of defining “community folders”. A community folder is an abstraction that represents a hypothetical “shared folder” with which all community members synchronize.

This concept is best illustrated by an example. If Joe wants to keep the My Documents folders of several of his computers in sync, he sets the community folder as, for example, JoesDocuments. Then, on each computer, Joe configures the mapping between the hypothetical JoesDocuments folder and the local My Documents folder. After that, when Joe's computers are synchronized with each other, they interact in terms of documents in the JoesDocuments folder, not their local articles. Thus, all of Joe’s computers understand each other without having to know who the others are — the community folder becomes the lingua franca community synchronization.

Configuring the synchronization service consists of three stages: (1) defining mappings between local folders and community folders; (2) setting synchronization profiles that determine what is synchronized (for example, who synchronizes with whom and which subsets need to be transmitted and which ones to receive); and (3) defining schedules by which each of the various synchronization profiles should be launched, or launching them manually.

(1) Community Folder Mappings

Community folder mappings are stored in separate XML configuration files. Each mapping has the following scheme:

/ mappings / communityFolder

This item names the community folder for which this mapping is intended. The name obeys the syntax rules for Mailboxes.

/ mappings / localFolder

This item names the local folder into which the mapping is converted. The name obeys the syntax rules for Mailboxes. For the display to be valid, the folder must already exist. Thanks to this mapping, articles in this pack are considered synchronized.

/ mappings / transformations

This element defines how to convert articles from the community folder to the local folder and vice versa. If the folder is missing or empty, no conversion is performed. In particular, this means that no IDs are displayed. This configuration is mainly useful for creating a Mailbox cache.

/ mappings / transformations / mapIDs

This element requests that the newly generated local IDs be assigned to all articles displayed from the community folder, instead of reusing community identifiers. The synchronization runtime will support ID mappings for converting articles in both directions.

/ mappings / transformations / localRoot

This element requests that all root articles in the community folder be made child of the specified root.

/ mappings / runAs

This element controls the basis under which requests for display are processed. In case of absence, the sender is assumed.

/ mappings / runAs / sender

The presence of this element indicates that the sender of the messages for this display should be non-personalized and requests are processed under his responsibility.

(2) Profiles

A synchronization profile is the complete set of parameters needed to start synchronization. The CCP sends it to the synchronization runtime to initiate synchronization. Synchronization profiles for synchronization between storage platforms contain the following information:

- A local folder that serves as a source and destination for changes;

- Name of the remote folder for synchronization - this Folder should be published from the remote partner by displaying as described above;

- Direction - the synchronization service supports synchronization with the ability to only send, only receive and send / receive;

- Local filter - selects what local information to send to the remote partner. Expressed as a storage platform request for a local folder;

- Remote filter - selects what remote information to retrieve from the given partner - expressed as a request from the storage platform regarding the community folder;

- Conversions - sets how to convert articles to a local format and from a local format;

- Local security - indicates whether the changes extracted from the remote endpoint are subject to application by permission of the remote endpoint (non-personalized) or the user initiating synchronization locally; and

- Conflict resolution policy - indicates whether conflicts should be dropped, registered or automatically resolved - in the latter case, it indicates which conflict resolution mechanism to use, as well as configuration settings for it.

The synchronization service provides a CLR runtime class that provides the ability to easily build synchronization profiles. Profiles can also be serialized to and from XML files for easy storage (often with schedules). However, the storage platform does not have a standard place where all profiles are stored; CCP provides the opportunity to build a profile in place even without its constant conservation. Note that it is not necessary to have a local mapping to initiate synchronization. All synchronization information can be specified in the profile. However, mapping is required to respond to synchronization requests initiated by the remote side.

(3) Schedules

In one embodiment, the synchronization service does not provide its own scheduling infrastructure. Instead, to accomplish this task, it relies on another component - the Windows Scheduler, which is part of the Microsoft Windows operating system. The synchronization service includes a command line utility that acts as a PCM and starts synchronization based on the synchronization profile stored in the XML file. This utility greatly simplifies the configuration of Windows Scheduler to start synchronization either on a schedule or in response to events, such as a user logging in or logging out.

d) Conflict handling

Conflict handling in the synchronization service is divided into three stages: (1) conflict detection that occurs at the time the change is applied - this stage determines whether the change can be applied safely; (2) automatic conflict resolution and registration - at this stage (which is carried out immediately after the conflict is detected), they turn to automatic conflict resolution mechanisms to see if the conflict can be resolved - if not, the conflict can be registered optionally; and (3) inspection and resolution of the conflict - this stage takes place if some conflicts have been registered and occurs outside the context of the synchronization session - at this time the registered conflicts can be resolved and deleted from the log.

(1) Conflict Detection

In this embodiment, the synchronization service detects two types of conflicts: based on knowledge and based on restriction.

(a) Knowledge-based conflicts

A knowledge-based conflict occurs when two duplicates make independent changes in the same Change Unit. Two changes are called independent if they are made without knowledge of each other, in other words, the version of the first is not covered by knowledge of the second and vice versa. The synchronization service automatically detects all such conflicts based on knowledge of duplicates, as described above.

It is sometimes useful to consider conflicts as forks in version history for change blocks. If during the life of the change blocks there are no conflicts, its version history is a simple chain - each change occurs after the previous one. In the event of a knowledge-based conflict, two changes occur in parallel, leading to a split chain and the creation of a version tree.

(b) Conflict based conflicts

There are cases where independent changes violate integrity constraints when used together. For example, two duplicates creating a file with the same name in the same directory can cause this conflict.

A constraint-based conflict involves two independent changes (just like knowledge-based), but they do not affect the same block of change. Instead, they affect different blocks of change, but with the constraint that exists between them.

The synchronization service detects constraint violations at the time the change is applied and automatically creates conflicts based on the constraint. Constraint-based conflict resolution usually requires customized code that modifies the changes so as not to violate the constraints. The synchronization service does not provide a general purpose mechanism that implements this.

(2) Conflict Handling

If a conflict is detected, the synchronization service can perform one of three actions (selected by the initiator of synchronization in the Synchronization Profile): (1) cancel the change, return it to the sender; (2) register the conflict in the conflict log; or (3) automatically resolve the conflict.

If the change is canceled, the synchronization service acts as if the change did not arrive at the duplicate. A negative acknowledgment is sent to the sender. This resolution policy is mainly useful on header duplicates (for example, file servers) where conflict registration is not possible. Instead, such duplicates force others to deal with conflicts, discarding them.

Synchronization initiators configure conflict resolution in their Synchronization Profiles. The synchronization service supports combining multiple conflict resolution mechanisms in a single profile in the following ways: firstly, by defining a list of conflict resolution mechanisms that you need to try one by one until one of them leads to success; and secondly, associating conflict resolution mechanisms with types of conflicts, for example, directing conflicts on the basis of knowledge between updates to one conflict resolution mechanism, and all other conflicts to the registration log.

(a) Automatic conflict resolution

The synchronization service provides a number of default conflict resolution mechanisms. This list includes:

- Local wins: ignore incoming changes in case of conflict with locally stored data;

- Remote wins: ignore local data in case of conflict with incoming changes;

- Wins of the last recording: select either local wins or remote wins for each change block based on the change timestamp (note that the synchronization service, in the general case, does not rely on the clock values; this conflict resolution mechanism is the only exception to this rule);

- Deterministic: choose a winner so that it is guaranteed to be the same on all duplicates, and otherwise it makes no sense - one option for implementing synchronization services uses lexicographic comparisons of partner IDs to implement this feature.

In addition, NPPs can implement and establish their own conflict resolution mechanisms. Specialized conflict resolution mechanisms can accept configuration parameters; The CCP must specify such parameters in the Conflict Resolution section of the Synchronization Profile.

When the conflict resolution engine processes the conflict, it returns the list of operations that need to be performed (instead of the conflicting change) back to the runtime. Then, the synchronization service applies these operations belonging to the remote knowledge setting so that it includes what is considered by the conflict processing mechanism.

It is possible that another conflict will be detected during the application of this resolution. In this case, a new conflict must be resolved before resuming the initial processing.

When considering conflicts as branches in the history of versions of an article, conflict resolution can be considered as connections — the union of two branches to form one point. In this way, conflict resolution turns version stories into ONG.

(b) Conflict Records

A very specific type of conflict resolution mechanism is the Conflict Recorder. The synchronization service registers conflicts as Articles of type ConflictRecord. These entries are linked to articles in conflict (unless the articles themselves are deleted). Each conflict record contains: an incoming change that caused the conflict; type of conflict: update-update, update-delete, delete-update, insert-insert or restriction; and the version of the incoming change and the knowledge of the duplicate that sent it. Registered conflicts are available for inspection and resolution as described above.

(c) Inspection and resolution of conflicts

The synchronization service provides an API for applications to check the conflict log and offer resolutions to the conflicts specified in it. The API allows the application to list all conflicts or conflicts related to this Article. It also allows such applications to resolve recorded conflicts in one of three ways: (1) remote wins — receiving a registered change and rewriting a conflicting local change; (2) local wins - ignoring the conflicting parts of the registered change; and (3) proposing a new change - when the application proposes a merger, which, in its opinion, resolves the conflict. After the conflicts are resolved by the application, the synchronization service removes them from the log.

(d) Convergence of duplicates and distribution of conflict resolution

In complex synchronization scenarios, the same conflict can be detected on multiple duplicates. If this occurs, the following may occur: (1) the conflict can be resolved on one duplicate, and the resolution is directed to another; (2) the conflict is automatically resolved on both duplicates; or (3) a conflict is resolved manually on both duplicates (via the Conflict Inspection API).

To ensure convergence, the synchronization service forwards conflict resolution to other duplicates. When a change resolving the conflict arrives at a duplicate, the synchronization service automatically finds in the log records of any conflicts that are resolved by this update and excludes them. In this sense, conflict resolution on one duplicate is associated with all other duplicates.

If different duplicates choose different winners for the same conflict, then the synchronization service applies the principle of linking conflict resolutions and selects one of two resolutions that automatically wins the other. The winner is determined deterministically, which is guaranteed to lead to the same results each time (one embodiment uses lexicographic comparisons of duplicate IDs).

If different duplicates offer different “new changes” for the same conflict, the synchronization service processes this new conflict as a special conflict and uses the Conflict Recorder to prevent it from spreading to other duplicates. This situation usually occurs when the conflict is resolved manually.

2. Synchronization with platform data warehouses without storage

According to one aspect of the storage platform of the present invention, the storage platform provides an architecture for NPPs to implement Synchronization Adapters that allow the storage platform to synchronize with well-known systems such as Microsoft Exchange, AD, Hotmail, etc. Synchronization adapters use many of the Sync Services provided by the synchronization service. as described below.

Despite its name, Sync Adapters do not have to be implemented as modules that are embedded in some storage platform architecture. If desired, the “synchronization adapter” can simply be any application that uses the interfaces of the synchronization service runtime to receive services such as enumeration and application of changes.

To make it easier for others to configure and start synchronization with this database machine, it is preferable that the creators of the Synchronization Adapters present the standard interface of the Synchronization Adapter, which starts synchronization based on the Synchronization Profile, as described above. The profile provides the adapter with configuration information, part of which the adapters pass to the synchronization runtime to manage the services of the runtime (for example, the folder to be synchronized).

a) Sync services

The synchronization service provides a number of synchronization services to the creators of adapters. For the remainder of this section, it is convenient to name the machine on which the storage platform synchronizes as “client”, and the platform database machine without storage as “server”.

(1) Listing Changes

Based on the change tracking data that the synchronization service manipulates, Change enumeration allows synchronization adapters to easily list changes that have occurred in the Data Warehouse Folder since the last time an attempt was made to synchronize with this partner.

Changes are listed based on the concept of an “anchor” - an opaque structure that represents information about the latest synchronization. Anchor takes the form of Knowledge storage platform as described in the following sections. Sync adapters using change enumeration services fall into two broad categories: those that use “saved anchors” and those that use “feed anchors”.

The difference is where the information about the last synchronization is stored - on the client or on the server. Adapters are often easier to store this information on the client - the database machine is often unable to conveniently store this information. On the other hand, if many clients are synchronized with the same database machine, storing this information on the client is inefficient and in some cases incorrect - one client may not be aware of changes that another client has already pushed to the server. If the adapter wants to use the server storage anchor, then the adapter needs to submit it back to the storage platform during the transfer of changes.

For the storage platform to support the anchor (either for local or remote storage), the storage platform must be aware of the changes that have been successfully applied to the server. These and only these changes can be included in the anchor. When enumerating changes, Sync Adapters use an acknowledgment interface to report which changes have been successfully applied. At the end of synchronization, adapters using submitted anchors must read a new anchor (which includes all successfully applied changes) and transfer them to their database machine.

Often, adapters have to store data related to the adapter, together with articles of interest to them, in the storage platform data warehouse. Common examples of such data are remote IDs and remote versions (timestamps). The synchronization service provides a mechanism for storing this data, and enumeration of changes provides a mechanism for receiving this additional data together with the returned changes. This in most cases eliminates the need for adapters to re-query the database.

(2) Application of changes

Applying changes allows Sync Adapters to apply the changes received from their database machine to local storage platforms. Adapters are implemented to convert changes to the storage platform schema. 24 illustrates a process by which storage platform API classes are generated from a storage platform diagram.

The main function of applying changes is to automatically detect conflicts. As with synchronization between Storage Platforms, a conflict is defined as two overlapping changes made without knowledge of each other. When adapters use Apply Changes, they must indicate the anchor with respect to which conflict detection is being carried out. Applying changes creates a conflict if an overlapping local change is detected that is not covered by the knowledge of the adapter. By analogy with enumeration of changes, adapters can use either stored or supplied anchors. Applying changes supports the efficient storage of metadata related to the adapter. Such data can be attached by the adapter to the applied changes and can be saved by the synchronization service. Data may be returned the next time the change is listed.

(3) Conflict Resolution

The conflict resolution mechanisms described above (registration and automatic resolution options) are also available for synchronization adapters. Sync adapters can define a conflict resolution strategy when applying changes. Once defined, conflicts can be transmitted to the specified conflict manipulator and resolved (if possible). Conflicts can also be logged. It is possible that the adapter might detect a conflict when trying to apply a local change to the database machine. In this case, the adapter may still transmit the conflict to the synchronization runtime to resolve it in accordance with the strategy. In addition, Synchronization Adapters may request that any conflicts detected by the synchronization service be sent back to them for processing. This is especially useful when the database engine is capable of storing or resolving conflicts.

b) adapter implementation

Although some “adapters” are just applications that use runtime interfaces, it is preferable that the adapters implement standard adapter interfaces. These interfaces allow synchronization management applications to request that the adapter synchronize according to this synchronization profile; canceled the current synchronization; and received a progress report (percentage of completion) for the current synchronization.

3. Security

The synchronization service seeks to change the security model implemented by the storage platform as little as possible. Instead of defining new synchronization rights, existing rights are used. In particular,

- Anyone who can read the Data Warehouse Article can list the changes for this article;

- Anyone who may record in a Data Warehouse Article may apply changes to this Article; and

- Anyone who can expand a Data Warehouse Article can associate synchronization metadata with this Article.

The synchronization service does not support protected authorship information. When changes are made to duplicate A by user U and sent to duplicate B, the fact that the change was originally made to A (or made U) is lost. If B forwards this change to duplicate C, this is done on behalf of B and not on behalf of A. This leads to the following restriction: if the duplicate is not trusted to make its own changes to the article, it cannot forward the changes made by others.

When initiating the synchronization service, this is done by the Application that manages the synchronization. The synchronization service imitates the identification of the CCP and performs all operations (both locally and remotely) on its behalf. As an example, note that user U cannot force the local synchronization service to retrieve changes from the remote storage platform for articles to which user U does not have read access.

4. Manageability

Controlling the distributed commonality of duplicates is a complex problem. The synchronization service can use the “sweep” algorithm to collect and distribute information about the status of duplicates. The properties of the sweeping algorithm ensure that information about all configured duplicates is ultimately collected and that bad (non-responding) duplicates are detected.

This community-wide control information is made available on every duplicate. Control tools can be run on a randomly selected duplicate to verify this control information and make administrative decisions. Any configuration changes must be made directly to the duplicates involved.

J. Interoperability with a traditional file system

According to the aforementioned storage platform of the present invention, according to at least some embodiments, is implemented as an integral part of a hardware-software interface system of a computer system. For example, a storage platform in accordance with the present invention can be implemented as an integral part of an operating system, for example, the Microsoft Windows family of operating systems. In this case, the storage platform API becomes part of the operating system API through which applications interact with the operating system. Thus, the storage platform becomes the means by which application programs store information in the operating system, and therefore, the data model based on the articles of the storage platform replaces the traditional file system of such an operating system. For example, being implemented in the Microsoft Windows family of operating systems, the storage platform can replace the NTFS file system implemented in this operating system. Currently, applications access NTFS file system services through the Win32 API, represented by the Windows operating system family.

However, recognizing that a complete replacement of the NTFS file system by the storage platform of the present invention will require recording of existing Win32-based applications, and that such recording may be undesirable, it would be preferable that the storage platform of the present invention provides some interoperability with existing file systems, such as NTFS. Therefore, in one embodiment of the present invention, the storage platform allows applications that rely on the Win32 programming model to access the contents of the data storage of both the storage platform and the traditional NTFS file system. For this, the storage platform uses a naming convention, which is a superset of Win32 naming conventions, to facilitate interoperability. In addition, the storage platform supports access to files and directories stored in the volume of the storage platform through the Win32 API.

Further details regarding this feature can be found in related applications incorporated herein by reference.

K. Storage Platform API

The storage platform contains an API that allows applications to access the features and capabilities of the storage platform discussed above and access articles stored in the data warehouse. This section describes one embodiment of a storage platform API for a storage platform of the present invention. Details regarding this feature can be found in related applications incorporated herein by reference, but for convenience, some of this information is summarized below.

According to FIG. 18, the Inclusion folder is an article that contains maintaining relationships with other Articles, and is equivalent to the general concept of a file system folder. Each Article is “contained” in at least one inclusion folder.

FIG. 19 illustrates a basic architecture of a storage platform API according to this embodiment. The storage platform API uses the SQLClient 1900 to communicate with the local data store 302 and can also use the SQLClient 1900 to communicate with remote data stores (eg, data warehouse 340). Local storage 302 can also communicate with remote storage 340 of data either using the RPG (distributed query processor) or through the storage platform synchronization service described above. The storage platform API 322 also acts as a bridging API for data warehouse notifications, sending application subscriptions to notification engine 332 and routing notifications to the application (e.g., application 350a, 350b or 350c), which is also described above. In one embodiment, the storage platform API 322 may also define a limited “provider” architecture, allowing it to access data in Microsoft Exchange and AD.

20 schematically illustrates various components of a storage platform API. The storage platform API consists of the following components: (1) data classes 2002, which represent the types of elements and articles of the storage platform, (2) the runtime structure 2004, which controls the storage of objects and provides support for the 2006 classes; and (3) 2008 tools that are used to generate CLR classes from storage platform schemas.

The class hierarchy resulting from this schema directly reflects the type hierarchy in this schema. As an example, consider the types of Articles defined in the "contacts" diagram shown in figa and figv.

Fig.22 illustrates the structure of the runtime in action. The runtime structure acts as follows:

1. The application 350a, 350b or 350c is associated with an article in the storage platform.

2. Structure 2004 creates an ItemContext object 2202 corresponding to the boundary entry and returns it to the application.

3. The application applies Find to this ItemContext to get a collection of Articles; the returned collection is conceptually a graph of 2204 objects (by virtue of relations).

4. The application modifies, deletes and inserts data.

5. The application saves the changes by calling the Update () method.

23 illustrates the execution of the “FindAll” operation.

24 illustrates the process by which storage platform API classes are generated from a storage platform diagram.

25 illustrates a diagram on which the file API is based. The storage platform API includes a namespace for file processing objects. This namespace is called System.Storage.Files. Data - members of classes in System.Storage.Files directly reflect the information stored in the storage platform storage; this information is “pushed” from file system objects or can be created internally using the Win32 API. The System.Storage.Files namespace has two classes: FileItem and DirectoryItem. The members of these classes and their methods can be imagined by looking at the diagram depicted in Fig.25. FileItem and DirectoryItem can only be read from the storage platform API. To change them, you need to use the Win32 API or classes in System.IO.

As for the API, a program interface (or just an interface) can be considered as any mechanism, process, protocol that allows one or more segments (s) of code to communicate or access functions provided by one or more other (s) segment (s) of code. Alternatively, a program interface can be considered as one or more mechanism (s), method (s), functional (x) call (s), module (s), object (s), etc. a component of a system capable of communicating with one or more mechanism (s), method (s), functional call (s), module (s), object (s), etc. other component (s). The term "code segment" in the previous sentence is intended to include one or more commands or lines of code and includes, for example, code modules, objects, subprograms, functions, etc. regardless of the terminology used or whether the code segments are separately compiled, or whether the code segments are provided as source, intermediate or object code, whether the code segments are used in the runtime system or in the process, or whether they are located on the same or different machines or distributed across multiple machines, or are the functionality represented by code segments implemented entirely in software, completely in hardware, or a combination of hardware and software mm means.

It is noteworthy that the program interface can be considered in general terms, as shown in figa or figv. Figa illustrates the interface Interface1 as a channel through which the first and second code segments are communicated. FIG. 30B illustrates an interface as containing interface objects I1 and I2 (which may or may not be part of the first and second code segments), which allows the first and second code segments of the system to communicate with each other through the medium M. FIG. 30B illustrates interface objects I1 and I2 can be considered as separate interfaces of the same system, and we can also assume that the objects I1 and I2 plus environment M form an interface. Although FIGS. 30A and 30B show a bi-directional stream and interfaces on both sides of a stream, certain implementations may have an information stream in only one direction (or may not have an information stream as described below) or may have an interface object on one side only. By way of example, but not limitation, terms such as the application programming interface (API), entry point, method, function, subroutine, remote procedure call, and component object model (COM) interface fall within the definition of a program interface.

Aspects of such a programming interface may include a method by which the first code segment transmits information (where “information” is used in its broadest sense and includes data, commands, queries, etc.) to the second code segment; a method by which a second code segment receives information; and the structure, sequence, syntax, organization, scheme, timing, and content of information. In this regard, the underlying transport medium itself may not be important for the operation of the interface, namely, whether the environment is wired or wireless or a combination of both, since the method of transporting information is determined by the interface. In certain situations, information may not be transmitted in one or both directions in the traditional sense, since information can be transferred through another mechanism (for example, information placed in a buffer, file, etc. separately from the information flow between code segments) or not exist, for example, when one code segment simply accesses the functions performed by the second code segment. Any or all of these aspects may be important in this situation, for example, depending on whether the code segments are part of the system in a loosely coupled or tightly coupled configuration, and therefore this list should be considered as an illustration, but not limitation.

This concept of a software interface is known to those skilled in the art and is explained in the foregoing detailed description of the invention. However, there are other possible ways of implementing the software interface, which, if not explicitly excluded, are covered by the claims at the end of this description of the invention. Such other methods may seem more sophisticated or complex than the simplified view of FIGS. 30A and 30B, but they nevertheless perform a similar function to achieve the same overall result. Some alternative implementations of the software interface are briefly described below.

Decomposition: Communication from one code segment to another can be carried out indirectly, by splitting the communication channel into several discrete communication channels. This is shown schematically in FIGS. 31A and 31B. It is shown that some interfaces can be described in terms of divisible sets of functions. Thus, the functions of the interface shown in FIGS. 30A and 30B can be decomposed to achieve the same result, like factoring the number 24 in the form 2, multiply by 2, multiply by 3, and multiply by 2. Accordingly, as shown in FIG. 31A, the function provided by the Interface1 interface can be decomposed to convert the interface communication channels into multiple interfaces Interface1A, Interface 1B, Interface 1C, etc. with the same result. As shown in FIG. 31B, the function provided by the I1 interface can be decomposed into a plurality of interfaces I1a, I1b, I1c, etc. with the same result. Similarly, the I2 interface of the second code segment, which receives information from the first code segment, can be decomposed into multiple interfaces I2a, I2b, I2c, etc. When decomposing, the number of interfaces included with the 1st code segment does not coincide with the number of interfaces included with the 2nd code segment. In any of the cases presented in FIGS. 31A and 31B, the meaning of the decomposition of the interfaces Interface 1 and I1 remains the same as for FIGS. 30A and 30B, respectively. The decomposition of interfaces can also obey the laws of associativity, commutativity, and other mathematical laws, so decomposition can be difficult to recognize. For example, the order of operations may not be important and, therefore, the function performed by the interface can be performed before reaching the interface, another piece of code or interface, or performed by a separate component of the system. In addition, it is obvious to a person skilled in the art that there are different ways of making calls to different functions that lead to the same result.

Overriding: In some cases, it may be possible to ignore, add or redefine certain aspects (for example, parameters) of the program interface, however, getting the desired result. This is illustrated in FIGS. 32A and 32B. For example, let the interface Interface1 shown in Fig. 30A include a function call Square (input, precision, output), a call that includes three parameters: input (input), precision (precision) and output (output), which issued by the 1st Code Segment to the 2nd Code Segment. If the average “accuracy” parameter is not important in this scenario, as shown in FIG. 32A, it can simply be ignored or even replaced with a meaningless (in this situation) parameter. You can also add an additional parameter that does not mean anything. In any case, the square function can be implemented if output is returned after input is squared by the second code segment. Precision can be a significant parameter for some subsequent in the execution chain or other part of the computing system; however, since it is understood that accuracy is not required for the narrow purpose of calculating the square, it can be replaced or ignored. For example, instead of transmitting the actual accuracy value, you can transmit a meaningless value, such as a date of birth, and this will not adversely affect the result. Similarly, as shown in FIG. 32A, interface I1 is replaced by interface I1 ′, redefined to ignore or add parameters to the interface. Interface I2 can likewise be redefined as interface I2 ', redefined to ignore optional parameters or parameters that can be processed elsewhere. The point is that in some cases, the program interface may include aspects, for example, parameters that are not needed for some purposes, and therefore can be ignored or redefined or processed elsewhere for other purposes.

Embedded coding: It may also be possible to merge some or all of the functionality of two separate code modules, resulting in a “interface” between them changing shape. For example, the function depicted in FIGS. 30A and 30B can be converted to the function depicted in FIGS. 33A and 33B, respectively. In FIG. 33A, the previous 1st and 2nd Code Segments shown in FIG. 30A are merged into a module containing both of them. In this case, the code segments can still communicate with each other, but the interface can be adapted to a form that is more suitable for a single module. So, for example, the formal Call and Return operators may no longer be needed, but similar processing or response (s) in accordance with Interface1 can still work. Similarly, as shown in FIG. 33B, the I2 interface shown in FIG. 30B can partially (or completely) be written inside the I1 interface to form the I1 ”interface. It is shown that the I2 interface is divided into I2a and I2b, and the interface part I2a is encoded together with the I1 interface to form the I1 interface. ” As a specific example, suppose that the I1 interface shown in FIG. 30B makes a function call square (input, output), which is received by the I2 interface, which, after processing the value transmitted from input (to square it) with a second code segment, passes the result of squaring back with output. In this case, the processing performed by the second code segment (squaring input) can be performed by the first code segment without calling the interface.

Disconnection: Communication from one code segment to another can be carried out indirectly by splitting the communication channel into several discrete communication channels. This is schematically depicted in FIGS. 34A and 34B. As shown in FIG. 34A, one or more pieces of middleware (Disconnect Interface (s) because they separate the functionality and / or functions of the interface from the original interface) are provided for converting communication channels on the first interface, Interface1, for matching them with another interface, in this case, interfaces Interface 2A, Interface 2B and Interface 2C. This can happen, for example, when the database of applications designed to communicate, say, with the operating system in accordance with the Interface1 protocol is installed, but then the operating system has changed to use a different interface, in this case, the Interface2A, Interface2B, and Interface2C interfaces. The point is that the original interface used by the 2nd Code Segment has changed, as a result of which it is no longer compatible with the interface used by the 1st Code Segment, and therefore, an intermediary is used to ensure compatibility of the old and new interfaces. Similarly, as shown in FIG. 34B, a third code segment can be entered with the DI1 disconnect interface to receive information from the I1 interface and with the DI2 disconnect interface to transfer the interface functions, for example, the I2a and I2b interfaces, tuned to work with DI2, but providing one same functional result. Similarly, DI1 and DI2 can work together to translate the functionality of the I1 and I2 interfaces shown in FIG. 30B into a new operating system, providing the same or similar functional result.

Rewriting: Another possible option is to dynamically rewrite the code to replace the functionality of the interface with some other ones, which nevertheless give the same general result. For example, there may be a system in which a segment of code represented in an intermediate language (for example, Microsoft IL, Java ByteCode, etc.) is delivered to an operational compiler (JIT) or interpreter in a runtime environment (for example, provided by a .Net structure, Java runtime or others with similar types of runtime). The JIT compiler can be written to dynamically convert transfers from the 1st Code Segment to the 2nd Code Segment, i.e. coordinate them with another interface, which may be needed by the 2nd Code Segment (either the source or another 2nd Code Segment). This is shown in FIGS. 35A and 35B. 35A, this approach is similar to the above disconnect scenario. This can happen, for example, when the installed application base is able to communicate with the operating system in accordance with the Interface 1 protocol, but then the operating system is changed to use a different interface. The JIT compiler can be used to quickly coordinate communication channels from installed base applications to the new operating system interface. 35B, this dynamic rewrite approach of the interface (s) can be applied to dynamically decompose or otherwise modify the interface (s).

Note also that the above scenarios to achieve the same or similar result as the interface, through alternative embodiments, can also be combined in various ways, sequentially and / or in parallel or with other intermediate codes. Thus, the alternative embodiments presented above are not mutually exclusive and can be mixed, matched, and combined to create scenarios that are identical or similar to the common scenarios shown in FIGS. 30A and 30B. It should also be noted that in most cases of programming conflicts, there are other similar ways to achieve the same or similar interface functionality, which are not described here, but nevertheless are presented by the essence and scope of the invention, i.e. at least in part, the functionality provided by the interface and the advantageous results provided by the interface form the basis of the interface.

III. Extensions and Inheritance

The main idea of the present invention is to use Articles, which to some extent model objects of practical application with complex structures, behaviors and operations described by circuits and implemented by a hardware-software interface system. In order to provide rich functionality for distinguishing subtypes and according to various embodiments of the present invention, a hardware-software interface system (which we will refer to simply as WinFS for convenience) can provide a mechanism by which Articles (and types of Articles) can be expanded using "Extensions". Extensions provide additional data structures (Properties, Relations, etc.) to existing structures of Article types.

As discussed above (and specifically discussed in Sections II.E.6. (A) and II.F.3), although it is intended to provide a storage platform with an initial set of circuits, according to at least some embodiments, the storage platform allows consumers to including independent software vendors (NPPs), create new schemes (i.e. new types of Articles and Nested Element). Since the type of the Article or the type of the Nested element specified by the initial set of storage platform schemes may not exactly meet the needs of the NPP application, it is necessary to allow the NPP to create the types they need. This is provided by the concept of Extensions. Extensions are strongly typed instances, but (a) they cannot exist independently and (b) they must be attached to an Article or Attached Element. In addition, in addition to addressing the need for extensibility schemes, Extensions are also designed to address issues of “multiplicity”. Because in some embodiments, the storage platform may not support multiple inheritance or overlapping subtypes, applications can use Extensions as a way to model instances of overlapping types (for example, a Document can be a “legal document” and at the same time a “protected document”).

A. Type system

In various embodiments of the present invention, the WinFS type system provides a mechanism for defining data structures. A 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 logically groups many types and other elements of the WinFS schema. WinFS schemas can be declared using the "schema definition language" (SDL), which can use the XML format. The following is an example of a possible schema definition:

<Schema Namespace = "System.Storage">

Type definitions

</Schema>

WinFS schemas also serve as blocks for type checking. WinFS defines several system circuits that enable self-tuning of the system. There is a System.Storage schema namespace that contains type declarations for the root types in the system, and a System.Storage.WinFS schema namespace that declares all primitive scalar types in the system.

The WinFS type system declares many simple scalar types. These types are used as the most primitive building blocks for all other types in the WinFS type system. These types are declared in the System.Storage.WinFS schema namespace. The following table defines many primitive types.

WinFS Type Managed SQL Type CLR Type Description String Sqlstring String Unicode data of variable length with a maximum length of 2 ^ 31 characters. The length can be fixed from 1 to 4000 characters or unlimited using the keyword “max”. Binary Sqlbinary Byte [] Variable-length binary data with a maximum length of 2 ^ 32 characters. The length can be fixed from 1 to 8000 bytes or unlimited using the keyword “max”. Boolean SqlBoolean Boolean Resettable boolean value Byte Sqlbyte Byte Unsigned Byte Int16 SqlInt16 Int16 Integer data from -2 ^ 15 (-32,768) to 2 ^ 15 - 1 (32,767). Int32 SqlInt32 Int32 Integer data (integer) from -2 ^ 31 (-2,147,483,648) to 2 ^ 31 - 1 (2,147,483,647). Int64 SqlInt64 Int64 Integer data (integer) from -2 ^ 63 (-9223372036854775808) to 2 ^ 63-1 (9223372036854775807). Single SqlSingle Single Floating-precision numeric data from -1.79E + 308 to 1.79E + 308 Double SqlDouble Double Floating-precision numeric data from -3.40E + 38 to 3.40E + 38 Decimal SqlDecimal Decimal SQLDecimal has a wider range of values than the CLR Decimal type.
In storage, accuracy is always 28 digits and scale is 0. Datetime SqlDateTime Datetime Time and date data from January 1, 1753 to December 31, 9999, with an accuracy of three hundredths of a second or 3.33 milliseconds. Guid Sqlguid Guid Globally Unique Identifier (GUID). Xml SqlXmlReader Xmlreader For breakpoint B, WinFS.Xml will be mapped to type “String”. At checkpoint C, support for true XML data types is expected. Stream TBD TBD A type of binary data that, using a file stream, reserves storage for efficient access. This type will be supported at checkpoint C.

The WinFS enumeration is a scalar type that declares a set of named constants, called a list of values. An enumeration type can be used anywhere where a scalar type can be used. The following is an example of a declaration of an enumeration:

<Enumeration Name = "Gender">

<Value Name = "Male" />

<Value Name = "Female" />

</Enumeration>

Enum values have a base value of 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 many properties. The property is a field of the type member and is specified by the name and type. A Property type can be either a scalar (including an enumeration type) or another complex type. A WinFS type that can be used as a type of a Property is called a nested type. An instance of a nested type can exist only as a value of Properties of a complex type of WinFS — an instance is nested in an instance of a complex type. A nested type is declared using the NestedType element of the schema. The following are examples of valid type declarations:

<NestedType Name = "Address" BaseType = "System.Storage.NestedObject">

<Property Name = "Street" Type = "WinFS.String" Size = "256"

Nullable = "false" />

<Property Name = "City" Type = "WinFS.String" Size = "256"

Nullable = "false" />

<Property Name = "State" Type = "WinFS.String" Size = "256"

Nullable = "false" />

<Property Name = "Country" Type = "WinFSString" Size = "256"

Nullable = "false" />

</NestedType>

<ItemType Name = "Person" BaseType = "System.Storage.Item">

<Property Name = "Name" Type = "WinFS.String" Size = "256"

Nullable = "false" />

<Property Name = "Age" Type = "WinFS.Int32"

Nullable = "false" Default = "1" />

<Property Name = "Picture" Type = "WinFS.Binary" Size = "max" />

<Property Name = "Addresses" Type = "MultiSet" MultiSetOfType = "Address" />

</ItemType>

For properties of type String (string) and Binary (binary), the Size attribute must be set. This attribute defines the maximum size of the values contained in the Property. A property can optionally declare a nullability restriction using the Nullable attribute. A false value for this attribute indicates that the application should provide a value when instantiating the type. Another optional attribute of the Property is the Default attribute, which defines the default value for the Property. This value will be assigned to the Property at the time of instance creation, if the application did not provide it.

The “address” property in the above example is of type MultiSet. A property of type MultiSet is also called a multi-valued property. In the example, MultiSet contains many instances of type Address. MultiSet is like a collection. It can contain zero or more instances of a complex type. The instance type in MultiSet must be a complex nested type. The MultiSet type does not support instances of scalar WinFS types (including enumerated types). Properties of type MultiSet cannot be nullable and cannot have default values.

WinFS supports single type inheritance. All types of WinFS must inherit from one and only one type of WinFS. The inherited type is called the derived type, and the type from which this type is derived is called the base type. The base type is the BaseType attribute of the WinFS type declaration elements. Let type A be derived from the base type B, which, in turn, is derived from type C. Type C is the ancestor type for types A and B. Type A is a descendant type for types B and C. The data instance stored in WinFS is always an instance of a unit type. However, you can treat this data instance as an instance of a plurality of types containing a type and all its ancestor types. For a data instance that is an instance of such a plurality of types, a type that is not the ancestor of any other type in the set is called the last derived type. A homogeneous data instance is an instance of exactly one of the last derived type. In general, the last derived type of the same type of element will be called its type. A derived type inherits all the properties declared in its base type. A derived type can declare new properties, but cannot override properties specified in the base type. 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 a data model is due to the ability to substitute inherited types. Consider the following example:

<NestedType Name = "Name" BaseType = "System.Storage.NestedObject">

<Property Name = "FirstName" Type = "WinFS.String" />

<Property Name = "LastName" Type = "WinFS.String" />

</Nestedype>

<NestedType Name = "NameWithMiddleInitial" BaseType = "Name">

<Property Name = "MiddleInitial" Type = “WinFS.String" />

</NestedType>

<NestedType Name = "Person" BaseType = "System.Storage.Item">

<Property Name = "RealName" Type = "Name" />

<Property Name = "OtherNames" Type = "MultiSet" MultiSetOfType = "Name" />

</NestedType>

In the above example, the Person type has a RealName Property of type Name and a OtherNames Property, which is a set of Name types. It is usually required that the RealName Property has only instances of the type Name. However, due to inheritance, the RealName value can be unambiguous, since the Name type is one of the ancestors of the last derived type of this element. Therefore, an instance of NameWithMiddleInitial may be the value of the RealName Property.

The same rule applies to many properties. The OtherNames property contains many elements. For each instance of the same type that is a member of this set, the last derived type of this instance must have Name as one of its ancestors. Therefore, some of the instances in the OtherNames set can be instances of the Name type, while others can be instances of the NameWithMiddleInitial type.

Inheritance also makes it easy to query, since all instances of a particular type can be found in WinFS. When searching for all instances of a type, the query engine will also return all instances whose last derived types are descendants of this type. However, these operations are only supported for Articles, Extensions, and Relationship Types (not Property Types). For nested types (for example, Nested elements, Properties, or complex property types), the operation is supported only for instances contained in the single property "multiset".

B. Type families

In essence, the WinFS type system defines four different type families:

- Nested Element Types (for example, Nested Types or Property Types);

- Types of Articles;

- Types of relationships;

- Types of extensions.

Each type family has a separate set of properties and its use in the WinFS type system. The System.Storage schema namespace declares four types that serve as root types for each type family. The following sections detail type families.

1. Types of nested element

Unlike other WinFS type families, nested types can be used as property types of complex WinFS types. Instances of a nested type can only be nested in an instance of another complex type. However, instances of nested types cannot be queried globally, i.e. applications cannot compose a simple query that returns all instances of a given nested type in WinFS storage.

2. Article types

A WinFS article is an instance of a type whose ancestor is the System.Storage.Item type. This type is a complex type that is the root of the Article type family. System.Storage.Item declares a Property NameItemId of type Guid. This is a special property of the article, which serves as the main key of the Article. The value of this Property is guaranteed to be unique to Articles in this WinFS repository. This property is non-nullable and must be assigned by the application when creating an instance of the Article type. The ItemId property is also immutable - it should never be changed and should not be reused.

The query engine can return instances of this type of Article in the WinFS repository. This query can return all instances of a type and all descendant types of this type. The following describes the main role that articles play in the semantics of WinFS system operations.

3. Relationship types

Types of Relationships ensure the existence of Relations between Articles. WinFS relationship types describe binary relationships, where one Article plays the role of the source and another Article plays the role of the goal. A relation is an instance of a type whose ancestor is the type System.Storage.Relationship. This type is the root of the relationship Type hierarchy.

The System.Storage.Relationship type declares the following properties:

- SourceItemId - ItemId of the Article, which is the source of the Instance of the relationship;

- RelationshipId - unique identifier of the Relationship in relation to the original article; a pair (SourceItemId, RelationshipId) forms the master key for Relation Types in WinFS;

- TargetItemId - ItemId of the relationship target;

- Mode - one of the 3 possible modes of Relationship Instances: holding, embedding, or reference;

- Name - contains the name of the Relationship for maintenance relationships;

- IsHidden - a boolean attribute that applications can use optionally to filter Relations that do not need to be displayed;

The values of the SourceItemId, RelationshipId, TargetItemId, and Mode properties are immutable. They are assigned at the time of creating the Relationship Instance and are not subject to change.

A Relationship type is declared as a complex type with the following additional restrictions:

- An indication of the source and target endpoints: each endpoint indicates the name and type of the Article to which it relates;

- The valid modes of instances of Relation Type: An instance of a relation cannot have a value for the Mode Property, which is not permitted in the Relationship declaration.

The following is an example of a Relationship declaration:

<RelationshipType Name = "DocumentAuthor"

BaseType = "System.Storage.Relationship"

AllowsHolding = "true"

AllowsEmbedding = "false"

AllowsReference = "true">

<Source Name = "Document" Type = "Core.Document" />

<Target Name = "Author" Type = "Core.Contact" />

<Property Name = "Role" Type = "WinFS.String" />

<Property Name = "DisplayName" Type = "WinFS.String" />

</RelationshipType>

The DocumentAuthor relationship (“document author") is declared with instance restrictions for maintenance and reference modes. This means that an instance of a DocumentAuthor Relationship can have instances with a value of Mode = ”Reference” or Mode = ”Holding”. Instances with a value of Mode = ”Embedding” are not allowed.

The relationship declares the source endpoint under the name “Document” with the type of the Article “Core.Document” and the target endpoint of the type “Core.Contact”. A relationship also declares two additional properties. Relationship instances are subject to storage and access separately from the Article. All instances of the Relationship Type are accessible from the global extension view. You can create a query that will return all instances of this type of Extension.

For this Article, all Relations for which the Article is the source can be listed based on the Relationship SourceItemId Property. Similarly for this Article, all Relations in the same repository for which the Article is the target can be listed using the Relationship TargetItemId Property.

a) Semantics of relationships

The following sections describe the semantics of the various relationship instance modes:

Maintaining Relationships: Maintaining relationships are used to model the life time management of targeted articles based on reference counts. An Article may be a starting endpoint for zero or more Relations with Articles. An article that is not an embedded article may be the goal of one or more maintenance relationships. The target article must be in the same repository as the Relationship Instance.

Maintenance relationships implement life-time management of the target endpoint. Creating an instance of the maintenance relationship and the Article for which it is the goal is an atomic operation. You can create additional instances of the maintenance relationship for which the same Article is the goal. When you delete the last instance of a maintenance relationship with this Article as the target endpoint, the target article is also subject to deletion.

The types of Endpoint Articles specified in the Relationship declaration are implemented when the Relationship is instantiated. The types of Endpoint Articles are not subject to change after the Relationship is established.

Maintaining relationships play a key role in shaping the WinFS Article namespace. All maintenance relationships are involved in the namespace declaration. The "name" property in the Relationship declaration sets the name of the target article relative to the original article. This relative name is unique to all maintenance relationships for which this Article is a source and cannot be reset. An ordered list of these relative names from the root Article to this Article forms the full name of the Article.

Maintenance relationships form an oriented acyclic graph (OAS). When creating a maintenance relationship, the system ensures that the loop is not created, and thus ensures that the WinFS Article namespace forms an OAS. For more information on the WinFS namespace and article paths, see the “WinFS Namespace” description.

Embedding Relationships: Embedding Relationships Model the Concept of Exceptional Time Management of the Target Article. They implement the concept of composite articles. Creating an instance of the implementation relationship and the Article, which is its purpose, is an atomic operation. An article can be a source of zero or more embedding relationships. However, an Article may be the goal of one and only one implementation relationship. An article that is the goal of an implementation relationship cannot be the goal of a maintenance relationship. The target article must be in the same repository as the Relationship Instance.

The types of Endpoint Articles specified in the Relationship declaration are implemented when the Relationship is instantiated. Once a Relationship is established, the types of Article-endpoints are not subject to change. Deployment relationships do not participate in the WinFS namespace. The value of the Name property of the injection relationship must be null.

Link relationships: Link relationships do not control the lifetime of the article to which they link. Link relationships do not guarantee the existence of a goal, nor do they guarantee the type of goal that is specified in the Relationship declaration. This means that the link relationship may hang. In addition, the link relationship may link to Articles in other WinFS repositories.

In WinFS, link relationships will be used to model most Relationships between Articles without life time management. Since the existence of the goal is not guaranteed, the link relation is convenient for modeling loosely coupled Relationships. The link relationship can be used for target articles in other WinFS repositories, including repositories on other machines. Deployment relationships do not participate in the WinFS namespace. The value of the Name property of the injection relationship must be null.

b) Rules and restrictions for relations

The following additional rules and restrictions apply to Relations:

- The article should be the goal of (exactly one implementation relationship) or (one or more maintenance relationships). The one exception is the root Article. An article may be the goal of zero or more link relationships;

- An article that is the goal of an implementation relationship cannot be the source of a maintenance relationship. It can be a source of link relationships;

- An article cannot be the source of a maintenance relationship if it is promoted from a file. It can be a source of embedding relationships and link relationships;

- An article advanced from a file cannot be the goal of an embedding relationship.

When Relation Type A is derived from the underlying Relation Type B, the following rules apply:

- Relation type A may further limit endpoint types. Endpoint types must be subtypes of the corresponding endpoint type in base relation B. If the endpoint is further restricted, a new endpoint name must be declared. If the endpoint is not limited, then the description of the endpoint is optional;

- Relation type A may further limit the allowed instance modes declared in the base relation. A limited set of instance modes must be a subset of the set of base types or permitted instance types;

- Endpoint names are treated as Property names: they cannot match the name of the Property or the name of the endpoint of the type or its base type;

- The source and target elements are optional if the corresponding type of endpoint is not additionally limited by the derived Relationship.

The following is an example of declaring a Relationship Type that is derived from the DocumentAuthor Relationship defined above:

<RelationshipType Name = "LegalDocumentAuthor"

BaseType = "Core.DocumentAuthor"

AllowsHolding = "false"

AllowsEmbedding = "false"

AllowsReference = "true">

<Source Name = "LegalDocument" Type = "Legal.Document" />

<Property Name = "CaseNumber" Type = "WinFS.String" />

</RelationshipType>

The LegalDocumentAuthor relationship further restricts the source endpoint, but not the destination endpoint. The source endpoint type is Legal.Document, which derives from Core.Document.

In this case, the target endpoint is not subject to further restriction, therefore, the target element is omitted.

The relationship also imposes additional restrictions on instance modes. It prohibits maintenance mode, so the only allowed mode is links.

4. Extension types

The WinFS extension is an instance of a type whose ancestor is the System.Storage.Extension type. This type is a complex type that is the root of the Extension Type family.

System.Storage.Extension defines two properties:

- ItemId - Article ID for the article with which the Extension is associated;

- ExtensionId is a unique identifier for the Extension in relation to the article ID. A pair (ItemId, ExtensionId) uniquely identifies an Extension Instance.

The following restrictions apply to Extension Types:

- Instances of the type of extension may exist independently of the Article; An instance of the Article type with the same ItemId as the ItemId of the Extension must exist in the repository before creating the Instance of the extension type. An extension cannot be created if an article with this ItemId does not exist. When deleting an Article, all Extensions with the same ItemId are deleted;

- At most one instance of this last derived Extension Type can be associated with a single article;

- Extensions cannot be the sources and goals of Relations.

There are no restrictions on the types of Extensions that can be associated with this type of Article. Any Type of extension is allowed to extend any type of Article. If many instances of various Extension Types are attached to an Article, they are independent of each other with respect to structure and behavior. Extension instances must be stored and accessed separately from the article. All Extension Type Instances are available from the global extension view. You can create a query that will return all instances of this type of Extension regardless of the type of Article with which they are associated. The ItemId Extensions indicates which Article they belong to, and can be used to retrieve the corresponding Article object from the global Article view. In addition, for this Article, all Extension Instances associated with the Article can be listed using the ItemId Properties of the Extension.

C. Advanced Features

In several embodiments of the present invention, the hardware-software interface system uses Extensions and Inheritance to formalize the relationship between the various Articles and thereby improve the ability to query a collection of Articles.

1. Inheritance

Fig. 36 illustrates a number of related Articles and a subset of their Relations. Article 3502 “document” and article 3604 “contact” are directly related by the assigned relation 3606, which in this case is the “relation of authorship”, i.e. Contact 3604 is the “author” of Document 3602. In this example, article 3622 “image”, article 36724 “music” and article 3626 “special” inherit from article 3602 “document” because the type of Article is a subtype of the type of Article “document”. Similarly, article 3642 “person” and article 3644 “organization” inherit from article 3604 “contact”. In several embodiments of the present invention, these inheriting Articles (Image 3622, Music 3624, Special 3626, Person 3642, and Organization 3644) not only inherit the properties of the respective parent articles (Document 3602 and Contact 3604), but also inherit the assigned Relationship between these parent Articles. For example, Image 3622 inherits a 3662 relationship with Contact 3604, a 3664 relationship with Person 3642, and a 3666 relationship with Organization 3644. A similar set of Relationships are also inherited by each of the other Articles displayed.

However, it is important to note that inheritance is not automatic and does not occur in every context. For example, attributes that describe when a type can be inherited (i.e., inheritance controls) are themselves not inherited. Inheritance parameters are supported and regulated by the system of hardware-software interface.

2. Extensions

Figa illustrates the disadvantages of the standard allocation of subtypes of Articles for specific purposes. In this drawing, Contact is available for four applications, Pr1, Pr2, PrX and PrY. Pr1 and Pr2 access the standard Contact, but each of PrX and PrY needs an extended contact object (with the addition of additional fields), and so they display Contact 'and Contact', each of which inherits from Contact. However, the problem is that there are three new instances of the original Article: “contact” - one in Contact, one in Contact 'and one in Contact.' '

A partial solution to this problem, illustrated in FIG. 37B, is to expand the properties of the Contact to include the fields required by the application that requires them. In this case, the Contact expands to include the Additional fields required for the PRX. However, the direct expansion of the Article fields, for example, “contact”, can be done only once, and thus PrY cannot use this method.

In one embodiment of the present invention, a more universal solution is to expand the Contact using the Extension, which is different and separated from the Contact itself, as shown in figs. Thus, PRX can expand the Contact to include its Additional PRX fields, while PRY can also separately expand the Contact to include its Additional PRY fields. These Extensions themselves are searched and requested, and thus these Extensions provide a form of multiplicity for the hardware-software interface system.

IV. Conclusion

According to the foregoing, the present invention relates to a storage platform for organizing, retrieving and sharing data. The storage platform of the present invention continues and extends the concept of storing data beyond existing file systems and database systems, and is intended to be a repository for all types of data, including structured, unstructured or partially structured data, such as relational (tabular) data, XML and a new data form called Articles. Through a common storage framework and schematized data, the storage platform of the present invention provides more efficient application development for consumers, IT professionals and entrepreneurs. It provides a rich and extensible application programming interface that not only makes available the capabilities inherent in its data model, but also extends and extends the existing file system and data access methods. It is understood that changes can be made to the above described embodiments without going beyond the scope of the invention. Accordingly, the present invention is not limited to the specific disclosed embodiments, but is intended to cover all modifications that meet the essence and scope of the invention defined in the attached claims.

From the foregoing description, it is apparent that various systems, methods, and aspects of the present invention can be fully or partially implemented as program code (i.e., instructions). This program code may be stored in a computer-readable medium, such as a magnetic, electrical, or optical storage medium, including, without limitation, a floppy disk, CD-ROM, CD-RW, DVD-ROM, DVD-RAM, magnetic tape, flash memory, a hard disk, or any other computer-readable medium in which, when a program code is loaded into a machine and executed by a machine, such as a computer or server, the machine becomes a device for practicing the invention. The present invention can also be implemented in the form of program code that is transmitted over a certain transmission medium, for example, via electric wires or cables, through optical fibers, through a network, including the Internet and an intranet, or by any other form of transmission, in which, when receiving and downloading software, code into the machine and its execution by a machine, such as a computer, the machine becomes a device for the practical implementation of the invention. Being implemented on a general-purpose processor, the program code is combined with the processor to provide a unique device that acts similarly to specific logic circuits.

Claims (16)

1. In a storage platform containing a data warehouse that implements a data model that represents information through discrete stored blocks, and a hardware-software interface system, a method for setting up a discrete stored block of information implemented by a storage platform, comprising the following steps:
access to the data warehouse to determine the source discrete stored block of information having a typed structure and a first identifier;
determining the extension characteristic of the desired additional data structure;
determining an extension instance having an extension type, wherein the extension instance is identified by the first identifier and the extension identifier, is stored and accessible separately from the discrete stored information block; and
creating a customized discrete stored information block in a data warehouse that is stored and accessible separately from a discrete stored information block, wherein creating a customized discrete stored information block comprises attaching an extension instance having an extension type to a discrete stored information block. 2. The method according to claim 1, wherein said extension cannot exist independently of said typed structure of said configured discrete stored information block. 3. The method according to claim 1, additionally containing the following steps:
defining a set of extensions, each extension being characteristic of a desired additional data structure; and
attaching extensions to the typed structure of the original discrete stored block of information. 4. The method according to claim 3, in which the set of extensions is used to model overlapping instances of types. 5. The method according to claim 1, in which the discrete stored block of information is an article. 6. The method according to claim 1, in which the discrete stored block of information is a nested element. 7. The method according to claim 1, in which the extension represents a specific property. 8. The method according to claim 1, in which the extension represents a specific ratio. 9. A hardware-software interface system for manipulating a plurality of discrete stored blocks of information by accessing a storage platform comprising a data store implementing a data model that represents information through discrete stored blocks, said system comprising
a processor configured to execute instructions executed by the processor;
a storage device connected with the possibility of exchanging data with the processor, storing instructions executed by the processor, which, when executed by the processor, implement a subsystem for
determining the source discrete stored blocks of information having a typed structure and corresponding first identifiers;
determining at least one type of extension specific to the desired additional data structure;
determining at least one extension instance of at least one type of extension, wherein at least one extension instance is identified by a corresponding first identifier of a discrete stored information block to which at least one extension instance is attached, and a corresponding extension identifier, wherein at least one instance of the extension is stored and accessible separately from discrete stored blocks of information; and
attaching extensions to the typed structure of the source discrete stored blocks of information and
creating customized discrete stored information blocks in a storage platform that are stored and accessible separately from discrete stored information blocks, the creation of customized discrete stored information blocks comprising attaching at least one extension instance of at least one type of extension to discrete stored information blocks. 10. The system of the hardware-software interface according to claim 9, in which at least one extension cannot exist regardless of the typed structure of the configured discrete stored information blocks. 11. The hardware-software interface system according to claim 9, further comprising a subsystem for determining a plurality of extensions, each extension being characteristic of a desired additional data structure; and attaching extensions to the typed structure of the source discrete stored blocks of information. 12. The hardware-software interface system according to claim 9, in which the discrete stored blocks of information are articles. 13. The hardware-software interface system according to claim 9, in which the discrete stored blocks of information are nested elements. 14. The hardware-software interface system of claim 9, wherein the extensions represent a specific property. 15. The system of the hardware-software interface according to claim 9, in which the extensions represent a certain relationship. 16. A computer-readable medium containing computer-readable instructions that, when executed by a processor, instructs the storage platform:
access the data warehouse to determine the original discrete stored block of information having a typed structure and a first identifier;
determine at least a first extension type and a second extension type, wherein the first extension type is characteristic of a first desired additional data structure required by the first application, and the second extension type is characteristic of a second desired additional data structure required by the second application;
determining a first extension instance of a first extension type, wherein the first extension instance is identified by a first identifier and a first extension identifier;
define a second extension instance of the second extension type, wherein the second extension instance is identified by the first identifier and the second extension identifier, wherein the first extension instance and the second extension instance are stored and accessible separately from the discrete stored information block; and
creating at least two tuned discrete stored information blocks that are stored and accessible separately from the discrete stored information block, the creation of at least two tuned discrete stored information blocks comprises attaching a first extension instance of the first extension type to a discrete stored information block to create the first tuned discrete stored information block and, separately, attaching a second extension instance of the second extension type I am going to a discrete stored information block to create a customized discrete stored information block.

Images