wording changed
Needs can declare goals that they want to achieve in collaboration with a counterpart need. For example, one need offers a taxi ride and the other needs is looking for a ride. This situation may be described as two complementary goals by the two needs which can result in a collaboration to fulfill actually a common goal of both - perform the ride togehter as driver and client.
-As described before needs are matched based on the data in their `won:is` and `won:seeks` branches. A third type of top level branch therefore is `won:goal`. A goal consists of data graph as input suggestion for the goal and a SHACL graph that defines how the data should look like after the goal is reached. Needs try to fulfill their goals in a conversation with a counterpart need after the matching happened and a connection is opened. Needs would look on the counterpart for fitting complementary goals where the data graph would fulfill the SHACL graph of its own goal(s) and where they can fulfill the SHACL shapes graph on the counterpart with their own data graph in reverse. To fullfill two goals on both both sides one need would propose a data graph that satisfies both SHACL constraints. This data graph would usually be a combination of data graphs of goals of both sides. The other side could then accept the proposed data graph if it satisfies one of its goals and thereby form an agreement with its counterpart need.
+As described before needs are matched based on the data in their `won:is` and `won:seeks` branches. A third type of top level branch is `won:goal`. A goal consists of data graph as input suggestion for the goal and a SHACL graph that defines how the data should look like after the goal is reached. Needs try to fulfill their goals in a conversation with a counterpart need after the matching happened and a connection is opened. Needs would look on the counterpart for fitting complementary goals where the data graph would fulfill the SHACL shapes graph of its own goal(s) and where they can fulfill the SHACL shapes graph on the counterpart with their own data graph in reverse. To fullfill two goals on both both sides one need would propose a data graph that satisfies both SHACL shape graph constraints. This data graph would usually be a combination of data graphs of goals of both sides. The other side could then accept the proposed data graph if it satisfies one of its goals and thereby form an agreement with its counterpart need.
-This structure of goals can be used to agree on actions like service/API calls executed by bots that mange needs. For instance, a bot could create a need that describes the input data for a certain API call (e.g. organize a ride and a call taxi) in its goals SHACL shape graph (e.g. specifying that there must be at least be a pickup location and optionally a time provided). It may for example use its own data graph in the goal to specify that the default time for pickup is in 10 minutes from now.
+This structure of goals can be used to agree on actions like service/API calls executed by bots that mange needs. For instance, a bot could create a need that describes the input data for a certain API call (e.g. organize a ride and a call taxi) in its goals SHACL shape graph (e.g. specifying that there must be at least be a pickup location and optionally a time provided).
### Declaring Goals
