We present (1) a virtual flamethrower factory as an abstraction of a real-world industrial setting that provides Read-Write Linked Data interfaces to devices, and (2) an agent that operates in this environment with the aim to produce flamethrowers. The interfaces allow for (1) obtaining information about state and capabilities of the devices, and (2) controlling the devices. The agent can (1) plan and (2) execute workflows. The agent is written in the Notation 3 language with ASM4LD semantics, can perform Hierarchical Task Network planning, and can execute workflows described in the WiLD ontology.
Under the impression of the recently standardised Web of Things descriptions1, which are a step towards read access to descriptions of (Internet of Things) device capabilities and read-write access to such devices’ state and functionality using Linked Data and other web technologies, we want to provide a showcase on the “demand” side for such possibilities for access to devices. Also outside of the Internet of Things, read-write capabilities to state maintained in Linked Data is on the rise around the SoLiD project2. Our showcase is therefore based on Read-Write Linked Data access to devices. As the stack of Linked Data is all about interoperability, facilitated in part using reasoning, e. g. to flexibly swap components that speak diferent vocabularies, we want rule-based reasoning as part of our showcase. To make use of the functional descriptions and write access, we want in our showcase to add to this traditional setting (Linked Data and rule-based reasoning) an agent that plans a workflow (from the functional descriptions and a goal) and executes this workflow.
Technologically, we therefore built an agent that uses HTTP for communicating with devices,
where messages are described in RDF. We use rules to express reasoning. To describe the agent’s
behaviour, we employ a workflow language that can be executed on Linked Data, specifically
the WiLD ontology [
© 2021 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
Workshop
Proceedings
ASM4LD [
As a setting, we chose manufacturing, where interoperability is a challenge and the increasing requirement for small lot sizes requires flexibility. To simplify the prototype development, we work in a virtual setting based on Factorio, a video game. Factorio3 is all about automation and the eficient and flexible production of various goods. Tech-trees and resource distribution in the virtual environments require you to repeatedly adapt your strategy. One of the less complex products in the game is a flamethrower, using which (1) enemies can be fought who want to destroy the manufacturing line or (2) trees can get burned down to make room for extensions of the manufacturing line. To build a flamethrower in Factorio, you need a set of iron gearwheels and steel plates which themselves are made using raw iron ore. In the game, you could go and do all the crafting by hand but it is cumbersome and not time-eficient. Therefore, you build a factory with ovens and other assembly machines, connected by robotic arms and transport belts. We want to make use of this game scenario, have re-built parts in Virtual Reality with Linked Data interfaces, and for our showcase, control it using an agent that builds and executes a workflow that produces a flamethrower. We have a virtual flamethrower manufacturing line which we know to work, which allows us to validate if the planned workflow works by checking if after execution a flamethrower is produced.
Planning with semantic technologies has been investigated in diferent technology settings:
SHOP2 [
ROSPlan [
OperaHtTioNna+l WSeiLmDantics
ASM4LD Implementation RDF(S) Semantics
Linked Data Platform Container Factory Component 1 Factory Component n
HTN + WiLD Models 1. HTN Plan Instances 2. WiLD Workflow Instances
System under Observation and Control
Our virtual factory shown in Figure 1 includes a set of robotic arms, transport belts and machines. All of them provide RESTful Linked Data interfaces and allow user agents to control them using unsafe HTTP requests. Moreover, we have descriptions of the device capabilities. The factory is built using the Java-based jMonkeyEngine4 along with 3D models built and animated using Blender5. In the next section we will explain the details of our prototype.
The theoretical foundation of our planner lies in Hierarchical Task Networks (HTN), first
designed by Sacerdoti [
However, our main goal was not to implement a full-blown HTN planner, but rather provide a set of rules that fulfil the core HTN decomposition principle, but with less technical complexity. There is no algorithm besides a processing engine that applies rules to a set of data, leading to easier implementation and acceptance through explainability.
We built an HTN vocabulary along with an operational semantics in the Notation3 language with ASM4LD semantics [17]. Using this approach, we can plan workflows in the WiLD [ 18] ontology for specifying workflows that can be executed on Linked Data. The operational semantics for WiLD can also be given in Notation3/ASM4LD. In our setup, see Fig. 1, an agent orchestrates the virtual devices along with a Linked Data Platform Container [19] that stores the vocabularies along with workflow models and instances. The agent runs the operational semantics for HTN planning and WiLD workflow execution using the Linked Data-Fu 6 interpreter. The code, including an HTN problem description, along with setup instructions is available 4https://jmonkeyengine.org/ 5https://www.blender.org/ 6https://linked-data-fu.github.io/ online, see the links on Page 1. In the following we want to give you an overview of how HTN works along with WiLD [18] and where it provides flexibility.
First, we need to introduce basic technologies from our environment Read-Write Linked Data.
We assume the data transferred in the message body of HTTP requests to be given using the Resource Description Framework (RDF) [20]. RDF is a graph-based data model, where the data is encoded in (subject , predicate, object ) triples. With as the set of all URIs, ℬ the set of all blank nodes, and ℒ the set of all literals (e. g. strings, numerical values), triples are restricted as follows: (subject , predicate, object ) ∈ ∪ ℬ × × ∪ ℬ ∪ ℒ . In this paper, we use a logical notation for RDF. As a triple encodes a binary predicate, we use predicate(subject , object ) to talk about a triple. As triples in RDF are valid conjunctively, we use the logical and (∧) to connect triples to a graph. We use Uniform Resource Identifiers (URIs) [ 21] to denote things, abbreviated as CURIEs7 and follow the abbreviations from prefix.cc8. We thus write a triple as follows: rdf:type(ex:produce-flamethrower-method , :Method ) As rdf:type assigns things to a class, we use the unary predicate for a class assignment: :Method (ex:produce-flamethrower-method )
Before we add modifications, we need to (simplifying) present how the planning works for our manufacturing workflow.
We can manufacture a flamethrower by executing tasks, which we identify using URIs. The tasks need to be in a specific order (workflow). The tasks can be executed as HTTP requests to a manufacturing device, which we can describe in RDF. We thus need to embed the requests in a structure that tells us to execute the requests (we call it primitive task).
:PrimitiveTask(ex:assemble-plate) ∧ :hasHttpRequest (ex:assemble-plate, ex:assemble-plate-request )
∧ :PrimitiveTask(ex:assemble-gearwheel) ∧ :hasHttpRequest (ex:assemble-gearwheel, ex:assemble-gearwheel-request )
∧ :PrimitiveTask(ex:produce-flamethrower ) ∧ :hasHttpRequest (ex:produce-flamethrower , ex:produce-flamethrower-request ) ∧ … Next, we need a another structure to determine the tasks’ order. We use a network of tasks based on the (linked) RDF list and some enclosing RDF for that purpose:
:TaskNetwork(ex:task-network) 7https://www.w3.org/TR/curie/ 8http://prefix.cc/. We use the empty prefix to denote https://purl.org/uberq/htn/vocab# and the prefix ex: to denote http://example.org/#. An underscore in prefix position indicates a blank node.
∧ :hasTaskList(ex:task-network, _:li1) ∧ rdf:first(_:li1, ex:assemble-plate) ∧ rdf:rest(_:li1, _:li2) ∧ rdf:first(_:li2, ex:assemble-gearwheel) ∧ rdf:rest(_:li2, _:li3) ∧ rdf:first(_:li3, ex:produce-flamethrower ) ∧ rdf:rest(_:li3, rdf:nil) The question a planner has to answer is to come up with such an order, i. e. workflow.
To determine such an order, a planner needs descriptions of the outcome of each task. We model the outcome as a postcondition (in HTN, this is called Literal) in the form of a SPARQL ASK query [22] in SPIN notation9. Such literals can be regarded as the goals the tasks fulfil.
sp:Ask(ex:literal-flamethrower ) ∧ sp:where(ex:literal-flamethrower , … ) ∧ … The task network can now be regarded as fulfilling the goal of manufacturing the flamethrower. :Goal(ex:goal-flamethrower ) ∧ :hasLiteral(ex:goal-flamethrower , ex:literal-flamethrower ) The method to achieve the goal now holds the task network, to be decomposed by the planner: :Method(ex:flamethrower-method) ∧ :forGoalTask(ex:flamethrower-method, ex:goal-flamethrower ) ∧ :hasTaskNetwork(ex:flamethrower-method, ex:task-network)
Now imagine we also want to manufacture a more precise flamethrower, by attaching midrange optics to it. We could define a completely new task network. Instead, we leverage the hierarchy of HTN and reuse our goal along with the method. We define additional goal tasks and primitive tasks, e. g. for a precise flamethrower. Now we can define a method to create the precise flamethrower, which re-uses ex:goal-flamethrower from earlier.
:Method(ex:precise-flamethrower-method) ∧ :forGoalTask(ex:precise-flamethrower-method, ex:goal-precise-flamethrower ) ∧ :hasTaskNetwork(ex:precise-flamethrower-method, _:tn)
∧ :hasTaskList(_:tn, _:tl1) ∧ rdf:first(_:tl1, ex:goal-flamethrower ) ∧ rdf:rest(_:tl1, _:tl2)
∧ rdf:first(_:tl2, ex:attach-optics) ∧ rdf:rest(_:tl2, rdf:nil) Goal ex:precise-flamethrower-goal can then get decomposed into ex:goal-flamethrower and the primitive task ex:attach-optics. Further decomposition gives us the new workflow.
We presented an agent that does integrated planning and execution of workflows in Linked Data. We showcased the agent in a virtual manufacturing setting and outlined how the set of technologies can facilitate flexibility, next to the flexibility gained by using semantic reasoning.
Actions and Change 2 (1998). URL: http://www.ep.liu.se/ej/enrac/1997/. [16] K. Erol, J. A. Hendler, D. S. Nau, Umcp: A sound and complete procedure for hierarchical task-network planning., in: AIPS, volume 94, 1994, pp. 249–254. [17] T. Käfer, A. Harth, Rule-based programming of user agents for linked data, in: LDOW@
WWW, 2018. [18] T. Käfer, A. Harth, Specifying, monitoring, and executing workflows in linked data environments, in: International Semantic Web Conference, Springer, 2018, pp. 424–440. [19] S. Speicher, J. Arwe, A. Malhotra, Linked data platform 1.0, 2015. URL: https://www.w3.
org/TR/ldp, w3C Recommendation. [20] R. Cyganiak, D. Wood, M. Lanthaler, RDF 1.1 Concepts and Abstract Syntax, Recommendation, W3C, 2014. http://www.w3.org/TR/rdf11-concepts/. [21] T. Berners-Lee, R. Fielding, L. Masinter, Uniform Resource Identifier (URI): Generic Syntax, RFC 3986, IETF, 2005. URL: http://www.ietf.org/rfc/rfc3986.txt, updated by RFCs 6874, 7320. [22] S. Harris, A. Seaborne, SPARQL 1.1 Query Language, Recommendation, W3C, 2013. http: //www.w3.org/TR/sparql11-query/.