update workflow_interface 101 to new api

Signed-off-by: kta-intel <[email protected]>

openfl-tutorials/experimental/Workflow_Interface_101_MNIST.ipynb → openfl-tutorials/experimental/Workflow_API_101_MNIST.ipynb

@@ -6,8 +6,8 @@
    "id": "14821d97",
    "metadata": {},
    "source": [
-    "# Workflow Interface 101: Quickstart\n",
-    "[![Open In Colab](https://colab.research.google.com/assets/colab-badge.svg)](https://colab.research.google.com/github/intel/openfl/blob/develop/openfl-tutorials/experimental/Workflow_Interface_101_MNIST.ipynb)"
+    "# Workflow API 101: Quickstart\n",
+    "[![Open In Colab](https://colab.research.google.com/assets/colab-badge.svg)](https://colab.research.google.com/github/intel/openfl/blob/develop/openfl-tutorials/experimental/Workflow_API_101_MNIST.ipynb)"
    ]
   },
   {
@@ -16,7 +16,7 @@
    "id": "bd059520",
    "metadata": {},
    "source": [
-    "Welcome to the first OpenFL Experimental Workflow Interface tutorial! This notebook introduces the API to get up and running with your first horizontal federated learning workflow. This work has the following goals:\n",
+    "Welcome to the first OpenFL Experimental Workflow API tutorial! This notebook introduces the API to get up and running with your first horizontal federated learning workflow. This work has the following goals:\n",
     "\n",
     "- Simplify the federated workflow representation\n",
     "- Help users better understand the steps in federated learning (weight extraction, compression, etc.)\n",
@@ -39,7 +39,7 @@
    "id": "a7989e72",
    "metadata": {},
    "source": [
-    "The workflow interface is a new way of composing federated learning expermients with OpenFL. It was borne through conversations with researchers and existing users who had novel use cases that didn't quite fit the standard horizontal federated learning paradigm. "
+    "The workflow API is a new way of composing federated learning expermients with OpenFL. It was borne through conversations with researchers and existing users who had novel use cases that didn't quite fit the standard horizontal federated learning paradigm. "
    ]
   },
   {
@@ -57,7 +57,7 @@
    "id": "4dbb89b6",
    "metadata": {},
    "source": [
-    "First we start by installing the necessary dependencies for the workflow interface"
+    "First we start by installing the necessary dependencies for the workflow API"
    ]
   },
   {
@@ -223,7 +223,7 @@
     "scrolled": true
    },
    "source": [
-    "Now we come to the flow definition. The OpenFL Workflow Interface adopts the conventions set by Metaflow, that every workflow begins with `start` and concludes with the `end` task. The aggregator begins with an optionally passed in model and optimizer. The aggregator begins the flow with the `start` task, where the list of collaborators is extracted from the runtime (`self.collaborators = self.runtime.collaborators`) and is then used as the list of participants to run the task listed in `self.next`, `aggregated_model_validation`. The model, optimizer, and anything that is not explicitly excluded from the next function will be passed from the `start` function on the aggregator to the `aggregated_model_validation` task on the collaborator. Where the tasks run is determined by the placement decorator that precedes each task definition (`@aggregator` or `@collaborator`). Once each of the collaborators (defined in the runtime) complete the `aggregated_model_validation` task, they pass their current state onto the `train` task, from `train` to `local_model_validation`, and then finally to `join` at the aggregator. It is in `join` that an average is taken of the model weights, and the next round can begin.\n",
+    "Now we come to the flow definition. The OpenFL Workflow API adopts the conventions set by Metaflow, that every workflow begins with `start` and concludes with the `end` task. The aggregator begins with an optionally passed in model and optimizer. The aggregator begins the flow with the `start` task, where the list of collaborators is extracted from the runtime (`self.collaborators = self.runtime.collaborators`) and is then used as the list of participants to run the task listed in `self.next`, `aggregated_model_validation`. The model, optimizer, and anything that is not explicitly excluded from the next function will be passed from the `start` function on the aggregator to the `aggregated_model_validation` task on the collaborator. Where the tasks run is determined by the placement decorator that precedes each task definition (`@aggregator` or `@collaborator`). Once each of the collaborators (defined in the runtime) complete the `aggregated_model_validation` task, they pass their current state onto the `train` task, from `train` to `local_model_validation`, and then finally to `join` at the aggregator. It is in `join` that an average is taken of the model weights, and the next round can begin.\n",
     "\n",
     "![image.png](attachment:image.png)"
    ]
@@ -670,7 +670,7 @@
    "metadata": {},
    "source": [
     "# Congratulations!\n",
-    "Now that you've completed your first workflow interface quickstart notebook, see some of the more advanced things you can do in our [other tutorials](broken_link), including:\n",
+    "Now that you've completed your first workflow API quickstart notebook, see some of the more advanced things you can do in our [other tutorials](broken_link), including:\n",
     "\n",
     "- Using the LocalRuntime Ray Backend for dedicated GPU access\n",
     "- Vertical Federated Learning\n",