WO2017061902A1 - System and method for processing requests in projects - Google Patents

Abstract

Claimed is a computer-embedded method for processing business data, which includes storing data in SPO (subject-predicate-object) triple format in a plurality of databases; using a data persistence layer to connect to several databases, wherein data consists of rules and an axiom and axioms represent user data; the rules and axioms are stored in SPO format; at least one ontology, representing a combination of at least several rules and axioms, said combination representing a certain interpretation of the data; a data persistence layer which allows the user to work with data stored in different databases simultaneously; converting user data according to a context provided by a business application, working with defined objects and ontologies, wherein a context is defined by a concrete ontology; carrying out operations according to triggers determined by rules; generating new data in the same context; processing requests for data conversion; and displaying data to the user.

Description

 SYSTEM AND METHOD OF PROCESSING REQUEST FOR PROJECTS

The present invention relates to the management of business processes, and more specifically, to a unified architecture and a single syntactic structure for presenting business process data and managing and monitoring business processes. Business process management is an increasingly popular area of research and modern software development. To date, there is no unified mechanism for the convenient presentation of data and the context of business process data. Typically, most software vendors provide one piece of the puzzle, such as CRM (Customer Relationship Management), invoice tracking, order tracking, Gantt chart software. Many suppliers in this area are relatively small companies and, as a rule, a software product grows out of their own initial need to solve a specific problem, and the product is often associated with a specific view of the supplier on the world.

 For typical business enterprises, it is necessary to buy and integrate several pieces of software, for example, project management software usually does not "talk" with accounting software. Customer Relationship Management software does not talk with spare parts ordering software and so on. In addition, most of these software packages have limited ability to change or change the way data is presented to the user. Often, relational databases are used as the engine with the resulting limited ability to manually add fields to the database. However, for most end users, the need to change the “direct” presentation of the data is a real challenge and often requires hiring consultants or additional IT staff.

 Semantic network, see FIG. 1 includes XML standards and tools, XML schemas, RDF, RDF schemas, and OWL, which are organized on the Semantic Web Stack. OWL Web Ontology Language Description describes the functionality and relationship of each of these components of the semantic network stack

 XML provides an elementary syntax for the structure of content within documents, and associates non-semantic with the meaning of the content contained in them.

 An XML schema is a language for providing and restricting the structure and content of elements contained in XML documents.

 RDF is a simple data model description language that refers to objects ("resources") and their relationships. An RDF-based model can be represented in XML syntax.

The RDF schema extends RDF and is a dictionary for describing properties and classes of RDF-based resources with the semantics of generalized hierarchies of such properties and classes.

 OWL (see FIG. 2) illustrates an additional vocabulary for describing properties and classes: in particular, relationships between classes (for example, non-intersection), cardinality (for example, "exactly one"), equality, a rich set of properties, characteristics of properties (for example, symmetry) and enumerated classes.

SUBSTITUTE SHEET (RULE 26) Accordingly, a unified architecture is needed that would allow business enterprises to easily present the context for business analysis in business processes that occurs within the enterprise and provide an easy mechanism for interaction between users, representing various aspects of the business and stored data in the business model.

In the drawings:

FIG. 1 illustrates a semantic network stack.

FIG. 2. illustrates a fragment of the semantic network, which includes a family of descriptive languages, including XML, XML Schema, RDF, RDF Schema, OWL.

FIG. 3 illustrates an RDF graph of a triple.

FIG. 4 illustrates the application of semantic network concepts in the architecture described here.

FIG. 5 illustrates a fragment of a semantic network using the Comindware language. FIG. 6 illustrates an exemplary system architecture.

FIG. 7 illustrates an example of various business applications used in various departments of a company in an exemplary embodiment.

FIG. 8 illustrates a data processing algorithm according to one embodiment of the invention.

FIG. 9 illustrates the details of the algorithm for working with axioms and rules.

FIG. 10 illustrates various operations with axioms, including conjunctions and disjunctions.

 FIG. 11 illustrates an example of the application of the principles described herein.

 FIG. 12 illustrates a diagram of a typical computer system that may be used to practice the invention.

FIG. 13 shows a primary data source in models.

FIG. 14 shows the logical organization of a database module.

FIG. 15 shows the basic elements for client-side database management.

FIG. 16 demonstrates ontologies.

FIG. 17 and FIG. 18 show various ways of partitioning databases.

SUBSTITUTE SHEET (RULE 26) Below are two examples of representing RDF graphs in XML format (which is often most convenient for computer processing) and in the form of тро-triples or N3 (which are used in this approach and which are most convenient for human understanding).

XML syntax:

<? xml version = "1.0"?>

<rdf: RDF xmlns: rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns: dc = "http://purl.org/dc/elements/ll / "xmlns: exterms =" http://www.example.org/terms/ ">

<rdf: Description rdf: about = "http://www.example.org/index.html">

<exterms: creation-date> August 16, 1999 </ exterms: creation-date>

</ rdf: Description>

<rdf: Description rdf: about = "http: // www. example.org/index.html">

<dc: language> en </ dc: language>

</ rdf: Description>

</ rdf: RDF>

N3-CHHT3KCHC will look like this: ex: index.html dc: creator exstaff: 85740. ex: index.html exterms: creation-date "August 16, 1999". ex: index.html dc: language "en".

 Thus, the XML syntax is much more detailed than the ES syntax, however, it is easier to process by computers.

The triple is the basic unit of the RDF Resource Description Environment (RDF) and consists of a Subject, a Predicate and an Object. A set of triples is usually called an RDF graph, an example of which is shown in FIG. 3. The direction of the arrow in any three taken indicates from the Subject to the Object (http: ** en.wikipedia.org/wiki/Resource_Description_Framework). The subject in the RDF statement is either a Unified Resource Identifier (URI) or an empty node, both of which define resources. Resources represented by an empty node are called anonymous resources. They are not directly identified from RDF statements. A predicate is a URI that also indicates a resource that represents a relationship. An object is a URI, an empty node, or a Unicode string literal. Triple zoom

SUBSTITUTE SHEET (RULE 26) is thereby what will be used in this application for processing information from various sources.

 As shown in FIG. 4, there is a semantic correspondence between the semantic web stack and (shown on the left) the semantic stack of the present application, shown on the right. As shown in FIG. 4, the semantic stack used in this application includes CmwL (Comindware language) 401, RDF circuit 403, RDF 405, N3 circuit 407 and N3 notation. The main idea here is that OWL is replaced by a special Comindware language, which is a limited version of OWL in order to improve performance and get rid of functionality and operations that are not necessary for the purpose of modeling business processes (however, it uses the OWL dictionary and some of its rules )

The following OWL concepts are used for custom templates (see http: ** www.w3.org/TR/owl-ref/):

3.1 Class Descriptions

3.1.1 Enumeration

3.1.2.2 Cardinality restrictions

3.1.3.2 owl: o6beflHHeHne4ero

 3.2.1 rdfs: noflMacc4ero

4.1 RDF circuit designs

RDF Data Types

Extended capabilities:

+ Ontology custom template

 + Ontology enumeration type

 + Ontology of the computed property

 + Security Ontology

System ontologies that should be described in OWL:

+ Ontology request

+ Ontology restrictions

+ Workflow ontology

+ Ontology user account,

+ User Interface Ontologies

+ Other ontologies (email, history, attachments, etc.)

SUBSTITUTE SHEET (RULE 26) Thanks to the use of RDF (resource description environment), it is possible to work with various data sources (databases, data warehouses that can be local, in a corporate environment or located on the Internet). It is possible to use a common URI dictionary, thereby allowing the integration of data from various sources. Also, based on data and rules, it is possible to provide data on the fly (unlike static slices, as is done in OLAP cubes).

An example of the data sources that may be presented in this content is a database server (or some other type of storage), which serves as the personnel department for storing data about new employees. The same data can be used by the IT department to add a user to the corporate network. Also, the same data can be used by the accounting department to make salary payments. It is worth noting that the servers can be either local (on the corporate network) or remote, for example, accessible via a global computer network or via the Internet. It is also worth noting that if one of the servers is offline, this will not affect the correctness of the data. For example, if the server of the IT department is offline when the new employee is added to the HR department, then as soon as the IT server is online again, thanks to the RD department, the same people will be reflected in both business applications. The email shown in the drawing is necessary not only to inform the other department about the addition of a new employee, but also to synchronize the terminology. For example, for a human resources department, a person is an employee, for an IT department, a user, for an accounting department, a recipient of money. Using RDF, a global database can display that the global: face = OK employee = IT: user, and then everything will be synchronized without any further effort.

 Data can also be taken from a web page or, for example, from any source identified by a URI. With the help of "data converters" any information described by RDF can be used, for example, the rule can say "something" from "source" - source: something - this is st \ l: "our thing" http: ** www.w3.org / 2000/10 / swap / doc / Reach)

Further, as an example, we consider that a company in which there are three business applications - one for OK (human resources management system), one for BUHG (accounting system) and one for IT (information technology - Support Service). Therefore, each business application can have its own server. When any employee begins to work, the personnel department "creates" a new employee, indicating his name, surname, position. Then, manually or automatically, this information is sent to accounting and the IT department.

 Accounting creates an employee with attributes related to his employment - salary, type of compensation, for example, hourly, monthly, etc., social security number, etc. The IT department creates a user account with attributes that are relevant to the IT department - such as access rights to internal resources of the company, equipment / computer transferred to the employee, license fees for software installed on the user's computer, etc. These three departments have their respective applications shown in FIG. 7 illustrating the human resources department and application 701,

SUBSTITUTE SHEET (RULE 26) accounting and application 703 and the IT department and application 705. The global can be represented as an engine that represents the data context for a specific business application, 707, so it can aggregate all the information from all business applications and generate contextualized information related to the employee (as well as to other employees). On the left in FIG. 6 (to the left of the Storage Layer) there is an information pool that can be stored in various databases or other storages. 707 is an element that allows contextualized business information to be displayed for a particular application. “Global” is an entity for representing data in the specific context of a business application.

The context can be considered as the environment of a particular event, object or individual, which determines the interpretation of data and actions / operations on data in a particular situation. Optionally, the context determines the data processing method in a particular situation. For example, someone's email address can be considered login information in one context and as contact information in a user profile in another context; it can be used as the requesting party in the application for technical support in the third context - it all depends on the interpretation of the data.

Information exchange between servers is performed automatically, since all servers use a common dictionary. For example: http: // <company_name> .com / tracker / ontology / global / hr, or http: // <company_name> .com / tracker / ontology / global / it or http: // <company_name> .com / tracker / ontology / global / acc, all are conjoined into http: // <company_name>. com / tracker / ontology / global).

Even in the case when the accounting department uses its own dictionary when creating the employee record manually, it is possible to write the rule {? X a Bukhpchelovek} => {? X a Global: employee}, thereby providing a translation mechanism between the accounting dictionary and the global dictionary.

 This example shows that the proposed architecture allows each individual group or department within the business to work with its own database / storage and its own server system, while a global server with the engine 707 can be a combined representation of data from all departments. This is done on the fly and without duplication of data, which is especially important from the point of view of information security, as well as from the point of view of maintaining the relevance of information (in this case, when the data on one repository changes, there is no need to change data on other repositories), global Employee + description of the rule for the “host” from local business applications is the ontology for the Person in the Global database. Thus, one option is to use different ontologies for each business application, while the second option is to use a common ontology for all applications.

FIG. 6 illustrates an implemented method of accessing any data store when using a URI and to present data in a specific context. As shown in FIG. 6, an enterprise may have several servers with databases 601A, 601B, ... 601N.

SUBSTITUTE SHEET (RULE 26) An enterprise can also connect to other database servers, for example, through a global computer network or via the Internet, see database servers 603A, 603B, ... 603N. Storage layer 605 provides the engine with requested data from a particular storage.

The provided data 609 can be divided into user data in the form of axioms (facts) 607 and ontologies (also represented as axioms, but which can be recognized by the N3 syntax). In other words, 611 contains information about what and how should be presented to a specific user in a particular Business application. 611, 607 and 611 are processed by the Core and the result of processing is 613 - The engine (The engine is part of the kernel), which can represent data in a specific context (615) in accordance with ontologies.

Presentation of data on the fly can be illustrated using the following example. Consider ontology data (for example, data that describes the entities that are affected) in the context of business applications, for example, project management, issue tracking, bug tracking, CRM, etc. Each of them is stored in its own database (or, alternatively, in a common database) and combined at a higher level. Using the logical core, it is possible to combine various data in various combinations and sets of ontologies, for example: using certain ontologies, the developer can see the context for representing the error declared by the QA as a task assigned to it, in other words, it is possible to track which task each specific error relates to, over which work is being done.

The differences between the on-the-fly view available through the approach described here and the static view provided by data mining using OLAP cubes (real-time network analytic processing) are also worth considering. OLAP is a common technique for generating reports and various statistical documents. OLAP cubes are often used by analysts to quickly process complex database queries, and they are especially common in marketing reports, sales reports, data analysis, and so on. The reason OLAP cubes are so common is because of the speed with which processing can be performed. Relational databases store information about various entities in separate tables, which are usually well normalized. This structure is convenient for most database operating systems, but complex multi-table queries are usually difficult to quickly complete. A good model for such queries (as opposed to changes) is a table built using facts from OLAP cubes. Cube metadata is typically created from the star or snowflake schema of relational database tables. http: ** en.wikipedia.org/wiki/OLAP#Concept

OLAP slices a relational database at a particular point in time and structures it into a spatial model for queries. OLAP structures generated from operational data are called OLAP cubes. A cube is generated by combining tables using a snowflake or star pattern. At the center of the star schema is a fact table containing key facts used to generate queries. There are many change tables associated with the fact table. These tables show how collected relational data can be analyzed. The number of possible aggregates is determined by the number of ways that can be displayed hierarchically

SUBSTITUTE SHEET (RULE 26) initial data. OLAP cubes contain master data and spatial information (aggregates). Potentially, the cube contains all the information that may be required to answer or respond to requests. Therefore, in order to analyze the information, it is necessary to generate slices of the cube (represented by tables). For example, you can look at different two-dimensional slices of a cube by moving the “position” of the slice vertically and horizontally in the cube, as well as opening and closing levels inside the cube.

The difficulty of using OLAP as a methodology is to generate queries, select the baseline data, and generate the appropriate schema, which is the reason why most modern OLAP products usually come with a lot of predefined queries.

Another problem is the basic knowledge of the OLAP cube, which must be complete and consistent. Thus, the main problem with OLAP cubes is that the analysis process usually requires re-creating the cube itself or frequently generating slices. Unlike OLAP cubes, the proposed approach advantageously allows the regeneration of data representation on the fly without the difficulties of predefining and preliminary generating queries.

In short, the process of the approach discussed here can be described as follows:

- the business layer requests data from the kernel;

- the logical core collects data from various sources;

- the logical core recognizes the nature of the data and divides the data into axioms and rules. For example, for a bug tracker, the axiom may be "solution: is" you need more information "", and the rule may be {? About operation: requires More Data? F. ? f field: empty True.} => {? o operation: allow False};

- the engine necessary to fulfill the request of the business layer collects compiled rules together (for example, in C # code, although the invention is not limited to any particular language).

The engine may have rules that were compiled and compiled earlier, as well as new rules for rules that have not yet been processed. Thus, compilation should only be done for new rules. Therefore, the kernel does not need to constantly work with data, but only to address data in response to requests from the business layer;

- the engine processes axioms, and new axioms arising from this are generated;

- the kernel returns the requested data to the business layer.

FIG. 8 illustrates a data processing algorithm according to one embodiment of the invention. As shown in FIG. 8, after the start step (801), the business layer requests data from the kernel (step 803). In step 805, data is received from the storage, and in step 807, the data is divided into axioms and rules.

SUBSTITUTE SHEET (RULE 26) In the next step, user data that is stored as facts (607 in FIG. 6) is received from the repository and divided into rules (809) and axiom data (808). At step 811, the existing rules are checked. If the rule exists, in step 813, then the rules and engine are used (step 819). Otherwise, after step 813, the new rules are compiled (step 815). After that, new rules are added to the engine (step 817). Then the system starts working with the Engine with the new rules inclusive (step 819). In step 821, the axioms are processed by the engine. Requested (step 823) new axioms (data required for a specific context) resulting from the processing of the Engine. The kernel returns the requested data (provides the user with the requested context) (step 825). The process ends in step 827.

 FIG. 9 illustrates the algorithm for working with the axioms and rules of the Kernel with a specific example (FIG. 9 illustrates the “request processing by the Kernel” block with FIG. 8). After starting (step 901), the data obtained in step 903 from the source is identified by the RDF URI. The data is divided into Axioms 907 and rules 909 in step 905. In step 911, the engine is prepared by compiling the Rules. In step 913, the original axioms (User data) are processed by the Engine. In step 915, new Axioms are accepted (e.g., contextualized data for a particular presentation of the data). At step 917, the process ends.

For example, there are several types of rules. A rule such as a filter is often used in cases of a tracker, for example, obtaining a list of calls / errors / tasks of a support service for a specific user and a specific project with specific attributes. Thus, it is necessary to filter information from a common pool of tasks / errors / requests for a specific user and project and present them as separate axioms.

Converting rules relate to the same information that might otherwise be presented. For example, the IT department sees people as users of an IT system. On the other hand, the project manager can consider the same users as resources working on specific tasks. As another example: transformative rules may include the following: at the input, data (axioms) are obtained that describe a specific application (for example, requests from a specific user) and the presentation of this data. Therefore, the input engine will accept axioms in the form of a specific user interface filled with data.

Another example of rule types is a generating rule. For example, in a specific project containing more than 50% of critical errors and more than 50% of critical tasks, the system automatically generates a fact about the status of the project (for example, the status of the project will be displayed as "Critical").

As an example below, it is shown how the three types of rules listed above can be combined using the N3 syntax:

@prefix error: <http: // <company name> .com / tracker / bugs #>.

@prefix task: <http: // <company name>. com / project manager / tasks #>.

@prefix prct: <http: // <company name> .com / projects #>.

SUBSTITUTE SHEET (RULE 26) @prefix mat: <http: // <company name> .com / mathematic #>. @prefix assert: <http: //comindware.eom/logics/assert#. @prefix cmw: <http: //comindware.eom/logics#.

First of all, the information is converted from the bug tracker and from the project management task to the data for the ABC project.

Further, only those errors whose status is “critical” are filtered and left, and the engine considers the total number of errors, after which if the number of “critical” errors is more than half of their total number, it generates a critical state of project errors:

{Error cmw: is error: Error. ? error przh: included prkt: Project_ABC. {? error prct: Status statusPrt: Critical} assert: c4HTaTb? {? error prct: Status? any} assert: c4 HTaTb? Total Error. (? Total Error 2) mat: split? Half All Error. ? number of Critical Mate Error: more? halfAllError.} => {prct: ABC_Project prct: Critical Errors true}.

The same operations on data (tasks) from the project management system

{? task: 15 task: 3 task. ? task prct: included prkt: Project_ABC. {Task pct: Status statusPrt: Critical} assert: c4HTaTb is a critical Critical Error. {? task prct: Status of Love} assert: count? TotalTasks. (? Total Tasks 2) Math: Divide? Half of All Tasks. ? number of Critical Tasks math: more? half All Tasks.} => {prct: Project_ABC prct: Critical Problems true}.

Next, the “Critical” status of the project is automatically generated if the project has tasks and errors in the “Critical” states:

{prct: Project_ABC prct: Critical Errors true. prct: Project_ABC prct: Critical Tasks true}. => {prct: Project_ABC prct: Status "Critical"}.

 The same thing happens with project status, but with a different condition: automatic generation of a “Critical” status for a project when more than half of “critical” errors OR tasks.

{? x cmw: is task: 3 task} => {? x cmw: is project: Task or Error}.

{? x cmw: is error: Error} => {? x cmw: is prct: Task or Error}.

{? x cmw: is prct: Task or Error. ? x project: included project: Project_ABC. {? x project: Status of the status of the Project: Critical}. assert: c4HTaTb? {? x prct: Status? any} assert: c4HTaTb? Total. (? Total 2) mate: divide? Half of the total. ? number of Critical Mat: more than half of the total.} => {prct: Project_ABC prct: Status "Critical"}.

As should be understood, real-life examples are usually more complex than this, and there may be many more types of rules in most real-life situations, however, the principle remains the same. I

SUBSTITUTE SHEET (RULE 26) Axiom conjunction example

An example of a conjunction of axioms is most often one of the easiest to understand examples. For example, when combining information related to project requirements (axiom “requirements” - requirements defined by analysts) and errors from a bug tracker (axiom “errors” - errors identified by testers, who are usually quality control specialists, and entered into forms tracking errors based on certain requirements), the results of the "resulting axiom", as a rule, are a combination of how many errors are associated with one functional requirement.

This is illustrated in FIG. 10. After the start of the process (step 1001), the data is received ^" or any store identified by the URI in step 1003. In step 1007, axiom 1 is identified. In step 1005, axiom 2 is identified, etc. In step 1009, the axioms are processed, see the result in “Resulting Axioms" (step 1011). The process ends in step 1013.

Another illustrative example is the use of the semantic network concepts and notational / syntactic approximation described here to describe the production process of a toy car. Suppose a toy car manufacturing uses a tracker to track the state of assembly changes. In this case, the axioms are related to any data received by the system in the form of a triple (subject, predicate, object). Here they are: wheels for a jeep wheel for a truck

% front wheels for Sports Car rear wheels for Sports Car

 Jeep body

 Truck body

 Sports car body

Jeep Pendant

Truck Suspension

Sports Car Suspension

 The rules in this case have a similar appearance and may look something like this: {? The toy has an olesha? X. ? toy: suspension? z} => {? toy: chassis (? z? x)}

This rule, written in N3 syntax, means that if something (X) is a wheel belonging to car Y, and Z is the suspension of car Y, then their combination will be a chassis for Y. In this manner, all other rules will be formulated . As specific examples, the following rules can be created:

SUBSTITUTE SHEET (RULE 26) Truck Suspension should be combined with Truck wheels -> Truck chassis, where Truck chassis is axiom +1 in FIG. 10, i.e. this is the result of a specific rule.

Truck Chassis combine with Truck body -> Truck

Jeep suspension combined with Jeep wheels -> Jeep chassis

Jeep chassis combined with Jeep -> Jeep

Sports Car Suspension combined with Sports Car wheels - Sports Car chassis

Sports Car chassis combined with Sports car body -> Sports car

Thus, all the axioms and rules are in the repository, and when a user working with the business layer of the system performs a certain action (for example, he collects the wheels and the Jeep suspension together, and wants to make changes to the tracking system, for example, a toy assembly tracker, which is assembly tracking, in other words, an alternative representation in the form of case management), the business layer (see 607-609) sends the request to the kernel and the kernel 607-613 performs calculations.

Further we consider the concept of "case" for this example. In this example, case 123 has:

Case ID 123 Assemblies Purpose Assemblies: Jeep

Facts: Done (for example, fully compiled, otherwise, any fact will not be available)

The body is ready

Wheels are ready

 Chassis ready

 The suspension is ready

As a result of this, the following actions can be performed: a) Add part (id) => If there is a car part (for example, add a body, id = some kind of identifier for a car part b) the following construction can be used to assemble the wheels and suspension:

Collect details (id1: id2) id1 assembled with id2 id assembled with id 3 => (In case there is a new part)

SUBSTITUTE SHEET (RULE 26) (in other words, this rule corresponds to the transition to block 1111 in FIG. 11).

Based on the rules, you can get a list of available actions for a particular assembly stage, which is why it can be described as a “case” and an “instruction” (for example, the case when the assembly cannot be completed because there are no bodies in the warehouse).

N3 is selected taking into account the main actions performed by the system, in this example, a syntactic notation, which means that all data stored in a specific format is defined by this notation. On the other hand, CmwL means that the user's own predicate can be used to describe the system, how it works, etc.

This is illustrated in FIG. 4. For example, data is stored in an example text file. 3

@prefix cmw: <http://www.comindware.com/logics#>. @prefix toys: <http://toys.com/description/toys#>. toyswheels sgtsh: belongs to the toy truck.

{? at toys ? toy: suspension? z} => {? toy: chassis (? z? x)}

From this it becomes clear that prefix is the place where specific predicates are formed. In other words, “belongs” - is cmw (short for http: //www.comindware.eom/logics#, and which may contain the necessary logic, that is, CmwL (Cmw language), while common the syntax is N3. Therefore, in the example of the production of a toy car, there is special data describing this case. Therefore, the engine (see FIG. 6) can take data from the storage layer, where, using N3 notations, axioms and rules are stated. The engine can parse the rules and based on the parse of the rules can receive data for working with the system, t .e. the business application that is currently being used.

 Thus, as soon as the N3 rule has been parsed, it can be used by the engine to provide contextualized data for a specific business application for modification and further work on it. The advantage, compared to OLAP cubes, is that this information can be presented as a “slice” at any time without the need for recompilation - the information has already been parsed, and there is no need to parse or compile it again. For example, the accounting department to calculate the proceeds from all collected toy cars of a particular seller, it is enough to take already compiled information about the collected cars and apply rules to it that filter information based on the employee’s identity. In other words, there is no need to recompile, it is only necessary to change the presentation of information. (See the example below about Formula 1.) For the presentation of data, switching between the contexts of a particular business application, the example with F1 is illustrative.

Example Formula F1:

F1 team Ferrari 2004

SUBSTITUTE SHEET (RULE 26) People:

Pilots:

Michael Schumacher Rubens Barrichello

1 team manager 20 engineers

2 cars / 8 wheels / 2 suspensions / 2 chassis / 8 engineers for the whole season / 2 car bodies / 15 grand prix per season / 1 grand prix for 3 training runs, 1 qualification race and 1 main event - race / 15 required engineers for the race /

The team needs:

 1 system for tracking the creation of the car (similar to the task tracker for engineers), so in the real case, this can be considered as:

Engineer / Pilot enters the system and works with tasks (tasks may look like: the chassis assembly is assigned to a specific engineer or test a car to drive several laps before the Canadian Grand Prix is assigned to Michael Schumacher)

 1 system for managing people in races (a similar project for a manager), for example, a manager uses engineers and pilots as resources for a particular race.

Comindware Architecture

 There is a data store (written in N3 notation: subject-predicate-object):

Axioms:

 Schumacher - pilot

 Peter - engineer

car needs 4 wheels car needs 1 engine

Set up system rules as follows:

 A pilot can only use one prepared vehicle (in N3 it may look like an example with a toy car)

 The kernel parses the data after receiving a request from the Business layer and compiles it into the Engine (based on the analyzed rules). Therefore, the compiled engine knows how to display information for a specific request (in other words, depending on the context,

SUBSTITUTE SHEET (RULE 26) presentation of information may vary). The kernel compiles additional rules for the Engine only if a specific rule has not been previously parsed before.

 When an engineer enters the system, he sees the tasks that he must do. Following the rules, he collects the car and updates the status of tasks. It also changes the available spare parts for the car in the system, since spare parts are resources for the Task.

The task tracker for the mechanics servicing the car to track its readiness for the race knows that the engineers are authorized, the engine provides users with information when a person is a user (for example, the owner of a task) and that the part is a resource. The engine presents information in a specific context, in this case, presenting information to mechanics.

When a manager logs in to assign people to a race, he sees people as resources for a particular race. Thus, for the manager, this will be a different tracker, more similar to project management software, and the mechanics for the manager’s tracker are resources, although these mechanics were ordinary users when the car needed maintenance.

In the proposed architecture, all data can be used in various business applications used in various business applications, with certain contextualized views (see FIG. 6). For the same system that uses relational databases or OLAP cubes, duplicate information is required in several databases (engineer Peter as an engineer for a project system to assign him to a specific race, and Peter as a user for the Task Tracker during car assembly process). Conditionally, if Ferrari hires a new pilot, then he must be added to the project system as a resource. And to the task tracker as a user.

A slice is a query for a specific “fact table” that requires the user to reconfigure the slice each time the user needs to change any field in the fact table because they have a relational database (for example, the pilot change field as a resource for the pilot in the form user in the fact table). The proposed architecture configures on the fly because it does not have duplicate data.

In one implementation, the Comindware ^® database uses an internal binary format to store axioms and rules. The storage is optimized for quick search and getting axioms. The following data types are supported for any part of the axiom triple (subject, predicate or object):

U I - corresponds to the URI in the definition of the RDF graph.

Empty Node - Anonymous resource name as defined by RDF

Unicode string literal - contains a Unicode string of arbitrary length Integer literal - Contains a 32-bit integer

SUBSTITUTE SHEET (RULE 26) Decimal literal - Contains a 128-bit number. This data type is intended for financial and monetary calculations.

Literal Date / Time - Contains date and time values in the UTC time zone

Duration literal - Contains a time interval (e.g. 4 hours)

Logical - Contains either "truth" or "false"

N3 formulas - an ordered collection of triples. For example {: car vet: red. : car: model: x}

N3 Lists - An ordered collection of names or literals. For example (red: blue: orange)

Unlike RDF, any type of data anywhere in the top three can be used in the Comindware Database. For example,

"l" ^AA xsd: integer log: paBHO "npnMep" ^AA xsd: string.

Rules are stored as axioms with the following structure. A subject is a formula containing a logical conjunction of triples, including rules of logic. The predicate is set to log: implies, often referred to as "=>". The subject is a formula containing triples of effect. Consider the following rule:

{? about operation: is there Required Data? f. ? f field: empty true.} => {? o operation: allow false}

 Here "{? O operation: is the Required Data? F.? F b field: empty is true.}" The formula in is subject

 "=>" is a predicate, "{? o operation: allow false}" is the formula for implicating an object.

Comindware ^® language extensions are a set of built-in predicates in addition to those defined by RDF (log namespace). Comindware ^® extensions are located in the "assert" namespace:

@prefix assert: <http: //comindware.eom/logics/assert#>.

The following extensions are defined: assertriff. Provides the ability to conditionally analyze logical conjunctions .. Example

{{Car shields red} assertriff ({? Car: type jabriolet} {? Car shields: blue})} => {? A8 car: lovely truth}.

A car is lovely if its type is a convertible and the color is red OR blue. assert: c4eT. Counts matching statements and returns a number.

SUBSTITUTE SHEET (RULE 26) {{Car: Car} assert: c4eT? N} => {: Car: account? N}. Counts all cars abzeg ^ sequence. Generates an N3 list of statements.

{({Car a: Car}? Car) aBBReg ^ sequence? List of Cars} => {result: list of Cars? car list}. Generates a list of all AzBeg vehicles ^ unique. Filters a set of claims containing only unique variable values

{{? car: color? color} aBBePunical Pcolor} => {result of a vetaAutomotive? color}. Generates a unique set of all existing vehicle displays. assert: o6pe3aTb. Limits the set of matching statements to a given number

{{? car a: car} assert: o6pe3aTb 2} => {result: cars? car}. Generates a set of a maximum of 2 cars. assert: 0TMeHa. Cancels calculations with a specific error message. Useful for diagnosing and tracking errors.

{? car: color? color. {? color log: paBHO red.}} asserfciff ({: car assert: 0TMeHa ("red cars are not allowed")} {}). } => {result: cars? car}. Generates a set of all cars, checking that it does not have red cars.

 In a complex system with many users and applications, data can be partitioned between databases in one of the following ways to achieve data isolation and context.

(i) According to the annex (see FIG. 17). Each application has its own database that stores data processed by the application. In this scheme, there are two types of data context. An application context provides access to application data to a specific application. The data of another application is not available in this database. The global context provides data access to many applications. This context can be used for reporting and statistics.

(P) According to the owner of the data (see FIG. 18). In this scenario, each user has his own database of personal data with personal data. A separate database can be used for shared data. In this case, the user data context combines the user database with a common database to allow the user access to personal and shared data. The global context can access all users' data for reporting, statistics, and administrative tasks.

(iii) By type of data (see FIG. 18). In this scenario, each database contains data (business applications) of a particular type. For example, a separate database for tracking orders and a database for order history can be used. In the case of a task management system, there may be three databases: one that contains

SUBSTITUTE SHEET (RULE 26) information about all users, another for tasks and a third for calendar events. A simple context containing only the most frequently used data of a particular type is used for most queries, while a full context containing all data types is used only in rare complex queries. In the above example, users mainly work with orders and only in rare cases request a history of orders.

In some cases, a combined approach is possible. For example, there may be databases for each data type and an untyped database for each user with personal data.

Any database can be divided into several smaller databases.

When describing an operation or query to the database, a configuration model is provided when the operation is performed inside the structure of this model. A model can be a combination of several data sources, such as databases and / or ontology files. A model is an effective data context that provides an interface for accessing data from multiple databases and other data sources. Within a single transaction, all changes are performed for only one database, even when data is stored in several databases. In one embodiment, there are four main data sources, see FIG. 13:

User data database

Operation History Database

 Base Configuration database containing application settings. Ontology files in N3 format

 In FIG. 14 is a block diagram of a database device. The database module has 3 main functional layers:

 A wrapper layer implemented, for example, in C #. The wrapper is responsible for converting the data to the format used by the next layer.

 An access layer, implemented, for example, in C ++, which is responsible for the logical connections between data stored in databases.

A B-tree storage layer that stores current user data in the form of a B-tree.

 In FIG. 14 also shows the main components for each layer and how the implementation distributes the components between the layers.

The client-side user database stores data in N3 format. The database module allows users to manage their data on a client computer, even with limited access to the server or without access to the server at all. This reduces the load on the server and allows the user to change, add, receive and modify data on the fly.

SUBSTITUTE SHEET (RULE 26) As a rule, large packets are used to transfer data to the server and to process and publish data on the server. How Since the same format is used on the client side and on the server side, there is no need to convert data between the client and server.

On the client side there are three main elements for database management, see FIG. fifteen:

Storage layer;

Data acquisition layer;

Layer of logic.

The storage layer consists of the following components:

 The triple memory model is the main component that controls other components. It provides basic, low-level mechanisms for adding, editing, deleting, and retrieving data.

 A dictionary is a list of “words” that can be any constant, for example, “My favorite movie” or “May 12, 2013”, or “25.4”. Each word in the dictionary has a unique Identifier and is accessed by index.

 A hash dictionary is a reverse dictionary that provides access to an index by word.

Link counter is a subcomponent for storing links for each word. Each time a word is used in a specific context, the counter is incremented by one. When a word is deleted, the counter decreases.

 The subject-predicate-object coordinate system can be used to represent context or facts as points in three-dimensional space. For example, consider three facts: “Peter likes cars,” “Peter likes fishing,” and “Jason likes fishing.” Probably, all the words used in these facts are already in the dictionary and the corresponding indices are already known, for example, (Peter, 0), (Like, 1), (cars, 2), (fishing, 3), (Jason, 4 ) Then the facts can be represented as (0, 1, 2), (0, 1, 3), (4, 1, 3).

 The subject-predicate-object coordinate system represents a similar concept except that the facts are written in the reverse order for further access to the objects.

The data acquisition layer includes the following components:

The “brain controller” provides an open interface for data acquisition functions. It allows the user to work with simple and simplified queries through the mechanism of the Processor of the Matcher of the Sequences.

The Sequencer Comparison processor provides functionality for processing matching sequences using the output parameters from previous matches as input parameters for the next sequence. Also

SUBSTITUTE SHEET (RULE 26) recursive processing is supported, for example, "What does Peter like, what does Jason also like?" (in natural language or “Does Peter like? x. Jason likes? x; Compare? x” in a more formal language), the result will be “fishing” in the above example, as well as filtering (for example, additional conditions for matches, for example, "who likes fishing and whose phone number starts at 212?"

Predicate Subject Matching allows the user to retrieve data based on a known subject and predicate. For example, based on the above facts, the brain controller may ask, “What does Peter like?” In a more formal presentation, the parameters “Peter” and “like” can be transferred to the Matcher of Subjects-Predicates, which will collect all the facts containing “Peter like ...” in the form of subjects and predicates. In this example, the result would be: "Peter likes cars and fishing."

Matching Predicate Objects deals with other matches, such as queries such as "who likes fishing?" In this case, the verb “like” and the object “fishing” are known. The result will be "Peter likes fishing. Jason likes fishing."

Subject Matching is a component similar to those described above, but it uses only the subject as an input parameter.

The Object Matcher is a component similar to those described above, but it uses an object as an input parameter.

The logic layer includes application logic, for example, rules, restrictions, description of business objects and their properties. Its main components are:

The entity controller is an open interface for creating, deleting, and retrieving business object data. He works with property ontologies, entity ontologies, a triple memory model, the Brain Controller, as well as with various models of business objects.

 API methods of the logic layer - usually of two types - requests and operations. Queries are designed to obtain data from the database (s) of data. Operations are intended for data modification. After changes to the database systems (for example, the user data database) during the operation, the changes are analyzed to determine whether they should be reflected in the history - user fields and some system fields are selected and then sent to a special object called the history keeper, which is responsible for recording change histories in the corresponding database and combining records for each object history.

At the end of the operation, the changes are recorded in a special database, for example, as a separate branch. Entries may be in string format:

Link to modified object

Change Author

Date of change

Type of change (create, edit, comment, etc.)

SUBSTITUTE SHEET (RULE 26) Modified Fields

Deleted (old) values

Added (new) values

If during the same period of time (for example, N minutes) the same user performs similar types of operations with the same object (for example, user John Smith edits the object "Error 120"), then the records in the history database can be combined into one record. The history keeper sets an internal list of links to the latest changes for each object. When receiving a new record, the first thing he checks is whether the new record can be combined with the previous record. Then, on the basis of the verification, he either creates a new record or edits the old record.

In FIG. 16 shows ontologies. The entity ontology has a tree structure that describes what properties a business object has and describes the relationships between the objects. For example, an ontology defines the Project business object and lists all of its properties, such as Start Date or Title.

A property ontology is a catalog of all the possible properties in the system, together with their types and other attributes, for example, in a format, for example, the "Start date" property is of the "date" type and of the "month / day / year" format.

The Task Logic Model is a structure that includes rules and restrictions for customization and access to the task properties of a business object. For example, the rule might be "If the completion date of the task is shifted and the task is part of the project, then the completion date of the project is also shifted."

The system object model usually reflects the component model described above. Upon receipt of a request to one of the web API methods, a specific controller performs the requested action and returns the desired result. The results can be in any format suitable for further processing, for example, in the form of trees, graphs, lists, tables, text, JSON objects, or in any other format defined by the user.

Comindware provides an ontology for describing metadata similar to specific OWLs and RDFSs. The following ontology describes itself as defined in its own expressions. This ontology introduces the concept of Class and Property.

A class is a collection of metadata that describes a particular data type. The class has the following attributes:

Name defined by the predicate ClassName

Description defined by predicate Class description

A set of properties defined by a property predicate.

Parent class. Indicates that this class inherits a set of properties from the specified parent class.

SUBSTITUTE SHEET (RULE 26) The property describes a specific predicate and constraints for statements that use a predicate. The property has the following attributes: PropertyName - a string that defines the name of the property, how it is displayed to the user Description Properties - a string that defines the description of the property, how it is displayed to the user Type of Property - indicates the class to which the property attributes should belong - determines the number or restrictions of the property values. Possible limitations: mandatory - the value for this predicate must be present in the instance of the multiValue class. Value - There may be several statements with given subjects and predicates, but with different objects. If not defined, then an instance can contain only one or zero statements (objects) with a given predicate.

An example of the ontology itself can be as follows:

(© prefix xsd: <http://www.w3.org/2001/XMLSchema#>.

@prefix log: <http://www.w3.org/2000/10/swap/log#>.

@prefix cmw: <http: //comindware.eom/logics#>.

cmw: Knacc a cmw: toiacc. sbsh: Class

steel \ l /: cmw property: Knacc

the scripture of the Class. sgsh: Class sgsh: Property st \ l /: Property.

SPGS and CMW Properties: Class. sgsh: parentCgt ™ class: attributesCmw properties: multipleValue.

sgsh: class name and ssh: property. cmw: nMfl ^ acca cmw: TnnCBoftcrBa xsd: cTpoKa.

SUBSTITUTE SHEET (RULE 26) css scripture Class a sggs: Property.

spl \ l /: description of the class of class and properties of \ l /: class.

atsh: Property st \ l /: attributes Properties st: ultiValue. cssh: Property

sgsh: ultiValue a st \ l /: AttributeProperties.

 SGTS: PROPERTY

sgsh: Property

 and st \ l /: Property.

sggsggip xsd: crpoKa properties.

st \ l /: type Property and st \ l /: Property.

cmw: nacc.

ssh: attributes

 @in? property.

 {

? property

?type of.

@ if-not {? type crap: and I'm Class? and me} @then

{

 ? TYPE ->? And me.

SUBSTITUTE SHEET (RULE 26) }

 } => {? property st \ l: showTypeProperties? and I. }.

real estate property and real estate property.

st \ ": descriptionProperties st \ l /: typeProperty xsd: crpoKa.

sms: Property Attribute.

sggs: attributes Properties sgs: attributes attributes st \ l: multiValue.

in? class.

{

? class

?parental

} => {? class cmw: all Parents? parent}.

in? class. {··

? class

?parental.

? parental union: all Parents? pp

} => {? class st \ l: all Parents? pp}.

in? x,? class.

 {? x ah? class} => {? x st \ l /: isType Class? class}.

in? x,? class.

 {? x ah? xs. ? xs sgsm: all Parents? class} => {? x st \ l: is a Class Type? class}.

An example of using an ontology:

 : Car and art.: Class.

 : Car spgsh: Property: color.

:Car

:title.

SUBSTITUTE SHEET (RULE 26) : name a

 : name st \ m: typeProperty xsd: crpoKa. : Color a st \ l: Class. Red A: Color. : blue a: color.

Referring to FIG. 12, a typical system for implementing the invention includes a multi-purpose computing device in the form of a computer 20 or a server including a processor 21, a system memory 22, and a system bus 23 that couples various system components, including the system memory to the processor 21.

The system bus 23 may be any of various 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. The ROM 24 stores the basic input / output system 26 (BIOS), consisting of basic routines that help exchange information between elements within the computer 20, for example, at the time of launch.

Computing device 20 may also include a hard disk drive 27 for reading from and writing to a hard disk, not shown, a magnetic disk drive 28 for reading from or writing to a removable magnetic disk 29, and an optical disk drive 30 for reading from or recording to a removable optical disc 31 such as a CD, a digital video disc, and other optical means.

The hard disk drive 27, the magnetic disk drive 28, and the optical disk drive 30 are connected to the system bus 23 by means of the hard disk drive interface 32, the magnetic disk drive interface 33, and the optical drive interface 34, respectively. Storage devices and their respective computer-readable means provide non-volatile storage of computer-readable instructions, data structures, program modules and other data for computer 20.

 Although the typical configuration described here uses a hard disk, a removable magnetic disk 29, and a removable optical disk 31, one skilled in the art will appreciate that other types of computer-readable media that can store data that are accessible by a computer may also be used in a typical operating environment. such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memory (RAM), read-only memory (ROM), etc.

 Various software modules, including operating system 35, may be stored on a hard disk, magnetic disk 29, optical disk 31, ROM 24, or RAM 25. Computer 20 includes a file system 36 associated with or included with the operating system 35 or more software application 37, other program modules 38, and program data 39. A user can enter commands and information into a computer 20

SUBSTITUTE SHEET (RULE 26) using input devices, such as a keyboard 40 and pointing device 42. Other input devices (not shown) may include a microphone, joystick, gamepad, satellite dish, scanner, or any other.

These and other input devices are connected to the processor 21 often through 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 visual display device is also connected to the system bus 23 via an interface, such as a video adapter 48.

Computing device 20 may operate in a networked environment through logical connections to one or more remote computers 49. The remote computer (or computers) 49 may be another computer, server, router, network PC, peer-to-peer device or other node of a single network, as well as usually includes most or all of the elements described above with respect to computer 20, although only an information storage device 50 is shown. Logical connections include a local area network (LAN) 51 and a global computer yuternuyu network (SCS) 52. Such networking environments are usually common in offices, enterprise-wide computer networks, intranets and the Internet.

The computer 20 used in the LAN network environment is connected to the local area network 51 via a network interface or adapter 53. The computer 20 used in the GC network environment typically uses a modem 54 or other means to establish communication with the global computer 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 or parts thereof described with reference to computer 20 may be stored on a remote information storage device. It should be noted that the network connections shown are typical, and other means may be used to establish communication communication between computers.

 Considering the described preferred option, it is obvious to a person skilled in the art that certain advantages of the described method and tool have been achieved. It should also be appreciated that various modifications, adaptations and alternative implementations can be made within the scope and spirit of the present invention. The invention is further defined by the following claims.

SUBSTITUTE SHEET (RULE 26)

Claims

CLAIM

1. A system for processing application data, including:

(A) a plurality of databases located on one or more hardware data storage devices, a plurality of databases storing rules and axioms in the format of STR triples (subject-predicate-object);

(B) a common data storage layer that provides applications with access to the STR-triples stored in multiple databases,

 where open source triples are presented in the form of a global virtual database uniquely presented for each application, where the global virtual database generates data associated with the application accessible through a common storage layer, without duplicating triples, through a translation mechanism between the dictionary of the corresponding application and the global dictionary; and where a global dictionary links many databases;

(B) at least one ontology stored in the form of STR triples and based on rules and axioms;

(D) the logical core that

(i) processes requests to convert one set of STR triples into another set of STR triples. depending on the context represented by the applications, which defines the interpretation of axioms,

(ii) performs operations on axioms and generates new axioms in the same context; and (Hi) filters the axiom depending on at least one ontology.

 2. The system according to claim 1, characterized in that the logical core filters the data based on the observance of the context of the entered data.

 3. The system according to claim 1, characterized in that the logical core filters the data based on the observance of the context of the entered data.

 4. The system according to paragraph 1, characterized in that the logical core interprets the data in their context.

 5. The system according to paragraph 1, characterized in that the logical core adds new ontologies, including new rules.

6. The system according to paragraph 1, characterized in that the axioms are stored in B-trees.

7. The system according to claim 1, characterized in that the plurality of databases includes a database of axioms, a database of operation histories and a database of configurations with application settings.

SUBSTITUTE SHEET (RULE 26)

8. The system of claim 1, wherein the plurality of databases include: a user database in which axioms of each user are stored; database of operations, which stores the history of changes to objects; and a configuration database that stores application settings.

9. The system according to claim 1, characterized in that the hardware storage devices are any of the data storages: RAM, hard disk, solid state drive, network storage, cloud storage, SAN and NAS.

10. The system according to claim 1, characterized in that the common data storage layer keeps track of what and in which database is stored, to ensure the processing of data from the databases depending on the context provided by the applications.

11. A method of processing business data embedded in a computer / including:

(A) storing a plurality of databases located on one or more hardware data storage means, a plurality of databases storing rules and axioms in the format of STR triples (subject-predicate-object);

(B) providing access to applications to STR triples stored in multiple databases,

 where open source triples are presented in the form of a global virtual database uniquely presented for each application, where the global virtual database generates data associated with the application accessible through a common storage layer, without duplicating triples, through a translation mechanism between the dictionary of the corresponding application and the global dictionary; and where a global dictionary links many databases;

 (B) storage of at least one ontology in the form of STR triples and based on rules and axioms;

 (D) processing requests for converting one set of STR triples into another set of STR triples depending on the context represented by the applications, which determines the interpretation of axioms,

 (E) performing operations on axioms and generating new axioms in the same context; and

(E) filtering axioms depending on at least one ontology.

 12. The method according to paragraph 11, characterized in that it further includes generating new axioms, presenting existing axioms in a new context.

13. The method according to paragraph 11, characterized in that it further includes the addition of new ontologies, including existing axioms.

SUBSTITUTE SHEET (RULE 26)

14. The method according to paragraph 11, characterized in that it further includes the addition of new ontologies, including new axioms.

 15. The method according to paragraph 11, characterized in that it further includes the addition of new ontologies, including existing rules.

 16. The method according to paragraph 11, characterized in that it further includes determining a context for the data, which determines what operations can be performed with the data.

17. The method according to paragraph 11, characterized in that it further includes generating a presentation of the data for the same data, but in a new context.

 18. The method according to paragraph 11, wherein the presentation includes filtering data based on relationships between objects established by ontologies.

19. The method according to paragraph 11, wherein the ontology includes restrictions for axioms that are used to verify data.

 20. The method according to paragraph 11, characterized in that the operations are user-defined and include a combination of tables, logical and mathematical operations.

SUBSTITUTE SHEET (RULE 26)