A workflow generation method and computing device

Abstract

This application provides a workflow generation method and computing device, relating to the field of computing device technology, and solves the problem of poor workflow flexibility. The method includes: acquiring initial workflow data; the initial workflow data includes: initial triggering conditions and identifiers of initial participating entities; determining target workflow data matching the initial workflow data from a pre-constructed knowledge graph; the knowledge graph stores multiple workflow data; each workflow data includes: triggering scenario information for the corresponding workflow and identifiers of participating entities; the target workflow is used to instruct a target electronic device to execute a target event under a target triggering scenario, and the target workflow data includes: target triggering scenario information and identifiers of target participating entities; the target triggering scenario is determined based on the initial triggering conditions and scenario information related to the initial event; and generating a target workflow based on the target workflow data.

Description

Technical Field

[0001] This application relates to the field of computing device technology, and in particular to a workflow generation method and computing device. Background Technology

[0002] With the rapid development of information technology, automated workflow technology has become a key tool for improving individual efficiency and organizational effectiveness. Its typical applications have expanded from the early automation of simple tasks to complex needs across platforms and multiple scenarios, including smart homes, smart offices, and health management.

[0003] Currently, automated workflows are typically implemented using "if this then that" (IFTTT) technology. Its core architecture is based on static rule logic of trigger conditions and execution events. Users can manually configure and predefine how to control the corresponding devices to execute specific events when the trigger conditions occur.

[0004] However, as application scenarios become more complex and user needs become more dynamic, the limitations of traditional workflows generated through static rule logic are becoming increasingly apparent. They are unsuitable for complex scenarios and cannot meet the diverse needs of users, resulting in poor flexibility. Summary of the Invention

[0005] This application provides a workflow generation method and computing device, which solves the problem of poor workflow flexibility.

[0006] In a first aspect, embodiments of this application provide a workflow generation method, the method comprising: acquiring initial workflow data; the initial workflow being used to instruct an initial electronic device to execute an initial event under initial triggering conditions; the initial workflow data including: initial triggering conditions and identifiers of initial participating entities participating in the initial workflow; the initial participating entities including: the initial electronic device and the initial event; determining target workflow data matching the initial workflow data from a pre-built knowledge graph; the knowledge graph storing multiple workflow data; each workflow data including: triggering scenario information of the corresponding workflow and identifiers of participating entities; the target workflow being used to instruct a target electronic device to execute a target event under a target triggering scenario, the target workflow data including: target triggering scenario information and identifiers of target participating entities; the target triggering scenario being determined based on the initial triggering conditions and scenario information related to the initial event; the target participating entities including: the target electronic device and the target event; and generating a target workflow based on the target workflow data.

[0007] In this solution, the target workflow data that matches the initial workflow data is determined by a pre-built knowledge graph. The target triggering scenario information is determined by the initial triggering conditions and the scenario information related to the initial event. Therefore, the target workflow generated based on the target workflow data no longer depends on a single pre-configured initial triggering condition, but can combine richer and broader scenario information related to the initial event. This solves the problem that traditional workflow generation methods cannot be applied to complex scenarios and can also meet the diverse needs of users.

[0008] In some embodiments, the triggering scenario information for each workflow data stored in the knowledge graph includes: the scenario type of the triggering scenario and the scenario content under the scenario type; determining the target workflow data that matches the initial workflow data from the pre-built knowledge graph includes: determining the target scenario type and / or target scenario content that matches the target scenario information from the knowledge graph; the target scenario information is determined based on the scenario information associated with the initial triggering conditions and the scenario information related to the initial event; and determining the workflow data in the knowledge graph that matches the target scenario type and / or target scenario content as the target workflow data.

[0009] In this embodiment, by constructing a hierarchical knowledge structure of scene types and scene content, fuzzy and multidimensional scene information can be transformed into standardized and efficiently searchable data. This allows for the rapid location of the most relevant target scene type and its specific content within the knowledge graph based on scene information associated with the initial triggering conditions and scene information related to the initial event. This enables precise matching of associated target workflow data. This not only significantly improves the efficiency and accuracy of workflow matching in complex scenarios but also effectively avoids the data bloat and performance degradation that can result from infinitely refined scene dimensions through structured scene management.

[0010] In some embodiments, each workflow data stored in the knowledge graph further includes: constraints under the triggering scenario of each workflow; the constraints are used to constrain the triggering and execution of the corresponding workflow; determining target workflow data that matches the initial workflow data from the pre-built knowledge graph includes: determining the workflow data to which the target constraint conditions that match the target scenario information in the knowledge graph belong as the target workflow data.

[0011] In this embodiment, by incorporating constraints into the knowledge graph and using them as key parameters for matching target workflow data, it is possible to determine not only whether the scenario is relevant, but also whether the workflow needs to be constrained under the corresponding triggering scenario, so that the final determined target workflow data is executable.

[0012] In some embodiments, each workflow data stored in the knowledge graph further includes: the event execution priority of each workflow-related event; the priority of the event execution priority is positively correlated with the degree of constraint risk of the constraints satisfied when executing the event.

[0013] In this embodiment, by establishing a positive correlation between event execution priority and the degree of risk of constraints, a decision-making basis can be provided when facing multiple concurrent or conflicting events, so that in complex scenarios, events with higher execution priority can be executed first, thereby improving the reliability of the target workflow in complex environments.

[0014] In some embodiments, determining target workflow data that matches the initial workflow data from a pre-built knowledge graph includes: if the workflow data that matches the initial workflow data in the knowledge graph includes first sub-workflow data and second sub-workflow data, and the execution logic of a first event involved in the first sub-workflow data conflicts with the execution logic of a second event involved in the second sub-workflow data, and the execution priority of the first event is greater than the execution priority of the second event, then the first sub-workflow data is determined as the target workflow data.

[0015] In this embodiment, by introducing event execution priority, the problem of how to accurately determine the target workflow data in the scenario where the execution logic of the first event and the second event conflict can be solved, thereby effectively avoiding the risk of event execution chaos, resource waste or delay of key operations caused by execution logic conflict.

[0016] In some embodiments, each workflow data stored in the knowledge graph further includes: attribute parameters of each workflow participant; the initial workflow data further includes: attribute parameters of the initial participant; determining target workflow data that matches the initial workflow data from the pre-built knowledge graph includes: determining the workflow data to which the attribute parameters that match the attribute parameters of the initial participant belong in the knowledge graph as the target workflow data.

[0017] In this embodiment, by incorporating attribute parameters into the knowledge graph and using them as key parameters for matching target workflow data, it is possible to determine not only the scenario information and participating entities when identifying target workflow data, but also whether the attribute parameters of the participating entities match, so that the final identified target workflow data is more accurate.

[0018] In some embodiments, the attribute parameters in each workflow data stored in the knowledge graph include: basic attribute parameters and extended attribute parameters stored in the knowledge graph in the form of key-value pairs; the basic attribute parameters are used to represent the fixed attribute characteristics of the corresponding workflow participants, and the extended attribute parameters are used to represent the additional attribute characteristics of the corresponding workflow participants.

[0019] In this embodiment, by distinguishing between basic attribute parameters and extended attribute parameters stored as key-value pairs, the basic attribute parameters with a fixed structure can ensure the efficiency and consistency of matching target workflow data, while the extended attribute parameters can expand the additional attribute features of the participating subjects, thereby enabling more accurate matching of target workflow data and enriching the variety of attribute parameters when generating the target workflow in the future.

[0020] In some embodiments, each workflow data stored in the knowledge graph further includes: the interaction relationships between each workflow participant; when the interaction relationships between target participants in the target workflow data include multiple types of interaction relationships, generating a target workflow based on the target workflow data includes: determining the execution order of target events involved in each type of interaction relationship based on each type of interaction relationship; generating a target workflow according to the execution order of the target events; the target workflow is also used to instruct the target electronic device to execute target events in the execution order under the target triggering scenario.

[0021] In this embodiment, by taking the interaction relationship as the core component of the workflow data and using it to directly deduce the execution order of the target events, the automated orchestration and scheduling of complex collaborative processes involving multiple subjects is realized. The originally potentially disordered target events can be transformed into a well-structured and time-defined sequence of event execution, thereby enabling the target workflow involving multiple target participants to run with accurate logic.

[0022] In some embodiments, the interaction relationships include at least one of the following types: triggering relationships, dependency relationships, and collaborative relationships. A triggering relationship indicates that the state of one participating entity triggers an event to be executed by another participating entity. A dependency relationship indicates that the execution of an event by one participating entity depends on the state of another participating entity. A collaborative relationship indicates that multiple participating entities collaboratively execute events.

[0023] In some embodiments, the method further includes: obtaining feedback information after the target electronic device executes a target event in a target triggering scenario; the feedback information includes at least one of the following: the execution result of the target event, the device status of the target electronic device, and the user's interaction feedback information with the target electronic device within a preset time period; and updating the target workflow data in the knowledge graph based on the feedback information.

[0024] In this embodiment, the target workflow data in the knowledge graph can be corrected by the execution result of the target event, the device status of the target electronic device, and the user's interactive feedback information on the target electronic device within a preset time period, so that the target workflow data can better meet the user's needs, thereby continuously improving the accuracy, personalization and overall reliability of the subsequent generated target workflow.

[0025] In a second aspect, embodiments of this application provide a computing device including a processor and a memory; the processor is coupled to the memory; the memory is used to store computer instructions, which are loaded and executed by the processor to enable the computing device to implement the methods provided in the first aspect and its possible embodiments described above.

[0026] Thirdly, embodiments of this application provide a computer-readable storage medium comprising: computer software instructions; when the computer software instructions are executed in a computing device, they cause the computing device to implement the methods provided in the first aspect and its possible embodiments.

[0027] Fourthly, embodiments of this application provide a computer program product that, when run on a computing device, causes the computing device to execute the steps of the relevant method described in the first aspect above, so as to implement the method of the first aspect above.

[0028] The beneficial effects of the second to fourth aspects mentioned above can be referred to the corresponding description of the first aspect, and will not be repeated here. Attached Figure Description

[0029] Figure 1 A schematic diagram of the system architecture of a workflow generation system provided in this application embodiment; Figure 2 A flowchart illustrating a workflow generation method provided in an embodiment of this application; Figure 3 A flowchart illustrating a workflow execution method provided in an embodiment of this application; Figure 4 This is a schematic diagram of the architecture of a computing device provided in an embodiment of this application. Detailed Implementation

[0030] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0031] In the description of this application, unless otherwise stated, " / " indicates that the objects before and after are in an "or" relationship. For example, A / B can mean A or B. "And / or" in this application is merely a description of the relationship between the related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. A and B can be singular or plural.

[0032] Furthermore, in the description of this application, unless otherwise stated, "multiple" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0033] Furthermore, to facilitate a clear description of the technical solutions in the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that "first" and "second" are not necessarily different. Meanwhile, in the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is being used as an example, illustration, or description. Any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of terms such as "exemplary" or "for example" is intended to present related concepts in a concrete manner for ease of understanding.

[0034] It should be noted that in the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0035] The following provides an exemplary description of the application scenarios of the embodiments of this application.

[0036] As described in the background section, the core architecture for implementing automated workflows typically includes computing devices and electronic devices. Users can manually configure workflow data on the computing device, such as the triggering conditions for the workflow and the events that the electronic devices to be controlled need to execute under those triggering conditions. The computing device can respond to the manually configured workflow data and generate the corresponding workflow based on that data.

[0037] In some embodiments, after a computing device generates a workflow, it can either execute the workflow directly or send the workflow to other devices so that those devices can execute the workflow.

[0038] Taking the direct execution of the workflow by a computing device as an example, the computing device can parse the workflow and set tasks related to its trigger conditions, such as continuously or periodically monitoring real-time data related to the trigger conditions, and comparing the acquired real-time data with the aforementioned trigger conditions to evaluate whether the trigger conditions are met. When the computing device confirms that the real-time data meets the trigger conditions, it can generate operation instructions based on the events to be executed defined in the generated workflow, and send the operation instructions to the electronic device to instruct the electronic device to execute the events to be executed according to the events to be executed defined in the workflow.

[0039] The application scenarios of the embodiments of this application will be illustrated below with specific examples.

[0040] Example 1: A user manually configures a workflow on their mobile phone (i.e., computing device), where the trigger condition is: "I will arrive home at 6 PM," and the execution event is: "Turn on the smart light in the living room." The phone can then generate a workflow based on the user's configuration: "If the user arrives home at 6 PM, then turn on the smart light in the living room."

[0041] Next, the phone can parse this workflow and set a scheduled location monitoring task, specifically to obtain the user's location information at 6 PM. The phone can then check in real-time or periodically whether the local time is 6 PM, and obtain the user's location information if it is. When the phone detects that the user's location is within the pre-defined home location range at 6 PM, it sends an on command to the smart light in the living room (i.e., the electronic device). Accordingly, the smart light responds to the on command sent by the phone and turns on.

[0042] Example 2: A user manually configures workflow data on a computer (i.e., a computing device), where the trigger condition is: 5 minutes before the start of a meeting in the calendar, and the execution event is: send a reminder message to my mobile phone. The computer can then generate a workflow based on the user's configuration: send a reminder message to the user's mobile phone 5 minutes before the start of the meeting in the calendar.

[0043] Next, the computer can parse the workflow and set a scheduled task to send a reminder message to the user's mobile phone 5 minutes before the meeting is scheduled to start. The computer can then check in real-time or periodically whether the local time has reached 5 minutes before the meeting is scheduled to start. When the computer detects that the local time has reached 5 minutes before the meeting is scheduled to start, it sends a reminder message to the user's mobile phone (electronic device) that the meeting is about to begin.

[0044] However, various scenarios may arise during the implementation of the aforementioned automated workflow. For example, in Example 1, if it's hot at 6 PM, the user would have to manually turn on the air conditioner after arriving home. In Example 2, since the workflow is designed for each meeting in the calendar, if the user has many meetings, the workflow might frequently send reminder messages, or send reminders for conflicting meeting times, leaving the user unsure which meeting to attend.

[0045] In other words, as application scenarios become more complex and user needs become more dynamic, the limitations of traditional automated workflows are becoming increasingly apparent. They are not suitable for complex scenarios and cannot meet the diverse needs of users.

[0046] To address the aforementioned issues, this application provides a workflow generation method that can acquire initial workflow data. The initial workflow is used to instruct an initial electronic device to execute an initial event under initial triggering conditions. The initial workflow data includes: the initial triggering conditions and the identifiers of the initial participating entities (including the initial electronic device and the initial event) involved in the initial workflow.

[0047] Next, target workflow data matching the initial workflow data can be determined from the pre-built knowledge graph, and a target workflow can be generated based on the target workflow data. The knowledge graph stores multiple workflow data, each including: the triggering scenario information for the corresponding workflow and the identifiers of the participating entities.

[0048] The target workflow is used to instruct a target electronic device to execute a target event under a target triggering scenario. The target workflow data includes: target triggering scenario information and identifiers of the target participants (including the target electronic device and the target event). The aforementioned target triggering scenario is determined based on initial triggering conditions and scenario information related to the initial event.

[0049] As can be seen from the above, in the target workflow data that matches the initial workflow data determined by the pre-constructed knowledge graph in the embodiments of this application, the target triggering scenario information is determined jointly based on the initial triggering conditions and the scenario information related to the initial event. Therefore, the target workflow generated based on the target workflow data no longer depends on a single pre-configured initial triggering condition, but can combine richer and broader scenario information related to the initial event, thereby solving the problem that traditional workflow generation methods cannot be applied to complex scenarios and can also meet the diverse needs of users.

[0050] The system architecture of the embodiments of this application will be described below as an example.

[0051] This application provides a system architecture for a workflow generation system, such as... Figure 1 As shown, the workflow generation system may include: a computing device 101 and an electronic device 102.

[0052] The computing device 101 is communicatively connected to the electronic device 102.

[0053] The computing device 101 is used to execute the workflow generation method provided in the embodiments of this application, including receiving initial workflow data manually configured by the user, determining target workflow data matching the initial workflow data according to a pre-built knowledge graph, and generating the target workflow.

[0054] Subsequently, the computing device 101 can also execute the target workflow, including sending a control command to the electronic device 102 when the target triggering scenario corresponding to the target workflow is met, so as to control the electronic device 102 to execute the target event corresponding to the target workflow.

[0055] In some embodiments, after generating a target workflow, the computing device can either execute the workflow directly or send it to other devices so that those devices can execute it. The embodiments of this application will be described below using the example of the computing device directly executing the workflow.

[0056] In one possible implementation, the computing device 101 can also be communicatively connected to a scene information acquisition device. This scene information acquisition device is used to acquire target trigger scene information involved in the target workflow. For example, in the above application scenario example, in the workflow scenario of automatically turning on the smart lights in the living room, the scene information acquisition device may include an environmental sensor and a camera deployed in the living room. The environmental sensor is used to acquire environmental information of the living room and its exterior, including at least one of light intensity, temperature, and humidity. The camera is used to acquire sound and / or image information of the living room.

[0057] The computing device can determine whether to trigger the target triggering scenario information corresponding to the target workflow based on the scenario information collected by the scenario information acquisition device, thereby determining whether to control the electronic device 102 to execute the target event.

[0058] Electronic device 102 refers to the electronic device that needs to execute the corresponding target event in the target workflow generated by computing device 101. This electronic device 102 can be the execution object of the event in an automated workflow scenario, such as the smart light in the workflow that automatically turns on the living room smart light, or the computer and mobile phone that automatically output meeting reminder messages, as shown in the application scenario example above.

[0059] This application does not impose any restrictions on the specific forms of the computing device 101 and the electronic device 102. For example, the computing device 101 and the electronic device 102 can be servers. The server can be a single server, or it can be a server cluster composed of multiple servers. In some embodiments, the server cluster can also be a distributed cluster, which is not limited in this application. As another example, the computing device 101 and the electronic device 102 can specifically be terminal devices. Terminal devices can be referred to as: terminals, user equipment (UE), terminal devices, access terminals, user units, user stations, mobile stations, remote stations, remote terminals, mobile devices, user terminals, wireless communication devices, user agents, or user devices, etc. Terminal devices can specifically be mobile phones, augmented reality (AR) devices, virtual reality (VR) devices, tablet computers, laptops, ultra-mobile personal computers (UMPCs), netbooks, personal digital assistants (PDAs), etc.

[0060] It should be pointed out that, Figure 1 The system architecture shown does not constitute a limitation on the workflow generation system, except Figure 1 In addition to the devices shown, the workflow generation system may include more or fewer devices than illustrated, or combine certain devices, or have different device arrangements.

[0061] For example, the aforementioned computing device 101 may be a server deployed in the cloud or a management center. In this case, the aforementioned workflow generation system also includes a user terminal communicatively connected to the computing device 101. The user can manually configure initial workflow data on the user terminal. In response to the user-configured initial workflow data, the user terminal can send the initial workflow data to the computing device 101, so that the computing device 101 executes the workflow generation method provided in the embodiments of this application based on the initial workflow data.

[0062] For example, the computing device 101 and the electronic device 102 described above can be integrated into the same device. When the computing device 101 and the electronic device 102 are integrated into the same device, the communication method between the computing device 101 and the electronic device 102 is the communication between internal modules of the device.

[0063] The workflow generation method provided in the embodiments of this application will be described in detail below.

[0064] like Figure 2 The diagram shown is a flowchart illustrating a workflow generation method provided in an embodiment of this application. Figure 2 The method shown can be applied to computing devices. For example, the method can be applied to... Figure 1 The computing device 101 shown. The workflow generation method includes: S201, The computing device acquires the initial workflow data.

[0065] As described in the application scenario of this application embodiment, users can manually configure initial workflow data on a computing device. For example, users can input initial workflow data by dragging and dropping components, filling out forms, or entering structured text on the graphical interface of the computing device.

[0066] In one possible implementation, the computing device can also receive initial workflow data sent from other software systems or computing devices. For example, the computing device can receive a workflow description file sent by a workflow generation service via an application programming interface (API), and the computing device can parse the workflow description file to obtain the initial workflow data.

[0067] The initial workflow is used to instruct the initial electronic device to execute an initial event under initial triggering conditions. Initial workflow data includes: the initial triggering conditions and the identifiers of the initial participants in the initial workflow. The initial participants include: the initial electronic device and the initial event.

[0068] The initial trigger condition defines the prerequisites that must be met for the initial workflow to begin execution. The initial trigger condition may include one or more sub-conditions. For example, in the above application scenario example, in the workflow scenario of automatically turning on the smart lights in the living room, the initial trigger condition may include the two sub-conditions that the user arrives home and that the local time reaches 6 p.m.

[0069] The initial participants define the main objects involved in the initial workflow, including the initial electronic device and the initial event. For example, in the application scenario above, in the workflow scenario of automatically turning on the smart living room light, the initial electronic device is the smart light, and the initial event is turning on the smart light.

[0070] Since the acquired initial workflow data is usually stored and transmitted in a structured data format, the initial triggering conditions and the identifiers of the initial participants in the initial workflow data can also be stored in a structured data format.

[0071] In this context, the identifier of the initial electronic device is used to uniquely identify the initial electronic device participating in the initial workflow. For example, it could be the network address, physical address, device serial number, or a unique device code registered on a specific platform. The identifier of the initial event is used to uniquely identify the specific operation or task required to be performed by the initial electronic device. For example, it could be a predefined operation command code, service function name, or a standardized description document of the actions that the initial electronic device can perform.

[0072] S202. The computing device determines the target workflow data that matches the initial workflow data from the pre-built knowledge graph.

[0073] The knowledge graph stores multiple workflow data. Each workflow data includes: the triggering scenario information for the corresponding workflow and the identifiers of the participating entities.

[0074] A pre-built knowledge graph is a data knowledge base stored in a tuple data structure. The tuple data can include two types of data: the triggering scenario information for the corresponding workflow and the identifiers of the participating entities.

[0075] Trigger scenario information refers to the set of information about the environments and situations in which the workflow is designed or historically validated to be applicable. This trigger scenario information is different from the initial trigger conditions in the initial workflow data. It is not a single trigger condition, but a scenario description that may contain multiple dimensions (protection time, space, event status, etc.), such as composite scenario information like a weekday evening, being at home with no one indoors, and an outdoor temperature of 28 degrees Celsius.

[0076] The participating entities are similar to the initial participating entities defined in the initial workflow data. They refer to the operators involved in the events to be executed as defined in the target workflow (such as smart lights in the living room, air conditioners, etc.) and the specific events to be executed (such as turning on smart lights, adjusting the air conditioner to 26°C, etc.).

[0077] Correspondingly, the identifiers of the participating entities are similar to those of the initial participating entities in the initial workflow data. For a detailed description, please refer to the above text, which will not be repeated here.

[0078] In some embodiments, each workflow data in the knowledge graph includes not only the triggering scenario information and the identifier of the participating entity for the corresponding workflow, but also at least one of the following: constraints under the triggering scenario of the workflow, the event execution priority of the events involved in the corresponding workflow, the attribute parameters of the participating entities of the corresponding workflow, and the interaction relationship between the participating entities of the corresponding workflow.

[0079] When each workflow data in a knowledge graph includes all six types of data mentioned above, the knowledge graph can store the workflow data for each workflow in the form of six-tuple data. In this way, the workflow generated through these six-dimensional six-tuple data not only enriches the triggering scenarios of the workflow, but also enriches its constraints, event execution priorities, attribute parameters, and interaction relationships, thereby further enriching the use cases of automated workflows and meeting diverse user needs, enabling users to make more refined automated workflow decisions. The following sections will introduce the other data in the six-tuple data besides the triggering scenario information and the identifiers of the participating entities; they will not be repeated here.

[0080] Optionally, after acquiring the initial workflow data, the computing device can use the initial workflow data as query input to query target workflow data that matches the initial workflow data from the knowledge graph.

[0081] This target workflow instructs a target electronic device to execute a target event under a target triggering scenario. The target workflow data includes: target triggering scenario information and identifiers of the target participants. The target triggering scenario is determined based on initial triggering conditions and scenario information related to the initial event. The target participants include: the target electronic device and the target event. The initial event and the target event can be the same or different, and the target electronic device can be the same or different from the initial electronic device.

[0082] As can be seen from the above, since the initial workflow data includes the initial triggering conditions and the identifiers of the initial participants in the initial workflow, the computing device can use the initial triggering conditions and the identifiers of the initial participants as query inputs to query the target workflow data that matches the initial workflow data from the knowledge graph.

[0083] Since the initial participants include the initial electronic device and the initial event, the electronic device can also use the initial triggering condition, the initial electronic device, and the initial event as query inputs to query the target workflow data that matches the initial workflow data from the knowledge graph.

[0084] However, in practical applications, the number of workflows matched with electronic devices is usually large. Therefore, the amount of workflow data retrieved from the knowledge graph through the initial electronic device query is also large. Thus, in this embodiment, the initial triggering condition and initial event can be used as query inputs to retrieve target workflow data matching the initial workflow data from the knowledge graph. In this way, the target triggering scenario information included in the target workflow data retrieved by the computing device is determined based on the initial triggering condition and scenario information related to the initial event.

[0085] For example, suppose the initial workflow is: turn on the indoor air conditioner when the outdoor temperature is greater than 30 degrees.

[0086] Suppose that the knowledge graph stores two workflow data. The workflow corresponding to the first workflow data is: turn on the indoor air conditioner at 8 pm when the user is at home.

[0087] The workflow corresponding to the second workflow data is: when the outdoor temperature is greater than 30 degrees Celsius and the user is at home, turn on the indoor air conditioner and close the smart window.

[0088] Although both the first workflow data and the initial workflow involve an electronic device (air conditioner) and the event of turning on the air conditioner, the triggering scenario and initial triggering conditions of the first workflow data differ, as do the scenario information related to the initial event of turning on the air conditioner (the initial workflow is related to temperature, while the first workflow data is related to time). Therefore, the matching degree between the first workflow data and the initial workflow data is low.

[0089] The participants in the second workflow data not only include the initial participants of the initial workflow (i.e., the air conditioner and the event of turning it on), but also the initial triggering conditions. Furthermore, the scenario information related to the initial event of turning on the air conditioner adds the scenario information of the user being at home, in addition to the outdoor temperature being greater than 30 degrees Celsius. Therefore, the second workflow data has a high degree of matching with the initial workflow data.

[0090] In this scenario, the computing device can use the second workflow data as the target workflow data.

[0091] In other words, while the target workflow data matched by the computing device from the knowledge graph also includes target triggering scenario information similar to the initial triggering conditions, and target participant identifiers similar to the initial participant identifiers, the target workflow data has been specified and adapted based on the extensive knowledge stored in the knowledge graph compared to the initial workflow data. For example, the target triggering scenario of the target workflow is more detailed than the initial triggering conditions, and the target participants can be expanded or replaced compared to the initial participants.

[0092] For example, the initial trigger condition "going home" in the initial workflow data is refined into the target trigger scenario "going home on a rainy evening" in the target workflow data. The initial electronic device "smart light" in the initial workflow data is expanded into the two target electronic devices "smart light and air conditioner" in the target workflow data. The initial event "turning on the smart light" in the initial workflow data is also expanded into multiple target events "turning on the smart light and turning on the air conditioner and adjusting the temperature to 26 degrees" in the target workflow data.

[0093] S203. The computing device generates the target workflow based on the target workflow data.

[0094] After determining the target workflow data, since the target workflow data is usually structured data, the computing device also needs to transform the structured target workflow data into a clear sequence of tasks that can be parsed and executed by the workflow engine.

[0095] First, the computing device can create a monitoring task instance for target-triggered scenario information. This monitoring task instance is configured to continuously or periodically monitor data sources (such as sensors, communication interfaces, and system events) related to the target-triggered scenario information.

[0096] The computing device can also create one or more action execution instances based on the identifiers of the target participants (especially the target electronic device and the target event). Each action execution instance can be bound to a target electronic device in the target workflow and encapsulate the specific operation instructions required to execute the target event.

[0097] Next, the computing device can combine the aforementioned monitoring task instances and action execution instances into a directed target workflow containing a clear control flow, following the process logic that when the data source monitored by the monitoring task instance triggers the target trigger scenario, the action execution instance is invoked to send specific operation instructions to the target electronic device.

[0098] In other words, the computing device generates the target workflow based on the target workflow data, completing the key transformation from descriptive data to an executable program. It can instantiate and compile the target workflow data matched from the knowledge graph and adapted to a specific scenario into a specific automated task sequence, which is the final target workflow that can be implemented and run.

[0099] As can be seen from the above, in the target workflow data that matches the initial workflow data determined by the pre-constructed knowledge graph in the embodiments of this application, the target triggering scenario information is determined jointly based on the initial triggering conditions and the scenario information related to the initial event. Therefore, the target workflow generated based on the target workflow data no longer depends on a single pre-configured initial triggering condition, but can combine richer and broader scenario information related to the initial event, thereby solving the problem that traditional workflow generation methods cannot be applied to complex scenarios and can also meet the diverse needs of users.

[0100] The workflow execution method provided in the embodiments of this application will be described in detail below.

[0101] like Figure 3 As shown, the execution methods of the target workflow include: S301. After generating the target workflow, the computing device monitors real-time data of the current scene.

[0102] S302. When the real-time data being monitored meets the target triggering scenario, the computing device sends an operation command to the target electronic device.

[0103] This operation instruction is used by the target electronic device to execute the target event indicated by the target workflow.

[0104] Specifically, after the computing device generates the target workflow, it can start a listening service associated with the monitoring task instance. This listening service, based on the monitoring task instance configuration, continuously or periodically obtains real-time data from a specified data source (such as environmental sensors or software service status interfaces) by invoking device drivers, subscribing to message queues, polling application programming interfaces, or listening to the system event bus. This real-time data is related to the target triggering scenario. A relevant example can be found in S303 below.

[0105] Once a monitoring task instance determines that the real-time data it is monitoring meets the target trigger scenario, it can send a trigger command to the action execution instance associated with it. After receiving the trigger command, the action execution instance can generate the operation command to be sent to the target electronic device based on the protocol specifications (such as the communication protocol with the target electronic device) and control parameters encapsulated in the action execution instance.

[0106] Understandably, if the monitored real-time data does not meet the target trigger scenario, the computing device will continue to monitor.

[0107] S303. After receiving the operation command, the target electronic device can respond to the operation command and execute the target event.

[0108] For example, suppose the target workflow generated by the computing device is: Given that a user is about to return home in the rain, turn on the entryway lights, set the air conditioner to 26°C, and close the balcony curtains in advance. When executing this target workflow, the computing device can first obtain the real-time weather forecast for the user's city and the user's location information through a monitoring task instance.

[0109] If the monitoring task instance detects that the weather in the user's city is rainy and the user's location is near their home, then the target trigger scenario is determined to be met, and a trigger command is sent to the associated action execution instance. Upon receiving the trigger command, the action execution instance can generate operation commands to be sent to the entryway light, air conditioner, and balcony curtains based on the communication protocols encapsulated within the action execution instance, including those for the entryway light, air conditioner, and balcony curtains.

[0110] Once the entryway light receives its corresponding command, it can be turned on. Similarly, the air conditioner, upon receiving its command, can be turned on and set to 26°C. The balcony curtains, upon receiving their command, can be opened. This way, after returning home in the rain, users don't need to manually operate each of these multiple electronic devices individually; they can immediately enjoy a comfortable and bright home environment pre-executed by the target workflow.

[0111] As shown above, by transforming the generated target workflow into executable logic containing monitoring task instances and action execution instances, the computing device can continuously and dynamically perceive and automatically determine the target triggering scenario. When the real-time data currently monitored meets the triggering conditions of the target triggering scenario, it drives the target electronic device to execute the predefined target event. This allows the user to perform the desired operation (such as adjusting the physical environment to an ideal state) in advance without the user's awareness or intervention. This achieves a leap from passive response control to proactive predictive service, improving the intelligence, convenience, and user experience of the automated workflow.

[0112] In some embodiments, the process of generating a target workflow described above is essentially configuring a reusable, automatically executed target workflow. Once generated, this target workflow can be executed once or multiple times by the computing device. For example, if the user-generated target workflow is: given that the user is about to return home in the rain, turn on the entryway lights, set the air conditioner to 26°C, and close the balcony curtains in advance, the computing device can obtain the weather forecast for the user's city and the user's location information in real time every day through monitoring task instances. Therefore, when the target trigger scenario of the user returning home in the rain is met, the device can execute the target events of turning on the entryway lights, setting the air conditioner to 26°C, and closing the balcony curtains in advance.

[0113] Furthermore, the target workflow generated by the computing device is not permanent and can be dynamically updated. For example, the computing device can respond to direct modification commands from users, modify the target workflow data, and generate a new target workflow based on the modified data. Alternatively, the target workflow can be updated synchronously after the target workflow data in the knowledge graph has been optimized. Updates can also be based on feedback information after the target workflow is executed; however, this embodiment does not limit the scope of this application.

[0114] The process of matching target workflow data based on knowledge graphs, as provided in the embodiments of this application, will be described in detail below.

[0115] Method 1: The knowledge graph stores the triggering scenario information for each workflow in the workflow data. The computing device can match the target workflow data based on the triggering scenario information pre-stored in the knowledge graph.

[0116] Optionally, the triggering scenario information for each workflow data stored in the knowledge graph includes: the scenario type of the triggering scenario and the scenario content under the scenario type.

[0117] To facilitate rapid matching of target workflow data with the initial workflow data by computing devices, and to allow for clearer setting of triggering scenarios when generating the target workflow, the triggering scenario information for each workflow in the knowledge graph can be configured with scenario type and scenario content. In this case, the triggering scenario information for each workflow in the knowledge graph includes: the scenario type of the triggering scenario and the scenario content under that scenario type.

[0118] For example, suppose the knowledge graph stores workflow data for a smart home scenario, and the scenario type for triggering the scenario information is: home. The scenario content is: evening (17:00-19:00), rainy day, user is about to arrive home and no one is home.

[0119] In this workflow data, "home" as a scenario type provides a high-level semantic classification. This helps computing devices quickly aggregate all events related to the home environment, facilitating initial filtering. For example, when the initial workflow data involves intentions related to returning home, the computing device can prioritize matching within the "home" scenario type, rather than engaging in invalid searches within the "office" or "travel" scenario types.

[0120] The scenarios of evening (5:00 PM - 7:00 PM), rainy days, and users arriving home when no one is home provide precise descriptions of specific and determinable scenarios within the "home" scenario type. These scenarios are typically generated based on quantifiable or identifiable variables related to sensor data, communication interface services, or user status.

[0121] In other words, the aforementioned knowledge graph can use a hierarchical structure combining scenario types and scenario content to store trigger scenario information, achieving precise scenario coverage and efficient storage. Scenario types are categorized according to core areas such as "home," "office," and "travel," forming a relatively stable and finite upper-level classification system. Scenario content, as specific instances under each scenario type, is dynamically generated through real-time combination and matching of multiple key scenario variables (such as weather, time of day, user status, and device status). For example, under the scenario type of "home," a specific scenario content can be a composite scenario description composed of three key variables: "rainy day," "evening," and "user status is about to arrive home."

[0122] This layered design, combining scenario types with scenario content, ensures both manageability and query efficiency of the knowledge graph at the scenario dimension through a limited and stable classification of scenario types. On the other hand, it allows for flexible definition of specific scenario content through dynamic combinations of key variables, guaranteeing the coverage and differentiation of a large number of refined specific scenarios. This overall balances the breadth and accuracy of scenario coverage with the efficiency of system storage and retrieval.

[0123] Correspondingly, by using the scene types and scene content under each scene type stored in the trigger scene information in the knowledge graph, the computing device can also quickly match the target workflow data. In other words, determining the target workflow data matching the initial workflow data from the pre-built knowledge graph (i.e., S203 above) specifically includes: From the knowledge graph, determine the target scenario type and / or target scenario content that match the target scenario information, and identify the workflow data in the knowledge graph that matches the target scenario type and / or target scenario content as the target workflow data.

[0124] The target scene information is determined based on the scene information associated with the initial triggering conditions and the scene information related to the initial event.

[0125] Optionally, the target scene information can be the intersection of scene information associated with the initial triggering condition and scene information related to the initial event, or it can be obtained by scene recognition of scene information associated with the initial triggering condition and scene information related to the initial event.

[0126] The scenario information associated with the initial triggering conditions can be determined by the computing device through semantic parsing and contextual deduction of the initial triggering conditions in the initial workflow data.

[0127] For example, if the initial trigger condition is that the outdoor temperature is below 5°C, the associated scene information may be parsed and expanded to include implicit contextual information such as season (winter), weather type (cold), and possible activities (staying warm at home).

[0128] Contextual information related to the initial event can be determined by computing devices through analysis of the execution logic, historical data, or domain knowledge of the initial event within the initial workflow data. It refers to environmental or state factors that, while not explicitly specified in the initial triggering conditions, are relevant to the effect or rationality of the initial event's execution. For example, for the initial event of opening the living room window, related contextual information might include the current indoor PM2.5 index, outdoor noise level, or whether it is raining.

[0129] In one feasible approach, after determining the target scenario type and / or target scenario content that matches the target scenario information, the computing device can directly identify the workflow data in the knowledge graph that matches the target scenario type as the target workflow data; or it can directly identify the workflow data in the knowledge graph that matches the target scenario content as the target workflow data; or it can first perform an initial screening based on the target scenario type, and then identify the workflow data that matches the target scenario content from the initial screening results as the target workflow data.

[0130] When a computing device identifies workflow data in a knowledge graph that matches the target scenario type and content as target workflow data, the computing device first matches the target scenario information obtained from the above parsing with predefined scenario types in the knowledge graph (such as home comfort type, energy-saving optimization type, security protection type, and office efficiency type). One or more matching scenario types are then used as the first-level filtering conditions, significantly narrowing down the filtering range for determining the target workflow data.

[0131] In one feasible approach, a computing device can determine the matching degree between target scene information and scene type by calculating the semantic relevance between keywords or semantic vectors of target scene information and descriptions of each scene type.

[0132] Next, within the defined scenario type range, the computing device can perform further refined matching. For example, specific, quantifiable parameters in the target scenario information (such as temperature value of 5℃, PM2.5 index of 80, and status of rainfall) are compared with the specific scenario content under each workflow data in the knowledge graph to obtain the target workflow data.

[0133] In one feasible approach, a computing device can determine the degree of matching between target scene information and target scene content using a similarity calculation model.

[0134] Method 2: Each workflow data stored in the knowledge graph also includes constraints for the triggering scenario of each workflow. These constraints are used to regulate the triggering and execution of the corresponding workflow. The computing device can match the target workflow data based on the constraints pre-stored in the knowledge graph.

[0135] Constraints are logical rules attached to workflow data to ensure that the workflow can be triggered and executed in a safe, reasonable, and feasible context. They are typically manifested as a series of preconditions that must be met or restrictions that must be avoided.

[0136] In one feasible approach, common constraints include at least one of the following: device state constraints, environment state constraints, resource or dependency constraints, and security and policy constraints.

[0137] Device state constraints are used to restrict electronic devices participating in the workflow to a specific state in order to execute. For example, an air conditioner must be online and in a non-faulty state, or a smart door lock must have a battery level higher than 20%.

[0138] Environmental constraints are used to restrict physical or virtual environments to meet specific conditions. For example, automatic window closing can only be performed when no one is indoors, or the current time is not within a preset do-not-disturb period.

[0139] Resource or dependency constraints are used to ensure that the resources on which execution depends are available or that preconditions are met. For example, before performing a data backup, the available space on the target storage device must be greater than a threshold, and before sending a notification, it must be confirmed that the network connection is normal.

[0140] Security and policy constraints are used to impose specific restrictions based on security rules or user policies. For example, prohibiting unlocking from the external network while the system is armed, or requiring secondary authentication for sensitive operations.

[0141] With the knowledge graph storing the constraints for each workflow's triggering scenario, the computing device can also match target workflow data based on these constraints. In this case, the method described above for determining target workflow data that matches the initial workflow data from a pre-built knowledge graph specifically includes: The workflow data to which the target constraints in the knowledge graph match the target scenario information are assigned is identified as the target workflow data.

[0142] Constraints and scenario information are closely related. Within a workflow, constraints can only be set after the trigger scenario for that workflow has been defined. Therefore, when a computing device matches target workflow data with constraints, it first needs to determine the scenario information related to the initial workflow data, namely, the target scenario information described above, including the scenario information associated with the initial trigger conditions and the scenario information related to the initial event. Next, the computing device can query the knowledge graph for target constraints that match the target scenario information and identify the workflow data to which the target constraints belong as the target workflow data.

[0143] For example, suppose the initial workflow data corresponds to the initial workflow of closing the smart window when it rains. The computing device can match a specific workflow data in the knowledge graph based on the target scenario information of "rainy day": the trigger scenario is rainy day, and the constraint is that the window controller is running normally. In this case, the computing device can use this matched workflow data as the target workflow data.

[0144] In other words, by introducing constraints as key decision factors in the process of matching target workflow data, the generated target workflow data can not only be semantically consistent with user intent and scenario, but also have immediate executability in terms of the physical state, resource availability and security policies of the target electronic device, thereby improving the reliability of the automatic implementation of the target workflow.

[0145] Method 3: Each workflow data stored in the knowledge graph also includes the event execution priority of each workflow's related events. The priority of event execution is positively correlated with the degree of constraint risk of the constraints satisfied when executing the event. The computing device can match target workflow data based on the pre-stored event execution priorities in the knowledge graph.

[0146] Optionally, when the workflow data stored in the knowledge graph does not include constraints related to the triggering scenario, the workflow data may also include the event execution priority of each event involved in the workflow. In this case, the priority order of the event execution priorities of each workflow-related event can be pre-defined by the user.

[0147] Event execution priority is used to indicate the basis for computing devices to make decisions and schedule events when multiple event triggering scenarios are triggered simultaneously and resource conflicts or logical mutual exclusions exist during workflow execution. The core principle of its setting logic is that the priority order of event execution is positively correlated with the degree of constraint risk corresponding to the constraints that need to be met to execute the event.

[0148] The degree of constraint risk is a quantitative assessment of the severity of the negative consequences that may result from violating or ignoring a constraint. The degree of constraint risk is usually predefined based on domain knowledge. For example, constraints with high risk, medium risk, and low risk can be defined.

[0149] High-risk constraints can involve personal safety, permanent equipment damage, or significant data loss (e.g., prohibiting the shutdown of ventilation systems when a flame is detected, requiring medical equipment to save data before power loss). Medium-risk constraints can affect the main functions of electronic devices, user experience, or potentially cause economic losses (e.g., requiring two-factor authentication for money transfers, prohibiting the deployment of new services when the core server load exceeds 90%). Low-risk constraints mainly involve convenience, comfort, or non-critical resource optimization (e.g., automatically dimming lights in night mode, entering energy-saving mode when battery level is below 50%).

[0150] When building or updating a knowledge graph, computing devices assign corresponding event execution priorities to the events involved in each workflow based on the level of constraint risk associated with the constraints. For example, if a workflow is associated with any high-risk constraint, the event execution priority of its involved events is set to the highest level (e.g., level 10). Conversely, if a workflow is associated with only low-risk constraints, the event priority of its involved events can be set to a lower level (e.g., level 3).

[0151] For example, a knowledge graph in a smart home scenario can store two workflow data: workflow data for workflow A and workflow data for workflow B.

[0152] Workflow A automatically opens all windows and shuts off the gas valve when smoke is detected. Its constraints include a smoke sensor alarm, which is a high-risk constraint due to its involvement in personal safety. The event execution priority of the events involved in this workflow is also set to the highest level (level 10).

[0153] Workflow B is to automatically turn on the main living room light when the indoor lighting is dim in the evening. Its constraint includes the presence of people in the room. Since this constraint only involves user comfort, it is a low-risk constraint. The event execution priority of the events involved in this workflow is also set to a low level (level 3).

[0154] In a knowledge graph where each workflow data entry also includes the event execution priority of the events involved in each workflow, the computing device can determine the target workflow data that matches the initial workflow data based on the event execution priority. In this case, determining the target workflow data that matches the initial workflow data from the pre-built knowledge graph includes: In the knowledge graph, the workflow data that matches the initial workflow data includes the first sub-workflow data and the second sub-workflow data. If the execution logic of the first event involved in the first sub-workflow data conflicts with that of the second event involved in the second sub-workflow data, and the execution priority of the first event is greater than that of the second event, then the first sub-workflow data is determined as the target workflow data.

[0155] After the computing device identifies workflow data matching the initial workflow data from the knowledge graph, if the matching workflow data includes multiple sub-workflow data, it can perform execution logic conflict judgment on the events involved in these multiple sub-workflow data. That is, for any two sub-workflow data, such as the first sub-workflow data and the second sub-workflow data, the computing device can perform execution logic conflict judgment on the first event involved in the first sub-workflow data and the second event involved in the second sub-workflow data.

[0156] When a conflict is found between the execution logic of the first and second events, the computing device does not choose randomly. Instead, it queries the knowledge graph for the execution priorities of the first and second events. If the execution priority of the first event is higher than that of the second event, it indicates that the first event is more important. In this case, the electronic device can identify the first sub-workflow data as the target workflow data.

[0157] For example, suppose in a smart home scenario, the computing device matches two sub-workflow data from a knowledge graph based on initial workflow data: The first event involved in the first sub-workflow data is closing the balcony window. This workflow aims to prevent rainwater from entering the room. In the knowledge graph, the execution priority of the event associated with the first event is preset to level 7 (higher) because its constraint involves a medium-risk constraint of preventing property damage (closing the balcony window due to rainwater).

[0158] The second event involved in the second sub-workflow data is opening the balcony window. This workflow aims to ventilate and improve indoor air quality. Its event execution priority is preset to level 4 (low) because its constraint is associated with the low-risk constraint of improving comfort (opening the balcony window when air quality is high).

[0159] Because the execution logic of the first event (closing the window) and the second event (opening the window) for the same electronic device (balcony window) conflicts, they cannot be executed simultaneously. Since the execution priority (7) of the first event is greater than the execution priority (4) of the second event, the computing device determines that the need to prevent rainwater intrusion is more important than ventilation in the current context. Therefore, the computing device determines the first sub-workflow data (containing the first event of closing the balcony window) as the target workflow data.

[0160] In some embodiments, when constructing a knowledge graph, the computing device can achieve coordination between constraints and event execution priorities through a predefined mapping relationship between constraint risk levels and event execution priorities. That is, the computing device can pre-configure corresponding default values ​​for event execution priorities for different levels of constraint risk based on domain knowledge; for example, constraints involving security risks are mapped to the highest event execution priority.

[0161] Meanwhile, the computing device can also provide a user-defined entry point, allowing users to adjust the event execution priority mapped to specific constraints according to specific scenarios or preferences. Through this mechanism of pre-defined mapping combined with user tuning, the basis for determining event execution priority based on the degree of constraint risk is ensured, while also supporting personalized strategy adjustments to meet diverse user needs.

[0162] Method 4: Each workflow data stored in the knowledge graph also includes attribute parameters for each workflow participant. The initial workflow data also includes attribute parameters for the initial participants. The computing device can match target workflow data based on the attribute parameters pre-stored in the knowledge graph.

[0163] In cases where each workflow data stored in the knowledge graph also includes attribute parameters of each workflow participant, the initial workflow data also includes: attribute parameters of the initial participants. In this case, the method described above for determining the target workflow data matching the initial workflow data from the pre-built knowledge graph specifically includes: The workflow data to which the attribute parameters in the knowledge graph match the attribute parameters of the initial participating subject belong are determined as the target workflow data.

[0164] Attribute parameters are used to precisely describe and define the attributes of each participant in a workflow, serving as a crucial data foundation for achieving refined matching and context-aware decision-making. Attribute parameters can be quantitative or qualitative descriptions of specific properties or states of workflow participants. For example, for a smart air conditioner, its attribute parameters might include the device model, current operating mode, required temperature setting, and energy consumption level.

[0165] The initial participants (initial electronic devices, initial events, etc.) included in the initial workflow data also have corresponding attribute parameters. These attribute parameters can be set by the user during configuration (such as setting the desired temperature of an air conditioner) or obtained by the computing device based on the identifier of the initial electronic device (such as the function list of the initial electronic device).

[0166] In the workflow data stored in the knowledge graph, attribute parameters do not exist in isolation, but rather serve as key supplementary information for the workflow participants.

[0167] Specifically, when matching target workflow data, the computing device can not only compare the identifier of the initial participant with the identifier of each workflow participant in the knowledge graph, but also compare the attribute parameters of the initial participant with the attribute parameters of each workflow participant in the knowledge graph.

[0168] For example, if the initial event in the initial workflow data is setting the air conditioner to 26 degrees Celsius, and there are two workflow data sets in the knowledge graph, where the first workflow data set has the event "setting the air conditioner to 26 degrees Celsius" and the second workflow data set has the event "setting the air conditioner to 27 degrees Celsius," and all other data in these two workflow data sets is the same, the computing device can identify the first workflow data set as the target workflow data set.

[0169] In some embodiments, the attribute parameters in each workflow data stored in the knowledge graph include: basic attribute parameters and extended attribute parameters stored in the knowledge graph as key-value pairs. The basic attribute parameters are used to represent the fixed attribute characteristics of the corresponding workflow participants, and the extended attribute parameters are used to represent the additional attribute characteristics of the corresponding workflow participants.

[0170] To efficiently and flexibly manage the diverse characteristics of various stakeholders participating in the workflow, when constructing a knowledge graph, computing devices can use a structured storage method to store the attribute parameters in each workflow data. These attribute parameters are designed to include basic attribute parameters and extended attribute parameters, both of which are stored in the form of key-value pairs.

[0171] Basic attribute parameters are used to characterize the fixed identity and core functions of the participants in the workflow. For example, for a smart air conditioner, its basic attribute parameters may include the air conditioner model, air conditioner category (home appliance category), and air conditioner function set (such as cooling function, heating function, etc.).

[0172] Since the fields of the basic attribute parameters are relatively fixed and stable, and are stored using a predefined structure, the efficiency and consistency of data querying when the computing device matches the target workflow data are guaranteed.

[0173] Extended attribute parameters are used to dynamically carry additional characteristics and real-time status of workflow participants. They can describe the additional characteristics, configurable items, or dynamically changing status of the corresponding workflow participants in a flexible manner.

[0174] Continuing with the example of a smart air conditioner, its extended attribute parameters may include: the current operating mode is cooling mode, the target temperature is 26 degrees Celsius, and the fan speed is level two. These extended attribute parameters can change according to user settings or the device's operating status.

[0175] Meanwhile, to ensure that extended attribute parameters are semantically clear and formatted correctly, avoiding data redundancy and ambiguity, computing devices can also establish and maintain an attribute dictionary. This attribute dictionary standardizes the key names, value ranges, and data types of commonly used extended attribute parameters. When building or updating knowledge graphs, computing devices can refer to this attribute dictionary to standardize the input and storage of extended attribute parameters.

[0176] In some embodiments, in order to accurately describe the execution logical order between workflows, each workflow data stored in the knowledge graph also includes: the interaction relationships between each workflow participant.

[0177] When the interaction relationships between the target participants in the target workflow data include multiple types of interaction relationships, the target workflow is generated based on the target workflow data, including: Based on each type of interaction relationship, determine the execution order of the target events involved in each type of interaction relationship, and generate the target workflow according to the execution order of the target events.

[0178] The target workflow is also used to instruct the target electronic device to execute target events in the order of execution under the target triggering scenario.

[0179] As shown above, the knowledge graph constructed by the computing device can store the interaction relationships between each workflow data point and each participating entity. In other words, each workflow data point stored in the knowledge graph not only defines who (entity) does what (event) under what circumstances (scenario), but also specifies the interaction logic of these entities when they collaboratively complete the corresponding workflow in a structured manner.

[0180] To clearly describe the interaction relationships among the various participants in the workflow described above, the computing device can define and manage these relationships using relationship type tags. In other words, the interaction relationships among the participants in the workflow can include at least one of the following categories: trigger-based relationships, dependency-based relationships, and collaborative relationships.

[0181] In this context, trigger-based relationships represent how the state of one participant triggers an event performed by another participant; that is, the state of one participant is the direct cause of the event performed by the other. This state can be the participant's current state or its state after performing the relevant event. For example, rainy weather data collected by a sensor can trigger the closing of the smart window in the living room.

[0182] Dependency relationships are used to represent that one participant's execution of an event depends on the state of another participant. In other words, when one participant performs an action or provides a service, it requires the data or state of another participant as a prerequisite. For example, the participant that sends a notification to parents to pick up their child from school depends on the participant that sends a notification about the child's dismissal time.

[0183] Collaborative relationships are used to represent multiple participants that need to collaborate in executing events. In other words, multiple participants need to execute related events in parallel or in coordination to achieve a common goal, without direct triggering or dependence on each other. For example, lighting and music collaborate to create the movie-watching atmosphere.

[0184] To further define the complex multiple interaction relationships, the computing device can also use a combination of master and slave relationships to generate the target workflow. The master relationship represents the core driving logic chain of the target workflow (e.g., rainy weather data collected by sensors triggering the closing of the smart window in the living room is the master relationship), while the slave relationship represents the necessary condition chain to complete the master relationship (e.g., closing the smart window in the living room depends on conditions such as an outdoor temperature of 26 degrees Celsius and the presence of people indoors).

[0185] As can be seen from the above, the workflow data stored in the knowledge graph not only includes the triggering scenario information, the identifiers of the participating entities, and the interaction relationships between the corresponding workflow participants, but also includes at least one of the following: the constraints under the triggering scenario, the event execution priority of the events involved in the corresponding workflow, and the attribute parameters of the corresponding workflow participants.

[0186] When constructing a knowledge graph, the computing device uses triggering scenario information, the identifiers of participating entities, and the interaction relationships between corresponding workflow participants as workflow data. In addition, it can also use at least one of the following as rich workflow data: the constraints under the triggering scenario, the event execution priority of the events involved in the corresponding workflow, and the attribute parameters of the corresponding workflow participants. Therefore, the embodiments of this application can meet the diverse user needs in complex scenarios.

[0187] When workflow data stored in a knowledge graph includes six items—trigger scenario information, participant identifiers, interaction relationships between corresponding workflow participants, constraints under the trigger scenario, event execution priorities of events involved in the corresponding workflow, and attribute parameters of corresponding workflow participants—the knowledge graph can store this workflow data in the form of six-tuples. Through these six-tuples, the target workflow data can be accurately matched to the initial workflow data, thus enabling the target workflow generated based on the target workflow data to better adapt to the diverse user needs in the complex scenarios of IFTTT. In some embodiments, the computing device may also update the target workflow data in the knowledge graph based on feedback information. In this case, the method provided in this application embodiment further includes: Obtain feedback information after the target electronic device executes the target event in the target trigger scenario, and update the target workflow data in the knowledge graph based on the feedback information.

[0188] The feedback information includes at least one of the following: the execution result of the target event, the device status of the target electronic device, and the user's interaction feedback information with the target electronic device within a preset time period.

[0189] The execution result of the target event can be obtained directly from the target electronic device, usually as a structured status code (such as success, failure, timeout) and related detailed logs.

[0190] The device status of the target electronic device refers to the status obtained by querying the target electronic device's status interface during the execution of the target event. The device status of the target electronic device can include statuses directly related to the execution of the target event (such as whether the light is actually on), and can also include other statuses (such as device temperature, network latency, battery level, etc.).

[0191] User interaction feedback within a preset time period refers to subsequent actions taken by the user within a specific time window after the target event has been completed. This can include user ratings, confirmations, cancellations, or complaints regarding the target workflow provided within the application. It can also include user corrections made by the user through manual operation of the target electronic device to perform the target event. For example, if the target workflow automatically sets the air conditioner to 26°C, and the user immediately adjusts it manually to 25°C, this behavior is considered strong negative feedback, indicating a deviation between the target workflow and the user's preferences.

[0192] After obtaining feedback, the computing device can correlate the feedback with the target workflow data and evaluate the effectiveness of the target workflow based on the feedback. For example, it can verify whether the target event truly achieved the expected results by combining the execution results and device status, and determine whether the target workflow meets the user's subjective expectations and comfort level by combining user interaction feedback.

[0193] Next, the computing device can process the target workflow data based on the above evaluation results, including updating or continuing to monitor its feedback information. For example, if a user frequently adjusts a parameter manually (such as air conditioning temperature), the computing device will automatically adjust the default values ​​or recommended ranges of the relevant attribute parameters in the corresponding workflow data in the knowledge graph, thus completing the update of the workflow data.

[0194] In an exemplary embodiment, this application also provides a workflow generation apparatus. This workflow generation apparatus may be a computing device that performs the aforementioned workflow generation method, or it may be a processor within the computing device. The workflow generation apparatus may include one or more functional modules for implementing the workflow generation method of the above method embodiments.

[0195] This application also provides a computing device. Figure 4 This is a schematic diagram of the architecture of a computing device provided in an embodiment of this application. Figure 4 As shown, the computing device 100 includes: one or more memories 120, one or more processors 110, a communication bus 140, and a communication interface 130. The processors 110 and memories 120 are connected via the communication bus 140; the one or more memories 120 are used to store computer program code, which includes computer instructions; when the one or more processors 110 execute the computer instructions, the computing device 100 performs the workflow generation method provided in this embodiment.

[0196] Optionally, the memory 120 may be a non-transitory computer-readable storage medium, such as a read-only memory (ROM), random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc. The embodiments of this application do not impose any limitations on this.

[0197] The processor 110 may be a central processing unit (CPU), a network processor (NP), a digital signal processor (DSP), a microprocessor, a microcontroller, a programmable logic device (PLD), or any combination thereof, and the embodiments of this application do not impose any limitations on this.

[0198] The communication bus 140 can be an industry standard architecture (ISA) bus, a peripheral component interconnect (PCI) bus, or an extended industry standard architecture (EISA) bus, etc. This communication bus 140 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 4 It is represented by a single thick line, but this does not mean that there is only one bus or one type of communication bus.

[0199] Communication interface 130 uses any transceiver-like device for communicating with other devices or communication networks, such as control systems, radio access networks (RAN), wireless local area networks (WLAN), etc.

[0200] It should be noted that the system architecture and application scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of system architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0201] This application also provides a computer-readable storage medium. All or part of the processes in the above method embodiments can be executed by computer instructions instructing related hardware; for example, the related hardware can be a processor of a computing device. The program instructions can be stored in the aforementioned computer-readable storage medium, and when executed, the processes of the above method embodiments can be implemented. The computer-readable storage medium can be memory. The aforementioned computer-readable storage medium can also be an external storage device, such as a hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc. Further, the aforementioned computer-readable storage medium can include both memory and external storage devices. The aforementioned computer-readable storage medium is used to store the aforementioned computer program instructions and other programs and data required by the aforementioned workflow generation method.

[0202] This application also provides a computer program product comprising a computer program that, when run on a computing device, causes the computing device to execute any of the workflow generation methods provided in the above embodiments.

[0203] Although this application has been described herein in conjunction with various embodiments, those skilled in the art, by reviewing the accompanying drawings, disclosure, and appended claims, will understand and implement other variations of the disclosed embodiments in carrying out the claimed application. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude multiple instances. A single processor or other unit can implement several functions listed in the claims. While different dependent claims may recite certain measures, this does not mean that these measures cannot be combined to produce good results.

[0204] Although this application has been described in conjunction with specific features and embodiments, it is obvious that various modifications and combinations can be made thereto without departing from the spirit and scope of this application. Accordingly, this specification and drawings are merely exemplary illustrations of this application as defined by the appended claims, and are considered to cover any and all modifications, variations, combinations, or equivalents within the scope of this application. Clearly, those skilled in the art can make various alterations and modifications to this application without departing from the spirit and scope of this application. Thus, if such modifications and modifications of this application fall within the scope of the claims of this application and their equivalents, this application is also intended to include such modifications and modifications.

[0205] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A workflow generation method, characterized in that, include: Obtain initial workflow data; The initial workflow is used to instruct the initial electronic device to execute an initial event under initial triggering conditions; The initial workflow data includes: the initial triggering conditions and the identifiers of the initial participants in the initial workflow; the initial participants include: the initial electronic device and the initial event; From a pre-constructed knowledge graph, target workflow data matching the initial workflow data is determined; the knowledge graph stores multiple workflow data; each workflow data includes: trigger scenario information and identifiers of participating entities; the target workflow is used to instruct a target electronic device to execute a target event under a target trigger scenario, and the target workflow data includes: the target trigger scenario information and identifiers of target participating entities; the target trigger scenario is determined based on the initial trigger conditions and scenario information related to the initial event; the target participating entities include: the target electronic device and the target event; The target workflow is generated based on the target workflow data.

2. The method according to claim 1, characterized in that, The triggering scenario information for each workflow data stored in the knowledge graph includes: the scenario type of the triggering scenario and the scenario content under the scenario type; The step of determining the target workflow data that matches the initial workflow data from the pre-built knowledge graph includes: From the knowledge graph, the target scene type and / or target scene content that match the target scene information are determined; the target scene information is determined based on the scene information associated with the initial triggering condition and the scene information related to the initial event; The workflow data in the knowledge graph that matches the target scenario type and / or the target scenario content is identified as the target workflow data.

3. The method according to claim 1 or 2, characterized in that, Each workflow data stored in the knowledge graph also includes: constraints under the triggering scenario of each workflow; the constraints are used to constrain the triggering and execution of the corresponding workflow; The step of determining the target workflow data that matches the initial workflow data from the pre-built knowledge graph includes: The workflow data to which the target constraints in the knowledge graph match the target scenario information are assigned is determined as the target workflow data.

4. The method according to claim 3, characterized in that, Each workflow data stored in the knowledge graph also includes: the event execution priority of each workflow-related event; the priority of the event execution priority is positively correlated with the degree of constraint risk of the constraints satisfied when executing the event.

5. The method according to claim 4, characterized in that, The step of determining the target workflow data that matches the initial workflow data from the pre-built knowledge graph includes: In the knowledge graph, the workflow data that matches the initial workflow data includes first sub-workflow data and second sub-workflow data. If the execution logic of the first event involved in the first sub-workflow data conflicts with the execution logic of the second event involved in the second sub-workflow data, and the execution priority of the first event is greater than that of the second event, then the first sub-workflow data is determined as the target workflow data.

6. The method according to any one of claims 1-5, characterized in that, Each workflow data stored in the knowledge graph also includes: attribute parameters of each workflow participant; the initial workflow data also includes: attribute parameters of the initial participant. The step of determining the target workflow data that matches the initial workflow data from the pre-built knowledge graph includes: The workflow data to which the attribute parameters in the knowledge graph match the attribute parameters of the initial participating subject belong are determined as the target workflow data.

7. The method according to claim 6, characterized in that, The attribute parameters in each workflow data stored in the knowledge graph include: basic attribute parameters and extended attribute parameters stored in the knowledge graph in the form of key-value pairs; the basic attribute parameters are used to represent the fixed attribute characteristics of the corresponding workflow participants, and the extended attribute parameters are used to represent the additional attribute characteristics of the corresponding workflow participants.

8. The method according to any one of claims 1-7, characterized in that, Each workflow data stored in the knowledge graph also includes: the interaction relationships between the participants in each workflow; When the interaction relationships between the target participants in the target workflow data include multiple types of interaction relationships, generating the target workflow based on the target workflow data includes: Based on each type of interaction relationship, determine the execution order of the target events involved in each type of interaction relationship; The target workflow is generated according to the execution order of the target events; the target workflow is also used to instruct the target electronic device to execute the target events in the execution order under the target triggering scenario.

9. The method according to any one of claims 1-8, characterized in that, The method further includes: The system obtains feedback information after the target electronic device executes the target event in the target triggering scenario; the feedback information includes at least one of the following: the execution result of the target event, the device status of the target electronic device, and the user's interaction feedback information with the target electronic device within a preset time period; The target workflow data in the knowledge graph is updated based on the feedback information.

10. A computing device, characterized in that, The computing device includes a processor and a memory; the processor is coupled to the memory. The memory is used to store computer instructions; The computer instructions are loaded and executed by the processor to enable the computing device to perform the method as described in any one of claims 1-9.

Images