WO2017061901A1 - Система и способ обработки данных графов - Google Patents

Система и способ обработки данных графов Download PDF

Info

Publication number
WO2017061901A1
WO2017061901A1 PCT/RU2016/000203 RU2016000203W WO2017061901A1 WO 2017061901 A1 WO2017061901 A1 WO 2017061901A1 RU 2016000203 W RU2016000203 W RU 2016000203W WO 2017061901 A1 WO2017061901 A1 WO 2017061901A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
request
paragraph
rules
processing
Prior art date
Application number
PCT/RU2016/000203
Other languages
English (en)
French (fr)
Inventor
Максим Викторович ЦЫПЛЯЕВ
Петр Евгеньевич ВОЛЫНСКИЙ
Original Assignee
Общество с ограниченной ответственностью "Колловэар"
Максим Викторович ЦЫПЛЯЕВ
Петр Евгеньевич ВОЛЫНСКИЙ
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Общество с ограниченной ответственностью "Колловэар", Максим Викторович ЦЫПЛЯЕВ, Петр Евгеньевич ВОЛЫНСКИЙ filed Critical Общество с ограниченной ответственностью "Колловэар"
Publication of WO2017061901A1 publication Critical patent/WO2017061901A1/ru

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor

Definitions

  • This invention relates to a method and system for processing data graphs.
  • Any data types can be represented as triples.
  • the data in question include user data and ontologies.
  • Data can be presented, for example, in the form of an RDF graph.
  • rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  • the triple is the basic unit of the RDF Resource Description Environment (RDF) and consists of a Subject, a Predicate and an Object.
  • RDF Resource Description Environment
  • a set of triples is usually called an RDF graph, an example of which is shown in FIG. 1.
  • the direction of the arrow (for example, (110a, 1106) in any triple taken (for example, 120) indicates from Subject (130) to Object (140).
  • the RDF data model is similar to classical conceptual modeling approaches, such as entity-relationships or class diagrams, since it is based on the idea of creating statements about resources (in particular, web resources) in the form of Subject-Predicate-Object expressions.
  • the Subject denotes a resource
  • the Predicate denotes the features or aspects of the resource and expresses the relationship between the Subject and the Object.
  • a set of RDF statements is a labeled, oriented multi-graph.
  • the RDF-based data model is more natural for representing certain types of knowledge than the relational model and other ontological models.
  • RDF data is often stored in relational databases or in the native repositories of Trojans, or repositories of Fours, if a context (i.e. a named graph) is also stored for each RDF triple.
  • Named graphs are a key concept of the Semantic Web architecture in which a set of statements of a Resource Description Environment (graph) is identified using a URI, allowing you to create descriptions of this set of statements, such as context, origin information, or other metadata.
  • Named graphs are a simple extension of the RDF data model by which graphs can be created, but such a model is devoid of effective means of distinguishing between them after they appear on the Web. While named graphs can be displayed on the Web as simple related documents (i.e., Linked Data), they are also extremely useful for managing RDF datasets within an RDF repository.
  • URIs Unified Resource Identifiers
  • Resources can also be shown as empty nodes. Empty nodes are not directly identified from RDF statements. In an RDF graph, an empty node is a node representing a resource for which no URI or literal is specified. A resource represented by an empty node is also called an anonymous resource. According to the RDF standard, an empty node can only be used as a Subject or an Object of an RDF triple. Empty nodes can be denoted by identifiers of empty nodes in the following formats, RDF / XML, Turtle, N3 and ⁇ -triples. The following example shows how this works in RDF / XML:
  • the identifiers of empty nodes are limited only in the serialization area of a certain RDF graph, i.e. the node "_: b" in the following example does not represent the same node as the node with by the name "_: b" in another column.
  • Empty nodes are considered as simple pointers to the existence of a thing without using a URI (Unified Resource Identifier) to identify a specific thing. This is not the same as assuming that an empty node points to an “unknown” URI.
  • the predicate (this) 110a, "position” 1106) are URIs that also indicate a resource, representing links.
  • the object (“Manager”, “Developer”, “General Manager” and, in special cases, "John”, “Michael”, “Morgan”, “Mona”, “Alex”) are URIs, empty nodes or string literals in Unicode . In this invention, a triple approach is used to process information from various sources.
  • FIG. 1 illustrates an example graph system in accordance with an exemplary embodiment
  • FIG. 2 illustrates part of a semantic network in accordance with an exemplary embodiment
  • FIG. 3 illustrates traditional data acquisition (customer request processing system) using existing technologies
  • FIG. 4 illustrates the implementation of the interface of the mater module of the data acquisition module
  • FIG. 5 illustrates a request processing algorithm using exact matching as an example
  • FIG. 6 illustrates the request processing algorithm by the example of data matching according to a pattern
  • FIG. 7 illustrates an example of various business applications used in various departments of a company and the processing of data therein.
  • FIG. 8 illustrates a system for an exemplary embodiment.
  • FIG. 9 illustrates a database with a B-tree structure for storing triples.
  • FIG. 10 illustrates an example of storing predicates and their attributes in a B-tree.
  • FIG. 11 illustrates an example system for implementing the invention.
  • FIG. 12 illustrates the processing of a client request after a matching rule is found.
  • FIG. 13A, 13B illustrate an example of combining models (combining models).
  • FIG. 2 shows a semantic stack in accordance with an exemplary embodiment of the invention.
  • the semantic stack used in the example embodiment includes a Unified Resource Identifier (URI) 201. It is worth noting that everything that can be identified using a URI can be described, so that the semantic network can relate to animals, people places, ideas and etc. Semantic markup is often generated automatically than manually.
  • URIs can be classified as pointers (URLs), names (URNs), or both.
  • a uniform resource name is a name for a person, while a Universal Resource Index (URL) resembles a person's address. URN defines the identity of an element, while a URL provides a way to find it.
  • CmwL (Comindware Language) 211 describes the function and relationships of all these components of the semantic web stack;
  • XML 203 provides elementary syntax for the structure of content in documents, since associations do not have semantics for the meaning of the content contained in documents;
  • RDF 205 is a simple language for representing a data model that relates 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.
  • Ontology 215 formally represents knowledge in the form of a set of concepts in a domain, using a common dictionary to determine the types, properties, and relationships of these concepts.
  • Ontologies are structural frameworks for organizing information. Ontologies are described through the (Ontology Description Language) OWL or through CmwL, which allows you to describe Classes and their relationships with each other and other entities (see below). Ontologies can extend a predefined dictionary (for example, RDF dictionaries or OWL dictionaries).
  • a dictionary is a data set of information of certain terms that have the same meaning in all contexts.
  • Ontologies use 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 contexts of use. Thus, the RDF schema is a dictionary for RDF. OWL or CmwL can be used to write domain semantics in an ontology. Essentially, any data, such as ontologies or taxonomies, can be expressed in triples. Three is a fact.
  • Taxonomy 209 is a hierarchical way to classify all objects in a given world: books, products, types, concepts, etc.
  • taxonomy is a dictionary of terms and their exact definitions.
  • a dictionary is logically ordered in a hierarchy, it is called a taxonomy. It is a common resource for everyone in the information ecosystem, used to synchronize the meaning of terms.
  • Comindware 211 is used in place of the Ontology Description Language (OWL) in the semantic stack.
  • OWL Ontology Description Language
  • the Comindware language is a limited version of OWL with the goal of improving performance and getting rid of functionality and operations that are not necessary for the purpose of business applications and / or for use with ontologies (but using the OWL dictionary and some of its rules 213).
  • data consists of user data and ontologies.
  • User data is stored in a database (for example, on a hard disk) in the form of axioms.
  • the axiom, or postulate, is the starting or starting point of reasoning. How classic It was thought, the axiom is such an obvious assumption that without argument it is taken for the truth.
  • N3 is based on RDF standards and is equivalent to the RDF / XML syntax, but has additional features such as rules and formulas. Rules can be written in N3, OWL, XNL, etc.
  • the curly braces here comprise a set of statements and represent a formula. All formulas are enclosed in braces.
  • the above example is a simple 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.
  • ? X is a variable (or unknown quantity, sought variable). It is worth noting that “? X” is not always represented by the desired value, instead, the known part of the statement (in the form of a URI) “? X” can be used to verify the authenticity of the fact.
  • any data such as an entity, an event, and others can be described by a triple.
  • a triple can describe a fact, for example, "Bill is a Man,” “John is a Man,” “John is a position is manager.”
  • the part of the statement “Product For Errors Tag” may be interpreted as “Tag for product for error” or as' Tag with name “Product for error”. In other words, "The tag that associates the Product with the Error.”
  • Another example is the “cmw.Property Attributes”, which can be interpreted as property attributes or intrinsic attributes.
  • part of the statement "creatorTag” can be interpreted as a tag whose name is "Creator” or author, i.e. A person who creates something, such as a task or error.
  • the values of the variables mentioned above can be predetermined before the rule with these variables is processed / calculated.
  • variables "? Tag”, "? Values” variables that must contain values, and determines the impossibility of using these variables without values, i.e. the values of these variables should not be undefined.
  • variables are also called Inputs, and the values of variables are input values, for example, for rules, methods / functions / built-in functions / functors, etc., which are described below.
  • the data received and processed during the work uses the rules given by you, depending on how these rules will be called and with what parameters, i.e. with unknown or with certain data.
  • brackets On the right side of the first rule, the contents of the brackets (? Tag? Values) is an array / list of two elements / variables. It is worth noting that a list or sequence is an abstract data type that implements a complete ordered collection of values, where the same value can occur more than once. An instance of a list is a computer representation of a mathematical finite sequence concepts; A (potentially) infinite counterpart to a list is a stream. All items / values found (and stored in the variable “? X”) on the left side of the second rule are the result of a search query “query: 42”, for example, a data search system for Objects in databases.
  • An Object / Element is an entity, for example, a business entity: the task "Add a description for the animal’s photo” is the Object / Item, the employee “Bill” - the Object /, like the request for "Building a bridge", a user record in the database, 1T - department, HR department or any other entity.
  • Such entities in the field of programming are called class instances.
  • the user "Bill” is an instance of the class "User”; 1T-department, HR-department are copies of the Class “department”, etc.
  • Such Objects / Elements are the desired data that is of interest to the user and / or system, and which must be found in the database.
  • built-in functions can be linked / registered to predicates, which (bill-ins) represent software (source) code that allows certain operations / actions to be performed. Such actions cannot be performed in triples, since triples are descriptive in nature and cannot be processed without special internal or external code.
  • Examples of data sources in this invention are data (for example, in the form of triples) from triples databases and from triples storages storing triples that are the result of rule processing.
  • Data (for example, in the form of triples) that was obtained during or after the execution of the ticket-in codes (which are associated with certain predicates) is another source of data in this invention.
  • a ticket-in could be associated with ": send to" from the triple / statement "? Name: send to: ComindwareProjectMoflynb.”.
  • the bill-in associated with the predicate causes the bill-in code to be executed when a rule with such a predicate is processed / read.
  • the ticket-in code will be executed instead of the usual processing of the rule described above.
  • the usual processing of a rule means performing a search for all triples with the predicate "addB” and Object where the found Subjects of the data of the found triples will be saved in the variable "? name”. If the ticket-in (which describes the system / set of steps for managing statements / rules and the predicate in particular) is associated with the predicate "? Send to”, then the rule with the said statement "? Name is correct It will not be processed as described above in this section (the process of searching for values for the variable "? Name" will not start), but the billing-in code will be executed.
  • the ticket-in associated with the predicate ": 50sendB” may include a code that is responsible for transmitting / sending data from the system (from the data receiving module) to external software or hardware modules, a printer, a screen, etc., where data, which must be passed are the values of the variable "? name", and ": ComindwareProjectMoflvmb” is an Object that identifies the external module (external module identifier).
  • bill-ins are usually associated with predicates at the start of the system or during the creation of the Data Acquisition Module, however, it is also possible to create and associate new bill-ins during the operation of the system (for example, while the Data Acquisition Module processes the rules). Break-ins can be saved in the external module. It is also worth noting that the ticket-ins can be untied or replaced with another ticket-in.
  • the tape-ins stored in external modules can be compiled, for example, into executable code, such as an .exe file, a library, in particular, a dynamic library (.dll).
  • a tie-in is essentially a function (Class, Subclass, method, etc.) or a set of them written in any programming language, such as C #, C ++, Java, java script, Comindware language, etc. .
  • the system “sees” the predicate mentioned above (for example, “: sendB”), it searches for the ticket-in associated with this predicate, and after that it calls / activates the corresponding ticket-in.
  • a tie-in can have several input parameters, for example, as well as all data found and stored in the variable "? name" in the form of a list or array (see the example above).
  • the functionality of the bill-in may include mathematical operations, data transfer / output to external devices, modules and applications, data operations (for example, arrays, lists, etc.), calculation of the element number, search for the initial element and etc., i.e. any operations, action, methods with data (with triples and parts of triples / statements).
  • Another example of the invention may include specialized keywords / reserved words.
  • the three mentioned in this invention are descriptive, and it is necessary to associate the bill-ins with predicates that describe operations.
  • the keywords mentioned here (if,” else ",” then "in this example) are used as an example of these types of bill-ins (so-called bill-in proofs):
  • Belt-in-proof is a way of providing an interface for using data from a data acquisition module (such as components, functions, facts, axioms, constants of a data acquisition module, parts of a system (illustrated in FIG. 8) and combinations thereof) to calculate the rules.
  • a data acquisition module such as components, functions, facts, axioms, constants of a data acquisition module, parts of a system (illustrated in FIG. 8) and combinations thereof
  • the bil-in-proof can access and use the internal data / components of the external and internal modules of the system, including the data-receiving module (and has permission to use the code of the data-receiving module), since the bil-in-proofs have a bil- ina (or similar to the bill-ins).
  • bill-in-proofs can be associated not only with “if, but also with program methods / functions and, for example, with such operators like “then”, “else”, “foreach”, “next”, “break”, “switch”, “continue” and any other operators and functions / methods, for example, trigonometric, logarithmic and other general (and special) functions / methods / actions / operations.
  • the bill-in-proof is part of a data acquisition module, and its calling method is the only visible aspect. This is a unified way to access data from the data acquisition module. It is worth noting that bilt-in proof can use the same part of the code as the data acquisition module.
  • Another example of the invention includes functors that are able to work, at least as a bill-ins, but the functors are written in triples.
  • a functor is a certain type of bill-in that uses triples and can be stored in the repository of the module for receiving triples, in a database, i.e. to any data warehouse.
  • the functor is able to perform the same functions as the ticket-in, but using triples and without using external modules.
  • the bill-ins, bill-in-proofs, functors can be expanded / supplemented after starting the data acquisition module, while the application is running, the bill-in can be expanded by adding new ticket-ins to it, or by creating new bill-ins and linking to existing ones.
  • the tie-ins can be stored in files external to the system modules shown in FIG. 4, FIG. 8 (such as data acquisition modules), which (files) with bil-ins can be connected, combined / connected.
  • bill-ins can be stored in data stores, such as triples; in RAM, databases, storage of modules for receiving data, etc.
  • additional files with bill-ins can be attached to the data-receiving modules, for example, dll-files can be used to store bill-ins, which (files) can be written specifically for the application, or they can be shared system OS files such as MICROSOFT WINDOWS components, LINUX components or as database files, etc.
  • any data source can be used, for example, a data stream, html, i.e. data source with data interface.
  • the bill-in can not only be an external module for this invention, but can also be part of a module as part of a component of the invention, such as semantic processor 840 (see FIG. 8), or can be attached to it. It is worth noting that the bill-ins can be stored in several files or data stores.
  • FIG. 3 illustrates a traditional data acquisition system (client request processing system) using existing technologies.
  • Events can be triggered by the actions of a user, software operator or developer, etc. For example, data can be queried from a database using the GUI function. Events can also be triggered by external modules or applications, in particular operations of program services or actions of an external module service.
  • the service is an automated user, i.e. user actions that can be programmed into the application are also a special case of the service.
  • the process of generating a client request for data used by the application is an example of how such events are handled.
  • Such requests can be either internal (addressed to application modules) or external (addressed to external application modules, databases, etc.). Such requests provide the application with certain data in accordance with the request. Queries can be presented in the form of a call to application functions / methods, database queries, etc.
  • Client 310 may act as an example application sending these types of requests.
  • Client 310 can be represented by application 801-806 (see FIG. 8), application module 807, semantic processor 840 (including the Business Logic Layer of Application 820), GUI module (for example, which are responsible for data retrieval), data acquisition modules, models mentioned below, parts of data acquisition modules, etc.
  • the data set is the data stored in the database 340 in the data warehouse 320.
  • the format of the stored data is determined by the internal structure of the database, i.e. if the database If B-trees are used, then the saved data will also be presented in the form of B-trees (see FIG. 9 and FIG. 10).
  • data is stored in a database, RAM, storage (e.g., storage of a data acquisition module), etc. and can be represented as a set of axioms, facts and rules.
  • Facts are data derived from axioms using at least one rule and simultaneously recorded, for example, in triples. It is worth noting that facts can also be deduced from other facts or axioms in combination with the rules.
  • This rule may be applicable to the axioms or facts "Error number 345 status closed", "Error number 235 status closed” and so on.
  • This rule can be applied to any fact or axiom, such as "Something status is closed.” After applying the rule, the following facts will be displayed: “Error number 345 see false” and “Error number 235 see false”, which can be interpreted by the system or application (such as Comindware Task Manager (), Comindware Tracker (R), etc. ) as an instruction to stop the display of errors Error number 345 and Error number 235.
  • client 310 After generating the request, in this case to the database, client 310 will wait for a response.
  • the client request is processed by the database using the matcher interface.
  • the interface of the matcher can be implemented as a common interface, i.e. one common interface of the matcher can be used for communication between external / internal module (s) (request initiator, client, etc.), database (databases), data acquisition module (s), new models, and integrated models described below.
  • the interface is a common border between two separate components of computer system information exchange (in this case, such components are the Database and the Client). In this case, the exchange is implemented between program modules.
  • a program interface can relate to a wide range of different types of interfaces at different "levels": in this implementation of the invention, objects / modules within an application must interact through methods.
  • RDFLib is one of the programs that uses RDFLib graph matching technology that supports the basic triplesO match patterns with the triplesO function. This function is a generator of triples corresponding to the pattern specified by arguments. These arguments are RDF conditions that restrict the returned triples. Conditions with no conditions are treated as an asterisk search.
  • the database is capable of responding to a client’s request through the interface of the matcher.
  • the matcher’s interface lets the client know that the database understands his requests and is able to process them, i.e. It is capable on its own to conduct a search for data related to a client’s request.
  • the interface of the matcher determines the format of this interaction, i.e. declares the capabilities of the matchter.
  • An example of a query would be “Bring 'ab to'triple.”
  • the system or program module
  • client request can be represented in the form of a call to the function / method of the interface of the matcher: "There is a Three in the System (ab c);”. Calling the methods of the interface of the matcher allows you to get answers to the client’s request.
  • the present invention in one implementation uses a matcher interface capable of responding to two types of requests:
  • the first method of the match interface is a request for an exact match (match).
  • the system says whether the Subject-Predicate-Object triples exist in the requested object (for example, the database) or not.
  • the database receives a request from the client “There is a troika” “is task1 closed” to the database? ”The match will return a corresponding answer -“ Yes ”or“ no ”.
  • the second method is the interface of the matcher.
  • the second type of query is a query with variables or unknowns.
  • the system will return a set (collection, list, array ...) of the found data.
  • a client can send a request to a database of the form "? X Predicate Object", “Subject Predicate? X”, “Subject? X Object”, “Subject? X? Y”, "? X? Y Object", "? x predicate? y "and so on. Then the client must wait for the system to return the corresponding data found.
  • Another example of the type of query mentioned above is "? X? Y? Z”, which asks the system to return all the data stored in the database.
  • the first method of the matcher interface uses exact match requests from the client to the database. All of the following examples that follow imply that the data is stored in a database.
  • client 310 has a GUI that can be used, for example, to view information about company personnel. The positions of employees are presented in the form of triples in the form of groups (see FIG. 1).
  • User CEO Alex wants to see information about his employees displayed on the screen.
  • the client prepares a request for data regarding the employee’s relationships with the name Morgan and other stored data. In this case, the request may fall into such categories as “developer”, “person”, “creator”, “Error corrector”, etc. In order to find out what data should be shown, the client prepares a request.
  • a data request can affect any intended event, for example, sending data to a screen, printer, external or internal module or application; data analysis (for example, in accordance with external rules not contained in the system / application).
  • client request may request a search for employees. For example, if the task is to find all the manager of the company, a query to the stored data may look like a triple "? X is a manager.”
  • a query to the database can be represented as a triple (or a call to a method / function of the interface of a match with an argument in the form of a triple, for example Calling the Match (a, b, c)) method that you want to find in the database with the database tools. If the database contains such a triple, then the system will return “yes / true”, otherwise the answer will be “no / false”.
  • the second method of the interface of the matcher operates on at least one variable, for example, the stream "? X b s".
  • the database Upon receipt of such a request, the database will not return anything, or will return a set of corresponding triples via an iterator (for example, in the form of a collection or set).
  • the collection is also an iterator. It does not contain all the elements found, on the contrary, each subsequent element will be obtained through the next request.
  • the system implements a deferred return of elements: for example, when a request like “give me the next element” is sent, the iterator returns the next element found. Those. each next element (triple) becomes available when necessary.
  • An iterator (lEnumerator in .NET) is an object that allows you to bypass a container, in particular lists. The iterator crawls and also accesses data items in the container.
  • An iterator can be considered as a type of pointer, which has such basic operations as a reference to one specific element in the collection of objects (the so-called "access to the element") and changing itself to point to the next element (the so-called “element traversal”) .
  • the iterator sequentially searches for triples matching client request 310.
  • FIG. 4 illustrates the implementation of the mater interface of a data acquisition module.
  • the database when the database implements the interface of the matcher, it is able to respond to customer requests, informing that the requested triple is present or returning all found triples in the database that match the client’s request. Due to its structure, the database can operate only with the axioms stored in it (the rules stored in the database are also called axioms in their context). If the client’s request contains facts, then the database is not able to say that they are not, because the facts are not stored in the database. As mentioned above, facts are derived from axioms and / or other facts using the rules through module 410, after which they are stored in the store 430.
  • module 410 stores information used to obtain this data, for example, a combination of facts and rules (or their Identifiers) from which they were derived.
  • the rule used to infer a fact can be identified by its left and right sides.
  • a rule can also be determined by the combination of both parts.
  • the left part of the rule can be indexed separately from the right part, just as the set of indexed / hashed parts can be used for identification by means of a common identifier obtained from identifiers of the left and right parts of the rule.
  • the left part of the rule or its right part, or the fact and / or rule can be completely processed by module 410 (for example, cached, hashed, indexed, identified, etc.) in order to reduce the time required to access the facts and rules stored in storage 430.
  • Module 410 belongs to the engine / semantic processor 840 (see FIG. 8) and does not operate on user data and ontologies.
  • One of The features of the data acquisition module is its ability to process rules for displaying new facts, as well as searching for data in the 430 storage.
  • the data acquisition module like the database, implements the interface of Matcher 440. Since the facts are derived using rules not only from other facts, but also from axioms, the data acquisition module has access to the database to determine if there are required axioms.
  • FIG. 4 illustrates the case where the database also implements the interface of the maker 450 (only in the case where there is no data receiving module, as shown in FIG. 3) for understanding requests from the data receiving module and responding accordingly.
  • a data acquisition module can be created after the event occurs (see above), which also leads to the creation of a database snapshot 460. It is worth noting that snapshots are usually created upon a request from a client or several such requests. Optionally, instead of creating a snapshot, the system can stop writing to the database. Also, when creating the data receiving module, the storage of the data receiving module 430 is created, which is used to store the rules taken from the database. It is worth noting that the rules taken from the database can be stored in the storage 430 not only explicitly, but can also be parsed, which facilitates their processing by the data acquisition module. For example, the store 430 may store the right parts of the rules taken from the database, together with the identifiers of the rules by which they are calculated. Data (rules) taken from the database (as well as data / facts obtained as a result of actions of module 410) can be cached by module 410 for faster access to them.
  • a client’s request for a data acquisition module formulated as a triple “a b s” (exact match).
  • the data acquisition module will have access to the database.
  • the methods of the interface of the match are used. If the requested data by the data receiving module is not in the database, then the module 410 will search for this triple in the storage 430. It should be noted that if the requested triple is not in the database, this means not only that it is absent, but also that it is not an axiom. If the triple is found in the storage 430 upon request by the module 410, then the data receiving module 410 will continue to search for the rule used to calculate this triple (since the triple is a fact, as was said above).
  • the right-hand sides of the rules used to calculate the requested triple need not contain the indicated triple. If the requested triple is formulated as "ab c", then the right part of the rule contained in the repository may contain "ab c", "? X b? Z", "? X? Y g", "a? Y? Z", "a? y g" or other triples, and even "? x? y? z", i.e. any triples that could potentially match what was requested. That is, there may be several rules that can be used to calculate the triples from the client’s request. Rules are parsed using lEnumerator, i.e. one rule is analyzed at the same time, and after this analysis the next rule is taken, if any exist. The triples are broken down into their constituent parts, where the triple is the minimum part for lEnumerator.
  • the rule After the data receiving module finds the requested triple, the rule will be analyzed, in particular its left side, to find out if there are triples that need to be processed by module 410, as the previously considered request from the client, i.e. through exact matching or matching with a variable (depending on the type of triples found on the left side of the rule, i.e. whether they are facts or axioms, and whether they contain variables or not).
  • module 410 starts a search in the storage and database using matching with the variable.
  • the response to the request sent to the data receiving module will be negative: the requested fact / triple is missing.
  • the module 410 can be removed or deactivated.
  • the data acquisition module can be created not only for each event described above.
  • One created data acquisition module can respond to any number of client requests.
  • the process of creating / deleting a data receiving module is controlled by the type of event, the number of requests in the event, etc.
  • a request to display data from user Alex in the above example is an event.
  • Client 310 may formulate at least one request related to the event.
  • a module 410 is created to process all requests related to the event.
  • a separate module 410 can be created.
  • the requests can be grouped, for example, according to the types of requested data or the data accessed, (user data, system data, axioms, ontologies), with their size, their belonging to the application (company, department, etc.) or they can be stored in different databases.
  • the module 410 After the module 410 processes all requests related to one event, the module can be destroyed. Modules 410 created for queries or grouped queries associated with an individual event can be destroyed as soon as the response to the query is ready. It is worth noting that the system can create one module 410 for a group of events, instead of creating modules for each individual event. Events can be grouped, for example, according to the time of their appearance (i.e., they happened in a certain period of time, for example, a few milliseconds or minutes from each other). In this case, the module 410 will be removed after it answers all requests related to this group of events. When creating the 410 data acquisition module, a database snapshot can be created at the same time.
  • Snapshots can also be replaced by other means of data logging built into the database. That is, the merging of data from various sources is implemented by means of databases.
  • data can be temporarily stored in intermediate storages.
  • Snapshots of the storage / database usually overlap, as in this case the data is written to the database asynchronously. Overlapping snapshots means that even if the data is written to the database in a sequence of snapshots, there is no guarantee that they will be continuous, complete and valid.
  • the data warehouse In order to make the record valid, complete and continuous, the data warehouse must be equipped with at least one intermediate data container for storing data that must be recorded in the data warehouse by a client, data acquisition module or database.
  • this container is a virtual storage located in the computer’s memory or in a specially allocated data storage (for example, storage with a database, storage with a client or network / "cloud" storage).
  • the storage 320 described above may contain a client 310, at least one database and other modules used to process triples, such as applications 801-806, application modules 807, semantic processor / engine 840.
  • Database 340, client 310 and other modules may reside in different repositories and in various combinations, for example, the client and the database in one repository, the rest of the modules in another, or the database in one repository, in the client in another repository (s), and etc.
  • FIG. 5 illustrates a request processing algorithm used in exact match.
  • the processing of the request begins at step 515.
  • the figure contains a request to the interface of the matcher 440 of the module 410.
  • the module 410 checks its compliance with the data stored in the database. If the database contains data for responding to a request, then the system returns 540 the fact that the request is True.
  • step 520 If in step 520 the system cannot find data to respond to the request, the process proceeds to step 530, where it attempts to find data to respond to the request, for example, facts (triples output by module 410, as described above). In the event that the module 410 finds the data necessary to respond to the request (530), the system returns "True” (540), confirming the truth of the request.
  • step 530 attempts to find data to respond to the request, for example, facts (triples output by module 410, as described above).
  • the system returns "True” (540), confirming the truth of the request.
  • step 530 the module 410 cannot find the data to respond to the request, the process proceeds to step 560, in which it tries to find the rules that can be used to output data for the request. If no rules were found in this step, the system returns the fact that the request / statement is False (580).
  • step 560 module 410 finds a rule that can be used to output data for a client request
  • the process proceeds to step 570, in which it tries to analyze the rule (described above), depending on the type of match. Statements resulting from the analysis of the left part of the rule, are used to create requests (input for module 410), which are then processed in the same way as client requests.
  • the analysis of the existing rule (s) in step 570 leads to the formation of at least one additional request, for example, a request for precision / exact matching or for template-based matching (pattern-based matching).
  • the process returns to step 510 and continues to process all requests generated as a result of the rule analysis.
  • the module 410 In the process of analyzing the request, the module 410 will return the data that it will find until the result is “False”. In the case when all the data related to the request is “True”, the module 410 will return the fact that the entire request / statement is “True”.
  • FIG. 5 applies not only to precise matching, but also to pattern-based data matching.
  • the process searches for all triples that match the specified pattern, for example, “? X b s”, each of which can be stored in the database, in the storage of the data receiving module 430, and can be displayed based on the rules.
  • the result of the initial request will be the data identified with the request.
  • lEnumerator is one way to return data to the requester (e.g. client / external module, etc.) in accordance with the pattern mentioned above. lEnumerator is allowed to return the found data to the client one by one until the client says enough. This means that the client request "? X b s" returns lEnumerator.
  • the client (initiator of the request, external / internal module, data acquisition module, etc.) must decide whether it needs the next element (in particular, the next three), including the first one, because at some point in time during the processing of the client the request, the client can get the result, so that he will not need the following elements. If the system detects that the client has enough data, then lEnumerator will stop. It is worth noting that lEnumerator is an interface with its own methods, such as Current_Element and Enum_Next. Enum Next takes the next element, while Current_Element reflects the current element. If the client is not satisfied with the data presented, then the Enum_Next method will be called to obtain the following data (in particular, triples). This process continues until the client is satisfied, or until there is no data corresponding to the request.
  • lEnumerator remains available (even if it is suspended) if it receives from the client a similar request or relating to the same initial request, or any other request, or from module 410. In this case, lEnumerator can continue to work, returning the rest data.
  • the store 430 stores not only the rules taken from the database, but also the facts, for example, “r s b Rule No. 1234”, meaning that the fact “t s b” is deduced according to “Rule No. 1234”. It is worth noting that the storage 430 stores data in any known format, for example, in the form of a tree (for example, a B-tree), tables, in xml format, text format (text file (s)). It is also worth noting that stored data formats can support data matching. Also, storage 430 stores attempted computations using at least one rule, and stores even unsuccessful attempts at these computations, i.e. calculation processes were started, and the result of these calculations is a lie where the desired result was not achieved, for example, triples were not found, the desired parts of triples were not found, etc.
  • the rules can be divided into triples of which they consist.
  • the rule “Rule Number 1234" can be written in the form where: “w with b” is the right part of the rule and "Rule Number 1234" is the identifier of the rule.
  • This record can be expanded with additional information, for example, whether this rule was analyzed or whether this fact was processed (for example, as described in step 570). If the rule or fact has not been analyzed, then the record may remain unchanged, or it may be expanded “Uncounted”, for example, as “r s b Rule No. 1234 Uncounted”, meaning that this rule has not yet been counted.
  • Additional information stored with the facts may include the Uncounted or Rule extensions, meaning that this rule has not yet been counted.
  • the addition “Done” means that the rule is completely counted, that is, the rule has been processed according to a specific request with certain values.
  • Supplement “Derived” means calculated and given facts.
  • the “Suspended” extension means that the rule has not been fully processed (this happens, for example, when a client is satisfied with the output at some point in time). Additional information (additions) is presented in the form of marks that are used during the match in the storage 430, as described above.
  • the facts will be transmitted, for example, to the client.
  • the facts will be transmitted until a certain mark is found.
  • the mark “Finish” cancels the repetition of the calculation of the current rule.
  • This mark also acts as a terminator in the B-tree (see below).
  • data processing begins with the most recently added / stored data (i.e., from top to bottom, if the stored data is presented in a list).
  • recently saved data will be found faster than older data.
  • the rules obtained from the database are placed at the beginning of the repository, while the triples (facts) derived from them are stored at the end of the repository.
  • the algorithm shown in this figure is a universal data return algorithm (applicable to both exact matching and pattern matching) to the request initiator, and can be presented as external (with respect to the data receiving module ) the initiator of the request and in the form of an internal initiator of the request, where the data receiving module itself acts as the initiator of the request.
  • An embodiment in which a data acquisition module initiates a request is shown in FIG. 5 and FIG. 6, see the transition from step 570 to step 515 (and from step 690 to step 620 in FIG. 6). In FIG.
  • step 690 the transition from step 690 to step 620 is shown by several lines, which are a specific case when during the analysis of rules (a) the main request 510 in step 570 is divided into several requests (which is also shown in FIG. 12 by dashed lines).
  • the main request 510 in step 570 is divided into several requests (which is also shown in FIG. 12 by dashed lines).
  • external query initiators are typical modules or software components that do not include a data acquisition module (for example, a full-fledged personnel management software product, such as Comindware Tracker, which includes data acquisition and search for these objects as one of their functionalities, or search for employee tasks, search for employees responsible for the project, components or parts belonging to the project, Processes, physical object, e.g., car and so on).
  • a data acquisition module for example, a full-fledged personnel management software product, such as Comindware Tracker, which includes data acquisition and search for these objects as one of their functionalities, or search for employee tasks, search for employees responsible for the project, components or parts belonging to the project, Processes, physical object, e.g., car and so on).
  • the initiators of the requests may not be part of such a computer program or component (for example, the data acquisition module may be a separate program and may act as an interface for software that does not have the capabilities of the data acquisition and search module, for example, via the GUI to make it possible to manage personnel in this example, or, in a more general sense, to make it possible to search for data, for example, in databases presented in the form of trees, B-trees, tables, text new files, etc., and which can be stored in RAM, on HDD, solid state drives, SAN, NAS, virtual storages, virtual RAM, etc.).
  • the data acquisition module may be a separate program and may act as an interface for software that does not have the capabilities of the data acquisition and search module, for example, via the GUI to make it possible to manage personnel in this example, or, in a more general sense, to make it possible to search for data, for example, in databases presented in the form of trees, B-trees, tables, text new files, etc., and which can be stored in RAM, on HD
  • FIG. 6 illustrates an example of processing a request from a requester 310 using pattern matching.
  • step 620 the data acquisition module 410 receives the request.
  • step 640 the system searches for axioms that match the request template in the database 340. Here, all the found axioms are given to the initiator of the request.
  • step 660 all facts are searched in the storage of the data receiving module 430, for example, facts found earlier using other rules.
  • step 680 the rules are searched (which are necessary in order to find the data requested by the query initiator), and if the rule is found for the processed request, the process proceeds to step 690, in which the rules are analyzed, as described above, and in step 620 at least one data retrieval request may be generated from the originally received request (initial request).
  • This request can be either a request for exact matching, or a request for matching a match.
  • the initial request is divided into several requests, some of which are requests for exact matching, and some are for template matching.
  • These exact match requests are requests 510 in FIG. 5, and requests for match by template - requests 620 in FIG. 6, although the algorithms shown in these figures apply to both cases.
  • the process returns to step 620, which in this case means recursion, thereby making the algorithm shown in FIG. b, recursive algorithm.
  • FIG. 5 may also be a recursive algorithm.
  • steps 640 and 660 can be performed both sequentially and asynchronously.
  • FIG. 12 illustrates the processing of a client request after a matching rule is found.
  • Rule 1220 found by module 410, is analyzed for a client request, that is, it is divided into component parts (statements / triples), i.e. left and right parts. The left side, in turn, is also divided into statements. As described above, the right side of rule 1210 is a fact deduced from the left side of the rule.
  • Rule 1220 (in particular parts 1232, 1234, 1236) uses data 1232a, 1234a. 1236a, generated by rules 1240, 1260, 1280, which is referenced (shown by dashed lines), and uses the data (in particular, part 1231) found in the database (s) 340.
  • the data is shown (1232a, 1234a , 1236a) generated based on the processing of rules 1250, 1270, 1290 and based on data 1230 from the database (s) 340. All these found data are used in rule 1220 and, in particular, in 1280.
  • the data which are used in the rules shown in FIG. 12 may refer to other rules or axioms.
  • the rules to which they refer can be found by the data receiving module during the analysis of the rules related to the original triples / facts 1210. When searching for the rules related to the calculation of the client triple during the analysis of triples, the triples receiving module stores their data.
  • FIG. 12 shows that fact 1210 is calculated using rule 1210 (step 560, see FIG. 5).
  • rule 1210 step 560, see FIG. 5
  • its left part is divided into composite statements 1232, 1234, 1236, data for which can be obtained, for example, from rules 1240, 1260, 1280, respectively.
  • One statement in 1290, namely 1234b refers to data that could potentially be the result of processing rule 1260.
  • the module 410 either waits for the calculation to finish, or uses the results of the calculations, or recounts the rule with other input data / parameters / instances (for example, for the new request described above ) etc.
  • rule processing status (during the processing of the request) is stored in the storage of the data receiving module, so that the system (in particular, the data receiving module) knows whether the rule processing was started or it was processed, or the rule processing was suspended. If rule processing has been suspended, rule processing may continue after a command from the data receiving module.
  • the type and parameters of the request are stored in the storage of the data receiving module and the processing status of the rule is marked in according to the requests to which they relate. Thus, if the queries are the same, but the query parameters are different, then the rule may have several markings.
  • a fully processed rule is marked immediately, and if the rule has not been fully processed, the point is marked that was reached during the calculation at the moment when a response to the client’s request was found. For example, marking can be done for fully counted, not counted and not fully counted rules according to the nesting level for triples. (The procedure is marking all fully counted / marking all incompletely counted rules.)
  • the client can request the data to be written to the database.
  • Director Alex decides to change the position of Morgan from Developer to Manager.
  • Alex using the GUI, can, for example, replace the employee’s position in the corresponding field (or such functionality can be implemented using the drop-down list).
  • Alex After the change is made, Alex must save them in order to apply them.
  • all data in the system (for example, the database) must be modified accordingly.
  • the client After saving the data, the client generates a request for data containing Morgan's connections with other data.
  • the client’s request may relate to all data related to Morgan, namely “developer”, “person”, “creator”, “error corrector”, etc.
  • the client also generates a request to find out what data has been modified. It is also worth noting that saving and changing data is given as an example, since even for displaying saved data in the GUI, a request to read and write GUI data is necessary.
  • the Builder component is used to write data to the database.
  • the Builder is an interface.
  • models can be used.
  • a model can combine a matcher and a builder. Unlike 420 Matcher, the model does not have its own methods.
  • the builder model adds facts to the current model. If there are at least two models, they can be combined into one. Models combined under one common model are called subordinate models. It is worth noting that each model can be subordinate to at least one common / virtual model.
  • Models can be combined into one, for example, by data type. Using this interface, the client / data acquisition module can access all subordinate models. Subordinate models are invisible to the user, so that he / she works only with the general model.
  • the requests sent to the data acquisition module 410 are directed to a single common model, which, in turn, redirects them to its subordinates.
  • Combining several models into one makes it possible to access data whose type is unknown or not important. Also, combining models allows you to access several models at once through one, when the model (s) associated with the requested data is unknown or not important.
  • Individual models can be used independently, i.e. they need not be combined if the client 310 or the data acquisition module 410 knows for sure which model matches the requested data. In this case, there is no need to refer to one model, and then to all its subordinates in order to find only system or only user data. If the data type is unknown, it is possible to directly specify the model in which the search will be performed.
  • each model can have its own type: one model (for example, for a company or department) may contain axioms, another may contain rules, another may contain configuration data or only system rules, or all the rules displayed and etc.
  • Models can not only be combined depending on their type, but they can also be grouped for any specific purpose or operation.
  • a unified model may consist of a model that stores operations with data from a database; Models with rules for database / table operations; Models with database overhead.
  • a unified user model may include: a model that stores important data (objects recently addressed to the user), a model with user settings, a model that stores communications with other users, a model with rules for performing user operations with data, etc.
  • Combined models can be further combined with each other in at least one virtual model.
  • Such a combination of models into one or more virtual models allows you to get new facts when accessing them. For example, one model is designed to work with user data, another is designed to work with rules for user data. If these two models are separated, then a query to the first one will return user data corresponding to the query, and a query to the second one will return the rules, but no new facts will be received, since queries to these models are separate. If these two models are combined, then the user data request will take into account the rules contained in the model with the rules.
  • the combined models are subordinate to the data acquisition module, so that the data acquisition module processes all the necessary knowledge about the rules, data (corresponding to the combined models), calculated / deduced facts (common to the subordinate models), and also knowledge about where to look as a rule, an axiom or deduced fact, how to access them, and so on.
  • FIG. 13A and FIG 13B illustrate an example of combining models (combining models).
  • Option 1 (FIG. 13A): Storage Troies 1 1310, i.e. some data read from the database and stored in RAM (or on HDD, SSD, etc.) is a model (Model A, 1305) and can be combined / connected with another model (Model B, 1315), which can be represented by Troika Storage 2 1320 (for example, storing a different set of data from the same database or from a different database (other databases)). Such a combination may be performed using the Combine Model. The result of the merger is the created Joint Model 1 1330.
  • Integrated Model 1 1330 in turn, can be subordinate to Data Acquisition Module 1 1340, thereby creating a New Model 1 1350, where Integrated Model 1 1330 is the usual repository for the data acquisition module (the model described above) described in this invention .
  • Option 2 (FIG. 13B): The storage of triples 1 1310 (Model A, 1305) can be subordinated to the Data Acquisition Module 2 1360 with the creation of a New Model 2 1380 using the Combination Model, while the Storage of Triples 2 1320 (Model B, 1315 ) can be subordinated to Data acquisition module 3 1370, creating New Model 3 1390. Further, New Model 2 1380 can be combined / combined with New Model 3 1390 into New Model 4 1392 using the Combination Model.
  • New Model 1 1350 can be combined with New Model 2 1380 or New Model 3 1390.
  • New Model 1 1350 can be combined with New Model 2 1380 and then subordinated to Data Acquisition Module 4 (not shown), thereby creating a New Model 5 (not shown), which can later be combined with New Model 3 1390, creating a combined not shown New Model 6 (which can also be subordinated to another data acquisition module, creating New Model 7, etc.).
  • the triples derived by one data acquisition module will become axioms for another data acquisition module and / or for other New Models.
  • the triples from the integrated models are axioms for any data acquisition module that is used with such a combined model (integrated models).
  • triples from New Model 2 1380 are axioms for Combined Model 4 1392
  • triples of New Model 3 1390 are axioms for Combined Model 4 1392.
  • rules are a conjunction of triples / facts / statements. Statements are pre-processed, then compiled, which leads to an even greater conjunction.
  • Rules can be compiled into C # code.
  • the rules are presented in the form of a request, divided into triples, which are then converted to C # code, which is used to calculate the received request. Compilation is carried out only upon receipt of the request (the process of compiling the rules is described below). It is worth noting that triples from the database can be represented by collections, i.e. collections storing statements in the following way: the zero element is “Subject1 Predicate1 Object1”, the first element is “Subject2 Predicate2 Object2”. The format of the element is determined by the template.
  • the template for storing triples looks like "Subject, Predicate, Object", and therefore each element of the collection is represented by an array of three components.
  • the template may look like a string variable, for example, “Subject Predicate Object”.
  • one collection can contain only Subjects, the other can contain only Predicates, and the other can contain only Objects.
  • these elements from each triple maintain links with other collections. For example, elements from the first three are recorded as zero elements in the corresponding collections: Collection of Subjects, Collection of Predicates and Collection of Objects. It is worth noting that the collections may not be filled at the same time, but sequentially, for example, the Subjects are added first, then the Predicates and the last - Objects. In addition, the order itself does not matter, and at first the collection of Objects can be filled.
  • the main point in filling the collection is that the elements from each subsequent triple should occupy the following positions in all collections: the elements of the first three should occupy zero positions, the elements of the second three should be sent to the first positions, and so on. It is also worth noting that numbering in arrays, collections, etc. starts from scratch.
  • queries that include at least one triple and / or triple from a database are compiled into machine-readable code or into a programming language such as C #, JavaScript, C ++, etc. , and then compiled into an intermediate language (for example, With Intermediate Language, Parrot intermediate representation, Microsoft's Common Intermediate Language, etc.) and / or into machine code that must be executed to process the request.
  • an intermediate language for example, With Intermediate Language, Parrot intermediate representation, Microsoft's Common Intermediate Language, etc.
  • only the necessary triples are compiled into the languages and code mentioned above, for example, only those triples (rules, in this embodiment of the invention) that were used at least once to answer the queries described here or parts of the queries ( parts of statements).
  • a query can be divided into several smaller elements, for example, a composite triple can be divided into at least two smaller ones.
  • Complex triples (including the rules represented by triples) look like the following:
  • the second storage can be either separate, or it can be part of the storage of the data receiving module, thus virtually breaking the storage of the data receiving module into two virtual storages, both of which are recognized by the system as a single storage of the data receiving module.
  • the rules can be copied from the database to the repository, for example, to the repository of the data receiving module, where they can also be compiled in advance. If the rules copied to the storage of the data receiving module have not been compiled, then, when the data receiving module accesses such a rule, it will be compiled into executable code (for example, using C #), so the rule (along with others rules and statements associated with it) can be fulfilled. Compiled rules along with auxiliary code for their execution are usually stored in a separate file (for example, in a DLL file) or in storage.
  • non-compiled rules are copied (or made common) between data acquisition modules (for example, among newly created data acquisition modules).
  • any remaining triples from one data acquisition module can be copied (or shared) between others, while the received data cannot.
  • links to compiled rules and the rules themselves can be copied (or made common) among other data acquisition modules, thereby avoiding repeating the compilation of rules that have already been compiled, for example, by creating a list of files of all compiled rules, for example, among the 'intellects' of the aforementioned DLL file, by the created data acquisition modules, which (all and all of them) can use the DLL file).
  • information about the rules that were compiled and which were not can be copied from one data acquisition module to others.
  • the corresponding code is compiled.
  • the data receiving module 410 performs calculations: if there were no such requests before, then this is a new calculation; if such requests were previously, the system returns the result (in addition, the calculation will either continue or start from scratch). As described above, the calculation continues until a satisfactory result is obtained (including a negative result, for example, the absence of data satisfying the request parameters).
  • the processing of the request will be suspended.
  • the data acquisition module will save the position it reached during the processing of the current request.
  • the Data Receiving Module receives a request that is similar to not suspended, and the data is not found in the array of calculated data, the request will be “thawed” and its processing will continue until the corresponding data is found.
  • the calculation / processing may be left unfinished because a satisfactory result has been found. The process will be completed later when a similar request is received, or it will be necessary to calculate the request suitable for the suspended triple.
  • 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).
  • 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.
  • RDF Resource Description Environment
  • 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 specific situation.
  • 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.
  • 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 the data on one repository changes, there is no need to change data on other repositories).
  • search results obtained on the fly can be illustrated by the following example.
  • ontology data i.e., data that describes managed entities
  • 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.
  • 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.
  • 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.
  • the business layer requests data from the kernel
  • the logical core collects data from various sources
  • the system 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).
  • the system may have rules that were compiled and compiled earlier, as well as new rules for rules that have not yet been processed. Thus, compilation should only be done for new rules. Therefore, the kernel does not need to constantly work with data, but only to address data in response to requests from the business layer;
  • the kernel returns the requested data to the business layer.
  • a filter type rule is most often used in tracker cases, for example, receiving a list of tickets / errors / tasks to the support service from a specific user and a specific project with certain attributes.
  • information from the general pool of tasks / errors / tickets should be filtered for a specific user and project and presented in the form of separate axioms.
  • Conversion rules apply to the same information that could be presented in a different way.
  • the Information Technology department sees people as users of information technology systems.
  • the project manager can see the same people in the form of resources working on specific tasks.
  • conversion rules may include the following: at the input, data (axioms) are received that describe a specific ticket (for example, a request from a specific end user) and the presentation of its data.
  • the system will receive, as an output, axioms in the form of a specific user interface filled with data.
  • a rule type is a generating rule. For example, in a specific project that has more than 50% critical errors and more than 50% critical tasks, the system automatically generates a fact about the status of the project (for example, the status of the project is designated as "Critical").
  • ⁇ Error cmw is error: Error. ? error project: includes project: Project_ABC. ⁇ ? error project: Status status of the Project: Critical ⁇ evidence: counting the number of critical Critical Errors. ⁇ ? Design error: Status? Any ⁇ Proof: Counting? Total Error. (TotallyError 2) checkmate: split the HalfEveryoneError. ? number of Critical Errors Mat: more
  • ⁇ ? x cmw is task: 3 task ⁇ -> ⁇ ? x cmw: is project: Task or Error ⁇ .
  • a conjunction of axioms is one of the most frequent of those that is easy to understand. For example, when combining information related to project requirements (“requirements” of axioms are requirements determined by analysts) and errors from a bug tracker (“errors” of axioms are errors detected by testers, who are usually quality control specialists , and fill out error tracking forms based on certain requirements), the result is a “resulting axiom,” which is essentially a combination of the number of errors associated with one functional t by rebuilding.
  • 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
  • the API manager module 826 uses 143 files 830 (which contain triples in N3 format) to search for the implementation of method 828, where the ontology "ar 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.
  • 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.
  • 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.
  • 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 the 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 in the form of a scheme 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 in conjunction with 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.
  • Web Services Description Language 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:
  • 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.
  • the API manager 826 accepts the input and checks the input arguments for compliance with the method description.
  • API manager 826 loads and prepares the necessary data model and creates a model snapshot to isolate from other requests and operations. A write transaction is open if the operation changes the model data.
  • the program code (or rules with ontologies and Comindware ® Language) is called that executes the method.
  • 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.
  • 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 method 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:
  • 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);
  • 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.
  • 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.
  • the LZ converter 849 allows you to generate a data model based on the contents of the N3 file 830. (It is worth noting that triples can be stored in a 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 carried out only in 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 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.
  • OSS transactions include the following phases:
  • Start Record a timestamp marking the start of a transaction.
  • 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.
  • a B-tree-shaped data store is used to make searches more efficient.
  • the b-tree can be implemented as a set of tables.
  • FIG. 9 shows a database with a B-tree structure for storing triples.
  • predicates, additions, and subjects are stored in a database in a hashed form.
  • the values of the task, status and owner of the task can be hashed before saving to the table. Hashing allows you to speed up the search process by sorting the hash values in the database.
  • the key table in the database is a table containing relationships between predicates, subject and additions.
  • the keys in the key table are sorted.
  • the predicate table 910 contains the predicates P1 ... Pn used to select the subjects and additions.
  • references N1S ... NnS are values in the predicate table and which are links to tables N1S ... NnS (920 and 940, respectively).
  • Tables 920 and 940 represent the relationship between the subject and the additions.
  • NnS NnS
  • P2 name
  • NnO N10 ... NnO.
  • PI al, a2, a3
  • B-tree An example of a predicate with three attributes is the following statement:
  • FIG. 10 illustrates an example of storing predicates with their attributes in a B-tree according to an exemplary embodiment.
  • the predicate table 1010 contains predicates sorted in a specific order.
  • the predicate table 1010 also contains references to the corresponding stored attributes for each of the predicates.
  • the first set of predicate P1 has degree three (i.e., the predicate has three attributes). Therefore, when the first predicate is recorded in table 1010, table 1010 contains four references to stored attributes.
  • the first link (Link1) refers to table 1020 containing all of the first attributes (i.e., attributes placed first in all sets).
  • the second link (Link2) points to table 1030 containing all the second attributes of all sets.
  • the third link (Link3) points to table 1040, which contains all the third attributes.
  • the fourth link (Link4) is an additional link that points to table 1050, which contains the terminator.
  • the terminator is a constant value (numeric or text).
  • the terminator is used to obtain triples from the B-tree 1000.
  • the triples are identified inside the B-tree by the terminator.
  • attributes are read from the B-tree 1000, the search for the triple continues until a terminator is found that matches the particular triple.
  • Each set of attributes, along with the corresponding predicate, is assigned an identification number when writing to the B-tree 1000. The next identification number is increased by one.
  • the data sets are ordered according to when they are written to the B-tree 1000.
  • each set (predicate, attributes, and terminator) has a corresponding unique identifier also stored in the B-tree 1000.
  • each attribute has a position identifier that identifies the position of the attribute in the set (i.e., first, second, third, etc.).
  • the first set contains the attribute “al” in the first position. Therefore, the attribute “al” is written to table 1020 with the identifier “1” indicating that the attribute belongs to the first set.
  • Attribute "a2" is the second in the first set. Thus, it is recorded in table 1030 with the identifier "1.”
  • the attribute "a3" is the third in the first set. Therefore, it is recorded in table 1040 with the identifier "1.”
  • the terminator with identifier "1” is recorded in table 1050. The terminator "1" indicates that there are no more attributes in the first set.
  • the "al” attribute is the first in the second set. Therefore, it is written to table 1020 with identifier "2", which indicates that the attribute "al” belongs to the second set.
  • the second set contains only one attribute. Thus, the terminator with the identifier "2" is recorded in table 1030.
  • tables 1020-1050 may contain links to other tables instead of actual identifiers. This example is depicted in FIG. 4.
  • Table 1010 contains a link (Table2Reference) to table 1020.
  • Table 1020 contains links (Table3Reference and Table4Reference) that point to tables 1020 and 1030 containing identifiers.
  • tables belong to the B-tree.
  • tables serve as branches of a B-tree. If you need to get a specific data set (predicate with attributes) from the B-tree, then the predicate, attributes and terminator are searched based on the corresponding identifier.
  • a typical system for implementing the invention includes a multipurpose 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. device (ROM) 24 and random access memory (RAM) 25.
  • ROM read-only memory
  • RAM random access memory
  • the ROM 24 stores the basic input / output system 26 (BIOS), consisting of the main routines that help exchange information between elements inside the computer 20, for example, at the time of launch.
  • BIOS basic input / output system 26
  • 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 disk drive 30 for reading from or recording to a removable optical disc 31 such as a compact disc, 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.
  • 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 may include be a microphone, joystick, gamepad, satellite dish, scanner, or any other.
  • serial port interface 46 that is connected to the system bus, but can be connected via other interfaces, such as a parallel port, game port, or universal serial bus (USB).
  • a monitor 47 or other type of visual display device is also connected to the system bus 23 via an interface, such as a video adapter 48.
  • 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 on 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.
  • LAN local area network
  • GC global computer network
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Educational Administration (AREA)
  • Game Theory and Decision Science (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • General Business, Economics & Management (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Stored Programmes (AREA)

Abstract

Способ обработки данных графов, представляющих связи Объектов, включающий инициацию запроса на данные от инициатора запроса; создание модуля получения данных с хранилищем модуля получения данных; копирование данных (которые характеризуют данные, хранящиеся во внешнем хранилище данных) в хранилище модуля получения данных; обработку запроса посредством поиска соответствующих запросу данных во внешнем хранилище данных; обработку запроса посредством поиска данных, соответствующих запросу, в хранилище данных модуля получения данных; обработку запроса посредством поиска и обработки правил, согласно которым выводятся данные, соответствующие запросу, в хранилище данных модуля получения данных; возврат найденных данных инициатору запроса, где взаимодействие между инициатором запроса, модулем получения данных и хранилищем данных осуществляется через общий интерфейс матчера, и где хранилище данных и модуль получения данных являются моделями, объединенными в любых вариациях, по крайней мере, в одну объединенную модель.

Description

СИСТЕМА И СПОСОБ ОБРАБОТКИ ДАННЫХ ГРАФОВ
Данное изобретение относится к способу и системе обработки графов данных.
Любые типы данных могут быть представлены в виде троек. В отношении настоящего изобретения, данные о которых идет речь, включают пользовательские данные и онтологии. Данные могут быть представлены, например, в виде RDF-графа.
Ниже приведены два примера представления RDF-графов в XML-формате (который зачастую наиболее удобен для компьютерной обработки) и в виде Ν-троек или N3 (которые используются в настоящем подходе и которые наиболее удобны для понимания человеком).
XM L-синтаксис:
<?xml version="1.0"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/l.l/"
xmlns:exterms="http://www.example.org/terms/">
<rdf description rdf:about="http://www.example.org/index.html">
<exterms:creation-date>August 16, 1999</exterms:creation-date>
</rdf:Description>
<rdf:Description rdf:about="http://www.example.org/index.html">
<dc:language>en</dc:language>
</rdf:Description>
</rdf:RDF>
^-синтаксис будет выглядеть следующим образом:
ex:index.html dc reator exstaff:85740 .
ex.index.html exterms:creation-date "August 16, 1999" .
ex:index.html dclanguage "en".
Таким образом, XML-синтаксис намного подробней З-синтаксиса, однако он легче обрабатывается компьютерами.
Тройка является основной единицей Среды Описания Ресурса RDF (RDF) и состоит из Субъекта, Предиката и Объекта. Набор троек обычно называют RDF-графом, пример которого представлен на ФИГ. 1. Направление стрелки (например, (110а, 1106) в любой взятой тройке (например, 120) указывает от Субъекта (130) к Объекту (140). Модель RDF-данных похожа на классические концептуальные подходы моделирования, такие как сущность-связь или диаграммы классов, так как в ее основе лежит идея создания утверждений о ресурсах (в частности, веб- ресурсов) в виде выражений Субъект-Предикат-Объект.
Данные выражения рассматриваются как тройки в RDF-терминологии. Субъект обозначает ресурс, а Предикат обозначает особенности или аспекты ресурса и выражает отношение между Субъектом и Объектом. Набор RDF-утверждений представляет собой помеченный, ориентированный мульти-граф. Таким образом, модель данных на основе RDF естественней подходит для представления определенных видов знаний, чем реляционная модель и другие онтологические модели.
Как было сказано выше, RDF-данные часто хранятся в реляционных базах данных или в нативных хранилищах Троек, или хранилищах Четверок, если контекст (т.е. именованный граф) также хранится для каждой RDF-тройки. Именованные графы являются ключевой концепцией архитектуры Семантической Сети, в которой набор утверждений Среды Описания Ресурса (граф) идентифицируется с использованием URI, позволяя создавать описания этого набора утверждений, таких как контекст, информации о происхождении или других метаданных.
Именованные графы являются простым расширением RDF-модели данных посредством которой могут быть созданы графы, однако такая модель лишена эффективных средств различения между ними после появления в Вебе целиком. В то время как именованные графы могут отображаться в Вебе в виде простых связанных документов (т.е. Связанных Данных), они также крайне полезны для управления наборами RDF-данных внутри RDF-хранилища.
Как традиционно известного на ФИГ. 1 объект "Человек", "Менеджер" 140 и субъекты "Джон" 130, "Майкл", "Морган", "Мона", "Алекс" RDF-утверждений являются Унифицированными Идентификаторами Ресурса (URI), определяющими ресурсы. Ресурсы также могут быть показаны пустыми узлами. Пустые узлы не являются непосредственно идентифицированными из RDF- утверждений. В RDF-графе пустой узел является узлом, представляющи ресурс, для которого не задан URI или литерал. Ресурс, представленный пустым узлом, также называется анонимным ресурсом. Согласно RDF-стандарту, пустой узел может быть использован только в качестве Субъекта или Объекта RDF-тройки. Пустые узлы могут быть обозначены посредством идентификаторов пустых узлов в следующих форматах, RDF/XML, Turtle, N3 и Ν-тройках. Следующий пример показывает, как это работает в RDF/XML:
"<rdf:Description rdf:about="http://www.mkp. lon.com/~hy561" с!с: 1е="Управление веб- данными ">
<ex:student rdf:nodelD="_:b"/>
</rdf:Description>
<rdf:Description rdf:nodelD="_:b" ex:fullName="C3M Адамс">
<ex:homePage rdf:resource="http://www.mkp.lon.com/~adams/"/>
</rdf:Description>".
Идентификаторы пустых узлов ограничены лишь в области сериализации определенного RDF-графа, т.е. узел "_:Ь" в последующем примере представляют не один и тот же узел, как узел с именем "_:b" в другом графе. Пустые узлы рассматриваются в качестве простых указателей на существование вещи без использования URI (Унифицированного Идентификатора Ресурса) для определения какой-то конкретной вещи. Это не то же самое, как если предположить, что пустой узел указывает на "неизвестный" URI.
Предикат ("это" 110а, "должность" 1106) являются URI, которые также указывают на ресурс, представляя собой связи. Объект ("Менеджер", "Разработчик", "Генеральный директор" и, в частных случаях, "Джон", "Майкл", "Морган", "Мона", "Алекс") являются URI, пустыми узлами или строковым литералов в Юникоде. В данном изобретении для обработки информации из различных источников используется троечный подход.
На рисунках:
ФИГ. 1 иллюстрирует пример системы графов в соответствии с примерным вариантом;
ФИГ. 2 иллюстрирует часть семантической сети в соответствии с примерным вариантом;
ФИГ. 3 иллюстрирует традиционное получение данных (систему обработки запроса клиента) с использованием существующих технологий;
ФИГ. 4 иллюстрирует реализацию интерфейса матчера модуля получения данных;
ФИГ. 5 иллюстрирует алгоритм обработки запроса на примере точного матчинга;
ФИГ. 6 иллюстрирует алгоритм обработки запроса на примере матчинга данных по шаблону;
ФИГ. 7 иллюстрирует пример различных бизнес-приложений, используемых в различных отделах компании, и обработку данных в них.
ФИГ. 8 иллюстрирует систему для примерного варианта.
ФИГ. 9 иллюстрирует базу данных со структурой В-дерева для хранения троек.
ФИГ. 10 иллюстрирует пример хранения предикатов и их атрибутов в В-дереве.
ФИГ. 11 иллюстрирует примерную систему для реализации изобретения.
ФИГ. 12 иллюстрирует обработку запроса клиента после того, как будет найдено соответствующее правило.
ФИГ. 13А, 13Б иллюстрирует пример комбинирования моделей (объединения моделей).
ДЕТАЛЬНОЕ ОПИСАНИЕ ПРЕДПОЧТИТЕЛЬНЫХ ВАРИАНТОВ
Обозначенные выше материалы будут описаны детально применимо к предпочтительным вариантам текущего изобретения, примеры которых проиллюстрированы на соответствующих рисунках.
На ФИГ. 2 показан семантический стек в соответствии с примерным вариантом изобретения. Семантический стек, используемый в примерном варианте, включает в себя Унифицированный Идентификатор Ресурса (URI) 201. Стоит отметить, что описано может быть все, что может быть идентифицировано при помощи URI, так что семантическая сеть может относиться к животным, людям местам, идеям и т.д. Семантическая разметка часто генерируется автоматически, чем вручную. URI могут быть классифицированы в качестве указателей (URL), имен (URN) или тех и других.
Единообразное имя ресурса (URN) является как именем для человека, в то время, как Универсальный Указатель Ресурса (URL) напоминает адрес проживания человека. URN определяет индивидуальность элемента, в то время как URL предоставляет способ его поиска. CmwL (Язык Comindware) 211 описывает функцию и отношения всех этих компонентов семантического веб-стека; XML 203 обеспечивает элементарным синтаксисом структуру содержимого в документах, поскольку ассоциации не имеют семантики для значения контента, содержащегося в них; RDF 205 является простым языком для представления модели данных, который относится к объектам ("ресурсам") и их связям. Модель на основе RDF может быть представлена в XML-синтаксисе. RDF-схема 207 расширяет RDF и является словарем для описания свойств и классов основанных на RDF ресурсов и семантики для обобщенных иерархий таких свойств и классов.
Онтология 215 формально представляет собой знания в виде набора понятий в домене, используя общий словарь для определения типов, свойств и взаимосвязей данных понятий. Онтологии представляют собой структурные каркасы для организации информации. Онтологии описываются посредством (Языка Описания Онтологий) OWL или посредством CmwL, который позволяет описать Классы и их связи друг с другом и другими сущностями (см. ниже). Онтологии могут расширять предопределенный словарь (например, RDF-словари или OWL-словари). Словарь представляет собой набор данных информации определенных терминов, которые имеют одинаковый смысл во всех контекстах.
Онтологии используют предварительно определенный зарезервированный словарь/глоссарий терминов для понятий и отношений, определенный для конкретного домена/предметной области. Онтологии могут быть использованы для выражения семантики терминов словаря, их связей и контекстов использования. Таки образом RDF-схема является словарем для RDF. OWL или CmwL могут быть использованы для записи семантики предметных областей в онтологии. По существу, любые данные, например, онтологии или таксономии, могут быть выражены в тройках. Тройка - это факт.
Таксономия 209 является иерархическим способом классифицировать все объекты в данном мире: книги, продукты, виды, концепции и др. В семантической сети таксономия является словарем терминов и их точных определений. Когда словарь логически упорядочен в иерархии, он называется таксономией. Он является общим ресурсом для всех в информационной экосистеме, использующимся для синхронизации значения терминов.
В одном варианте осуществления, язык Comindware 211 используется вместо Языка описания Онтологий (OWL) в семантическом стеке. Comindware-язык представляет собой ограниченную версию OWL с целью повышения производительности и избавления от функциональности и операций, которые не являются необходимыми для целей бизнес- приложений и/или для использования с онтологиями (но с использованием OWL-словаря и некоторых его правил 213).
Как было сказано выше, данные состоят из пользовательских данных и онтологий. Пользовательские данные хранятся в базе данных (например, на жестком диске) в виде аксиом. Аксиома, или постулат, является исходной или стартовой точкой рассуждений. Как классически задумывалось, аксиома является настолько очевидным предположением, что без споров принимается за истину.
Как было сказано выше, N3 основан на RDF-стандартах и эквивалентен синтаксису RDF/XML, однако обладает дополнительными особенностями, такими как правила и формула. Правила могут быть написаны на N3, OWL, XNL и др.
Простое правило ( -правило) может сказать что-то вроде: если X является частью Y и если Y является частью Z, то X является частью Z, или "{ ?х rdfs:4acTbOT ?у. ?у rdfs:4acrbOT ?z} => {?х rdfs:4acrbOT ?z}."
Комбинация скобок "{" и "}" и "=>" является правилом. Фигурные скобки здесь заключают в себе набор утверждений и представляют собой формулу. Все формулы заключены в фигурные скобки. Не считая того, что Субъект и Объект тройки (Субъект формулы представлен двумя утверждениями, а Объект формулы представлен одним утверждением) является формулой, показанный выше пример является простым утверждением. Формула является частью правила и может быть представлена набором утверждений (по крайней мере, одним утверждением), где правило также является утверждением, и где утверждение является тройкой.
В приведенном выше примере утверждения "?х" является переменной (или неизвестной величиной, искомой величиной). Стоит отметить, что "?х" не всегда представлен искомой величиной, вместо этого известная часть утверждения (в виде URI) "?х" может быть использована для проверки подлинности факта. Как было сказано выше, любые данные, такие как сущность, событие и другие могут быть описаны тройкой. Тройка может описывать факт, например, "Билл - это Человек", "Джон - это Человек", "Джона должность - менеджер".
Если тройка выглядит следующим образом: "?х это Человек", то будут найдены все вещи (которые удовлетворяют утверждению). Но если часть утверждения, такая как "Билл" и "Джон" будут использоваться в качестве входных данных для "?х", то данное утверждение может быть проверено на "истину" или "ложь", т.е. хранился ли данная тройка(тройки) среди троек. Для данного примера после подстановки "Билл" и "Джон" в "?х" следующие утверждения: "Билл - это Человек" и "Джон - это Человек" будут истинны, поскольку эти тройки хранятся в базе данных. Если используется утверждение "?х должность менеджер", и "Джон" и "Билл" используются в качестве входных параметров для "?х", то только одно утверждение " Джона должность - менеджер" интерпретируется, как истина, а утверждение "Билла должность - менеджер" является ложью, поскольку такой тройки не хранится в базе данных (и она не выводится из тройки (троек)). Если переменная "?х" не связана со значением из тройки "?х это Человек", то данная тройка используется для поиска всего, что удовлетворяет данной тройки, т.е. будут найдены "Билл" и "Джон".
В описанном выше примере "->" используется в качестве специального предиката, означающего "следует". Он используется для связи формул. На самом деле, это - сокращение от URI log:implies, или: http://www.w3.Org/2000/10/swap/log#implies. Когда две формулы связаны при помощи "log:implies", это - правило, и, как было сказано выше, все правила являются просто различными видами утверждений. Формула содержит вещи, которые могут быть представлены с использованием текущих RDF/XML; эти правила не являются частью стандартного RDF-синтаксиса.
Стоит отметить, что значение выражений, написанных на N3 при помощи фактов и правил, легко могут быть поняты без знания языка программирования. В данном описании изобретения части утверждений поименованы в виде описательных имен. Так "Ошибка" является ошибкой; "Джона должность менеджер" означает, что Джона занимает должность менеджера (например, в компании); "Билл - это человек" означает, что Билл является человеком; "задача1 статус закрыта" означает, что статус "задачи1" - закрыта и т.д. таким образом код, описанный в данном изобретении, может быть использован в качестве описания особенностей изобретения.
Например, часть утверждения "продуктДляОшибкиТег" может быть интерпретирована как "Тег для продукта для ошибки" или как 'Тег с именем "Продукт для ошибки". Другими словами, "Тег, который ассоциирует Продукт с Ошибкой". Другим примером является "cmw.-атрибутыСвойства", который может быть интерпретирован как атрибуты свойства или свойственные атрибуты. Еще один пример: часть утверждения "создательТег" может быть интерпретирована как Тег, имя которого "Создатель" или автор, т.е. человек, который что-то создает, например, задачу или ошибку.
Упомянутые выше значения переменных могут быть предопределены перед тем, как будет обрабатываться/вычисляться правило с этими переменными.
Следующая запись используется для определения "?тег" и "?значения" в качестве входных данных (стоит отметить, что Входные данные могут быть связаны/зарегистрированы на данные переменные, как обсуждается в данном изобретении:
-вх ?тег, ?значения.
Данная запись маркирует переменные "?тег", "?значения" как переменные, которые должны содержать значения, и определяет невозможность использование данных переменных без значений, т.е. значения данных переменных не должны быть не определены. Такие переменные также называются Входами, а значения переменных входными значениями, например, для правил, методов/функций/встроенных функций/функторов и т.д., которые описаны ниже.
Следующий пример демонстрирует использование Входов для вычисления правил.
вх ?тег, ?значения.
{
?тег теппредикат ?предикат. #для всех предикатов тегов.
?значения список:член Рзначение. #со всеми значениями тегов
-?х Рпредикат ?значение. #поиск всех данных, написанных в тройках.
} => { (?тег ?значения) запрос:тегЗапрос ?х }.
{
(пример:продуктДляОшибкиТег (продукты:Продукт1 продукты:Продукт2)) запрос:тегЗапрос
?х.
(пример: важностьОшибкиТег (важностьОшибки:высокая)) запрос: запростегЗапрос ?х. } => { запрос:42 запросрезультат ?х }. В данном примере переменные "?тег" и "?значения" определены в утверждениях "(пример:продуктДляОшибкиТег (продукты:Продукт1 продукты:Продукт2)) запростегЗапрос ?х." и "(пример:важностьОшибкиТег (важностьОшибки:высокая)) запрос: тегЗапрос ?х", где "пример:продуктДляОшибкиТег" и "пример:важностьОшибкиТег" являются значениями для "?тег"; и "важностьОшибки:высокая", а список из "продукты:Продукт1" и "продукты:Продукт2" является значениями для "Рзначения".
Данные, получаемые и обрабатываемые в процессе работы, используют приведенные ваше правила в зависимости от того, как эти правила будут вызваны и с какими параметрами, т.е. с неизвестными или с определенными данными.
В одном варианте осуществления настоящего изобретения, если "- вх ?тег, ?значения." не добавлена в исходный код, то приведенные выше два правила все еще остаются вычисляемыми, однако все, что будет найдено в базе данных и/или в Хранилищах Модуля Получения Данных будут использованы вместо Входов.
В другом варианте осуществления настоящего изобретения, если во втором правиле вместо "-(пример:продуктДляОшибкиТег (продукты:Продукт1 продукты:Продукт2)) запростегЗапрос ?х." написать "- ТнекаяПеременная запростегЗапрос ?х.", другими словами, если список значений заменить на неизвестную переменную, то результатом обработки утверждения является все, что ему соответствует. Стоит отметить, что в данном варианте "?тег" и "?значения" не определены в качестве Входов, как в предыдущем варианте.
В другом варианте осуществления изобретения, если "?тег" и "?значения" не определены в качестве Входов и вместо них в предыдущем описанном примере, вместо неизвестных переменных, используются известные значения, то обработкой утверждения будет являться проверка наличия данной конкретной тройки.
Возвращаясь к обсуждению обработки правил с Входами "?тег" и "?значения", в условиях приведенного выше исходного кода утверждения первой формулы используются для поиска данных, где найденные данные (например, Объекты/Элементы, которые являются экземплярами Классов и о которых будет сказано ниже), сохраняются в "?х"; а значения "?значения" и "?тег" из второго правила используются в качестве входных параметров (Входов) для первого правила (для вычисления правила). На самом деле, первое правило вызывается из второго правила с заданными параметрами - значениями "?тег" и "?значения".
В левой части первого правила ищутся пары с общим предикатом "теппредикат". Части утверждений ("пример:продуктДляОшибкиТег" и "пример:важностьОшибкиТег") являются значениями для ?тег. В связи с тем, что приведенный выше исходный код содержит тройку "пример:важностьОшибкиТег теппредикат пример:важностьОшибки;", то одной из искомых пар может быть пара "пример:важностьОшибкиТег + пример:важностьОшибки", а пара "пример:продуктДляОшибкиТег + пример: продукт" может быть второй искомой парой, как видно из исходного кода.
В правой части первого правила содержимое скобок (?тег ?значения) представляет собой массив/список из двух элементов/переменных. Стоит отметить, что список или последовательность является абстрактным типом данных, который реализует законченную упорядоченную коллекцию значений, где одно и то же значение может встречаться более чем один раз. Экземпляр списка представляет собой компьютерное представление математической концепции конечной последовательности; (потенциально) бесконечным аналогом списка является поток. Все найденные вещи/значения (и сохраненные в переменную "?х") в левой части второго правила являются результатом запроса на поиск "запрос:42", например, системе поиска данных Объектов в базах данных.
Стоит отметить, что первое утверждение в левой части второго правила "(примергпродуктДляОшибкиТег (продукты:Продукт1 продукты:Продукт2))" является списком из двух элементов, где первым элементом является "пример:продуктДляОшибкиТег", а вторым элементом - список/массив, содержащий элементы "продукты:Продукт1", "продукты :Продукт2".
Пользовательские данные и онтологии используются для описания Объектов/Элементов и связей Объектов/Элементов с другими объектами/Элементами, а также системы или ее части, которой принадлежат Объекты/Элементов, их взаимодействия с системой и т.д.
Объект/Элемент является сущностью, например, бизнес-сущностью: задача "Добавить описание для фото животного" является Объектом/Item, сотрудник "Билл" - Объект/, как и запрос на "Строительство моста", запись о пользователе в базе данных, 1Т-отдел, HR-отдел или любая другая сущность. Такие сущности в области программирования называются экземплярами класса. Таким образом, пользователь "Билл" является экземпляром Класса "Пользователь"; 1Т-отдел, HR- отдел являются экземплярами Класса "департамент" и т.д. Такие Объекты/Элементы являются искомыми данными, которые интересны пользователю и/или системе, и которые необходимо найти в базе данных.
В другом варианте осуществления изобретения встроенные функции (билт-ины) могут быть связаны/зарегистрированы на предикаты, которые (билт-ины) представляют программный (исходный) код, который позволяет выполнять определенные операции/действия. Такие действия не могут быть выполнены в тройках, поскольку тройки по своей природе носят описательный характер и не могут быть обработаны без специального внутреннего или внешнего кода.
Примерами источников данных в данном изобретении являются данные (например, в форме троек) из баз данных троек и из хранилищ троек, хранящих тройки, которые являются результатом обработки правил. Данные (например, в форме троек), которые были получены в процессе или после выполнения кодов билт-инов (которые связаны с определенными предикатами) являются другим источником данных в данном изобретении. Например, билт-ин может быть связан с ":отправитьВ" из тройки/утверждения "?имя :отправитьВ :ComindwareProjectMoflynb.". Связанный с предикатом билт-ин вызывает выполнение кода билт- ина, когда обрабатывается/считается правило с таким предикатом. Код билт-ина будет выполнен вместо обычной обработки правила, описанной выше. Обычная обработка правила (если ни один билт-ин не связан с предикатом "ютправитьВ"), например, означает выполнение поиска всех троек с предикатом "ютправитьВ" и Объектом
Figure imgf000010_0001
где найденные Субьекты данных найденных троек будут сохранены в переменную "?имя". Если билт-ин (который описывает систему/набор шагов для управления утверждениями/правилами и предикатом в частности) связан с предикатом "?отправитьВ", то правило с упомянутым утверждением "?имя ютправитьВ
Figure imgf000010_0002
Не будет обработано, как описано выше в данном параграфе (процесс поиска значений для переменной "?имя" не будет запущен), а будет выполнен код билт-ина. Например, билт-ин, связанный с предикатом ":50тправитьВ", может включать код, который отвечает за передачу/отправку данных из системы (из модуля получения данных) во внешние программные или аппаратные модули, принтер, экран и т.д., где данные, которые необходимо передать, являются значениями переменной "?имя", а ":ComindwareProjectMoflvmb" является Объектом, который идентифицирует внешний модуль (идентификатор внешнего модуля).
Стоит отметить, что билт-ины обычно связываются с предикатами при старте системы или при создании Модуля Получения Данных, однако также возможно создавать и связывать новые билт-ины во время работы системы (например, во время обработки правил Модулем Получения Данных). Билт-ины могут быть сохранены во внешнем модуле. Также стоит отметить, что билт-ины могут быть отвязаны или заменены другим билт-ином.
Билт-ины, сохраненные во внешних модулях, могут быть скомпилированы, например, в исполняемый код, такой как ".ехе" файл, библиотеку, в частности, в динамическую библиотеку (.dll). Билт-ин по сути является функцией (Классом, Подклассом, методом и т.д.) или их набором, написанном на любом языке программирования, таком как С#, С++, Java, java script, Язык Comindware, и т.д. Когда система "видит" упомянутый выше предикат (например, ":отправитьВ"), она ищет связанный с этим предикатом билт-ин, и после этого она вызывает/активирует соответствующий билт-ин. Билт-ин может иметь несколько входных параметров, например,
Figure imgf000011_0001
также как и все данные, найденные и сохраненные в переменной "?имя" в виде списка или массива (см. пример выше).
Эти параметры отправляются в билт-ин и обрабатываются в соответствие с функциональностью, прописанной в билт-ине. Билт-ин способен возвращать значения по их типу (целое, список, массив, строковый, символ и т.д.), а также то, был ли вызов успешно обработан или нет (если что-то может быть возвращено) в виде "истина" или "ложь". "Истина" означает, что вызов билт-ина был успешно обработан, и, например, правило может обрабатываться дальше (т.е. будет обработано следующее утверждение). "Ложь" означает, что система прекращает обрабатывать правило, содержащее предикат, используемый для вызова текущего билт-ина. Другими словами, "истина" и "ложь" указывают на наличие решения/результата согласно входу билт-ина.
Также стоит отметить, что функциональность билт-ина может включать математические операции, передачу/вывод данных на внешние устройства, модули и приложения, операции с данными (например, массивами, списками и т.д.), вычисление номера элемента, поиск начального элемента и т.д., т.е. любые операции, действие, методы с данными (с тройками и частями троек/утверждениями).
Другой пример изобретения может включать специализированные ключевые слова/зарезервированные слова. Как было сказано выше, тройку, упомянутые в данном изобретении, являются описательными, и необходимо связывать билт-ины с предикатами, которые описывают операции. Упомянутые здесь ключевые слова ("if, "else", "then" в данном примере) используются в качестве примера таких типов билт-инов (так называемые билт-ин- доказательства):
if {
Рчеловек :прозвище ?имя.
} then
{
}
else {
"Человек" -> ?имя }
Упомянутые билт-ины-доказательства могут быть вызваны также, как и билт-ины, и способны выполнять те же функции, что и билт-ин, и даже некоторые дополнительные, однако принцип их работы отличается. Билт-ин-доказательство является способом предоставления интерфейса для использования данных из модуля получения данных (таких как компоненты, функции, факты, аксиомы, константы модуля получения данных, части системы (проиллюстрированной на ФИГ. 8) и их комбинации) для вычисления правил. Другими словами, билт-ин-доказательство может получить доступ и использовать внутренние данные/компоненты внешних и внутренних модулей системы, включая модуль получения данных (и имеет разрешение на использование кода модуля получения данных), поскольку билт-ины- доказательства имеют интерфейс вызова билт-ина (или подобный билт-инам).
Рассмотрим "If" в качестве примера билт-ин-доказательства. "If является понятным (для разработчиков программного обеспечения) сокращением (короткой записью) для операций/действий с утверждениями или частями утверждений. Парсер ассоциирует имена билт- инов-доказательств для перевода части исходного кода с определенным билт-ином- доказательством (билт-ином-доказательством "если" в данном случае) в тройки, чтобы эти тройки могли быть обработаны системой. Стоит отметить, что билт-ин-доказательства могут быть связаны не только с "if, но и с программными методами/функциями и, например, с такими операторами, как "then", "else", "foreach", "next", "break", "switch", "continue" и любыми другими операторами и функциями/методами, например, тригонометрическими, логарифмическими и другими общими (и специальными) функциями/методами/действиями/операциями.
В другом варианте билт-ин-доказательство является частью модуля получения данных, и его вызывающий метод является единственным видимым аспектом. Это является унифицированным способом доступа к данным модуля получения данных. Стоит отметить, что билт-ин- доказательство может использовать ту же самую часть кода, что и модуль получения данных.
Другой пример изобретения включает функторы, которые способны работать, как минимум, как билт-ины, однако функторы написаны на тройках. Другими словами, функтор является определенным видом билт-ина, который использует тройки и может быть сохранен в хранилище модуля получения троек, в базу данных, т.е. в любое хранилище данных. Таким образом, функтор способен выполнять те же функции, что и билт-ин, но с использованием троек и без использования внешних модулей. Стоит отметить, что билт-ины, билт-ин-доказательства, функторы могут быть расширены/дополнены после запуска модуля получения данных, во время выполнения приложения, Билт-ин может быть расширен путем добавления в него новых билт-инов, или путем создания новых билт-инов и связывания с существующими. Билт-ины могут храниться в файлах, внешних по отношению модулям системы, показанным на ФИГ. 4, ФИГ. 8 (таких как модули получения данных), которые (файлы) с билт-инами могут быть связаны, объединены/соединены. Также билт-ины могут быть сохранены в хранилища данных, таких как хранилища троек; в ОЗУ, базах данных, хранилища модулей получения данных, и т.д. Кпак было сказано выше, к модулям получения данных могут быть присоединены дополнительные файлы с билт-инами, например, для хранения билт-инов могут быть использованы dll-файлы, которые (файлы) могут быть написаны специально для приложения, или они могут быть общими системными файлами ОС, такими как компоненты MICROSOFT WINDOWS, компоненты LINUX или как файлы баз данных и т.д. Также стоит отметить, что вместо присоединения файла может быть использован любой источник данных, например, стрим данных, html, т.е. источник данных с интерфейсом передачи данных. Также стоит отметить, что билт-ин может быть не только внешним модулем для данного изобретения, но и являться частью модуля в составе компонента изобретения, таким как семантический процессор 840 (см. ФИГ. 8), или может быть присоединен к нему. Стоит отметить, что билт-ины могут сохранены в нескольких файлах или хранилищах данных.
ФИГ. 3 иллюстрирует традиционную системы получения данных (систему обработки клиентских запросов) с использованием существующих технологий.
Одной из функций любого приложения является получение данных во время работы, например, для отображения их на экране или для дальнейшей обработки. В контексте данного обсуждения такой запрос данных/запрос называется 'событием'. События могут быть вызваны действиями пользователя, оператора программного обеспечения или разработчика, и т.д. Например, данные могут быть запрошены из базы данных с использованием ГИП-функции. События также могут быть вызваны внешними модулями или приложениями, в частности операциями сервисов программы или действиями сервиса внешнего модуля. В примерном варианте сервис представляет собой автоматизированного пользователя, т.е. действия пользователя, которые могут быть запрограммированы в приложение, также являются частным случаем сервиса. Процесс формирования клиентского запроса к данным, используемым приложением, является примером того, как обрабатываются такие события. Такими запросами могут быть либо внутренними (адресованными модулям приложения), либо внешними (адресованными внешним модулям приложения, баз данных и т.д.). Такие запросы обеспечивают приложение определенными данными в соответствии с запросом. Запросы могут быть представлены в виде вызова функций/методов приложения, запросов к базе данных и т.д.
Клиент 310 может выступать в роли примера приложения, отправляющего данные типы запросов. Клиент 310 может быть представлен приложением 801-806 (см. ФИГ. 8), модулем приложения 807, семантическим процессором 840 (включая Слой Бизнес-Логики Приложения 820), модуль ГИПов (например, которые отвечают за поиск данных), модулями получения данных, моделями, упомянутыми ниже, частями модулей получения данных и т.д.
Следующий пример клиентского запроса к совокупности хранимых данных работает, как при традиционном подходе, так и в настоящем изобретении. В данном случае, совокупностью данных являются данные, сохраненные а базе данных 340 в хранилище данных 320. Формат сохраненных данных определяется внутренней структурой базы данных, т.е. если база данных используется Б-деревья, то сохраненные данные также будут представлены в виде Б-деревьев (см. ФИГ. 9 и ФИГ. 10).
В одном примерном варианте данного изобретения данные хранятся в базе данных, ОЗУ, хранилищах (например, хранилище модуля получения данных) и т.д. и могут быть представлены в виде набора аксиом, фактов и правил. Факты представляют собой данные, выведенные из аксиом с использованием, как минимум, одного правила и попутно записаны, например, в тройках. Стоит отметить, что факты также могут быть выведены из других фактов или аксиом в сочетании с правилами.
Например, правило, из которого может быть выведен факт: "{?х статус закрыт} => {?х видим ложь}". Данное правило может быть применимо к аксиомам или фактам "Ошибка номер 345 статус закрыта", "Ошибка номер 235 статус закрыта " и так далее. В приведенном выше примере все тройки, выведенные из правила "{?х статус закрыт} => {?х видим ложь }", являются фактами. Данное правило может быть применимо к любому факту или аксиоме, таким как "Что-то статус закрыт ". После применения правило будут выведены следующие факты: "Ошибка номер 345 видим ложь" и "Ошибка номер 235 видим ложь", которые могут быть интерпретированы системой или приложением (таким как Comindware Task Manager ( ), Comindware Tracker (R) и т.д.) в качестве инструкция для остановки показа ошибок Ошибка номер 345 и Ошибка номер 235.
После формирования запроса, в данном случае к базе данных, клиент 310 будет ждать ответа.
В приведенном выше традиционном примере запрос клиента обрабатывается базой данных с использованием интерфейса матчера. Стоит отметить, что интерфейс матчера может быть реализован в виде общего интерфейса, т.е. один общий интерфейс матчера может быть использован для связи между внешним/внутренним модулем (модулями) (инициатором запроса, клиентом и т.д.), базой данных (базами данных), модулем (модулями) получения данных, новыми моделями и объединенными моделями, описанными ниже.
Интерфейс представляет собой общую границу между двумя отдельными компонентами обмена информацией компьютерной системы (в данном случае такими компонентами являются База данных и Клиент). В данном случае обмен реализуется между программными модуля ми. Программный интерфейс может относиться широкому диапазону различных типов интерфейса на различных "уровнях": в данной реализации изобретения объекты/модули внутри приложения должны взаимодействовать посредством методов.
RDFLib является одной из программ, использующих технологию матчинга RDFLib графов, поддерживающую основные шаблоны матчинга троек с функцией "triplesO". Данная функция является генератором троек, соответствующих шаблону, заданному с помощью аргументов. Этими аргументами являются RDF-условия, которые ограничивают возвращаемые тройки. Условия с отсутствием условия рассматриваются как поиск со звездочкой.
База данных способна ответить на запрос клиента посредством интерфейса матчера. Интерфейс матчера дает знать клиенту о том, что база данных понимает его запросы и способна обработать их, т.е. способна своими силами провести поиск данных, связанных с запросом клиента. Интерфейс матчера определяет формат данного взаимодействия, т.е. декларирует возможности матчера. Особенности реализации системы (см. ФИГ. 3) позволяют базе данных обмениваться данными строго согласно запросу клиента (в частноаи, аксиом, хранимых в базе данных) без дополнительного анализа хранимых данных. Примером запроса может являться "Верни 'a b с' тройку". В соответствии с данным запросом система (или программный модуль) либо вернет данную тройку (если она существует) из набора данных (например, данных, хранимых в базе данных), либо вернет факт ее отсутствия. Такой клиентский запрос может быть представлен в виде вызова функции/метода интерфейса матчера: "ЕстьТройкаВСистеме (a b с);". Вызов методов интерфейса матчера позволяет получить ответы на запрос клиента.
В отличие от традиционных систем настоящее изобретение в одном из реализаций использует интерфейс матчера, способный отвечать на запросы двух типов:
Первым методом интерфейса матчера является запрос на точное совпадение (матчинг). Отвечая на данный запрос, система говорит, существуют ли тройки Субъект-Предикат-Объект в запрашиваемом объекте (например, базе данных) или нет. Например, база данных получает запрос от клиента "Существует тройка" "задача1 есть закрыта" в база данных?" Матчер вернет соответствующий ответ - "Да" или "нет".
Второй метод интерфейса матчера. Вторым типом запроса является запрос с переменными или неизвестными. В ответ на такой запрос система вернет набор (коллекцию, список, массив...) найденных данных. Например, клиент может отправить запрос к базе данных, вида "?х Предикат Объект", "Субъект Предикат ?х", "Субъект ?х Объект", "Субъект?х ?у", "?х ?у Объект", "?х Предикат ?у" и так далее. Затем клиент должен дождаться возврата системой соответствующих найденных данных. Другим примером типа запроса, о котором было сказано выше, является "?х ?у ?z", который просит систему вернуть все данных, хранящиеся в базе данных.
Имплементация интерфейса матчера. Первый метод интерфейса матчера использует запросы на точное совпадение от клиента к базе данных. Все последующие примеры, которые следуют далее, подразумевают, что данные хранятся в базе данных. Рассмотрим, например, что в клиенте 310 существует ГИП, который может быть использован, например, для просмотра информации о персонале компании. Должности сотрудников представлены в виде троек в форме групп (см. ФИГ. 1). Пользователь генеральный директор Алекс хочет посмотреть информацию о своих сотрудниках, выведенную на экран. Клиент подготавливает запрос данных, касающихся связей сотрудника с именем Морган и другими сохраненными данными. В данном случае запрос может относиться к таким категориям, как "разработчик", "человек", "создатель", "Корректор ошибок" и т.д. Для того, что выяснить, какие данные должны быть показаны, клиент подготавливает запрос. Могут быть отображены следующие данные: личная информация сотрудника, его/ее подчиненные и руководители, его/ее проекты, связанные с ним/с ней ошибки и т.д. Таким образом запрос на данные может затрагивать любое предполагаемое событие, например, отправку данных на экран, принтер, внешний или внутренний модуль или приложение; анализ данных (например, в соответствие с внешними правилами, не содержащимися в системе/приложении).
Другой тип клиентского запроса (например, посредством ГИПа или клиентской консоли) может запросить поиск сотрудников. Например, если задачей является поиск всех менеджером компании, запрос к сохраненным данным может выглядеть как тройка "?х это менеджер".
Запрос к базе данных (например, посредством интерфейса) может быть представлен в виде тройки (или вызова метода /функции интерфейса матчера с аргументом в виде тройки, например, вызова метода Match(a, b, с)), которую требуется найти в базе данных инструментами базы данных. Если в базе данных содержится такая тройка, то система вернет "да/истина", в противном случае ответом будет - "нет/ложь".
Второй метод интерфейса матчера оперирует по крайней мере одной переменной, например, трока "?х b с". При получении такого запроса база данных ничего не вернет, либо вернет набор соответствующих троек посредством итератора (например, в форме коллекции или набора). Коллекция также является итератором. Она не содержит все найденные элементы, напротив каждый последующий элемент будет получен посредством следующего запроса. Таким образом, система реализует отложенный возврат элементов: например, когда отправлен запрос типа "дай мне следующий элемент", итератор возвращает следующий найденный элемент. Т.е. каждый следующий элемент (тройка) становится доступным, когда это необходимо.
Итератор (lEnumerator в .NET) представляет собой объект, который позволяет обойти контейнер, в частности списки. Итератор выполняет обход и также получает доступ к элементам данных в контейнере. Итератор можно рассматривать как тип указателя, который обладает такими основными операциями, как ссылка на один конкретный элемент в коллекции объектов (так называемый "доступ к элементу") и изменение самого себя, чтобы указывать на следующий элемент (так называемый, "обход элементов "). Итератор проводит последовательный поиск троек, соответствующих запросу клиента 310.
ФИГ. 4 иллюстрирует реализацию интерфейса матчера модуля получения данных. Как было описано выше, когда база данных реализует интерфейс матчера, она способна отвечать на запросы клиентов, информируя о том, что запрошенная тройка наличествует или возвращая все найденные тройки в базе данных, которые соответствуют запросу клиента, Из-за своей структуры база данных может оперировать лишь с аксиомами, хранимыми в ней, (правила, хранимые в базе данных, также называются аксиомами в своем контексте). Если запрос клиента содержит факты, то база данных не способна сказать, что их нет, поскольку факты не хранятся базе данных. Как было сказано выше, факты выводятся из аксиом и/или других фактов с применением правил посредством модуля 410, после чего они сохраняются в хранилище 430.
Помимо фактов модуль 410 хранит информацию, используемую для получения этих данных, например, комбинацию фактов и правил (или их Идентификаторов), из которых они были выведены. Пример записи факта в хранилище 430 с Идентификатором правила из которого он был выведен: "т с b Правило номер 1234". Правило, используемое для вывода факта, может быть идентифицировано по его левой и правой части. Правило также может быть определено по совокупности обеих частей. Кроме того, левая часть правила может быть проиндексирована отдельно от правой части, так же как и совокупность проиндексированных/захэшированных частей может быть использована для идентификации посредством общего идентификатора, полученного из идентификаторов левой и правой частей правила. Левая часть правила или его правая часть, или факт и/или правило целиком могут быть обработаны модулем 410 (например, закешированы, захэшированы, проиндексированы, идентифицированы и т.д.) для того, чтобы сократить время, необходимое для доступа к фактам и правилам, хранимым в хранилище 430.
Для того чтобы ответить на запрос клиента, связанный с фактами, необходимо использовать модуль получения данных 430. Модуль 410 принадлежит движку/семантическому процессору 840 (см. ФИГ. 8) и не оперирует пользовательскими данными и онтологиями. Одной из особенностей модуля получения данных является его способность обрабатывать правила для вывода новых фактов, а также поиска данных в хранилище 430.
Модуль получения данных, как и база данных, реализует интерфейс матчера 440. Поскольку факты выводятся с использованием правил не только из других фактов, но и из аксиом, то модуль получения данных имеет доступ к базе данных для выяснения наличия там требуемых аксиом. ФИГ. 4 иллюстрирует случай, когда база данных также реализует интерфейс матчера 450 (только в случае, когда нет модуля получения данных, как показано на ФИГ. 3) для понимания запросов от модуля получения данных и ответа на них соответствующим образом.
Модуль получения данных может быть создан после возникновения события (см. выше), что также приводит к созданию снепшота базы данных 460. Стоит отметить, что обычно снепшоты создаются при запросе от клиента или нескольких таких запросах. Опционально, вместо создания снепшота система может остановить запись в базу данных. Также при создании модуля получения данных создается хранилище модуля получения данных 430, которое используется для хранения правил, взятых из базы данных. Стоит отметить, что взятые из базы данных правила могут быть сохранены в хранилище 430 не только в явном виде, а могут быть разобраны, что облегчает их обработку модулем получения данных. Например, хранилище 430 может хранить правые части правил, взятых из базы данных, вместе с Идентификаторами правил, по которым они вычисляются. Данные (правила), взятые из базы данных (также как и данные/факты, полученные в результате действий модуля 410) могут быть закешированы модулем 410 для более быстрого к ним доступа.
Стоит отметить, что вместо хранения данных (правил), полученных из базы данных, в хранилище 430, в хранилище 410 могут быть помещены ссылки на данные, сохраненные в базе данных.
В качестве примера рассмотрим запрос клиента к модулю получения данных, сформулированный в виде тройки "a b с" (точный матчинг). В отличие от случая, показанного на ФИГ. 3 (без модуля получения данных), в данном случае модуль получения данных будет иметь доступ к базе данных. Для того чтобы скоординировать запросы между модулем получения данных и базой данных, используются методы интерфейса матчера. Если запрошенные данные модулем получения данных не находятся в базе данных, то модуль 410 будет искать данную тройку в хранилище 430. Стоит отметить, что если запрошенной тройки нет в базе данных, то это означает не только то, что она отсутствует, но и то что она не является аксиомой. Если тройка найдена в хранилище 430 при запросе модулем 410, то модуль получения данных 410 продолжит поиск правила, используемое для вычисления этой тройки (поскольку тройка является фактом, как было сказано выше).
Также стоит отметить, что правые части правил, используемых для вычисления запрошенной тройки, не обязательно должны содержать указанную тройку. Если запрошенная тройка сформулирована как "a b с", то правая часть правила, содержащаяся в хранилище, может содержать "a b с", "?х b ?z", "?х ?у г", "а ?у ?z", "а ?у г" или другие тройки, и даже "?х ?у ?z", т.е. любые тройки, который потенциально могут соответствовать запрошенной. То есть может существовать несколько правил, которые могут быть использованы для вычисления тройки из запроса клиента. Правила анализируются с использованием lEnumerator, т.е. одновременно анализируется одно правило, и после этого анализа берется следующее правило, если таковое существует. Тройки разбиваются на составные части, где тройка является минимально частью для lEnumerator'a.
После того как модуль получения данных находит запрошенную тройку, будет проанализировано правило, в частности его левая часть, чтобы выяснить, существуют ли тройки, которые необходимо обработать модулем 410, как рассматривавшийся ранее запрос от клиента, т.е. посредством точного матчинга или матчинга с переменной (в зависимости от типа троек, найденных в левой части правила, т.е. являются ли они фактами или аксиомами, и содержат ли они переменные или нет).
Если используется точный матчинг, то после того, как будет найдено хотя бы одно правило, то это правило проверяется на истинность путем подстановки запрошенной тройки в правую и левую части правила. Например, правило "{?х d е. m ?у d} => {?х b с}", так что проверяется следующая тройка "{a d е. m ?у d} => {a b с}". Если правая часть может быть выведена из левой части, то ответ на запрос клиента будет положительным ("Истина"), в противном случае клиентское выражение маркируется как "Ложь".
Если в запросе клиента существует хотя бы одна переменная, то модуль 410 запускает поиск в хранилище и базе данных с использованием матчинга с переменной.
Если модуль получения данных не может найти правила, из которых может быть выведен данный факт, то ответ на запрос, отправленный в модуль получения данных, будет отрицательным: запрошенный факт/тройка отсутствует.
После того, как модуль получения данных 410 отвечает на запрос клиента, модуль 410 может быть удален или деактивирован. Однако стоит отметить, что модуль получения данных может быть создан не только на каждое событие, описанное выше. Один созданный модуль получения данных может отвечать на любое количество клиентских запросов. Процесс создания/удаления модуля получения данных управляется типом события, количеством запросов в событии и т.д. Например, запрос на отображение данных от пользователя Алекс в приведенном выше примере является событием. Клиент 310 может сформулировать, по крайней мере, один запрос, относящийся к данному событию. При обнаружении системой произошедшего события, вовлекающее обращение к хранимым данным, создается модуль 410 для обработки всех связанных с событием запросов. Также стоит отметить, что для каждого такого запроса или для группы запросов, связанных с одним и тем же событием, может быть создан отдельный модуль 410. Запросы могут быть сгруппированы, например, в соответствии с типами запрошенных данных или данных, к которым осуществляется доступ, (пользовательские данные, системные данные, аксиомы, онтологии), с их размером, их принадлежностью приложению (компании, отделу и т.д.) или они могут храниться в разных базах данных.
После того как модуль 410 обработает все запросы, относящиеся к одному событию, модуль может быть уничтожен. Модули 410, созданные для запросов или сгруппированным запросом, связанных с индивидуальным событием, могут быть уничтожены, как только будет готов ответ на запрос. Стоит отметить, что система может создавать один модуль 410 для группы событий, вместо создания модулей для каждого отдельного события. События могут быть сгруппированы, например, по времени их появления (т.е. они случились в определенный период времени, например, в нескольких миллисекундах или минутах друг от друга). В данном случае модуль 410 будет удален после того, как он ответит на все запросы, относящиеся к такой группе событий. При создании модуля получения данных 410 в это же время может быть создан снепшот базы данных. В случае если существует несколько баз данных, то снепшот может быть создан не для каждой базы данных, а только для тех, к которым осуществляется доступ настоящим запросом (может включать только части баз данных, например, некоторые таблицы). Снепшоты также могут быть заменены другими средствами согласования записи данных, встроенными в базы данных. То есть, слияние данных из различных источников реализуется средствами баз данных. При использовании встроенных в базы данных/хранилища или внешних средств хранения и согласования записи данных, основанных на снепшотах базы данных и/или хранилища, данные могут временно храниться в промежуточных хранилищах.
Снепшоты хранилища/базы данных обычно перекрываются, так как в этом случае данные записываются в базу данных асинхронно. Перекрытие снепшотов означает, что даже, если данные записаны в базу данных в последовательности снепшотов, то нет гарантии того, что они будут непрерывными, целостными и валидными. Для того чтобы сделать запись валидной, целостной и непрерывной, хранилище данных должно быть снабжено, по крайней мере, одним промежуточным контейнером данных для хранения данных, которые должны быть записаны в хранилище данных клиентом, модулем получения данных или базой данных. Обычно, данный контейнер представляет собой виртуальное хранилище, расположенное в памяти компьютера или в специально выделенном хранилище данных (например, хранилище с базой данных, хранилище с клиентом или сетевое/"облачное" хранилище). Стоит отметить, что описанное выше хранилище 320 может содержать клиента 310, по крайней мере одну базу данных и другие модули, используемые для обработки троек, такие как приложения 801-806, модули приложений 807, семантический процессор/движок 840. База данных 340, клиент 310 и другие модули могут располагаться на различных хранилищах и в различных комбинациях, например, клиент и база данных - на одном хранилище, остальные модули - на другом, или база данных - на одном хранилище, в клиент - на другом хранилище (хранилищах), и т.д. ФИГ. 5 иллюстрирует алгоритм обработки запроса, использующийся при точном матчинге.
Обработка запроса начинается в шаге 515. Фигура содержит запрос к интерфейсу матчера 440 модуля 410. После того, как интерфейс матчера модуля 410 получает 520 запрос, модулем 410 проверяется его соответствие данным, хранимым в базе данных. Если в базе данных содержатся данные для ответа на запрос, то далее система возвращает 540 факт того, что запрос "Истинен".
Если в шаге 520 система не может найти данных для ответа на запрос, то процесс переходит в шаг 530, где осуществляет попытку обнаружить данные для ответа на запрос, например, факты (тройки, выведенные модулем 410, как было описано выше). В том случае если модуль 410 находит данные, необходимые для ответа на запрос (530), то система возвращает "Истина" (540), подтверждая истинность запроса.
Если в шаге 530 модуль 410 не может найти данные для ответа на запрос, то процесс переходит к шагу 560, в котором пытается обнаружить правила, которые могут быть использованы для вывода данных для запроса. Если в данном шаге правила не были найдены, система возвращает факт, что запрос/утверждение "Ложно" (580).
Если в шаге 560 модуль 410 находит правило, которое может быть использовано для вывода данных для клиентского запроса, то процесс переходит к шагу 570, в котором пытается проанализировать правило (описанное выше), в зависимости от типа матчинга. Утверждения, получающиеся в результате анализа левой части правила, используются для создания запросов (входных данных для модуля 410), которые затем обрабатываются так же как и клиентские запросы. Другими словами, анализ существующего правила (правил) в шаге 570 приводит к формированию, по крайней мере, одного дополнительного запроса, например, запроса на прецизионный/точный матчинг или на матчинг на основе шаблона (основанный на паттерне матчинг). Таким образом процесс возвращается к шагу 510 и продолжает обрабатывать все запросы, сгенерированные в результате анализа правила.
В процессе анализа запроса модуль 410 вернет данные, которые найдет до тех пор, пока результатом не будет "Ложь". В случае, когда все данные, относящиеся к запросу "Истинны", модуль 410 вернет факт того, что весь запрос/утверждение "Истинно".
В отличие от точного матчинга, описанного выше, матчинг с переменной для троек вида "?х b с" вернет любые данные, соответствующие данной маске/паттерну, например, "a b с", "m b с", "о b с". Данные, которые возвращаются инициатору запроса (например, клиенту), могут быть взяты из базы данных или из хранилища 430.
Стоит отметить, что ФИГ. 5 применим не только к точному матчингу, но также и к матчингу данных на основе паттерна. В данном случае в шаге 520 процесс выполняет поиск всех троек, которые соответствуют указанному паттерну, например, "?х b с", каждая из которых может храниться в базе данных, в хранилище модуля получения данных 430, и могут быть выведены на основании правил. Таким образом, результатом первоначального запроса будут являться данные, отождествленные с запросом. lEnumerator является одним из способов возвращения данных инициатору запроса (например, клиенту/внешнему модулю и т.д.) в соответствие с шаблоном, упомянутым выше. lEnumerator позволяется возвращать найденные данные клиенту один за другим, пока клиент не скажет хватит. Это значит, что клиентский запрос "?х b с" возвращает lEnumerator.
Далее клиент (инициатор запроса, внешний/внутренний модуль, модуль получения данных и т.д.) должен решить, требуется ли ему следующий элемент (в частности, следующая тройка), включая первый, поскольку в какой-то момент времени во время обработки клиентского запроса клиент может получить результат, так что следующие элементы ему не понадобятся. Если система обнаружит, что клиенту достаточно данных, то lEnumerator будет остановлен. Стоит отметить, что lEnumerator является интерфейсом со своими методами, такими как Current_Element и Enum_Next. Enum Next берет следующий элемент, в то время как Current_Element отражает текущий элемент. Если клиент не удовлетворен представленными данными, то для получения следующих данных (в частности, троек) будет вызван метод Enum_Next. Данный процесс продолжается до тех пор, пока клиент не будет удовлетворен, или до тех пор, пока не останется данных, соответствующих запросу.
Стоит отметить, что lEnumerator остается доступным (даже если он будет приостановлен), если он получит от клиента аналогичный запрос или относящийся к тому же первоначальному запросу, или любой другой запрос, или от модуля 410. В данном случае lEnumerator может продолжить работу, возвращая остальные данные.
Как было описано выше, хранилище 430 хранит не только правила, взятые из базы данных, но и факты, например, "т с b Правило Номер 1234", означающий, что факт "т с Ь" выведен согласно "Правилу Номер 1234". СТОИТ отметить, что хранилище 430 хранит данные в любом известном формате, например, в виде дерева (например, Б-дерева), таблиц, в xml-формате, текстовом формате (текстовом файле (текстовых файлах)). Также стоит отметить, что форматы хранимых данных могут поддерживать матчинг данных. Также, хранилище 430 хранит попытки вычислений с использованием, по крайней мере, одного правила, и хранит даже неудачные попытки этих вычислений, т.е. процессы вычисления были запущены, а результат этих вычислений - ложь, где желаемый результат не был достигнут, например, не были найдены тройки, не были найдены желаемые части троек и т.д.
Также стоит отметить, что перед сохранением в хранилище 430 правила могут быть разбиты на тройки, из которых они состоят. Таким образом, правило "Правило Номер 1234" может быть записано в виде, где: "ш с Ь" - правая часть правила и "Правило Номер 1234" - идентификатор правила. Эта запись может быть расширена дополнительной информацией, например, о том, было ли это правило проанализировано или был ли данный факт обработан (например, как описано в шаге 570). Если правило или факт не были проанализированы, то запись может остаться неизмененной, или может быть расширена "НеСчиталось", например, как "т с b Правило Номер 1234 НеСчиталось", означающее, что данное правило еще не было подсчитано. Если правило было подсчитано, но процесс был приостановлен, то добавляется следующее расширение: "т с b Правило Номер 1234 Приостановлено". Если правило считается/обрабатывается в настоящее время, то расширение будет следующим: "т с b Правило Номер 1234 Обрабатывается".
Дополнительная информация, хранимая вместе с фактами, может включать расширения "НеСчиталось" или "Правило", означающие, что данное правило еще не было подсчитано. Дополнение "Готово" означает, что правило полностью подсчитано, то есть правило было обработано согласно определенному запросу с определенными значениями. Дополнение "Выведено" означает подсчитанные и отданные факты. Расширение "Приостановлено" означает, что правило не было полностью обработано (такое происходит, например, когда, клиент удовлетворен выходными данными в какой-то момент времени). Дополнительная информация (дополнения) представлена в виде отметок, которые используются во время матчинга в хранилище 430, как было описано выше.
В случае если подсчитанный результат (факты) соответствуют определенному типу запросов (включая текущий запрос), факты будут переданы, например, клиенту. Факты будут передаваться до тех пор, пока не будет найдена определенная отметка. Таким образом, отметка "Готово" отменяет повторение вычисления текущего правила. Данная отметка также выступает в роли терминатора в Б-дереве (см. ниже).
Стоит отметить, что как только будет найдено правило, используемое для выведения факта, этот факт будет добавлен в хранилище 430. Для оптимизации работы с данными, хранящимися в хранилище 430, правило будет помещено в него в том же порядке, в котором было взято из базы данных. Также после окончания вышеупомянутого преобразования правила могут быть упорядочены по имени, идентификаторам и т.д. Факты, взятые из хранилища 430, в свою очередь, будут добавлены в конец списка правил, как только будут найдены соответствующие правила. В процессе обработки клиентских запросов факты берутся начиная с последней добавленной в хранилище записи.
В одном варианте изобретения обработка данных начинается с последних добавленных/сохраненных данных (т.е. сверху вниз, если хранимые данные представлены списком). Таким образом, недавно сохраненные данные будут найдены быстрее более старых данных. В связи с этим, полученные из базы данных правила помещаются в начало хранилища, в то время как тройки (факты) выведенные из них сохранены в конец хранилища.
Возвращаясь к ФИГ. 5, следует отметить, что алгоритм, продемонстрированный на данной фигуре, является универсальным алгоритмом возврата данных (применимым, как к точному матчингу, так и к матчингу по шаблону) инициатору запроса, и может быть представлен в виде внешнего (по отношению к модулю получения данных) инициатора запроса и в виде внутреннего инициатора запроса, где сам модуль получения данных выступает в роли инициатора запроса. Вариант, в котором модуль получения данных является инициатором запроса, показан на ФИГ. 5 и ФИГ. 6, см. переход от шага 570 в шаг 515 (и из шага 690 в шаг 620 на ФИГ. 6). На ФИГ. б переход из шага 690 в шаг 620 показан несколькими линиями, которые представляют собой специфический случай, когда во время анализа правил(а) основной запрос 510 в шаге 570 разбивается на несколько запросов (что также показано на ФИГ. 12 пунктирными линиями). Когда запрос разбивается на несколько запросов, это означает, что в ходе анализа правила, были выявлены ссылки на другие правила. Возвращаясь к обсуждению внешних и внутренних инициаторов запросов, следует отметить, что внешние инициаторы запросов являются типичными модулями или программными компонентами, которые не включают в себя модуль получения данных (например, полноценный программный продукт для управления персоналом, такой как Comindware Tracker, который включает получение данных и поиск данных объектов в качестве одной из своих функционал ьностей, или поиск задач сотрудника, поиск ответственных за проект сотрудников, компоненты или части, принадлежащие проекту, процессу, физическому объекту, например, автомобилю и так далее). Также следует отметить, что инициаторы запросов могут не являться частью такой компьютерной программы или компонента (например, модуль получения данных может быть отдельной программой и может выступать в роли интерфейса для программного обеспечения, в котором нет возможностей модуля получения данных и поиска, например, посредством ГИП, чтобы сделать возможным управление персоналом в данном примере, или, в более общем смысле, сделать возможным поиск данных, например, в базах данных, представленных в виде деревьев, Б-деревьев, таблиц, текстовых файлов и т.д., и которые могут быть сохранены в ОЗУ, на НЖМД, твердотельных накопителях, SAN, NAS, виртуальных хранилищах, виртуальной ОЗУ и т.д.).
На ФИГ. 6 проиллюстрирован пример обработки запроса от инициатора запроса 310 с использованием матчинга по шаблону.
В шаге 620 модуль получения данных 410 получает запрос. Далее, в шаге 640 система проводит поиск аксиом, которые соответствуют шаблону запроса, в базе данных 340. Здесь все найденные аксиомы отдаются инициатору запроса. Далее, в шаге 660 ищутся все факты в хранилище модуля получения данных 430, например, факты, найденные ранее с использованием других правил. Далее, в шаге 680 ищутся правила (которые необходимы для того, чтобы найти запрошенные инициатором запросов данные), и, если правило найдено для обрабатываемого запроса, то процесс переходит к шагу 690, в котором правила анализируются, как было описано выше, и в шаге 620 из первоначально полученного запроса (первоначального запроса) может быть сгенерирован, по крайней мере, один запрос на поиск данных. Данный запрос может быть как запросом на точный матчинг, так и запросом на матчинг по шаблону. Как правило, первоначальный запрос разбивается на несколько запросов, часть которых являются запросами на точный матчинг, а часть - на матчинг по шаблону. Этими запросами на точный матчинг являются запросы 510 на ФИГ. 5, а запросами на матчинг по шаблону - запросы 620 на ФИГ. 6, хотя алгоритмы, показанные на этих рисунках, применимы к обоим случаям. Как только запросы были разделены (разбиты), процесс возвращается в шаг 620, что в данном случае обозначает рекурсию, делая тем самым алгоритм, показанный на ФИГ. б, рекурсивным алгоритмом. Аналогично, ФИГ. 5 также может представлять собой рекурсивный алгоритм.
Стоит отметить, что шаги 640 и 660 могут быть выполнено как последовательно, так и асинхронно.
Результатом работы алгоритмов, проиллюстрированных на этих фигурах, является получение инициатором запроса данных по мере их нахождения.
ФИГ. 12 иллюстрирует обработку клиентского запроса после того, как будет найдено соответствующее правило. Правило 1220, найденное модулем 410, для клиентского запроса анализируется, то есть разбивается на составные части (утверждения/тройки), т.е. левые и правые части. Левая часть, в свою очередь, также разбивается на утверждения. Как было описано выше, правая часть правила 1210 являются фактом, выведенным при помощи левой части правила. Правило 1220 (в частности, части 1232, 1234, 1236) используют данные 1232а, 1234а. 1236а, сгенерированные правилами 1240, 1260, 1280, на которые и ссылается (показано пунктирными линиями), и использует данные (в частности, часть 1231), найденные в базе данных (базах данных) 340. В конкретном примере показаны данные (1232а, 1234а, 1236а), сгенерированные на основе обработки правил 1250, 1270, 1290 и на основе данных 1230 из базы данных (баз данных) 340. Все эти найденные данные используются в правиле 1220 и, в частности, в 1280. В данном варианте осуществления изобретения данные, которые используются в правилах, показанных на ФИГ. 12, могут ссылаться на другие правила или аксиомы. Правила, на которые они ссылаются, могут быть найдены модулем получения данных во время анализа правил, относящихся к первоначальным тройкам/фактам 1210. При поиске правил, относящихся к вычислению клиентской тройки, во время анализа троек, модуль получения троек сохраняет их данные.
Стоит отметить, что данные, которые были найдены во время обработки этих формул и правил, зависят от того, как правила вызываются и с какими параметрами. Другими словами, найдено может быть множество различных данных, удовлетворяющих формулам и их составным частям.
ФИГ. 12 демонстрирует, что факт 1210 вычисляется с использованием правила 1210 (шаг 560, см. ФИГ. 5). В процессе анализа правила (шаг 570, см. ФИГ. 5), его левая часть разделяется на составные утверждения 1232, 1234, 1236, данные для которых могут быть получены, например, из правил 1240, 1260, 1280 соответственно. Одно из утверждений в 1290, а именно 1234b, ссылается на данные, которые потенциально могут являться результатом обработки правила 1260. В зависимости от маркировки правила 1260, т.е. было ли начато его вычисление или нет, или оно было приостановлено и т.д., модуль 410 либо ожидает окончания вычисления, либо использует результаты вычислений, либо пересчитывает правило с другими входными данными/параметрами/экземплярами (например, для нового запроса, описанного выше) и т.д. Стоит отметить, что статус обработки правила (во время обработки запроса) сохраняется в хранилище модуля получения данных, так что система (в частности, модуль получения данных) знает, был ли запущен процесс обработки правила или оно было обработано, или обработка правила была приостановлена. Если обработка правила была приостановлена, обработка правила может быть продолжена после команды от модуля получения данных. Тип и параметры запроса сохраняются в хранилище модуля получения данных и статус обработки правила маркируется в соответствии с запросами, к которым они относятся. Таким образом, если запросы - одинаковые, но параметры запросов - разные, то правило может иметь несколько маркировок.
Как правило, полностью обработанное правило маркируется сразу, а если правило не было полностью обработано, то помечается точка, что была достигнута во время вычисления на тот момент, когда был найден ответ на запрос клиента. Например, маркировка может быть сделана для полностью подсчитанных, не подсчитанных и не полностью подсчитанных правил в соответствии с уровнем вложенности для троек. (Процедура представляет собой маркирование всех полностью подсчитанные/маркирование всех не полностью подсчитанные правила.)
Помимо запроса на предоставление данных клиент может запросить запись данных в базу данных. Например, директор Алекс (см. ФИГ. 1) решил сменить должность Моргана с Разработчика на Менеджера. В данном случае, Алекс, используя ГИП, может, например, заменить позицию сотрудника в соответствующем поле (или такой функционал может быть реализован посредством выпадающего списка). После того как изменение будет сделано, Алекс должен сохранить их, чтобы применить их. После сохранения изменений все данные в системе (например, базе данных) должны быть модифицированы соответствующим образом. После сохранения данных клиент генерирует запрос к данным, содержащим связи Моргана с другими данными. В этом случае запрос клиента может относиться ко всем данным, связанным с Морганом, а именно "разработчик", "человек" "создатель", "корректор ошибок " и т.д. Клиент также генерирует запрос для выяснения того, какие данные были модифицированы. Также стоит отметить, что сохранение и изменение данных приведены в качестве примера, поскольку даже для отображения в ГИП'е сохраненных данных, необходим запрос на чтение и запись данных ГИП'а.
Возвращаясь к обработке данных, в частности, к записи данных в базу данных, следует отметить, что для записи данных в базу данных используется компонент Builder. Как и матчер, Builder является интерфейсом.
Для упрощения обработки данных (чтения/записи) из базы данных или хранилищ(а) модуля получения данных, могут быть использованы модели. Модель может объединять матчер и Builder. В отличие от матчера 420 у модели нет своих методов.
Builder-модель обеспечивает добавление фактов в текущую модель. Если существует, по крайней мере, две модели, они могут быть объединены в одну. Модели, скомбинированные под одной общей моделью, называются подчиненными моделями. Стоит отметить, что каждая модель может быть подчиненной, по крайней мере, для одной общей/виртуальной модели.
Модели могут быть объединены в одну, например, по типу данных. Использование данного интерфейса, клиент/модуль получения данных может получать доступ ко всем подчиненным моделям. Подчиненные модели невидимы для пользователя, так что он/она работает только с общей моделью.
Отправленные в модуль получения данных 410 запросы направлены единой общей модели, которая, в свою очередь, перенаправляет их своим подчиненным. Комбинирование нескольких моделей в одну делает возможным получить доступ к данным, тип которых неизвестен или не важен. Также комбинирование моделей позволяет получить доступ сразу к нескольким моделям через одну, когда модель(и), связанная с запрашиваемыми данными, неизвестна или не важна. Отдельные модели (системные или конфигурационные модели и т.д.) могут быть использованы независимо, т.е. они не обязательно должны быть объединены, если клиент 310 или модуль получения данных 410 знает наверняка, какая модель соответствует запрошенным данным. В данном случае нет необходимости обращаться к одной модели, а затем ко всем подчиненным ей для того, чтобы найти только системные или только пользовательские данные. В случае если тип данных неизвестен, существует возможность напрямую указать модель, в которой будет произведен поиск.
Некоторые модели, так называемые модели только для чтения, не могут быть модифицированы. Данные могут быть получены/прочитаны, но для записи данных, вычисленных модулем получения данных 410, использующим этот и/или другие модули, должна быть использована другая подходящая для записи модель (перезаписываемая модель).
Как было описано выше, каждая модель может иметь свой собственный тип: одна модель (например, для компании или отдела) может содержать аксиомы, другая - может содержать правила, еще одна может содержать данные о конфигурации или только системные правила, или все выведенные правила и так далее.
Модели могут быть не только объединены в зависимости от их типа, но они также могут быть сгруппированы для каких-либо определенных целей или операции. Объединенная модель может состоять из модели, хранящей операции с данными из базы данных; модели с правилами для операций с базами данных/таблицами; модели со служебными данными базы данных.
Объединенная пользовательская модель может включать: модель, хранящую важные данные (объекты, недавно адресованные пользователю), модель с пользовательскими установками, модель, хранящую связи с другими пользователями, модель с правилами выполнения операций пользователей с данными и т.д.
Комбинированные модели (объединенные модели посредством использования Модели Объединения, описанной здесь) могут быть в дальнейшем скомбинированы друг с другом, по меньшей мере, в одну виртуальную модель. Такое объединение моделей в одну или несколько виртуальных моделей позволяет при обращении к ним получить новые факты. Например, одна модель создана для работы с данными пользователей, другая создана для работы с правилами для данных пользователей. Если эти две модели разделены, то запрос к первой вернет пользовательские данные, соответствующие запросу, а запрос ко второй вернет правила, но новые факты получены не будут, поскольку запросы к данным моделям - раздельные. Если эти две модели объединить, то запрос к пользовательским данным будет учитывать правила, содержащиеся в модели с правилами.
Как было описано выше, объединенные модели подчинены модулю получения данных, так что модуль получения данных обрабатывает все необходимые знания о правилах, данных (соответствующих объединенным моделям), подсчитанным/выведенным фактам (общим для подчиненных моделей), а также знания о том, где искать правило, аксиому или выведенный факт, как к ним получить доступ и так далее.
ФИГ. 13А и ФИГ 13В иллюстрируют пример комбинирования моделей (объединение моделей). Вариант 1 (ФИГ. 13А): Хранилище Троек 1 1310, т.е. некоторые данные, прочитанные из базы данных и сохраненные в ОЗУ (или на НЖМД, SSD и т.д.), является моделью (Модель А, 1305) и может быть объединена/связана с другой моделью (Модель В, 1315), которая может быть представлена Хранилищем Троек 2 1320 (например, хранящим другой набор данных из той же базы данных или из другой базы данных (других баз данных)). Такая комбинация может быть выполнена с использованием Модели объединения. Результатом объединения является созданная Объединенная модель 1 1330.
Объединенная модель 1 1330, в свою очередь, может быть подчинена Модулю получения данных 1 1340, тем самым создавая Новую Модель 1 1350, где Объединенная модель 1 1330 является обычным хранилищем модуля получения данных (модель, о которой сказано выше), описанной в данном изобретении.
Вариант 2 (ФИГ. 13В): Хранилище троек 1 1310 (Модель А, 1305) может быть подчинена Модулю получения данных 2 1360 с созданием Новой модели 2 1380 с использованием Модели объединения, в то время как Хранилище Троек 2 1320 (Модель В, 1315) может быть подчинено Модулю получения данных 3 1370, создавая Новую Модель 3 1390. Далее Новая модель 2 1380 может быть комбинирована/объединена с Новой Моделью 3 1390 в Новую Модель 4 1392 с использованием Модели объединения.
Принимая во внимание две результирующие/объединенные модели (Новая Модель 1 1350 и Объединенная Модель 4 1392), становится видно, что выдаваемые ими результаты будут различаться, т.е. результаты Новой Модели 1 не равны результатам Новой Модели 4. Также стоит отметить, что результирующие Новая Модель 1 и Новая Модель 4 также могут быть объединены друг с другом либо частично, либо в полном объеме. Например, Новая Модель 1 1350 может быть объединена с Новой моделью 2 1380 или Новой моделью 3 1390. Например, Новая Модель 1 1350 может быть объединена с Новой моделью 2 1380 и затем подчинена Модулю получения данных 4 (не показано), таким образом создавая Новую Модель 5 (не показано), которая в дальнейшем может быть объединена с Новой моделью 3 1390, создавая объединенную не показанную Новую Модель 6 (которая в дальнейшем также может быть подчинена другому модулю получения данных, создавая Новую Модель 7 и т.д.). Тройки, выведенные одним модулем получения данных, станут аксиомами для другого модуля получения данных или/и для других Новых Моделей. Тройки из объединенных моделей (объединенных модулей получения данных, объединенные хранилища троек) являются аксиомами для любого модуля получения данных, который используется с такой объединенной моделью (объединенными моделями). Например, тройки из Новой Модели 2 1380 являются аксиомами для Объединенной Модели 4 1392, а тройки Новой Модели 3 1390 являются аксиомами для Объединенной Модели 4 1392. Такие комбинации частей системы возможны между частями моделей, исключительно из-за того, что они сами являются моделями (интерфейсами моделей).
Далее будет описана обработка/компиляция правил. Как было сказано выше, правила являются конъюнкцией троек/фактов/утверждений. Утверждения предварительно обрабатываются, затем компилируются, что приводит к еще большей конъюнкции.
Правила могут быть скомпилированы в С# код. В данном варианте изобретения правила представлены в виде запроса, разбитого на тройки, которые затем преобразуются С#-код, использующийся для вычисления полученного запроса. Компиляция осуществляется только при получении запроса (процесс компиляции правил описан ниже). Стоит отметить, что тройки из базы данных могут быть представлены коллекциями, т.е. коллекциями, хранящими утверждения следующим способом: нулевой элемент - "Субъект1 Предикат1 Объект1", первый элемент - " Субъект2 Предикат2 Объект2". Формат элемента определяется шаблоном. Например, в данном случае шаблон для хранения троек выглядит как "Субъект, Предикат, Объект", и поэтому каждый элемент коллекции представлен массивом из трех компонент. Также, шаблон может выглядеть как строковая переменная, например "Субъект Предикат Объект ".
Также стоит отметить, что одна коллекция (массивы, списки и т.д.) может содержать только Субъекты, другая может содержать только Предикаты, а другая может содержать только Объекты. При добавлении в коллекцию эти элементы из каждой тройки поддерживают связи с другими коллекциями. Например, элементы из первой тройки записаны в качестве нулевых элементов в соответствующие коллекции: КолекцияСубъектов, Коллекция Предикатов и КоллекцияОбъектов. Стоит отметить, что коллекции могут быть заполнены не одновременно, а последовательно, например, сначала добавляются Субъекты, затем идут Предикаты и последними - Объекты. Кроме того, порядок сам по себе не имеет значения и сначала может быть заполнена коллекция Объектов. Основным моментом в наполнении коллекции является то, что элементы из каждой последующей тройки должны занимать последующие позиции во всех коллекциях: элементы первой тройки должны занимать нулевые позиции, элементы второй тройки отправляются на первые позиции и так далее. Также стоит отметить, что нумерация в массивах, коллекциях и т.д. начинается с нуля.
Также стоит отметить, что вместо коллекций могут быть использованы массивы, ListArrays, списки, хеш-таблицы, Enumerators и т.д. При использовании хеш-таблиц порядок элементов не так важен, поскольку элементы тройки идентифицируются в соответствии с их хешом, который соотносит элемент со своей тройкой. Также стоит отметить, что для отдельного хранения элементов троек нет необходимости использовать несколько коллекций. Элементы или тройки целиком, как было описано выше, могут быть сохранены в единственной коллекции.
Что касается компиляции, стоит отметить, что запросы, включающие, по крайней мере, одну тройку и/или тройку из базы данных, компилируются в машиночитаемый код или в язык программирования, такой как С#, JavaScript, С++ и т.д., и далее компилируются в промежуточный язык (например, С Intermediate Language, Parrot intermediate representation, Microsoft's Common Intermediate Language и т.д.) и/или в машинный код, который должен быть выполнен для обработки запроса. Стоит отметить, что в упомянутые выше языки и код компилируются только необходимые тройки, например, скомпилированы могут быть только те тройки (правила, в данном варианте изобретения), которые были использованы по крайней мере один раз для ответа на описанные здесь запросы или части запросов (части утверждений). Как было сказано выше, запрос может быть разделен на несколько меньших элементов, например, составная тройка может быть разделена, по крайней мере, на две меньшие. Комплексные тройки (включая правила, представленные тройками) выглядят, как показано ниже:
{
(пример:продуктДляОшибкиТег (продукты:Продукт1 продукты:Продукт2)) запростегЗапрос
?х.
(пример:важностьОшибкиТег (важностьОшибки:высокая)) запростегЗапрос ?х.
} => { запрос:42 запросрезультат ?х }. (*Правило_1)
Следующие тройки являются простыми:
?тег теппредикат ?предикат. запрос:42 запросрезультат ?х.
Учитывая процесс компиляции правил, может существовать второе хранилище для хранения результатов вычислений, например, для правил (троек) согласно запросу клиента. Второе хранилище может быть как отдельным, так и может являться частью хранилища модуля получения данных, таким образом виртуально разбивая хранилище модуля получения данных на два виртуальных хранилища, оба из которых распознаются системой как единое хранилище модуля получения данных.
Как здесь описано, правила могут быть скопированы из базы данных в хранилище, например, в хранилище модуля получения данных, где они также заранее могут быть скомпилированы. В случае если правила, скопированные в хранилище модуля получения данных, не были скомпилированы, то далее, когда модуль получения данных обратится к такому правилу, оно будет скомпилировано в исполняемый код (например, с использованием С#), так что правило (вместе с другими правилами и утверждениями, связанными с ним) может быть выполнено. Скомпилированные правила вместе с вспомогательным кодом для их выполнения обычно хранятся в отдельном файле (например, в файле DLL) или в хранилище.
Как было сказано выше, некоторые языки программирования используют промежуточный язык, в который могут быть скомпилированы правила. Процесс работы с такими скомпилированными тройками, файлами и хранилищами (включая НЖМД и ОЗУ) для их хранения, напоминает процесс работы с билт-инами. Файл, содержащий скомпилированные правила, может быть расширен/увеличен (например при компилировании троек), могут быть добавлены другие файлы и т.д. В хранилище с не скомпилированным правилом (или не скомпилированными методами и функциями) появляется ссылка на хранилище со скомпилированной тройкой (или скомпилированным методом), как только она будет скомпилирована. Также стоит отметить, что скомпилированная тройка также может быть связана с не скомпилированным правилом, хранящимся в модуле получения данных.
Стоит также отметить, что не скомпилированные правила (также как и скомпилированные правила) копируются (или делаются общими) между модулями получения данных (например, среди новых созданных модулей получения данных). Кроме того, любые оставшиеся тройки из одного модуля получения данных могут быть скопированы (или быть сделаны общими) между другими, в то время как полученные данные - нет. Стоит также отметить, что ссылки на скомпилированные правила и сами правила могут быть скопированы (или сделаны общими) среди других модулей получения данных, тем самым избегая повторения компиляции правил, которые уже были скомпилированы, например, путем создания списка файлов всех скомпилированных правил, например, упомянутого выше DLL-файла, среди 'интеллектов' - созданными модулями получения данных, которыми (всем и из них) может быть использован DLL- файл). Другими словами, информация о правилах, которые были скомпилированы и которые - не были, могут быть скопированы из одного модуля получения данных в другие.
Для каждой комплексной тройки (например, правила) существует машиночитаемый код. Соответственно, когда запрос касается одного правила "Правило_1", он разбивается на простые тройки, для которых скомпилирован машиночитаемый код. В следующий раз, когда будет запрошено то же самое правило, новый код не будет компилироваться, а вместо этого будет использоваться уже существующий код. Стоит отметить, что код компилируется в соответствии с запросом, т.е. вида и типа запрашиваемых данных. Например, для компиляции машиночитаемого кода из троек, необходимо знать содержание тройки, независимо от того, содержит ли она переменные и какое их количество, на каких позициях эти переменные стоят, или является ли запрос запросом на точный матчинг и поэтому не содержит переменных. В частности, запрос, где тройка либо "a b с" в базе данных, либо в выведенных тройках, которые были получены во время обработки предыдущих запросов и оставлены в ОЗУ, например. Для каждого конкретного типа запроса компилируется соответствующий код. При получении запроса модуль получения данных 410 производит вычисления: если таких запросов раньше не было, то - это новое вычисление; если такие запросы были ранее, то система возвращает полученный результат (кроме того, вычисление будет либо продолжено, либо начато с нуля). Как было описано выше, вычисление продолжается до тех пор, пока не будет получен удовлетворяющий результат (включая негативный результат, например, отсутствие удовлетворяющих параметрам запроса данных).
Как только результат будет получен (запрошенные данные будут найдены), обработка запроса будет приостановлена. Модуль получения данных сохранит позицию, которой он достиг во время обработки текущего запроса. После этого, когда Модуль получения данных получает запрос, похожий не приостановленный, и данные не будут найдены в массиве подсчитанных данных, то запрос будет "разморожен", и его обработка продолжится, пока не будут найдены соответствующие данные. Таким образом, вычисление/обработка может быть оставлена незаконченной, поскольку был найден удовлетворяющий результат. Процесс будет завершен позже, когда будет получен похожий запрос, или необходимо будет обсчитать запрос, подходящий к приостановленной тройке.
ФИГ. 7 иллюстрирует пример различных бизнес-приложений, используемых в различных отделах компании, и схему обработки данных в них. Данные из базы данных могут быть разделены на пользовательские данные в виде аксиом, фактов, правил и онтологий (представленных также в виде аксиом, но которые могут быть различимы по N3 синтаксису). Другими словами, онтологии содержат информацию о том, что за данные и как данные должны быть представлены конкретному пользователю в конкретном бизнес-приложении. Факты и онтологии обрабатываются Ядром, и результатом обработки являются данные в определенном контексте в соответствии с онтологиями.
Благодаря использованию RDF (Среды Описания Ресурса) можно работать с различными источниками данных (т.е. базами данных, локальными хранилищами данных, расположенными в корпоративной сети или расположенными в Интернете). Возможно использовать U I общего словаря, что позволяет интегрировать данные из различных серверов. Также, основываясь на данных и правилах, возможно обеспечить представление данных на лету (в отличие от статичных срезов (например, слепков) , как это делается в OLAP кубах).
Пул информации (например, данные со всех департаментов: ИТ (705), Разработка (не показано), ЧР (701), Администрирование (не показано), Сбыт (не показано). Бухгалтерия (703) могут быть сохранены в различных базах данных или других хранилищах. Элемент 707 позволяет отображение контекстуализированной бизнес-информации для конкретного приложения. "Глобальная" является сущностью для представления данных в конкретном контексте бизнес- приложения.
Контекст может рассматриваться в качестве среды окружения конкретного события, объекта или индивида, который определяет интерпретацию данных и действий/операций над данными в конкретной ситуации. Опционально, контекст определяет метод обработки данных в конкретной ситуации. Например, чей-то адрес электронной почты может считаться информацией для входа в систему в одном контексте и в качестве контактной информации в профиле пользователя в другом контексте. Он может использоваться в качестве запрашивающей стороны в заявке в техническую поддержку в третьем контексте - все зависит от интерпретации данных.
Обмен информацией между серверами выполняется автоматически, поскольку все серверы используют общий словарь. Например:
http://<company_name>.com/tracker/ontology/global/hr, or http://<company_name>.com/tracker/ontology/global/it or
http://<company_name>.com/tracker/ontology/global/acc, all are conjoined into http://<company_name>.com/tracker/ontology/global
Даже в случае, когда бухгалтерия при создании вручную записи о сотруднике использует свой собственный словарь, возможно написать правило {?х а Бухпчеловек} => {?х а Глобальнохотрудник}, тем самым обеспечив механизм перевода между словарем бухгалтерии и глобальным словарем.
Из этого примера видно, что предлагаемая архитектура позволяет каждой отдельной группе или отделу в рамках бизнеса работать со своей собственной базой данных/хранилищем и своей собственной серверной системой, в то время как глобальный сервер с движком может представлять собой объединенное представление данных из всех отделов. Это осуществляется на лету и без дублирования данных, что особенно важно с точки зрения безопасности информации, а также с точки зрения поддержания актуальности информации (в данном случае, когда данные на одном хранилище меняются, то нет необходимости менять данные на других хранилищах).
Основанные на подсчитанных тегах результаты представления поиска, полученные на лету, могут быть проиллюстрированы следующем примером. Рассмотрим данные онтологий (т.е. данные, которые описывают управляемые сущности) в контексте бизнес-приложений, например, управления проектами, отслеживания проблем, отслеживания ошибок, CRM и т.д. Каждый из них хранится в своей собственной базе данных (или, альтернативно, в общей базе данных), и которые объединены на более высоком уровне. При помощи логического ядра можно комбинировать различные доступные данные в различные комбинации и наборы онтологий, например, используя специальные онтологии. Разработчик может видеть контекст представления ошибки, представленный Отделу качества в виде назначенной ему задачи. Другими словами, является возможным проследить, к какой задаче относится конкретная ошибка.
Различия между представлением на лету, доступным благодаря описанному здесь подходу, и статичным представлением, предоставляемым поиском данных с использованием OLAP кубов (сетевая аналитическая обработка в реальном времени) также заслуживают рассмотрения. OLAP является общепринятой техникой для генерирования отчетов и различных статистических документов. OLAP кубы часто используются аналитиками для быстрой обработки сложных запросов к базе данных, и они особенно часто встречаются в маркетинговых отчетах, отчетам по продажам, анализе данных и так далее. Причина, по которой OLAP кубы настолько распространены, кроется в скорости, с которой может быть выполнена обработка. Реляционные базы данных хранят информацию о различных сущностях в отдельных таблицах, которые обычно хорошо нормализованы. Эта структура удобна для большинства операционных систем баз данных, однако сложные многотабличные запросы обычно сложно быстро выполнить. Хорошей моделью для таких запросов (в отличие от изменений) является таблица, построенная с использованием фактов из OLAP кубов.
Сложность использования OLAP в качестве методологии заключается в генерировании запросов, выборе базовых данных и генерировании соответствующей схемы, которая является причиной, по которой большинство современных OLAP продуктов обычно поставляются вместе с большим количеством предопределенных запросов.
Другая проблема заключается в базовых знаниях OLAP куба, которые должны быть завершенными и непротиворечивыми. Таким образом, основной проблемой с OLAP кубами является то, что процесс анализа обычно требует пересоздания самого куба или частого генерирования срезов. В отличие от OLAP кубов предложенный подход выигрышно позволяет перегенерацию представления данных (результатов поиска) на лету без сложностей предопределения и предварительного генерирования запросов. Вкратце, процесс обсуждаемого здесь подхода может быть описан следующим образом:
- бизнес-слой запрашивает данные из ядра;
- логическое ядро собирает данные из различных источников;
- логическое ядро распознает природу данных и делит данные на аксиомы и правила. Например, для баг-трекера аксиомой может быть "решение это "нужно больше информации"", и правилом может быть { ?о операция.требуетсяБольшеДанных ?f. ?f Ьполе:пусто Истина.} => {?о операция:раз решить Ложь};
- система, необходимая для выполнения запроса бизнес слоя, собирает вместе скомпилированные правила (например, в С# коде, хотя изобретение не ограничено каким либо конкретным языком программирования). У системы могут наличествовать правила, которые были собраны и скомпилированы ранее, так же как и новые правила для правил, которые еще не были обработаны. Таким образом, компилирование должно быть выполнено только для новых правил. Поэтому ядру нет необходимости постоянно работать с данными, а только лишь адресовать данные в ответ на запросы из бизнес слоя;
- система обрабатывает аксиомы, и генерируются новые вытекающие из этого аксиомы;
- ядро возвращает запрошенные данные в бизнес слой.
Для обработки данных могут существовать несколько типов правил. Правило типа фильтр наиболее часто используется в трекер-кейсах, например, получение списка тикетов/ошибок/задач в службу поддержки от конкретного пользователя и конкретного проекта с определенными атрибутами. Кроме того, информация из общего пула задач/ошибок/тикетов должна быть отфильтрована для конкретного пользователя и проекта и представлена в виде отдельных аксиом.
Преобразовательные правила относятся к той же информации, что может быть представлена другим способом. Например, отдел Информационных Технологий рассматривает людей в качестве пользователей систем информационных технологий. С другой стороны, менеджер проекта может видеть тех же людей в виде ресурсов, работающих над конкретными задачами. В другом примере преобразовательные правила могут включать следующее: на входе получают данные (аксиомы), которые описывают определенный тикет (например, запрос от конкретного конечного пользователя) и представление его данных. Кроме того, система получит, в качестве выхода, аксиомы в виде определенного пользовательского интерфейса, наполненного данными.
Еще одним примером типа правил является генерирующее правило. Например, в определенном проекте, имеющем более 50% критических ошибок и более 50% критических задач, система автоматически генерирует факт о статусе проекта (например, статус проекта обозначен как "Критический").
Далее представлен пример применения правил. Информация преобразуется из баг-трекера и из задачи управления проектами в данные для проекта ABC. Далее фильтруются и оставляются только ошибки со статусом "критическая" и система подсчитывает общее количество ошибок, и далее, если количество "критических" ошибок больше половины от общего количества ошибок, генерируется критическое состояние ошибок проекта:
{ Рошибка cmw:is ошибка:Ошибка. ?ошибка проект:включает проект:Проект_АВС. {?ошибка проект:Статус статусПроекта:Критический}доказательство:подсчет ?колвоКритическихОшибок. { ?ошибка проект :Статус ?любой} доказательство: подсчет ?ВсегоОшибок. (РВсегоОшибок 2) мат:разделить РполовинаВсехОшибок. ?колвоКритическихОщибок мат:больше
?половинаВсехОшибок.} => {проект:Прое т_АВС проект:КритическиеОшибки истина}.
Те же самые операции выполняются для данных (задач) из систем управления проектами:
{ ?задача :is задача:3адача. ? задача проект:включает проект:Проект_АВС. {? задача проект:Статус статусПроекта:Критический}доказательство:подсчет ?количествоКритическихОшибок. { ?задача проект:Статус ?любой} доказательство:подсчет ?ВсегоЗадач. (РВсегоЗадач 2) мат:разделить РполовинаВсехЗадач. РколвоКритическихЗадач мат:больше РполовинаВсехЗадач.} => {проект:Проект_АВС проект:КритическиеОшибки истина}.
Далее выполняется автоматическое генерирование статуса "Критического" проекта, если в проекте есть задачи и ошибки со статусами "Критический":
{проект:Проект_АВС проект:КритическиеОшибки истина. проект:Проект_АВС проект:КритическиеЗадачи истина}. => { проект:Проект_АВС проект:Статус "Критический" }.
То же самое происходит со статусом проекта, но с другим условием: автоматическим генерированием "Критического" статуса проекта, когда количество "критических" ошибок или задач станет больше половины.
{ ?х cmw:is задача:3адача} -> { ?х cmw:is проект:ЗадачаИлиОшибка}.
{ ?х cmw:is ошибка:Ошибка} => { ?х cmw:is проект:ЗадачаИлиОшибка}.
{?х cmw:is проект: ЗадачаИлиОшибка. ?х проект:включает проект:Проект_АВС. {?х проект:Статус статусПроекта:Критический} доказательство:подсчет РколичествоКритических. { ?х проект:Статус Рлюбой} доказательство:подсчет РВсего. (РВсего 2) мат:разделить РполовинаВсех. ?колвоКритических мат:больше РполовинаВсего.} => { проект:Проект_АВС проект:Статус "Критический"}.
Как могут увидеть специалисты в данной области, примеры из реальной жизни обычно гораздо сложнее, чем те, что описаны выше, и в большинстве реальных случаев может существовать гораздо больше типов правил, однако, принцип остается тем же самым.
Пример конъюнкции аксиом является одним из наиболее частым из тех, что легко понять. Например, при комбинировании информации, относящихся к требованиям проекта ( "требования" аксиом представляют собой требования, определяемые аналитиками) и ошибкам из баг-трекера ( "ошибки" аксиом представляют собой ошибки, обнаруженные тестировщиками, которые, как правило, являются специалистами по контролю качества, и заполняют формы отслеживания ошибок на основании определенных требований), результатом становится "результирующая аксиома", которая, по существу, является комбинацией количества ошибок, связанных с одним функциональным требованием.
ФИГ. 8 иллюстрирует систему в одном варианте реализации изобретения. JSON/Ajax API 822 является модулем для реализации протокола вызовов методов API (Интерфейса Программирования Приложений) с использованием формата сообщений JSON и передачей данных посредством HTTP с использованием запросов Ajax. WCF API 824 является модулем, который реализует протокол вызова методов API с использованием формата представления XML/SOAP и передачи данных посредством HTTP.
Модуль менеджера API 826:
- ищет требуемый метод API,
- реализует сериализацию аргументов в структуры данных, использующуюся в онтологиях бизнес-логики,
- реализует вызовы метода API,
- десериализует результаты, возвращенные методом.
Модуль менеджера API 826 использует 143-файлы 830 (которые содержат тройки в формате N3) для поиска реализации метода 828, где онтология "ар Метод" (например) содержит все методы, типы аргументов и возвращает значения. Реализация метода является программным кодом. Например, он может сохранять данные в базу данных или закрыть или открыть задачу, и другие операции.
Например, API метод "СоздатьЗадачу" используется для создания задачи. Метод принимает данные задачи в виде аргумента и возвращает идентификатор для созданной задачи. JSON- обработчик получает имя метода и аргументы (данные задачи) в JSON- формате, где метод вызывается посредством JSON-протокол. Далее аргументы преобразуются во внутреннее представление данных в памяти и передаются в API-менеджер. API-менеджер (у которого есть список методов) может найти требуемый метод "СоздатьЗадачу" по имени. Далее API-менеджер проверяет аргументы (количество и тип) и реализует метод "СоздатьЗадачу". После создания задачи методом "СоздатьЗадачу", API-менеджер возвращает результат JSON-обработчику. JSON- обработчик преобразует результат в JSON- формат и отправляет его обратно клиенту (например, в клиент MS Outlook или в приложение мобильного устройства). API-менеджер загружает API-спецификацию и модули расширения из Базы данных во время запуска приложения (MS Outlook расширение 807). Данная спецификация может быть запрошена Outlook расширением/плагином 807 MS Outlook клиента 806 или посредством специального Ajax- запроса или в виде схемы в WSDL-формате с использованием SOAP-протокола.
Веб-клиент 802 (например, на базе JavaScript или на HTML5) или Клиент Командной Строки 804 могут быть использованы вмеао MS Outlook. Консольный клиент является клиентским приложением, которое может вызывать методы API с использованием командной строки. Также может быть использовано мобильное приложение на мобильном устройстве 801.
Клиент JavaScript является клиентским приложением, которое исполняется в пользовательском веб-браузере и которое может вызывать методы API с использованием языка JavaScript.
Outlook расширение (Outlook-клиент) является клиентским приложением, которое исполняется в приложении MS-Outlook и которое может вызывать методы API с использованием WCF-протокола.
Язык Описания Веб-сервисов (WSDL) является основанным на XML языке описания интерфейсов, который используется для описания функциональности, предоставляемой веб- сервисом.
WSDL-описание веб-сервиса (также называемое WSDL-файлом) обеспечивает машиночитаемое описание того, как сервис может быть вызван, какие параметры он ожидает и какие структуры данных он ожидает. Таким образом, он служит той же цели, что, которая примерно соответствует цели сигнатуры метода в языке программирования.
Далее клиентские приложения могут осуществлять вызовы с использованием отчетности запросов Ajax в формате протокола JSON или SOAP.
Основными стадиями обработки запросов являются:
1. Входящий запрос обрабатывается HTTP-сервером (или Внешним сервером, или MS Exchange Сервером). Выполняется JSON сериализация или SOAP преобразование во внутренний формат.
2. API-менеджер 826 принимает входные данные и проверяет входные аргументы на соответствие описанию метода.
3. API-менеджер 826 загружает и подготавливает необходимую модель данных и создает снепшот модели для изоляции от других запросов и операций. Транзакция записи открыта, если операция меняет данные модели.
4. Вызывается программный код (или правила с онтологиями и Язык Comindware®), который выполняет метод.
5. Транзакция закрывается, если операция является модифицирующей операцией, и выполняется проверка изменения в безопасности, определение конфликтов, обновление истории транзакций.
6. Результат сериализуется в формат, требуемый клиентом и передается в HTTP-запрос. Бизнес логика приложения 820 реализует объектный слой поверх хранилища данных. Доступ к данным обеспечивается посредством клиентского API, который содержит методы для чтения/записи объектов (т.е. шаблоны объектов, бизнес-правила и т.д.) Вызовы клиентами методов API реализованы посредством сессий, которые создаются после авторизации клиента. Этот слой содержит несколько системных онтологии, таких как, например, "шаблон пользовательского объекта" или "бизнес-правило". Онтологии используются в API для сериализации и проверки данных.
Хранилище данных 842 обеспечивает физическое хранилище для модели данных на жестком диске. Данные оправляются в хранилище данных 842 и обратно в форме фактов (троек). Факт является тройкой, которая хранится в модели. Также, факт может быть получен путем применения правил или запросов. Хранилище данных состоит из:
- потокового хранилища троек 858 позволяет записывать и запрашивать тройки специального файлового формата. Потоковое хранение троек поддерживает несколько типов запросов по различным компонентам;
- менеджер транзакций и слепков 854 позволяет создавать:
а. транзакции. Транзакции являются объектами с интерфейсом для атомарной модификации троек хранилища. Изменение модели возможно только в рамках такой транзакции, гарантируя атомарную модификацию троек хранилища (подтверждение всех изменений, сделанных внутри транзакции, или ни одной из них);
б. слепки. Слепки представляют собой обладающие интерфейсом объекты для консистентного чтения из хранилища троек. Это гарантирует, что ни одна из транзакций (которые были подтверждены во время выполнения слепка) не повлияет на его содержимое.
- тройки, хранящиеся в репозитории, являются простыми, небольшими объектами (числами, строками, именами). Менеджер бинарных потоков 856 используется для сохранения больших значений (файлов, потоков данных) в хранилище. Поток хранится в отдельном файле, и хранится ссылка на поток сохраняется в этом файле;
- Модель хранилища данных 850 представляет набор интерфейсов для управления хранилищем данных 851. Такие интерфейсы могут включать транзакции, слепки, интерфейс для запроса фактов (троек) из слепка и интерфейс для записи фактов в транзакцию.
- Семантический процессор 840 содержит описание интерфейсов, таких как имя, факты (тройки) и правило модели.
ЫЗ-конвертер 849 позволяет генерировать модель данных на основе содержимого N3- файла 830. (Стоит отметить, что тройки могут быть сохранены в базе данных в любом формате, как говорилось выше). Объединение с хранилищем данных является еще одним методом формирования паттерна. Кроме того, могут быть сформированы объединенные модели, так что несколько моделей объединяются в одну. Запросы к таким моделям приводят к запросу фактов из каждой объединенной модели. Запись данных при этом продолжает производиться только в одну из моделей. Обработчик бизнес-правил 844 является опциональным дополнением поверх модели данных. После подключения обработчика 844 к модели, он позволяет вычислять производные на основе существующих фактов и правил.
Интерфейс модели данных 846 является набором интерфейсов для запроса фактов из модели, для записи в модель, создания транзакция и слепков модели. Сериализатор онтологий 848 создает запросы на получение объектов из всей модели на основании онтологий (описание структуры объектов хранится в модели).
Транзакции и запросы изолированы с использованием транзакций. После открытия транзакции на запись или чтение, транзакция полностью изолирована от других транзакций. Любые изменения в модели данных, сделанные другими транзакциями, не отражаются в ней. Определение конфликтов и разрешение конфликтов выполняется при закрытии транзакции, которая была открыта на запись. Используется так называемая модель оптимистичного параллелизма. Определения конфликтов происходит на уровне отдельных семантических фактов. Конфликт возникает, когда факт был модифицирован двумя транзакциями после создания слепка модели и до закрытия транзакции. Во время определения конфликта будет сгенерировано исключение. В этом случае пользователь может попробовать обновить сохраненные изменения и попробовать еще раз подтвердить изменения.
Оптимистическое управление параллелизмом (ОСС) является методом управления параллелизмом для систем управления реляционными базами данных, который предполагает, что несколько транзакций могут быть завершены без влияния друг на друга и, следовательно, транзакции могут быть обработаны без блокировки ресурсов данных, которые они затрагивают. Перед подтверждением, каждая транзакция проверяет, что ни одна другая транзакция не изменила данные. Если проверка выявляет конфликтующие модификации, то подтверждающая транзакция откатывается.
ОСС, как правило, используется в средах с низкими конфликтами данных. Когда конфликты редки, транзакции могут быть завершены без затрат на управление блокировками и без необходимости транзакциям ожидать очистки других блокировок транзакций, что приводит к повышению пропускной способности по сравнению с другими методами управления параллелизмом. Однако, если конфликты происходят часто, то цена неоднократного перезапуска транзакций значительно влияет на производительность, и другие методы управления параллелизмом обладают большей производительностью при таких условиях.
Более конкретно, ОСС транзакции включают следующие фазы:
Начало: запись метки времени, отмечающей начало транзакции.
Модифицирование: чтение значений из базы данных и предварительная запись изменений.
Проверка: Проверка, модифицировали ли другие транзакции данные, которые используются текущей транзакцией (запись или чтение). Это включает транзакции, которые были завершены после даты начала текущей транзакции и опционально транзакции, которые еще активны на момент проверки.
Подтверждение/Откат: Если конфликта нет, сделать все изменения имеющими силу. Если конфликт существует, разрешить его, обычно путем отмены транзакции, хотя возможны другие схемы разрешения. Стоит позаботиться об избегании ошибки TOCTTOU (Time-Of-Check-To-Time-Of- Use), особенно если текущая фаза и предыдущая не выполнены в виде одной атомарной операции (см. также обсуждение механизмов разрешения конфликтов между транзакциями, т.е. транзакциями, не влияющими друг на друга, упомянутым выше.
Хранилище данных в форме В-дерева используется для того, чтобы сделать поиск более эффективным. В-дерево может быть реализовано в виде набора таблиц. На ФИГ. 9 показана база данных со структурой В-дерева для хранения троек. Согласно примерному варианту предикаты, дополнения и подлежащие хранятся в базе данных в хэшированном виде. Другими словами, значения задачи, статуса и владельца задачи могут быть захэшированы перед сохранением в таблицу. Хэширование позволяет ускорить процесс поиска путем сортировки значений хэшей в базе данных.
Для того чтобы найти связи между вершинами графов поиск в базе данных выполняется с помощью предикатов. Таким образом, таблица ключей в базе данных является таблицей, содержащей связи между предикатами, подлежащими и дополнениями. Подлежащие в таблице ключей отсортированы. Таблица предикатов 910 содержит предикаты Р1...Рп, используемые для выбора подлежащих и дополнений.
Стоит отметить, что данный метод хранения данных не ограничен задачами в тройках. Данные четверок также могут храниться в таблице ключей. Ссылки N1S ... NnS являются значениями в таблице предикатов и которые представляют собой ссылки на таблицы N1S ... NnS (920 и 940 соответственно). Таблицы 920 и 940 представляют собой связи между подлежащим и дополнениями. Таблица предикатов 910 также содержит ссылки на таблицы N10 ... NnO (930 и 950 соответственно), которые также представляют собой связи между подлежащим и дополнениями. Для некоторых предикатов (т.е. для предикатов одного типа), например, для предиката Р1=владелец, создается свой собственный набор таблиц N1S ... NnS, а для других типов предикатов, например, для Р2=имя, создается другой набор таблиц N10 ... NnO. Стоит отметить, что приведенный выше пример использует тройки, которые используют только два зависимых значения (атрибута). Любой узел графа может быть использован в качестве атрибута. В случаях, когда используется более двух связанных аргументов, например PI (al, а2, аЗ), то используется альтернативный метод для хранения. Также используется В-дерево. Примером предиката с тремя атрибутами может служить утверждение:
"кружки цвет красный вчера " или " цвет(чашка, красный, вчера). Другими словами, " цвет" - это предикат, а "чашка" - подлежащее, "красный" - дополнение и "вчера" - обстоятельство (атрибуты) данного предиката.
На ФИГ. 10 проиллюстрирован пример хранения предикатов с их атрибутами в В-дереве согласно примерному варианту. Таблица предикатов 1010 содержит предикаты, отсортированные в определенном порядке. Таблица предикатов 1010 также содержит ссылки на соответствующие сохраненные атрибуты для каждого из предикатов.
Запись предикатов и их соответствующих атрибутов в В-дерево 1000 реализуется следующим образом: первый набор предиката Р1 имеет степень три (т.е. у предиката есть три атрибута). Следовательно, когда первый предикат записан в таблицу 1010, таблица 1010 содержит четыре ссылки на сохраненные атрибуты. Первая ссылка (Ссылка1) ссылается на таблицу 1020, содержащую все первые атрибуты (т.е. атрибуты, размещенные первыми во всех наборах). Вторая ссылка (Ссылка2) указывает на таблицу 1030, содержащую все вторые атрибуты всех наборов. Третья ссылка (СсылкаЗ) указывает на таблицу 1040, которая содержит все третьи атрибуты. Четвертая ссылка (Ссылка4) является дополнительной ссылкой, которая указывает на таблицу 1050, которая содержит терминатор.
Согласно примерному варианту терминатор является постоянной величиной (числовой или текстовой). Терминатор используется для получения троек из В-дерева 1000. Тройки идентифицируются внутри В-дерева посредством терминатора. Когда атрибуты считываются из В- дерева 1000, поиск тройки продолжается до тех пор, пока не будет найден терминатор, соответствующий конкретной тройке.
Каждому набору атрибутов, наряду с соответствующим предикатом, присваивается идентификационный номер при записи в В-дерево 1000. Следующий идентификационный номер увеличивается на единицу. Таким образом, наборы данных упорядочены согласно тому, когда они записаны в В-дерево 1000. Таким образом, каждый набор (предикат, атрибуты и терминатор) обладает соответствующим уникальным идентификатором, также сохраненным в В-дереве 1000.
Кроме того, каждый атрибут обладает идентификатором позиции, который идентифицирует позицию атрибута в наборе (т.е. первую, вторую, третью и т.д.). В примере на ФИГ. 3 первый набор содержит атрибут "al" на первой позиции. Следовательно, атрибут "al" записан в таблицу 1020 с идентификатором "1", указывающим на то, что атрибут принадлежит первому набору.
Атрибут "а2" - второй в первом наборе. Таким образом, он записан в таблицу 1030 с идентификатором "1." Атрибут "аЗ" - третий в первом наборе. Следовательно, он записан в таблицу 1040 с идентификатором "1." Терминатор с идентификатором "1" записан в таблицу 1050. Терминатор "1" указывает на то, что в первом наборе больше нет атрибутов.
Атрибут "al" - первый во втором наборе. Следовательно, он записан в таблицу 1020 с идентификатором "2", который указывает на то, что атрибут "al" принадлежит второму набору. Второй набор содержит только один атрибут. Таким образом, терминатор с идентификатором "2" записан в таблицу 1030.
Для всех остальных наборов предикаты, атрибуты и терминаторы сохранены таким же образом. Стоит отметить, что таблицы 1020 - 1050 могут содержать ссылки на другие таблицы вместо фактических идентификаторов. Данный пример изображен на ФИГ. 4. Таблица 1010 содержит ссылку (Таблица2Ссылка) на таблицу 1020. Таблица 1020 содержит ссылки (ТаблицаЗСсылка и Таблица4Ссылка), которые указывают на таблицы 1020 и 1030, содержащие идентификаторы.
Стоит отметить, что таблицы принадлежат В-дереву. Другими словами, таблицы служат ветвями В-дерева. Если необходимо получить определенный набор данных (предикат с атрибутами) из В-дерева, то предикат, атрибуты и терминатор ищутся на основе соответствующего идентификатора.
Со ссылкой на ФИГ. 11, типичная система для реализации изобретения включает в себя многоцелевое вычислительное устройство в виде компьютера 20 или сервера, включающего в себя процессор 21, системную память 22 и системную шину 23, которая связывает различные системные компоненты, включая системную память с процессором 21.
Системная шина 23 может быть любого из различных типов структур шин, включающих шину памяти или контроллер памяти, периферийную шину и локальную шину, использующую любую из множества архитектур шин. Системная память включает постоянное запоминающее устройство (ПЗУ) 24 и оперативное запоминающее устройство (ОЗУ) 25. В ПЗУ 24 хранится базовая система ввода/вывода 26 (БИОС), состоящая из основных подпрограмм, которые помогают обмениваться информацией между элементами внутри компьютера 20, например, в момент запуска.
Компьютер 20 также может включать в себя накопитель 27 на жестком диске для чтения с и записи на жесткий диск, не показан, накопитель 28 на магнитных дисках для чтения с или записи на съёмный магнитный диск 29, и накопитель 30 на оптическом диске для чтения с или записи на съёмный оптический диск 31 такой, как компакт-диск, цифровой видео-диск и другие оптические средства. Накопитель 27 на жестком диске, накопитель 28 на магнитных дисках и накопитель 30 на оптических дисках соединены с системной шиной 23 посредством, соответственно, интерфейса 32 накопителя на жестком диске, интерфейса 33 накопителя на магнитных дисках и интерфейса 34 оптического накопителя. Накопители и их соответствующие читаемые компьютером средства обеспечивают энергонезависимое хранение читаемых компьютером инструкций, структур данных, программных модулей и других данных для компьютера 20.
Хотя описанная здесь типичная конфигурация использует жесткий диск, съёмный магнитный диск 29 и съёмный оптический диск 31, специалист примет во внимание, что в типичной операционной среде могут также быть использованы другие типы читаемых компьютером средств, которые могут хранить данные, которые доступны с помощью компьютера, такие как магнитные кассеты, карты флеш-памяти, цифровые видеодиски, картриджи Бернулли, оперативные запоминающие устройства (ОЗУ), постоянные запоминающие устройства (ПЗУ) и т.п.
Различные программные модули, включая операционную систему 35, могут быть сохранены на жёстком диске, магнитном диске 29, оптическом диске 31, ПЗУ 24 или ОЗУ 25. Компьютер 20 включает в себя файловую систему 36, связанную с операционной системой 35 или включенную в нее, одно или более программное приложение 37, другие программные модули 38 и программные данные 39. Пользователь может вводить команды и информацию в компьютер 20 при помощи устройств ввода, таких как клавиатура 40 и указательное устройство 42. Другие устройства ввода (не показаны) могут включать в себя микрофон, джойстик, геймпад, спутниковую антенну, сканер или любое другое.
Эти и другие устройства ввода соединены с процессором 21 часто посредством интерфейса 46 последовательного порта, который связан с системной шиной, но могут быть соединены посредством других интерфейсов, таких как параллельный порт, игровой порт или универсальная последовательная шина (УПШ). Монитор 47 или другой тип устройства визуального отображения также соединен с системной шиной 23 посредством интерфейса, например видеоадаптера 48. В дополнение к монитору 47, персональные компьютеры обычно включают в себя другие периферийные устройства вывода (не показано), такие как динамики и принтеры.
Компьютер 20 может работать в сетевом окружении посредством логических соединений к одному или нескольким удаленным компьютерам 49. Удаленный компьютер (или компьютеры) 49 может представлять собой другой компьютер, сервер, роутер, сетевой ПК, пиринговое устройство или другой узел единой сети, а также обычно включает в себя большинство или все элементы, описанные выше, в отношении компьютера 20, хотя показано только устройство хранения информации 50. Логические соединения включают в себя локальную сеть (ЛВС) 51 и глобальную компьютерную сеть (ГКС) 52. Такие сетевые окружения обычно распространены в учреждениях, корпоративных компьютерных сетях, Интранете и Интернете. Компьютер 20, используемый в сетевом окружении ЛВС, соединяется с локальной сетью 51 посредством сетевого интерфейса или адаптера 53. Компьютер 20, используемый в сетевом окружении ГКС, обычно использует модем 54 или другие средства для установления связи с глобальной компьютерной сетью 52, такой как Интернет.
Модем 54, который может быть внутренним или внешним, соединен с системной шиной 23 посредством интерфейса 46 последовательного порта. В сетевом окружении программные модули или их части, описанные применительно к компьютеру 20, могут храниться на удаленном устройстве хранения информации. Надо принять во внимание, что показанные сетевые соединения являются типичными, и для установления коммуникационной связи между компьютерами могут быть использованы другие средства.
Принимая во внимание описанный предпочтительный вариант, для специалиста в данной области очевидно, что были достигнуты определенные преимущества описанного способа и инструмента.
Также должно быть оценен тот факт, что различные модификации, адаптации и альтернативные реализации могут быть сделаны в пределах объема и духа настоящего изобретения. Изобретение далее определяется следующей формулой изобретения.
Принимая во внимание описанный предпочтительный вариант, для специалиста в данной области очевидно, что были достигнуты определенные преимущества описанного способа и инструмента.
Также должно быть оценен тот факт, что различные модификации, адаптации и альтернативные реализации могут быть сделаны в пределах объема и духа настоящего изобретения. Изобретение далее определяется следующей формулой изобретения.

Claims

Формула изобретения
1. Способ обработки данных графов, представляющих связи Объектов, включающий:
инициацию запроса на данные от инициатора запроса;
создание модуля получения данных с хранилищем модуля получения данных;
копирование данных (которые характеризуют данные, хранящиеся во внешнем хранилище данных) в хранилище модуля получения данных;
обработку запроса посредством поиска соответствующих запросу данных во внешнем хранилище данных;
обработку запроса посредством поиска данных, соответствующих запросу, в хранилище данных модуля получения данных;
обработку запроса посредством поиска и обработки правил, согласно которым выводятся данные, соответствующие запросу, в хранилище данных модуля получения данных;
возврат найденных данных инициатору запроса.
2. Способ по пункту 1, отличающийся тем, что взаимодействие между инициатором запроса, модулем получения данных и хранилищем данных осуществляется через общий интерфейс матчера.
3. Способ по пункту 1, отличающийся тем, что хранилище данных и модуль получения данных являются моделями.
4. Способ по пункту 3, отличающийся тем, что модели объединены в любых вариациях, по крайней мере, в одну объединенную модель.
5. Способ по пункту 4, отличающийся тем, что объединенные модели объединены, по крайней сере, в одну новую объединенную модель.
6. Способ по пункту 1, отличающийся тем, что данные являются аксиомами, фактами, онтологиями и правилами, хранимыми в виде троек.
7. Способ по пункту 6, отличающийся тем, что факты выводятся на основе правил и аксиом.
8. Способ по пункту 1, отличающийся тем, что правила компилируются один раз по запросу в исполняемый код при первом их вызове, чтобы избежать рекомпиляции их во время последующих их вызовов.
9. Способ по пункту 1, отличающийся тем, что встроенные функции используются во время обработки правил.
10. Способ по пункту 9, отличающийся тем, что встроенные функции предварительно компилируются в исполняемый код и отвечают за выполнение действий, которые не могут быть реализованы в правилах.
11. Способ по пункту 10, отличающийся тем, что встроенные функции зарегистрированы на предикаты СПО (субъект-предикат-объект) троек.
12. Способ по пункту 10, отличающийся тем, что встроенные функции разрегистрируются с предикатов СПО-троек.
13. Способ по пункту 9, отличающийся тем, что встроенные функции представлены функторами, написанными на тройках.
14. Способ по пункту 1, отличающийся тем, что обработка правил включает точный матчинг и матчинг по паттерну.
15. Способ по пункту 1, отличающийся тем, что запрос является:
- запросом от модуля получения данных;
- запросом от приложения с модулем получения данных;
- запросом от внешнего (для модуля получения данных) приложения.
16. Способ по пункту 1, отличающийся тем, что внешнее хранилище данных включает, по крайней мере, одну базу данных.
17. Способ по пункту 1, отличающийся тем, что запрос разбивается на несколько запросов.
18. Способ по пункту 1, отличающийся тем, что правила маркируются в соответствии с запросом и параметрами запроса, и в соответствии со аатусом обработки правил: обработка правила началась, правило обработано, обработка правила приостановлена.
19. Способ по пункту 1, отличающийся тем, что данные, которые характеризуют данные, хранящиеся во внешнем хранилище данных, и факты хранятся в отсортированном виде в хранилище данных модуля получения данных.
20. Способ по пункту 19, отличающийся тем, что данные, которые характеризуют данные, хранящиеся во внешнем хранилище данных, и факты хранятся в форме списка, и отличающийся тем, что новые выведенные факты и данные добавляются в верх списка.
21. Способ по пункту 19, отличающийся тем, что обработка фактов и данных начинается с последних добавленных фактов и данных.
22. Способ по пункту 1, отличающийся тем, что найденные данные возвращаются инициатору запроса по одному.
23. Система обработки данных графов, представляющих связи Объектов, включающая:
- инициатор запроса, инициирует запрос на данные;
- внешнее хранилище данных, хранящее аксиомы и правила в виде СПО-троек (субъект- предикат-объект);
- возвращающий найденные данные инициатору запроса модуль получения данных для обработки запроса следующими способами:
- посредством поиска соответствующих запросу данных во внешнем хранилище данных; - посредством поиска данных, соответствующих запросу, в хранилище данных модуля получения данных;
- посредством поиска и обработки правил, согласно которым выводятся данные, соответствующие запросу, в хранилище данных модуля получения данных;
- хранилище модуля данных, в котором генерируются данные, которые характеризуют данные, хранящиеся во внешнем хранилище данных.
24. Система по пункту 23, отличающаяся тем, что включает общий интерфейс матчера, который обеспечивает взаимодействие между инициатором запроса, модулем получения данных и хранилищем данных.
25. Система по пункту 23, отличающаяся тем, что хранилище данных и модуль получения данных являются моделями.
26. Система по пункту 25, отличающаяся тем, что модели объединены в любых вариациях, по крайней мере, в одну объединенную модель.
PCT/RU2016/000203 2015-10-08 2016-04-07 Система и способ обработки данных графов WO2017061901A1 (ru)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
RU2015142786 2015-10-08
RU2015142786A RU2708939C2 (ru) 2015-10-08 2015-10-08 Система и способ обработки данных графов

Publications (1)

Publication Number Publication Date
WO2017061901A1 true WO2017061901A1 (ru) 2017-04-13

Family

ID=58488074

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/RU2016/000203 WO2017061901A1 (ru) 2015-10-08 2016-04-07 Система и способ обработки данных графов

Country Status (2)

Country Link
RU (1) RU2708939C2 (ru)
WO (1) WO2017061901A1 (ru)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110134335A (zh) * 2019-05-10 2019-08-16 天津大学深圳研究院 一种基于键值对的rdf数据管理方法、装置及存储介质
US20220075674A1 (en) * 2020-09-09 2022-03-10 Ciena Corporation Configuring an API to provide customized access constraints
US20230075655A1 (en) * 2017-12-29 2023-03-09 DataWalk Spólka Akcyjna Systems and methods for context-independent database search paths

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100185700A1 (en) * 2007-09-17 2010-07-22 Yan Bodain Method and system for aligning ontologies using annotation exchange
CN102722542A (zh) * 2012-05-23 2012-10-10 无锡成电科大科技发展有限公司 一种资源描述框架图模式匹配方法
US8478766B1 (en) * 2011-02-02 2013-07-02 Comindware Ltd. Unified data architecture for business process management
WO2014051455A1 (en) * 2012-09-26 2014-04-03 Obschestvo S Ogranichennoy Otvetstvennostyu "Colloware" Method and system for storing graph data
US20140172914A1 (en) * 2012-12-14 2014-06-19 Microsoft Corporation Graph query processing using plurality of engines

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001037134A1 (en) * 1999-11-16 2001-05-25 Searchcraft Corporation Method for searching from a plurality of data sources
US7702636B1 (en) * 2002-07-31 2010-04-20 Cadence Design Systems, Inc. Federated system and methods and mechanisms of implementing and using such a system
US8244772B2 (en) * 2007-03-29 2012-08-14 Franz, Inc. Method for creating a scalable graph database using coordinate data elements
US7890518B2 (en) * 2007-03-29 2011-02-15 Franz Inc. Method for creating a scalable graph database
US8458451B2 (en) * 2009-01-20 2013-06-04 New York University Database outsourcing with access privacy
RU2490702C1 (ru) * 2012-05-02 2013-08-20 Корпорация "САМСУНГ ЭЛЕКТРОНИКС Ко., Лтд." Способ ускорения обработки множественных запросов типа select к rdf базе данных с помощью графического процессора

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100185700A1 (en) * 2007-09-17 2010-07-22 Yan Bodain Method and system for aligning ontologies using annotation exchange
US8478766B1 (en) * 2011-02-02 2013-07-02 Comindware Ltd. Unified data architecture for business process management
CN102722542A (zh) * 2012-05-23 2012-10-10 无锡成电科大科技发展有限公司 一种资源描述框架图模式匹配方法
WO2014051455A1 (en) * 2012-09-26 2014-04-03 Obschestvo S Ogranichennoy Otvetstvennostyu "Colloware" Method and system for storing graph data
US20140172914A1 (en) * 2012-12-14 2014-06-19 Microsoft Corporation Graph query processing using plurality of engines

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230075655A1 (en) * 2017-12-29 2023-03-09 DataWalk Spólka Akcyjna Systems and methods for context-independent database search paths
CN110134335A (zh) * 2019-05-10 2019-08-16 天津大学深圳研究院 一种基于键值对的rdf数据管理方法、装置及存储介质
US20220075674A1 (en) * 2020-09-09 2022-03-10 Ciena Corporation Configuring an API to provide customized access constraints
US11579950B2 (en) * 2020-09-09 2023-02-14 Ciena Corporation Configuring an API to provide customized access constraints

Also Published As

Publication number Publication date
RU2015142786A3 (ru) 2018-09-18
RU2015142786A (ru) 2017-04-13
RU2708939C2 (ru) 2019-12-12

Similar Documents

Publication Publication Date Title
JP2020091902A (ja) 分散型データストアのバージョン化された階層型データ構造
JP4738908B2 (ja) ハードウェア／ソフトウェアインターフェースシステムにより管理可能な情報の単位のピアツーピア同期化のための競合処理を提供するためのシステムおよび方法
JP5108749B2 (ja) データ記憶システム内のデータを操作するシステムおよび方法
US6704747B1 (en) Method and system for providing internet-based database interoperability using a frame model for universal database
US10019537B1 (en) System and method for data search in a graph database
US20030182282A1 (en) Similarity search engine for use with relational databases
US9213698B1 (en) Unified data architecture for business process management and data modeling
US9892191B2 (en) Complex query handling
MXPA06001984A (es) Sistemas y metodos para conectar con una interfase programas de aplicacion una plataforma de almacenamiento basada en elementos.
MXPA06001986A (es) Sistemas y metodos para modelar datos en una plataforma de almacenamiento basada en elementos.
US11106665B1 (en) Automated SQL source code review
RU2707708C2 (ru) Система и способ поиска данных в базе данных графов
Lee et al. Ontology management for large-scale enterprise systems
US10592391B1 (en) Automated transaction and datasource configuration source code review
US10585663B1 (en) Automated data store access source code review
RU2708939C2 (ru) Система и способ обработки данных графов
US7996384B2 (en) Query based rule optimization through rule combination
Medina et al. A Fuzzy temporal object‐relational database: model and implementation
RU2393531C2 (ru) Антивирус для хранилища элементов
US10275237B1 (en) Automated spring wiring source code review
Nishida et al. Data Integrity in Cloud Transactions.
Kvet et al. Enhancing Analytical Select Statements Using Reference Aliases
Klausner Semantic XVSM: design and implementation
Heine et al. A DSL for Automated Data Quality Monitoring
Bellamy-McIntyre LSPARQL: Transaction Time Queries in RDF

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16853979

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 17.07.2018)

122 Ep: pct application non-entry in european phase

Ref document number: 16853979

Country of ref document: EP

Kind code of ref document: A1