RU2707708C2 - System and method of searching data in database of graphs - Google Patents

Abstract

FIELD: physics.

SUBSTANCE: invention relates to a method and a system for marking objects for search thereof. Method comprises storing input data, including axioms, representing facts, obtaining and converting input data objects into a n-tuple format based on context, processing axioms for determining a subject, a predicate and a complement of the n-tuple, analysis of data objects and determination of indirect links between data objects, determination of attributes and properties of data objects, marking automatically generated tags (autotags) of data objects based on indirect links between data objects, marking with auto-cells of data objects based on attributes and properties of said objects, storing the obtained subject, predicate in the database, additions and auto-tagged objects, ranging objects in accordance with autotags, determining a search region based on data objects, where search region is represented by n-tuple predicates associated with data objects, representation of search region variants for specific search areas, obtaining a query for searching for data objects in a search area and searching for tagged auto-locks of input data objects in a database based on graphs using predicates and autotag values.

EFFECT: technical result consists in automation of objects search.

22 cl, 9 dwg

Description

The present invention relates to data retrieval methods and, in particular, to a graph search method of data in databases.

Computer systems are often used to store large amounts of data, individual records of which must be extracted in accordance with some search criteria. Therefore, efficient storage of data to enable fast retrieval and retrieval is a critical issue.

Data mining is inextricably linked to the concept of data filtering. In general, with respect to data, a search means a procedure used to check large volumes of data in order to find non-obvious, hidden or lost parts. Data retrieval is usually associated with data warehouse processing. Depending on the nature of the data, a large number of search algorithms are used to search for data.

Data search may include searching for files in a data warehouse, searching for data in files / documents, data / information on the Internet, data in a database, and so on. Typically, a data search (i.e., an object search) is based on various data parameters that distinguish one data from other data (i.e., search by parameter (s), which uniquely characterizes the desired data). For example, file name, file type, file size can be used as such distinguishing characteristics; table name, table identifier - for the database; the number of characters in a word, part of speech for words, and so on. Tags can be used to facilitate and optimize data retrieval.

Typically, a tag can be manually assigned to a document during the process of creating data or documents, saving and / or adding to the database. Tags characterize data, so these tags can be used to search for data. Tags is a non-hierarchical keyword or concept assigned to a piece of information (such as an Internet bookmark, digital image or computer file). This kind of metadata helps describe the data and allows it to be found again by searching. Tags are usually selected informally and personally by the data creator or by those who view them, depending on the system, data structure, data type, data content, data context, and so on. For example, data related to computer science can be characterized by the tags "computer", "science", "information", "software", "hardware", etc. Various algorithms can be used to create tags.

For example, tags can be created based on the analysis of the text of a document. Tags can be created automatically (referred to below as "auto-tags") for a document and can be further associated with it. Auto tags can be created not only for data / document search, but also for searching for an Object, for example, in a database (DB). An object is an entity, for example, a business entity: the task “Add a description for an animal’s image” is an Object serving “Bill” - an Object, as well as a request for “Building a bridge”, an entry in the database for the user, IT department, personnel department or any other entity. Such entities in the field of programming are called class instances. So, the user "Bill" is an instance of the class "User"; The IT department, human resources department are instances of Class "department", etc. Such Objects are the searched data that are of interest to the user and which should be found in the database.

Tags can be created for any type of data stored in various forms, for example, in the form of triples / n-tuples. For example, triples can be stored in various types of databases, for example, relational, hierarchical, network, object-oriented databases, etc.

As a rule, triples are stored in triples stores. The triples repository is a special database for storing and receiving triples. The treasury is a database created for certain purposes for storing and receiving triples, a triple being a data entity (also known as a statement) consists of a Subject-Predictable-Addition, like "John is 35 years old" or "John knows Helen."

Unlike a relational database, the triples storage is optimized for storing and retrieving triples. To access the triples stored in the data warehouse, the query language is used. In addition to queries, triples can usually be imported / exported using the Resource Description Framework (RDF) and other formats. Some storages are built as a DBMS from scratch, while others are built on top of existing commercial relational DBMSs (for example, based on SQL). Like the early development of real-time analytic processing (OLAP) of databases, this intermediate approach made it possible to create large and powerful DBMSs with low programming costs in the initial phases of data warehouse development.

However, in the long run, it is likely that native data warehouses will have performance advantages over. The difficulty with implementing data warehouses on top of SQL is that although triples can be stored, implementing efficient graph-based RDF queries into SQL queries is quite complex.

The number of tags grows with data volume. The stored data changes over time, so old tags are deleted or replaced with new tags. You must create new tags. Typically, data objects intersect each other, and changing one piece of data can affect the other. Manually creating tags for new data and updating changed data is a very laborious and expensive process.

Accordingly, a method is required for automatically creating tags and ranking data based on tag weights to facilitate data acquisition.

The present invention relates to a method for searching data in graph databases, which substantially overcomes the disadvantages of the prior art.

In one aspect of the invention, a method for automatically generating tags and retrieving data from a graph database is provided. According to an exemplary embodiment, triples are stored in a data warehouse. A data warehouse is a special database for storing and receiving triples. A triple storage is a specially designed database for storing and retrieving triples, where a triple is a data entity (also known as a statement) consisting of a Subject-Predictable-Addition.

Unlike a relational database, the triples storage is optimized for storing and retrieving triples. The query language is used to access triples stored in the triples repository. In addition to queries, triples can usually be imported / exported using RDF and other formats. Searched Objects must be tagged for search and retrieval. The number of tags grows with the growth of data volume. The stored data changes over time, so old tags are deleted or replaced with new tags. New tags must be created. Tags are created automatically (i.e. auto tags) to ensure efficient data retrieval.

Additional features and advantages of the invention will be set forth in the following description, and in part will be apparent from the description, or may be learned by practice of the invention. The advantages of the invention will be realized and achieved in structure, in particular in those indicated in the written description and claims, as well as in the attached drawings.

It should be understood that both the above-described general description and the following detailed description are exemplary and explanatory and are intended to provide further explanation of the invention as claimed.

The accompanying drawings, which are included to provide a further understanding of the invention, and which form part of this description, illustrate embodiments of the invention, together with the description, serve to explain the principles of the invention.

In the figures:

FIG. 1 illustrates an example graph according to an exemplary embodiment;

FIG. 2 illustrates part of a semantic network, according to an exemplary embodiment;

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

FIG. 4 illustrates a block diagram of a search for autotags for a modified Object and for related Objects, according to one embodiment of the invention;

FIG. 5 illustrates an example of data relationships, applicable to searching for Objects;

FIG. 6 illustrates the data processing process when creating an Object;

FIG. 7 illustrates an example of various business applications used in various departments of a company, and data processing in them in an example case;

FIG. 8 illustrates a system according to an exemplary embodiment;

FIG. 9 illustrates a computer or server that may be used in an exemplary embodiment.

The query language is used to access triples stored in the triples repository. In addition to queries, triples can usually be imported / exported using RDF and other formats. Searched Objects must be tagged for search and retrieval. The number of tags grows with data volume. The stored data changes over time, so old tags are deleted or replaced with new tags. New tags must be created. Tags are created automatically (i.e. auto tags) to ensure efficient data retrieval.

The following are two examples of representing RDF graphs in XML format (which is often more convenient for computer processing) and in the form of N-triples or N3 (which is used in the existing approach, and which is more convenient for human understanding).

Thus, the XML syntax is much more verbose than the N3 syntax, but is easier to handle by computers.

The triple is the basic unit of RDF and consists of Subject, Predicate (Predicate) and Addition. A set of triples is usually associated with an RDF graph, an example of which is presented in FIG. 1. The direction of the arrow (ie (110a, 110b) in any triple presented (ie 120) indicates from Subject (130) to Appendix (140). The RDF data model is similar to classical conceptual modeling approaches, such as the relationship of entities or class diagrams, since it is based on the idea of creating statements about resources (in particular, web resources) in the form of expressions Subject-Predicate-Addition.

These expressions are considered triples in RDF terminology. Subject denotes a resource, and a predicate denotes features or aspects of a resource and expresses the relationship between Subject and Addition. The collection of RDF statements is essentially a labeled directional multi-graph. As such, the RDF-based data model is more naturally suited to some types of graph representations than the relational model and other ontological models.

As mentioned above, RDF data is often stored in a relational database or in native repositories of triples or repositories of quadruples, if the context (i.e., named graph) for each RDF triple is also stored. Named graphs are a key concept of the Semantic Web architecture in which the Resource Description Framework (RDF) assertion set (graph) is identified by a URI, allowing you to create descriptions for a given set of statements, such as context, origin information, and other metadata.

Named graphs are a simple extension of the RDF data model through which graphs can be created, but by and large, the model does not have effective means of distinguishing between them after being published on the network. While named graphs can appear on the Web as simple related documents (i.e., Linked Data), they are also extremely useful for managing sets of RDF data within an RDF repository.

In FIG. 1 additions of "Man", "Manager" 140 and the subject "John" 130, "Michael", "Morgan", "Mona", "Alex" RDF statements are the Unified Resource Identifier (URI), which designates resources. Resources can also be shown by nodes with an unknown stream. Nodes with an unknown stream are not directly identified from RDF statements. A node with an unknown stream is a node in an RDF graph, reflecting a resource for which no URI or literal is specified. A resource represented by a node with an unknown stream is also called an anonymous resource. According to the RDF standard, a node with an unknown stream can only be used as a Subordinate or Supplement to an RDF triple. Nodes with an unknown stream can be designated by identifiers of nodes with an unknown stream in the following formats, RDF / XML, Turtle, N3 and N-triples. The following example shows how this works in RDF / XML:

The identifiers of a node with an unknown stream are limited only by the serialization area of a certain RDF graph, i.e. the node "_: b" in the following example does not represent the same node with the name "_: b" in any other graph. Units with an unknown flow are considered as simple evidence of the existence of an item without using a Uniform Resource Identifier (URI) to identify any specific item. This is not the same as the assumption that a node with an unknown stream denotes an “unknown” URI.

A predicate ("this" 110a, "position" 110b) is a URI that also indicates a resource reflecting the relationship. Addition ("Manager", "Developer", "General Manager" and in special cases "John", "Michael", "Morgan", "Mona", "Alex") is a URI, a node with an unknown stream, or a string literal in Unicode. The triple approach is what is used in this invention to process information from various sources.

In FIG. 2 shows a semantic stack of an exemplary embodiment. The semantic stack used in the exemplary embodiment includes URI 201. It is worth noting that everything that can be identified using the URI can be described, so that the semantic network can refer to animals, people, places, ideas, etc. Semantic markup is more often generated automatically than manually. URIs can be classified as pointers (URLs), as names (URNs), or both.

A Uniform Resource Name (URN) serves as the person’s name, while a Unified Resource Index (URL) looks like a person’s mailing address. URN defines the personality of an Object, while a URL provides a method for finding it. CmwL (Comindware Language) 211 describes the function and relationship of each of these components of the semantic network stack; XML 203 provides elementary syntax for the structure of content within documents, and also associates non-semantic with the content value; RDF 205 is a simple language for data description models that relate to objects ("resources") and their relationships. An RDF-based model can be represented in XML syntax. RDF Schema 207 extends RDF and is a dictionary for describing properties and classes of RDF-based resources and semantics for generalized hierarchies of such properties and classes.

Formally, ontology 215 represents knowledge in the form of a set of concepts within a domain using a joint dictionary to indicate the types, properties and relationships of these concepts. Ontologies are the structural framework for organizing information. Ontologies are described (by the Ontology Description Language) of OWL or CmwL, which allow you to describe Classes and their relationships with each other and other entities (see below). Ontologies can extend a predefined dictionary (for example, RDF or OWL dictionaries). A dictionary is a collection of data / information of certain terms that have a common meaning in all contexts.

The ontology uses a predefined reserved glossary / glossary of terms for concepts and relationships defined for a specific domain / subject area. Ontologies can be used to express the semantics of vocabulary terms, their relationships and context of use. Thus, the RDF Schema is a dictionary for RDF. OWL or CmwL and can be used to write semantics of subject areas in ontology. In fact, any data, such as ontologies or taxonomies, can be expressed in triples. The triple is a fact.

Taxonomy 209 is a hierarchical way of categorizing all objects in a given world: books, products, types, concepts, etc. In the semantic network, taxonomy is a dictionary of concepts and their exact definitions. When a dictionary is logically ordered within a hierarchy, it is called a taxonomy. It is a common resource that has gathered everything in the information ecosystem, used to synchronize the meaning of terms.

The Comindware 211 language is used instead of the Ontology Description Language (OWL) in the semantic stack. The Comindware language is a limited version of OWL with the goal of increasing productivity and eliminating functionality and operations that are not necessary for business application purposes and / or for use with ontologies (however, using the OWL dictionary and some of its rules 213).

In terms of data storage, a relational database is not the best choice for RDF storage, since it is poorly suited for working with poorly structured data. In relational databases, MySQL-search for information by tags is solved by introducing an intermediate table, so that the following structure can be obtained:

If the Task Table, User Table, Account Table, and other tables are used in addition to the Articles table, so the Link Tables must be created (Link Table 2, Link Table 3, etc.). In this case, if one adds, deletes or edits any data in one of the tables, the related data in the other tables must also be changed. If we need to access data from several tables, the SQL CONNECT statement should be used. The SQL JOIN statement joins records from two or more tables in a database. It creates a set that can be saved as a table or used as is. JOINT is a tool for combining fields from two tables using values common to each of them (for example, identifiers). This and other related operations are time consuming.

Relational databases provide a sufficiently high search speed only for the data for which the search has been configured / adjusted. For example, a search in SQL databases uses SQL queries that need to be rewritten each time new data is added to the database or new data types are used that are different from the data stored in the database. Another example is the addition of a department (departments have not been added before and such an Object has not been used) in the database. In this case, when adding a new department, the following should be available for adding: Information Technology (IT), Human Resources Department (HR), Research and Development (R&D) and others. So several new tables must be created in which at least one of them stores department data and in which at least the other table stores relationships between other database tables.

A large number of SQL queries (including search queries) must be modified / rewritten to allow searching for stored data. Such a rewrite / change of requests is an extremely expensive and resource-intensive action associated with involving a database operator and / or developer. An example implementation provides a system that automatically adapts to data changes within the database and that implements search query (s) that are simple for the user, such as: "What should I find?" -> "Errors" + "High priority" or "manager" + "Alex"). Such user search queries may use text fields into which a search query may be displayed. Also, the system should provide a choice of data types / search sets in which the search will be performed.

An application for implementing an exemplary embodiment includes a Graphical User Interface (GUI), a text user interface, a console, and other elements for human interaction with the system / application. The GUI can include a text box in which the user can enter a search term to begin the process of searching for Objects (sometimes referred to as "data objects"). It is worth noting that the GUI can contain more than one text field. In the text field, the user can enter part of the search word, and the system will provide options for automatically filling this word. For example, the user can enter the first characters of the word (or characters from the middle of the word) "Morgan", i.e. "Mo" in the text box.

The system provides a possible option for automatic completion (word endings, that is, words where such a sequence will be found or where these characters will appear in any sequence), Morgan and Mona. Further, the system is able to provide a search area to the user, for example, using the GUI. The search area is represented by triple predicates that are associated with the search word. For example, for the word "Morgan" the system will provide the following search areas: "Creator", "Error Corrector" and others, if they were found in the database. Such variants of search fields are represented by predicates of autotags for found autotags for the word "Morgan". If the user selects the search area "Creator", the search result will include "Error Number 2121", according to FIG. one.

Here, "Error" is a Class, and "Error 2121" is an instance of this Class. It is worth noting that the search area can be identified / defined and further narrowed. Examples of Classes and their instances for specific cases will be discussed below. The GUI allows the user to select at least one search area to enter a search word or part of it. The user can skip the selection of certain search areas, such as "Creator" or "Error Corrector". User can reject selected / provided search areas. In this case, such a solution is tantamount to choosing all the search areas. If at least one search area is selected, the search will be carried out in this search area. Class instances act as the required Objects (which are associated with the search word). "Michael", "Morgan" (FIG. 1) are another example of instances of the Class "Man"; "products: Product1", "products: Product2", "products: Product3" from the code below are instances of the Example: Product class.

As mentioned above, the system offers the user two options for automatic filling: "Morgan" and "Mona" (see FIG. 1) after the user entered a part or a search word, for example, several characters "Mo" (assuming that the user had in view of the word "Morgan"). The user can select at least one of them (or all), so that the system starts the process of searching for Objects for the selected options.

As mentioned above, data can be stored as triples or n-tuples. Data search conditions can be implemented in triples, however, all triples associated with data must be known for the search. Using autotags is a more convenient way to search for data. The following is an example of a description / definition of an autotag, and an example of a process for finding autotag values. An example of searching the Object by the values of autotags is also given. The following source code is written in N3. N3 is based on RDF standards and is equivalent to the RDF / XML syntax, however, it has additional features such as rules and formulas.

The following are examples of implementation of the invention in the form of source code, where each line begins with a symbol

- @ cmw prefix: <http://comindware.com/logics#>. This defines "http://comindware.com/logics#" for the prefix "cmw". Specifying @ prefix associates the prefix with the URI namespace. This indicates that a specific name (qname) with this prefix will further be abbreviated for URI and consists of combining the namespace identifier and the qname part to the right of the colon.

<"http://comindware.com/logics#"> is a Uniform Resource Identifier (URI), which is represented by a Unified Resource URL, which refers to a resource identified as comindware.com/logics#, which can be represented in HTML form via Hypertext Transfer Protocol (http) from a network host whose domain name is comindware.com. Once installed, the prefix can be used for the rest of the source code. Everything, be it Subject, Predicate or Addition, is identified by a URI.

- @ autotag prefix: <http://comindware.com/ontology/autotag#>.

- @ xsd prefix: <http://www.w3.org/2001/XMLSchema#>.

- # ontology of autotag. This is where the ontology example for autotag begins.

According to the syntax of the language, comments describing a particular block of the document follow the "#" sign. Comments can also be enclosed in "##".

- Auto tag: Auto tag a cmw: Class;

If you need to add a new dictionary, it is possible to define new classes of objects and new properties. A property that reports that the type of something is rdf: the type can be reduced in N3 simply to "a".

Classes just talk about the subject that they contain. Addition can be represented / described by many classes. No hierarchical relationship is required. If there is a connection between the two classes, then this can be argued. See class properties in the RDF Scheme (http://www.w3.org/TR/rdf-schema/) and OWL dictionaries (http://www.w3.org/TR/owl-guide/ or http: //www.w3.org/TR/owl2-overview/). As it becomes clear, the invention can be used with triples, quadruples, and so on. As an example, triples are used.

-cmw: autotag property: name,

For identical objects, the abbreviation is used: semicolon ";" represents another property of the same object.

- auto tag: predicate,

- auto tag: value.

For identical objects, the abbreviation is used: the comma represents another Addition with the same Predicate and Subject.

The following are examples for determining auto tags:

- ## Auto-tag of enumeration type (enum) ##. An autotag with a property in the form of an autotag type and a property of a given autotag is a list of specific values (in other words, an autotag for a property, and the property contains a list of values). An enum can be used as a list of values. An example of such an enum is an error or the importance / priority of a task:

Here, the criticality of the error is a property. In computer terminology, the criticality of Errors is an instance of the Property class. The name of the property (severity of the error) is Criticality of the Error. The type of the property is "Enum Property". The property may have a description, such as “Error Criticality,” which can be used to display through the GUI as a hint / additional information for the user. This tooltip can be presented in the form of text that can be seen when the user holds the mouse cursor over any GUI element without clicking on it. The criticality of the error matters ("VariantValues"). In this case, the error can have low criticality, medium criticality and high criticality (which can be represented as “criticality Errors: low,” “criticality Errors: medium” and “criticality Errors: high”).

Each value of the severity of the error (low, medium and high, presented as criticality Errors: low, criticality Errors: medium, criticality Errors: high) is an instance of the Class "VariantValues":

Each error severity value can have a name (as well as a property from the source block above):

Next, an autotag will be created for the severity of the error.

- example: criticality Errors Auto tag and auto tag: Auto tag;

Here the autotag is sealed as autotag for the severity of the error.

- autotag: name "Criticality";

- autotag: predicate example: criticality Errors;

Now the criticality of the error will be used as an autotag predicate.

- auto tag: criticality value Errors: low, criticality Errors: medium, criticality Errors: high.

Here, each value of the severity of the error (low, medium, high) is the value of the autotag of the autotag fidelity.

Here was announced / created a product for autotag errors. In computer terminology, this triple can be interpreted as: the product for error is an instance of the AutoTag Class.

- auto tag: name "Product";

- autotag: predicate example: product.

Now the product is an autotag predicate.

- # The first option to determine autotag values for links (enum properties)

- # direct definition

- @ prefix products: <http://comindware.com/examples/products#>.

In the following lines, Product1, Product2, and Product3 will be defined as an instance of the Product Class. They will also be assigned headers (names).

Auto tag values can be determined manually or can be found automatically. In the above lines, Product1, Product2, and Product3 have been defined directly / manually as auto tag values. Manually created autotag values must be created each time a new Object is created or changed. Also, if an Object is deleted by autotag (s), autotag values must also be deleted. Rules can be used to avoid manually creating / defining autotag values.

- # second option for determining autotag values for links (enum properties)

Defining auto-tag values through rules can be used instead of directly defining auto-tag values. The rule-based method is a more acceptable method for determining auto-tag values.

It is worth noting that the meaning of expressions written in N3 in facts and rules can be easily understood without programming knowledge. In this description of the invention, parts of the statements are referred to as descriptive names. So "creatorAutoteg" is an autotag for the author; "example: creatorAuto tag and auto tag: Auto tag;" means that "example: creatorAutotag" is an autotag, "cmw: creator and cmw: Property;" means the creator is a property; "cmw: creator cmw: property name" Created by: "; means" Created by: "is the name of the property;" cmw: creator cmw: type Property cmw: Property of the Account; "is the account that is the type of property; example: creator Auto tag: the name "Created by" means that "Created by" is the name of the autotag, etc. Therefore, the code described in this invention can be used as a description of the features of the invention.

For example, the “Product For Errors Auto Tag” part of the statement could be interpreted as “Auto tag for the product for error” or “Auto tag with the name“ Product for Error. ”In other words,“ Auto tag that associates the Product with a Error. ”Another example is“ cmw: auto attributes Properties ", which can be interpreted as property attributes or property attributes. Another example: the" creator Auto tag "part of a statement can be interpreted as an Auto tag with the name" Creator "or the author, that is, the person who creates something: for example, a task or Errors.

As mentioned above, N3 is based on RDF standards and is equivalent to RDF / XML syntax, but it has additional features such as rules and formulas. Rules can be written in N3, OWL, XNL and others.

A simple rule (rule N3) might say something like: if X is part of Y, and if Y is part of Z, then X is part of Z, or

The combination of brackets "{" and "}" and "=>" is the rule. Curly braces enclose a set of statements and represent a formula. All formulas are enclosed in braces. Besides the fact that the Subject and the Addendum (the Subject in the formula is represented by two statements, and the Addendum in the formula is represented by one statement) the triples are the formula, the example shown above is a single statement. The formula is part of the rule and can be represented by a set of statements (at least one statement), where the rule is also a statement, and where the statement is a triple.

In the above statement example, "? X" is a variable (or an unknown value, the desired value). It is worth noting that "? X" is not always represented by an unknown quantity, on the contrary, a known part of the statements (in the form of URIs) of "? X" can be used to verify the authenticity of the fact. As mentioned above, any data, such as an entity, an event, and others can be described by a triple. The troika can also describe a fact, for example, “Bill is Man,” “John is Man,” “John’s position is manager.”

If the triple is similar to this: “? X is Man,” then all objects (which satisfy the statement) will be found. But, if part of a statement such as “Bill” and “John” is used as input for “? X”, then this statement can be checked for “true” or “false”, i.e. whether this triple (triples) is stored among triples. For the current example, after replacing "Bill" and "John" with "? X", the following statements: "Bill is a Man" and "John is a Man will be true, because these triples are stored in the database. If you use the statement"? X position manager "and" John "and" Bill "will be used as input parameters for"? x ", then only the statement" John position manager "is interpreted as true, but the statement" Bill position manager "is false, because this triple is not stored in the database data (and not derived from triples (triples)). If none of the variables "? X" is not associated with the value in the top three "? X is a man", then this trio is used to find anything that fits into the top three this, that will be found, "Bill" and "John."

In the above example, "=>", used here as a special predicate, means "follows". It is used to relate formulas. In fact, this is a short URI log: it follows either: http://www.w3.org/2000/10/swap/log#implies. When two formulas are connected by means of “log: follows”, they are rules, as mentioned above, all rules are different kinds of statements. The formula provides items that can be represented using current RDF / XML; these rules are not part of the standard RDF syntax.

The left side of this rule states that all instances of the Product Class are searched in all saved triples. The right side of the equation says that all the values found on the left side of the formula are acceptable / possible values for the product "For Error AutoTag" autotag.

In this case, the following instances will be found: "products: Product1.", "Products: Product2" and "products: Product3", i.e. instances that have been described by the triples above: "products: Product1 as an example: Product;", "products: Product2 as an example: Product;", "products: Product3 as an example: Product;".

In other words, this is an indirect definition of the value for the autotag "productFor AutoTag Errors."

As mentioned above, directly defined values for autotags must be updated by the software developer (or by someone else with the necessary permissions) each time an object is created or modified. These values must be deleted after the removal of the corresponding Objects. Thus, if the object "Product4" is added (for example, if a new triple is created or automatically generated - products: Product1 and example: Product; "and optionally added to the database), then the triple" example: example: productFor Errors Auto tag: value Products: Product1, Products: Product2, Products: Product3. " should be replaced by the three "example: example: productFor Errors Auto tag: value products: Product1, products: Product2, products: Product3, products: Product4." After a new Object is created by the user, new values are searched for for the autotag using the engine 305 using the "determine by rules" method (here the autotag values are the result of processing data / triples by software).

For example, if a new product is created, it is converted by the engine 305 into at least one triple, for example, into the following triple: "products: Product4 and example: Product;", and other necessary triples, such as "products: Product4 cmw: title" Software event management software, version 2.5 "." Filter of Event Interceptor with Object "310, which is part of engine 305, intercepts all events with Objects." Structured Data Processing Module "315, which is also part of engine 305, translates all events with Objects and triples.) When creating an Object for an autotag, acceptable / possible values corresponding to the added Object are searched.

It is worth noting that triples for a new or changed Object can be added to the database (or in RAM and / or cached) during the configuration of the Object parameters, i.e., if at least one of the objects is created or changed, it can one or more triples are generated and saved to the database before the Object is saved. This set of triples describes an object, relations of an object with other Objects, a data warehouse where triples of objects are stored. It is worth noting that these mentioned triples can be created / recorded manually by the developer, user, database administrator, etc. Also, such triples can be created by software.

Saving the Object (storage in RAM, hard disk, Network / Cloud storage, etc.) can be an intermediate saving, for example, when the parameters and attributes of the Object are saved during the configuration of the object. Full saving can also be performed when the user, system administrator, developer, database user or administrator decides whether the Object is sufficiently modified / configured / configured for current purposes. It is worth noting that the object and its parameters can be changed / reconfigured in the future, for example, a new ontology can be added, the Object can be marked as an autotag, and so on.

It is worth noting that acceptable / possible values for the autotag can be found not only after creating the Object, but also during the search request (search request (s) will be discussed below) from the user (in fact, the system sends a request to search for data (converted from a user search query) -> auto-tags are searched for this data -> auto-tag values are searched using auto-tag predicates -> auto-tag values are used to search for Objects to form a response to a search request from the system). So, as described above, the rule is used to search for auto-tag values (the so-called auto-tag calculation), which are necessary for searching for Objects using search words.

Thus, the rule-based determination method (indirect determination method) replaces the manual addition of auto-tag values. It is worth noting that the method of determining by rules does not limit the ability to manually add triples, including parts of statements, including properties / attributes and values. It is also worth noting that manually adding triples does not limit the ability to automatically add triples, including parts of statements, including properties / attributes and values.

The combination of manual and automatic / software methods for adding / creating triples can be used to fine-tune / more detailed description of Objects or the system as a whole (for example, such a system can be a system for tracking and correcting errors in a user service system, a personnel management system, etc. .). Also, it can be used to automate the description / definition of an object, for example, in the case of duplicate parameters of Objects using the parameter of similar / related objects, similar triples, including ontologies. Ontologies are used for descriptive information of the Object, which can be obtained by calculation (from the rules) and can be written in the code as axioms. It is possible to use several ontologies for an Object, and one ontology can be used for several Classes, for example, for similar Classes.

. Данное правило используется для поиска следующих значений автотега: критичностьОшибки:низкая, критичностьОшибки:средняя и критичностьОшибки:высокая для автотега серьезности ошибка.Regarding the method of determining by rules, it should be noted that in a special case, another rule can be used, namely for the autotag of the severity of the error:

. This rule is used to search for the following auto-tag values: criticality Errors: low, criticality Errors: medium and criticality Errors: high for auto-tag severity error.

Further, another example of an autotag (for an author) includes a search for autotag values:

These two lines introduce the property attribute (some kind of flag) for the AccountAttribute tag. Each error creator is flagged with this flag, i.e. each creator will have an attribute attribute AccountTag.

On the left side of this rule is a formula, and the formula consists of two statements. The first statement searches for all items with the AttributeTag attribute as a property attribute. The second statement searches for all objects that are associated with the predicate name Property, and these objects are stored in the variables "? Property" and "? Name". Thus, all objects found and stored in variables are transferred to the right side of the rule. In other words, all pairs for the predicate PropertyName will be found and passed to the right side of the rule.

The first two statements on the right side of the rule state that all things found on the left side of the rule are auto-tags and predicates of auto-tags. The third statement consists of using the data stored in the variable? Name as autotags. The fourth statement declares the Account as a type of autotag.

As mentioned above, this method allows you to define / declare properties, names, types, predicates, etc. autotag.

The following is an example of indirectly determining auto-tag values:

In the first statement of the left part of the rule, a search is performed for all items with auto-tags like account. The second statement of the rule searches for all items that are accounts, i.e. Objects used as instances of the Class account: Account.

All items stored in the "? Account" on the left side of the rule are auto-tag values on the right side of the rule.

Up to this point, only one predicate has been described for an autotag, however, an autotag can have more than one predicate, so the search area for an autotag can be significantly expanded. All autotag predicates belong to one common group, which, in turn, can be divided into several groups to expand search capabilities.

An example of defining several predicates for a single autotag (in this case for "example: user Associated with an Error AutoTag"):

This creates an autotag with the URI "example: user Associated with Error AutoTag". This autotag is used to establish the connection (s) between the person and the error. Such relationships may be represented by the error and the error creator (in some embodiments of the invention, the error creator is the person who discovered the error and / or created the Error Object). A developer, an error corrector, a user, a DBA, or a system administrator, an operator, and others can be such people. The following statements show that some people may be associated with the error, for example, the error creator and the developer / or error corrector that will correct the error. In other words, in this case, the error can be associated with or assigned to the person responsible for this error.

Here for the autotag "example: user Associated with Error AutoTag." two predicates of the autotag "cmw: creator" and "example: error corrector" are defined. Auto tag predicates are auto tag features. Based on predicates, you can tell which search region an autotag belongs to. In other words, the autotag predicates of a particular predicate belong to the same type. In this example, the predicates of the cmw auto tag: creator and example: Error corrector that identifies a person / person (for example, for the user tag "User Associated with Error AutoTag"). The previous example shows that the values of the? Property were obtained using the triple "? Property cmw: attributesProperties auto-attributeAccountTag" and one type? Property is used. In the following example, the values of the? Property are used as autotag predicates.

All items (here - accounts) are searched on the left side of the rule. All items found (which were recorded in the "Raccount") are auto-tag values for the auto-tag example: user Associated with Error Auto-tag on the right side of the rule.

- # Examples of queries. Information entered by the user (in the GUI) for the search will be converted into a query, for example, after the user clicks on the "Search" button.

- @ prefix request: <http://comindware.com/ontology/query#>.

- # Example request for "Or" and "And"

- # Find by Product1 or Product2 and Criticality Errors: High // Exact

The following is an example of a search query for errors with high severity status and associated with Products1 and Product2.

In the first statement of the left part of the rule, all pairs with the common predicate "example: product" are searched. The second statement is a complex statement and is written using the Comindware Language. In this example, the Comindware language allows you to use the logical operator "or" for "products: Product1" and "products: Product2" as the variable "? Product". In other words, the first statements written above can be described as: find all pairs "? X +? Product" with the predicate "example: product", where the variable "? Product" can be the value "products: Product1" or the value "products" : Product2 ". All items (in this case errors) with a status of high severity will be found in the third statement of the rule (on the left side of the rule).

On the right side of the rule, all items found are recorded in the variable "? X" and are the result of the query "query: 42".

Here, “query: 42” is an interpretation of a search by a user search query. The above example describes the search for all errors for "Product1" and "Product2". This example can be considered as: the user enters "high" as a search word in the GUI text field; the system associates the entered word with at least one element of the statement (in this case, “criticality Errors: high”) based on the analysis of the statement. The criticality statement Errors: high cmw: highValue name can be one of the following assertions. The statement element will be associated with the predicate “autotag: value” (this can be seen from the statement “example: criticality Errors Auto tag: value criticality Errors: low, criticality Errors: medium , criticality Errors: high. ").

Then the system will find all the Objects using the specified rule, for at least one of the mentioned autotag predicates (in this case, the predicate "example: criticality Errors" from the statement "example: criticality Errors Auto tag: predicate example: criticality Errors;"). It is worth noting that any type of request read by a computer / processor / application can be used. Here, the request characterizes and describes the request from the user, and the result (s) of the search for autotags are stored in the variable "? X".

The following example is an alternative implementation of a search query for errors of high severity status that relate to Products1 and Product2.

A method is implemented here using list: member instead of or. As in the example above, the first two statements can be described as: find all pairs "? X +? Product" with the predicate "example: product", where the variable "? Product" can have the values "products: Product1" or "products: Product2 ".

The following is an example of searching for all autotag predicates that are associated with a search word, and all autotag values that are used to search for an Object.

In this example, the string "in? Tag,? Values." according to the syntax used, means that the values of "? tag" and "? values" must be defined before they are used in formulas. In other words, in the example below, these variables are defined in the statement "(example: criticality Errors Auto tag (criticality Errors: high)) query: auto tag Request? X.".

The second rule is similar to the above example query / search query to search for an Object. The search for the Object itself is performed in the first formula, in which the found objects are stored in "? X"; and "? values" and "? tag" from the second rule are used as input parameters. In other words, the first rule is called from the second rule with certain parameters - the values "? Tag" and "? Values".

In the left part of the first rule: pairs with the common predicate "autotag: predicate" are searched. And the statement elements ("example: example: product For Errors Auto tag" and URI "example: criticality Errors Auto tag") are used as input parameters for the? Tag. Due to the fact that the above source code contains the triple “example: criticality Errors Auto tag auto tag: predicate example: critical Error Errors;”, couple “example: criticality Errors Auto tag + example: criticality Errors” will be one of the found pairs, and couple “example: example: product For Errors Auto tag + example: product "will be the second pair found, as you can see from the source code provided.

On the right side of the first rule, the contents of the brackets (? Tag? Values) are an array / list of two elements / variables. It is worth noting that a list or sequence is an abstract data type that implements a finite ordered set of values, where the same values can occur more than once. An instance of a list is a computer representation of the mathematical concept of a finite sequence; an infinite (potentially) counterpart to a list is a stream. All items found (and stored in the variable “? X”) on the left side of the second rule are the result of the search query “query: 42”.

It is worth noting that in the first statement of the left part of the second rule "(example: example: productFor ErrorsAutotag (products: Product1 products: Product2))" is a list of two elements, where the first element is "example: example: productFor ErrorsAutotag" and the second element - list / array consisting of the elements "products: Product1", "products: Product2".

The following is an example of a transitive autotag. Transitive autotag can be used to search for an Object where the Objects are linked to other Objects. For example, such autotags can be used to search for Objects in the Object group. A group of Objects can be created for several Objects in order to provide links / relationships between Objects. In this case, such related Objects (for example, related by at least one group / family) can be found by the characteristic, which can then be used as a predicate of an autotag. In this case, the predicates “example: family of Products” can be used to establish that an object belongs to at least one group / family. It is worth noting that some common attributes / properties of Objects can be described and used for all Objects in the group, for example, for the severity / priority of an error or task belonging to the same product, etc.

In this part of the code, the statement element “Example: Product Family” is defined as Class. The following are “Product families: Family1” and “Product families: Family1” are defined as instances of “Example: Product Family”. The concept of a product family is also introduced. Such families can be used to search for Objects (products in this case) that are included in the family. This can be implemented by declaring the properties of the approval element and used to search for errors that are associated with the family, for example, products that relate to Corporate products. Such properties can be used as auto tag values for searching for Objects. As mentioned above, the Object has the mentioned attributes, such as name, attribute properties, property types, etc. It is worth noting that some attributes can be assigned to the Object by default, for example, by using ontologies that may contain facts and / or rules.

It is also worth noting that additional rules can be used (outside ontologies). For example, the attribute name of the Object can be assigned from system data, an external application / module, combined from another name of the Object or attribute or property. For example, a counter (each Object can be numbered according to the counter) or the current date can be used to add to the attribute of the Object, for example, Object 001, Object 002 or Error_10_10_2014.

The result of this rule will consist of associating errors "? Error" with products (or more precisely family of products "? Family") using the predicate "example: transitive Error in Product in Family Predicate", and besides this, the search for "? Error" "? Family" is performed in the left part of the rule.

The following is an example of the definition of autotag for the property presented above.

This rule is another demonstration of the automatic search for autotag values without the need to define them manually, although the implementation of the present invention also allows the use of manually written autotags and their predicates, values, etc. It is worth noting that one of the implementations of this invention allows the combination of all of them. In the above examples, the Search for Objects is performed among all possible autotags and all autotags that are associated with the search word. However, the user can select at least one of the search areas (FIG. 5), which can be used to search for Objects. Search for Objects in the designated search area can be implemented using rules.

According to an exemplary embodiment, the names of the autotag predicates can be displayed to the user in the form of search areas using the GUI. For example, the word “high” entered by the user is the name “criticality Errors: high” (as seen from the statement “example: criticality Errors cmw: optionValues (criticality Errors: low criticality Errors: medium criticality Errors: high).” And “criticality Errors: high cmw: variant Values“ High "."). In turn, the importance / criticality of the error property has the name "Error Criticality" (see the statement above: "example: criticality Errors cmw: property name" Error Criticalism ";"). This name can be used as a search field. Also, as can be seen from the source code, the criticality of the error is a predicate of the autotag (see the statement above: “example: criticality Errors Auto tag: auto predicate: predicate example: critical Errors;”), and the automatic tag is named “Critical” (statement from source code: “example: criticality Errors Auto tag autotag: name "Criticality"; "), which can also be shown to the user as a search area.

Auto tag searches can be performed in at least three ways:

- the user knows the property of the object by which he wants to search; for example, by “executor” or “manager”. If the user selects "manager", the system will offer the user one of the autotags associated with the selected property of the Object, for example, "ManagerName". After the user selects the corresponding autotag and then selects the username from the list, the system will save the autotag and autotag value (the autotag predicate can also be saved). This stored data can be used to further search for Objects and / or to search for all objects associated with the current Object.

- the user knows exactly who / what needs to be found (i.e., he knows the name of the Object). The user can enter “Bill”, and the system will provide him with auto tags such as “artist”, “manager” and other auto tags associated with the entered search word “Bill”. In this case, the name of the object is known, and the corresponding auto tags are searched for it. Then the search process is performed as described in the previous paragraph.

- The user can enter the search word, but he does not know which search area suits him, so he can select the search in all autotags using the logical operator "OR". In this case, the user will be shown all the search results (whose predicates are associated with the search word).

A portion of several auto tags may belong to a set (s) of auto tags. In other words, a set of autotags can be created / described for the severity of the error, for the product, and so on. The autotag values from the autotag set will belong to this autotag set. Depending on whether a search is performed on Objects belonging to one or several different sets, the search for autotags is performed using the logical operators "AND" and "OR". The OR operator is used to search for Objects with autotag values from the same autotag set. For example, if the user wants to find an error with the criticality of "High" and "Low", then the "OR" operator will be used, and the query can be interpreted as "search for all errors whose priority is High OR Low." The AND operator is typically used to combine search queries from various sets of autotags. In the framework of this invention, an autotag can be defined by an autotag predicate, an autotag property, an Object property.

The contents of the Object can be analyzed in the process of searching for the Object, i.e. the text of the main body of the Object, the contents of the text fields of the Object, attached documents can be parsed during the search for the Object. Parsing or parsing is the process of analyzing a string of characters, either in natural language or in computer languages, in accordance with the rules of formal grammar. Instead of parsing, a search can be made in such elements in these languages. Such a search or parsing can be provided by third-party modules (in addition to a search engine, which, for example, can provide a full search in Objects). However, for such a search, auto tags can be created, for example, to search for data in the contents of the Object.

Such autotags may reflect the nature or emotions of the data / content. Such autotag values can be described based on an analysis of the object's data, for example, such data can be contained in the description of the Object, in the attachments of the Object, etc. So, if the data of an object or attachment contains content elements (words or a set of words) of "A", "B", "C" and "D," then "ABCDE" can be considered as the AutoTag value. Such summarized content may be shrunk before being used as an autotag value, for example, it may be cached. Such content elements may be common elements in various Content Objects. So conclusions can be made based on the data of the Object, and these conclusions can be used as values of autotags. For the analysis described above, semantic analysis of these objects can be used.

It should be noted that the above-described example of the invention (when the user initiates the process of searching for Objects) is also called on-demand and on-demand search. It is worth noting that previously found autotags, autotag values, and autotag predicates can be used in a further search for data / items that can be initiated by the user or the system. Such found auto-tags, auto-tag predicates, and auto-tag values can be used to search for Objects (which correspond to custom search words and selected parameters) that have not changed since the last search query.

In this case, the on-demand search method provides relevant search results, and there is no need to start a new search process. It is worth noting that objects that changed after the last search can be marked in the list of changed Objects. The list of changed objects can be used during an on-demand search for a signal to the system - for which Objects it is necessary to find the values of autotags again, and for which Objects the values of autotags are relevant.

FIG. 3 illustrates a data processing algorithm according to one embodiment of the invention. The Object Processing System 305 in combination with the GUI is used to allow the user to create, delete, and edit Objects. System 305, through use, Module 315 converts user actions on Objects into triples and stores them in Database 390.

The triples are stored in the database (s) that can be stored on a data warehouse, such as a local data warehouse, cloud storage in cloud services, SAN, NAS, various web services and others. It is also worth noting that any known data storage system (for example, data serialization can be used to store data, for example, in xml format) can be used instead of the Database. The triples can be saved in database format or in triples format.

The user can create a new task with the heading "Add a new color image with a mobile device to the product folder" for the employee "Maxim" (who is its executor) and associate this task with the product, for example, "Comindware Process," i.e. this will associate the task with the product to which the task belongs. Also, the user can change the status (from "Open" to "Closed"), the title and other properties of the Object. In this case, System 305 converts the result of user actions into triples, so, for example, the triple “Task Status Closed” is created and replaces the triple “Task Status Open” in the database 390. Actions with objects (for example, editing, creating, deleting , moving the Object between groups, etc. by the user; or by the system, for example, deleting the Object after three years after its creation; or by an application, for example, a third-party application / module, such as the “Comindware Project”) are monitored by the Action Filter-Action Interceptor module C about Object 310. One of the tasks of this module is to track the need for marking / unmarking from the Object as potential for generating an auto tag. As an example of actions initiated by the system / application, the automatic closing of an error after the termination of technical support for a product (for which an error was created) can be considered. Another example of such actions is the creation of an error (and / or the creation of a task for a given error) by the system / application after an error is detected by the user or the software debugger, or through the "try-catch" function.

System 305 also sends at least one request to the Auto Tag Processing System 320 to search for an Object, according to the search word. The request initiates the Object search process (in System 320) by using the rules mentioned above to search for auto-tag values. A “request” may be considered as an example of such a request. The result of the operation of System 320 is at least one Object found. It is worth noting that a “zero” result can be obtained from System 320 if not a single Object is found in the process of searching for Objects.

According to an exemplary embodiment, auto-tags, auto-tag predicates, and auto-tag values can be stored in RAM, including their optional caching. Such data stored in RAM can be used, for example, by the GUI to display the found Objects and to further search for Objects, which can be initiated by the user by using other search words and the same or different search field (s). Search areas can be expanded by the user.

The Module for Defining Associated Objects 330 is responsible for identifying relationships between Objects with each other. An example of Object links is the "transitive auto tag", which is used to establish direct or indirect links between Objects. A direct connection of an object can be represented as a link between two objects, and an indirect connection of an Object is a link to another Object through at least one other Object. Relations between objects can be established by using rules and using the description of objects, properties of the Object and can be represented in the form of an autotag and predicates of autotags.

Since the Object or the properties of the Object can be changed during its lifetime, the same values of autotags for the Object must be found again. Here is an example of a case where it is necessary to find the autotag values again: an error was found in Product 1, which is part of Family 1. After a certain amount of time, Product 1 was moved to Family 2. In this case, all the values found for autotags for the error must be found again because his relationship with Product 1 and Product 2 has changed. It is worth noting that earlier autotag values were found for the Objects (Product 1 and Product 2) associated with the current Object (an error in this case).

The search for autotags, autotag predicates, and autotag values for related Objects is performed on the basis of the data received from module 330 (and data from RAM) and from database 390. As mentioned above, the result of previously found objects and all data associated with them can be saved in RAM. Using data from RAM can increase the speed of performing further searches. Data from database 390 can be obtained (and used by System 305 and System 320) in the form of triples, a list of Objects with links, and in other forms. The data of Object links (and associated auto tags, auto tag values, auto tag predicates) can optionally be stored in database 390 (or in another database that can be used to store triples of related objects) or in RAM for further processing. For example, such Object link data can be used for a second search query from a user or from a system.

The autotag processing system 320 uses data from the module 330 and from the database 390 via the optional triples processing module 360. The optional module 360 is responsible for presenting data from the database 390 in a form suitable for the autotag counting system, for example, if such data were not saved in the format Subject-Predicate-Addition, but in DB format. Data can be converted using the database or modules instead of being converted in the 360 module. It is worth noting that the 360 module is responsible for applying the rules to facts from the database. The module 360 may be part of the Semantic processor 840 (FIG. 8) and perform all of its functions or part of them. Also, module 360 is responsible for presenting data from the Object Processing System 305 to the database format. If necessary, data from the Object Processing System 305 can be written to the database 390 after converting the data to the appropriate database format.

FIG. 4 illustrates a flowchart of a part of an Object search process (406) containing a search for autotags for modified or created Objects. As mentioned above, auto tags and other data that are necessary for the Object search process can be found for related objects. An embodiment of the invention that does not use on-demand search for auto-tags, auto-tag values and auto-tag predicates is shown in FIG. 4. As mentioned above, auto-tags, auto-tag values and auto-tag predicates can be found when the user asks to find objects using search words (here auto-tag and other data will be found on demand) or when the Object changes or a new Object is created. After creating or modifying the object (for example, by the user) in step 405, the process proceeds to step 410.

At step 410, the process determines whether the current Object is associated with other Objects. Relationships are established during the creation of a new Object and during the association and reassociation of Objects with each other (for example, a task can be reassigned to another user or linked to a second Product, or the Product can be moved to another Project or Family, etc.). If the current Object is not associated with other Objects, then in step 430, the process searches for autotag, predicates, and autotag values for the current search words. Next, the process proceeds to step 455, in which the found auto tag, auto tag predicates and auto tag values for the Object are stored in RAM or a database. It is worth noting that steps 410, 430 and 440 are steps of the object search process. It is also worth noting that the found autotag predicates and autotag values can be sent to an external application, for example, if the search query was sent by an external application or the search result must be processed by an external application (for example, to display to users after conversion to a displayed format). It is also worth noting that auto-tag predicates and auto-tag values can be converted to an external application format.

If at least one related Object is defined in step 410, the process proceeds to step 440, in which the values and predicates of autotags for related Objects are searched. Next, the process proceeds to step 430. It is worth noting that previously found values and predicates of autotags are deleted if the user or system deletes the corresponding Object. If the Object changes, the predicates and autotag values must be found again. Also, for related Objects, it is required to find again the predicates and values of autotags.

It is worth noting that the method of propagating autotags with weights, i.e. an autotag predicate can be assigned a weight. This weight is used to search for objects outside the found autotag predicates using the previously described method for searching for Objects using autotag predicates.

Here we describe the weights of the autotag predicates and their use. To describe an example of using autotag predicate weights, many predicates are used. In this example, many predicates describe family relationships within a family. For example, a person has a mother, father, sister, cousin, and second cousin. “ConnectionsAutotag” is created to describe the type of connection between family members: “MotherMan Communication”, “CousinMan Communication”, “second cousinMan Communication”, “second cousinMan Communication” and “sisterMan Communication” of this autotag.

Mother, father and sister are close relatives, a cousin is a distant relative, and a second cousin is the farthest relative. The distance along the family tree of the Object (a person in this case) can be described by the weight of the autotag predicates. The closer this relationship with the Object, the higher the weight of the autotag predicate. Thus, the predicates mother of the person Communication, the father of the person Communication and sister of the Communication person have more weight (for example, the weight is 1) than the predicate cousin Human Brother Communication (weight 0.7), but the weight of the predicate the second cousin Human Brother Communication will be the smallest and will be equal to 0.3. In the above example, sister, cousin, brother are Objects.

The weights described above can be used to search for such Objects, i.e. it is possible to find Objects by predicates of autotags with weights that are more than 0.5. In the described example, the Search for Objects is performed using the following predicates of autotags: the mother of the PersonSvyaz, the father of the PersonSvyaz, the sister of the PersonSvyaz and the first cousin Brother of the PersonSvyaz, and the predicate of the autotag the second cousin of the HumanSvyaz will not participate in this search.

It is worth noting that weights can be assigned to autotag predicates manually and saved (i.e., for example, they can be saved to the database by the user, developer, database administrator, etc.) during the process of creating and configuring the Object. Also, autotag predicate weights can be calculated and assigned / added to them. Autotag predicate weights can be calculated using rules and the surrounding context, such as ontologies, data of the current Object, and data of other Objects. For example, if the error was created Friday, then the weight of the predicate for this error may be higher. The calculated weight can be added to the autotag predicate. In one embodiment, calculating the weight of an autotag predicate can lead to adding, increasing, decreasing the weight of an autotag predicate (including reducing the weight to zero, meaning that the autotag predicate has no weight or that the weight is infinitely small).

The autotag predicate name can contain the weight in explicit or implicit form: the predicate weight is bigMessManCommunication can have a weight of 1 (the "bigWeight" in the predicate name is associated with units of weight), and the average Weight of a HumanCommunication can have a weight of 0.5 ("MediumWeight"). It is worth noting that the weight in the name of the predicate can be determined directly, for example, WeightOneMotherManConnection, Weight1MotherManConnection, WeightHalfOtherManManConnection, Weight0 Point5FriendManConnection.

It is also worth noting that the presence of certain words or phrases in the name of the predicate can affect the weight of the autotag predicate. For example, words such as mother, father, wife, sister, brother, important, interesting, WOW, dazzling, great, etc. can realize higher weights for autotag predicates, while a small, weak, listless, dark, cousin can realize lower weights. In other words, the semantics (meaning) of the part of the autotag predicate names can determine the weight of the autotag predicates.

Here is an example of using autotag predicate weights for the search order of Objects. The search for relatives of Michael (who is the second cousin of William's man) is performed using predicate weights for autotags. For example, the search for Objects (in this case, Objects are relatives) is performed in descending order of the autotag predicate weights. In this case, the closest relative will be found first (mother, father, brother, etc.). After that, distant relatives will be found (mother-in-law, cousins, second uncle's nephew, etc.). Also, as was said earlier, after being found, these found Objects can be used or can be saved as array elements (ArrayList) in RAM or data storage.

Propagation can be used to define at least one additional predicate that is also involved in the search for Objects. An autotag predicate can be used as a propagation parameter (i.e., an additional descriptor). For example, the predicate of the autotag "cmw: creator" can be supplemented with the descriptor "propag", which means that the predicate is propagated by the following predicates "main predicate predicate propagate target predicates", through the predicate "example: correct Error".

Propagation weight can be configured to avoid calculating weights for duplicate links to Objects. For example, an error has the text field "same_as_this_error", i.e. Duplicate links exist and are stored in a database or presented in a virtual form of links / links calculated on demand. Virtual connections in this context mean relationships that can be found using rules, ontologies, etc. For example, Bill changes similar / identical errors, so that Bill (if propaganda is not configured, i.e. default propagation is used) can be assigned large weights, since each error affects a different one.

In order to avoid this, duplicates can be ignored and not used when searching for Objects. In other words, the search system can consider such duplicate errors as one error or consider these links between errors as one link. It is worth noting that in this context weights of relations are considered, and not the weights of predicates, i.e. the estimated weight of the predicate is considered. It is also worth noting that such duplicates can also be assigned small weights, for example, the weight value can be equal to 0.00001, so that it has little effect on the sorting of the found Objects. It is worth noting that by adjusting the values of the weights, you can build a flexible system for searching Objects taking into account the values for the weight. Such a search engine is able to automatically distribute weights based on algorithms and / or previously obtained data.

The weight of the Object (and its position in the sorted list of found objects) depends on the autotag predicate that was used when searching for Objects, i.e. Objects with small weights (for predicates of autotags with small weights) are located closer to the end of the sorted list of Objects than Objects with large weights. It is worth noting that the predicate weights of autotags are also used to establish the depth of the Search for Objects. The weight of autotag predicates and search parameters determine whether a particular Object will be found, or some other Object, or nothing will be found.

In one exemplary embodiment, the propaganda described above for an automobile and automobile parts can be used. The car consists of the following parts: doors, bumpers, trunk, hood, wings, etc. Each of them is an instance of the Class, named for the part of the Car and are Objects. Color is a property of an object. Let's say that Color is propagated through parts of the car. The Car 1 object is an instance of the Car Class. Color Red can be used as a search term for Objects, i.e. user wants to find Red Car. In this case, the colored parts of the car can determine the color of the entire car, i.e. if one of the parts of the car has a red part, then the color of the car is red.

In another example of the invention, the color can be propagated through at least one predicate, for example, a door predicate (left_front_door predicate, right_back_door predicate), bumper predicate, trunk predicate, hood predicate, wing predicate, etc. For example, a bumper is 5 percent of the entire car, so the weight of this predicate is 0.05. The weight of the door predicate is 0.1, the weight of the trunk is 0.2, the body is 0.5, etc. The database is supposed to contain the following data for Car 1: the front and rear bumpers are Green, the body is Green, the trunk is Red and the door is Black.

In this case, Car 1 has 60 percent of the parts painted Green, 20 percent of the parts painted Red and 10 percent of the parts painted Black (the front left door has been replaced and has not been painted yet). Another Object, Car 2, may contain 40 percent of the parts painted in Green (painted in trunk Green and two front doors painted in green), and also contains 50 percent of parts painted in Red (in this case, the car body is Red ), and 10 percent of the car is black-painted bumpers.

When a user initiates the process of searching for Objects by Color (for example, Green is used here), the database can store (in the form of ontologies and / or rules) the fact that the car is Green, if the parts of the car painted in Green are more than 50 percent (i.e. e. the total weight of autotag predicates is more than 0.5), and the car is Red if the total weight of predicates is more than 0.4, and the car is painted Black and Red if the weight of predicates is more than 0.5 for Red and 0.09 for Black.

In this case, if the Object Search process is initiated by Color (1) Green, (2) Red or (3) Red-White, the search system will combine the predicates of the auto parts of the car parts during the search process, so that Car 1 will be found like a Green-painted car, and Car 2 will be found as a Red and Red-Black Car. It is worth noting that the weight of the autotag predicate is part of the total value (in this case, 0.1 is 10% of the color of the car, 0.5-50%, etc.). The input and operations with weights may vary, since weights may represent the value of a specific predicate, high priority, etc. so propaganda is an implicit / indirect relationship between Objects.

FIG. 7 illustrates an example of various business applications used in various departments of a company, and a data processing scheme therein. Data from the database can be divided into user data in the form of axioms, facts, rules, and ontologies (also represented as axioms, but which can be distinguished by the N3 syntax). In other words, ontologies contain information about what kind of data and how data should be presented to a specific user in a particular business application. Facts and ontologies are processed by the Kernel, and the result of processing is data in a certain context in accordance with ontologies.

Using RDF (Resource Description Environment), you can work with various data sources (i.e. databases, local data stores located on the corporate network or located on the Internet). It is possible to use the URI of a common dictionary, which allows you to integrate data from various servers. Also, based on data and rules, it is possible to provide data on-the-fly (unlike static slices (e.g. snapshots), as is done in OLAP cubes).

A pool of information (for example, data from all departments: IT (705), Development (not shown), Czech Republic (701), Administration (not shown), Sales (not shown), Accounting (703) can be stored in various databases or other repositories. Element 707 allows the display of contextualized business information for a specific application. "Global" is an entity for representing data in a 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 a 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 of them are combined in

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 a rule

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 an engine 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 data on one storage is changing, there is no need to change data on other storage).

Based on counted auto tags, search results obtained on the fly can be illustrated by the following example. Consider ontology data (i.e., data that describes managed entities) in the context of business applications, for example, project management, problem tracking, error tracking, CRM, etc. Each of them is stored in its own database (or, alternatively, in a common database), and which are combined at a higher level. Using the logical core, you can combine various available data into various combinations and sets of ontologies, for example, using special ontologies. The developer can see the context of the presentation of the error presented to the Quality Department in the form of the assigned task. In other words, it is possible to trace which task a particular error relates to.

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.

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 the presentation of data (search results) 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 "the solution is" you need more information "", the rule may be

;

- 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 programming language). An engine can 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.

Some types of rules may exist for data processing. A rule such as a filter is often used in tracker cases, for example, receiving a list of support / error / task tickets from a specific user and for a specific project with specific attributes. Therefore, the information should be filtered out from a common pool of tasks / errors / tickets for a specific user and project, and presented in the form of separate axioms.

Converting rules apply to the same information that may be presented in a different manner. For example, the IT department sees people as users of an IT system. On the other hand, the project manager can consider these same people in the form of resources working on specific tasks. In another example, the transforming rules may include the following: at the input, data (axioms) are obtained that describe a specific ticket (i.e., a request from a specific end user) and its presentation of data. Therefore, the engine will receive axioms at the output 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, which contains more than 50% of critical errors and more than 50% of critical tasks, the system will automatically generate a fact about the status of the project (that is, the status of the project will be marked as "Critical").

An example of applying the rules is as follows. Information is converted from the bug tracker and project fixes into data for the ABC project. Further, only errors with the “critical” status that will remain are filtered, and the engine will calculate the total number of errors, and then, if the number of “critical” errors is more than half the total number of errors, then the critical error state will be generated in the project:

The same operations are performed with data (tasks) from project management systems:

Next, automatic generation of the Critical project status is performed if the project has tasks and errors in the Critical states:

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

As will be understood by those skilled in the art, life examples are usually more complex than those described here, and there may be many more types of rules in most cases from real life, however, the principle remains the same.

An example of a conjunction of axioms is often the easiest to understand, for example, when combining information related to project requirements (axiom “requirements” - requirements defined by analysts) and errors from the bug tracker (axiom “errors” - errors discovered by testers who as a rule, are quality control specialists, and filled out error tracking forms based on certain requirements), the results are the "resulting axiom", which in essence is a combination of the number of errors associated with one functional requirement.

FIG. 8 illustrates a system in one embodiment of the invention. JSON / Ajax API 822 is a module for implementing the API method call protocol (Application Programming Interface) using the JSON message format and transmitting data via HTTP using Ajax requests. WCF API 824 is a module that implements an API method call protocol using the XML / SOAP presentation format and data transfer via HTTP.

API 826 Manager Module:

- Searches for the required API method,

- implements serialization of arguments into data structures used in ontologies of business logic,

- implements API method calls,

- deserializes the results returned by the method.

The API manager module 826 uses N3 files 830 (which contain triples in the N3 format) to search for the implementation of method 828, where the oniology api: Method (for example) contains all methods, argument types, and returns values. The implementation of the method is program code. For example, it can save data to a database or close or open a task and other operations.

For example, the CreateTask API method is used to create a task. The method takes the task data as an argument and returns the identifier for the created task. The JSON handler receives the method name and arguments (task data) in the JSON format, where the method is called using the JSON protocol. Next, the arguments are converted to an internal representation of the data in memory and passed to the API manager. The API manager (which has a list of methods) can find the required Create Task task by name. Next, the API manager checks the arguments (quantity and type) and implements the "Create Task" method. After creating a task using the Create Task method, the API manager returns the result to the JSON handler. The JSON handler converts the result to JSON format and sends it back to the client (for example, to MS Outlook client or to a mobile device application).

The API manager loads the API specification and extension modules from the Database during application startup (MS Outlook extension 807). This specification can be requested by Outlook extension / plugin 807 MS Outlook client 806 or through a special Ajax request or as a diagram in WSDL format using the SOAP protocol.

Web Client 802 (for example, based on JavaScript or HTML5) or Client Command Line 804 can be used instead of MS Outlook. The console client is a client application that can invoke API methods using the command line. A mobile application on mobile device 801 may also be used.

The JavaScript client is a client application that runs in a custom web browser and that can call API methods using the JavaScript language.

The Outlook extension (Outlook client) is a client application that runs in MS-Outlook and can call API methods using the WCF protocol.

The Web Services Description Language (WSDL) is an XML-based interface description language that is used to describe the functionality provided by the web service.

The WSDL description of the web service (also called the WSDL file) provides a machine-readable description of how the service can be called, what parameters it expects and what data structures it expects. Thus, it serves the same purpose as that which roughly corresponds to the purpose of a method signature in a programming language.

Client applications can then make calls using the reporting of Ajax requests in either JSON or SOAP protocol format.

The main stages of request processing are:

1. The incoming request is processed by the HTTP server (or an External server, or MS Exchange Server). JSON serialization or SOAP conversion to internal format is performed.

2. The API manager 826 accepts the input and checks the input arguments for compliance with the method description.

3. API manager 826 downloads and prepares the required data model and creates a model nugget to isolate it from other requests and operations. A write transaction is open if the operation changes the model data.

4. The program code (or rules with ontologies and Comindware ^® Language) is called that executes the method.

5. A transaction is closed if the operation is a modifying operation, and the security change is checked, conflicts are determined, and transaction history is updated.

6. The result is serialized to the format required by the client and passed to the HTTP request.

The application 820 business logic implements the object layer on top of the data warehouse. Access to data is provided through the client API, which contains methods for reading / writing objects (i.e., object templates, business rules, etc.) API calls by clients are implemented through sessions that are created after client authorization. This layer contains several system ontologies, such as, for example, a "custom object template" or a "business rule". Ontologies are used in the API for serializing and validating data.

Data Warehouse 842 provides physical storage for the data model on the hard disk. Data is sent to the data warehouse 842 and back in the form of facts (triples). The fact is the triple that is stored in the model. Also, a fact can be obtained by applying rules or queries. The data warehouse consists of:

- the stream storage of triples 858 allows you to record and query triples in a special file format. Streaming storage of triples supports several types of requests for various components;

- The transaction manager and casts 854 allows you to create:

but. transactions. Transactions are objects with an interface for atomic modification of storage triples. Changing the model is possible only within the framework of such a transaction, guaranteeing the atomic modification of the warehouse triples (confirmation of all changes made within the transaction, or none of them);

b. casts. Snapshots are objects with an interface for consistent reading from the triples repository. This ensures that none of the transactions (which were confirmed during the execution of the snapshot) will affect its contents.

- triples stored in the repository are simple, small objects (numbers, lines, names). The binary stream manager 856 is used to store large values (files, data streams) in storage. The stream is stored in a separate file, and a link to the stream is stored in this file;

- The data warehouse model 850 represents a set of interfaces for managing data warehouse 851. Such interfaces can include transactions, nuggets, an interface for querying facts (triples) from a nugget, and an interface for recording facts in a transaction.

- The semantic processor 840 contains a description of interfaces such as name, facts (triples), and model rule.

N3-converter 849 allows you to generate a data model based on the contents of the N3-file 830. (It should be noted that triples can be stored in the database in any format, as mentioned above). Combining with a data warehouse is another method of patterning. In addition, combined models can be formed, so that several models are combined into one. Requests to such models lead to a query of facts from each combined model. At the same time, data recording continues to be performed in only one of the models.

The 844 business rule engine is an optional add-on on top of the data model. After attaching the 844 handler to the model, it allows you to calculate derivatives based on existing facts and rules.

The 846 data model interface is a set of interfaces for querying facts from a model, for writing to a model, creating a transaction, and model snapshots. The 848 ontology serializer creates requests for obtaining objects from the entire model based on ontologies (a description of the structure of objects is stored in the model).

Transactions and queries are isolated using transactions. After opening a transaction for writing or reading, the transaction is completely isolated from other transactions. Any changes to the data model made by other transactions are not reflected in it. Conflict detection and conflict resolution is performed when closing a transaction that has been opened for writing. The so-called optimistic concurrency model is used. Definitions of conflicts occur at the level of individual semantic facts. The conflict occurs when a fact has been modified by two transactions after creating a model nugget and before closing the transaction. An exception will be thrown during conflict detection. In this case, the user can try to update the saved changes and try to confirm the changes again.

Optimistic Concurrency Management (OSS) is a concurrency management method for relational database management systems that assumes that several transactions can be completed without affecting each other and, therefore, transactions can be processed without blocking the data resources that they affect. Before confirming, each transaction verifies that no other transaction has changed the data. If the check reveals conflicting modifications, then the confirming transaction is rolled back.

OSS is typically used in environments with low data conflicts. When conflicts are rare, transactions can be completed without the expense of managing locks and without the need for transactions to wait for other transaction locks to be cleared, resulting in higher throughput compared to other concurrency management methods. However, if conflicts occur frequently, the cost of repeatedly restarting transactions significantly affects performance, and other concurrency management methods have better performance under such conditions.

More specifically, OSS transactions include the following phases:

Start: Record a timestamp marking the start of a transaction.

Modification: reading values from the database and pre-recording changes.

Check: Check if other transactions modified the data used by the current transaction (write or read). This includes transactions that were completed after the start date of the current transaction, and optionally transactions that are still active at the time of verification.

Confirmation / Rollback: If there is no conflict, make all changes effective. If a conflict exists, resolve it, usually by canceling the transaction, although other resolution schemes are possible. It is worth taking care to avoid the TOCTTOU (Time-Of-Check-To-Time-Of-Use) error, especially if the current phase and the previous one are not performed as a single atomic operation (see also a discussion of conflict resolution mechanisms between transactions, i.e. transactions not affecting each other mentioned above.)

With reference to FIG. 9, 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), which consists of basic routines that help exchange information between elements within the computer 20, for example, at the time of launch.

Computer 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 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 discs, 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 may enter commands and information into computer 20 using input devices such as a keyboard 40 and pointing device 42. Other input devices (not shown) may include be 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, which 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. In addition to the monitor 47, personal computers typically include other peripheral output devices (not shown), such as speakers and printers.

Computer 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, and typically also includes 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 network (GC) ) 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.

Claims (50)

1. The method of automatic tagging of objects introduced into the computer with tags for their search and retrieval from the database based on graphs, including: storage of input data, including axioms representing facts; obtaining input data objects and converting input data objects to an n-tuple format based on context; axiom processing in order to determine the subject, predicate and complement of the n-tuple; analysis of data objects and determination of indirect relationships between data objects; definition of attributes and properties of data objects; marking automatically generated tags (autotags) of data objects based on indirect relationships between data objects; autotagging of data objects based on the attributes and properties of these objects; storing in the database the received subject, predicate, addition, and objects marked with auto tags; ranking of objects in accordance with autotags; defining a search region based on data objects, where the search region is represented by n-tuple predicates associated with data objects; Presentation of search area options for specific search areas; receiving a request to search for data objects in the search area; and search for input data objects marked by autotags in a database based on graphs using predicates and autotag values. 2. The method of claim 1, further comprising automatically marking data objects based on context. 3. The method according to claim 2, characterized in that the context is determined by the corresponding ontologies and represents the environment of the data object. 4. The method according to claim 3, characterized in that several ontologies are used for one data object. 5. The method according to claim 2, characterized in that the context includes a method for processing axioms based on the nature of the data object. 6. The method of claim 1, further comprising calculating auto-tags on demand. 7. The method according to claim 1, characterized in that the data objects are represented by instances of classes. 8. The method of claim 1, further comprising propagating autotags to determine at least one additional predicate of the n-tuple, which is also involved in the search for Objects. 9. The method according to claim 8, characterized in that the autotag predicate is assigned a weight and is used to search for Objects outside the found autotag predicates. 10. The method according to p. 8, characterized in that the weight describes a tree of Objects. 11. A system for automatically tagging data objects with tags for searching and retrieving from a graph-based database, a system including: a data source configured to provide data for processing by the system; a data processing module configured to intercept and convert data from a data source into an n-tuple format and process axioms in order to determine the subject, predicate and complement of the n-tuple; and a processing module for automatically generated tags (auto-tags) connected to a data processing module and configured to receive a request for processing data from a data processing module, and also for tagging data objects with auto-tags based on indirect relationships between data objects and based on attributes and properties of data objects; and an object processing module connected to the autotag processing module and (i) configured to create, delete and edit Objects, and (ii) also configured to send at least one request to the auto-tag processing module to search for objects, and also ( iii) configured to convert actions with Objects into an n-tuple; and storing in the database the received subject, predicate, addition, and objects marked with auto tags; where the object processing module includes an event filter for intercepting actions with objects for use in processing autotags; and where the data include axioms representing facts; and Where: the data processing module searches for data objects marked with autotags; and the data processing module searches for data objects based on auto-tags using predicates and auto-tag values. 12. The system according to p. 11, characterized in that the autotag processing module is configured to perform any of: marking data objects with autotags based on indirect relationships between data objects; marking data objects with autotags based on the attributes and properties of data objects; and ranking of data objects according to autotags. 13. The system of claim 11, wherein the n-tuple is a triple of Resource Description Environment (RDF). 14. The system of claim 13, wherein the triple includes a subject, predicate, and addition. 15. The system of claim 11, wherein the data source is an RDF graph database. 16. The system according to claim 11, characterized in that the autotag processing module searches for objects tagged with autotags using a taxonomy. 17. The system according to claim 11, characterized in that the autotag processing module searches for data objects marked with autotags using a search query. 18. The system of claim 11, wherein the data objects are represented by multiple instances of classes. 19. The system according to claim 11, characterized in that the autotags, predicates of autotags and the values of autotags are stored in RAM. 20. The system according to p. 13, characterized in that the data object is determined by a set of triples. 21. The system according to claim 11, characterized in that the autotag predicate is assigned a weight and is used to search for an Object outside the found autotag predicates. 22. The system according to p. 11, characterized in that the weight describes the distance in the tree of objects.

Images