|
| 1 | +# Wrapper development |
| 2 | + |
| 3 | +SimPhoNy Wrappers are software components that transform data from the |
| 4 | +assertional-knowledge form to the data structures of |
| 5 | +other software and back. Wrappers are abstracted to users as |
| 6 | +[sessions](../usage/sessions/introduction.ipynb), which may be viewed |
| 7 | +as "boxes" where ontology individuals can be stored. |
| 8 | + |
| 9 | +Sessions work in a way similar to databases. To start using them, one first |
| 10 | +has to “open” or “connect” to them. After that, changes can be made on the |
| 11 | +data they contain, but such changes are not permanent until a “commit” is |
| 12 | +performed. When one finishes working with them, the connection should be |
| 13 | +“closed”. Unconfirmed changes are lost when the connection is “closed”. |
| 14 | + |
| 15 | +Therefore, developing a wrapper involves crafting: |
| 16 | + |
| 17 | +- An abstraction of the concepts handled by the software as terminological |
| 18 | + knowledge, that can then be used to represent the information as assertional |
| 19 | + knowledge. |
| 20 | +- A database-like interface that is used by SimPhoNy to communicate with the |
| 21 | + software. |
| 22 | + |
| 23 | +For the latter, SimPhoNy defines the _Wrapper API_, that must be implemented by |
| 24 | +the developer. |
| 25 | + |
| 26 | +## `Wrapper` abstract class |
| 27 | + |
| 28 | +The database-like interface used by SimPhoNy to communicate with the software, |
| 29 | +called _Wrapper API_, is defined by the `simphony_osp.development.Wrapper` |
| 30 | +abstract class. Objects belonging to the `Wrapper` class are indirectly |
| 31 | +controlled by the interactions between the user and session objects, as the |
| 32 | +diagram below shows. |
| 33 | + |
| 34 | +<figure style="display: table; text-align:center; margin-left: auto; margin-right:auto"> |
| 35 | + |
| 36 | + |
| 37 | + |
| 38 | +<figcaption style="display: table-caption; caption-side: bottom; text-align:center"> |
| 39 | + |
| 40 | +_[UML object diagram](https://www.uml-diagrams.org/class-diagrams-overview.html#object-diagram) |
| 41 | +showing the objects involved in the SimPhoNy wrapper mechanism that are |
| 42 | +relevant from a developer's perspective._ |
| 43 | + |
| 44 | +</figcaption> |
| 45 | + |
| 46 | +</figure> |
| 47 | + |
| 48 | +SimPhoNy makes use of the [RDFLib](https://github.com/RDFLib/rdflib) library to |
| 49 | +handle [RDF](https://www.w3.org/TR/rdf-concepts/) data. Thus, the session is in |
| 50 | +fact an interface to an |
| 51 | +[RDFLib Graph](https://rdflib.readthedocs.io/en/stable/intro_to_graphs.html). |
| 52 | +As the user interacts with the session, triples from the underlying graph are |
| 53 | +queried, added or removed. |
| 54 | +The library also provides a further abstraction, the |
| 55 | +[store](https://rdflib.readthedocs.io/en/stable/_modules/rdflib/store.html). |
| 56 | +Stores abstract [triplestores](https://en.wikipedia.org/wiki/Triplestore), a |
| 57 | +kind of database that can store collections of RDF graphs in the form of |
| 58 | +triples. SimPhoNy implements a special kind of store that is designed to |
| 59 | +communicate with SimPhoNy wrapper objects, the final pieces of the chain. |
| 60 | + |
| 61 | +The **wrapper object's interface is what the developer must implement** in |
| 62 | +order to make the software interoperable with SimPhoNy. As pointed out in the |
| 63 | +diagram, there are several RDF Graph objects, session objects and lists (of |
| 64 | +[ontology individual objects](../usage/assertional_knowledge.ipynb#Ontology-individual-objects)) |
| 65 | +that are accessible from the wrapper object. Those offer several ways for the |
| 66 | +developer to retrieve the inputs from the user and translate them into inputs |
| 67 | +for the software, or conversely, reflect the outputs from the software into the |
| 68 | +user's session. |
| 69 | + |
| 70 | +Perhaps the most important of all is the **base graph**. The base graph is an |
| 71 | +[RDFLib Graph](https://rdflib.readthedocs.io/en/stable/intro_to_graphs.html) |
| 72 | +that is accessible from the wrapper object, and must be kept in sync with the |
| 73 | +software's data structures at all times, as it constitutes their |
| 74 | +**RDF representation**. The goal of the SimPhoNy Wrapper API is to facilitate |
| 75 | +this task to the developer. |
| 76 | + |
| 77 | +```{note} |
| 78 | +If an |
| 79 | +[RDFLib store plug-in](https://rdflib.readthedocs.io/en/stable/plugin_stores.html) |
| 80 | +already exists for a specific software, then it can be trivially reused to |
| 81 | +implement a SimPhoNy wrapper. Just create a graph using the plug-in, and set it |
| 82 | +as the base graph for the SimPhoNy wrapper object. |
| 83 | +``` |
| 84 | + |
| 85 | +## API Overview |
| 86 | + |
| 87 | +The [flowchart](https://en.wikipedia.org/wiki/Flowchart) below illustrates the |
| 88 | +**lifecycle** of a session connected to a wrapper object: from its creation to |
| 89 | +the moment it is closed. |
| 90 | + |
| 91 | +A sequence of method calls is executed as a |
| 92 | +consequence of each possible action the user can take. Each sequence is |
| 93 | +represented using a different color, and the action that triggers it is written |
| 94 | +next to its accompanying arrow, that points to the first method call in the |
| 95 | +sequence. |
| 96 | + |
| 97 | +<figure style="display: table; text-align:center; margin-left: auto; margin-right:auto"> |
| 98 | + |
| 99 | + |
| 100 | + |
| 101 | +<figcaption style="display: table-caption; caption-side: bottom; text-align:center"> |
| 102 | + |
| 103 | +_Flowchart showing the catalogue of possible user actions and how they |
| 104 | +translate to calls to the methods of the wrapper class, that the wrapper |
| 105 | +developer must implement._ |
| 106 | + |
| 107 | +</figcaption> |
| 108 | + |
| 109 | +</figure> |
| 110 | + |
| 111 | +The `Wrapper` object is spawned when the user opens the session. The `open` and |
| 112 | +`populate` methods are then subsequently called in order to gain access to the |
| 113 | +resources needed by the software and pre-populate the session with ontology |
| 114 | +individuals if necessary. After that, the session is ready to be used. The user |
| 115 | +may then access or modify the assertional knowledge (triggering the optional, |
| 116 | +low-level RDF manipulation methods), access files associated to ontology |
| 117 | +individuals belonging to the _File_ class (triggering the `load` method), |
| 118 | +add or change files, commit the changes or request the software to compute new |
| 119 | +results. When the user is done, the session is closed. |
| 120 | + |
| 121 | +## API Specification |
| 122 | + |
| 123 | +This section describes the expected behavior of all methods from the Wrapper |
| 124 | +API. |
| 125 | + |
| 126 | +### Main methods |
| 127 | + |
| 128 | +#### `open` |
| 129 | + |
| 130 | +Secure access to the resources used by your software. For example: |
| 131 | + |
| 132 | +- spawn simulation engine objects |
| 133 | +- open a connection to a database |
| 134 | +- open files that need to be accessed |
| 135 | + |
| 136 | +```{eval-rst} |
| 137 | +.. autofunction:: simphony_osp.development.Wrapper.open |
| 138 | +``` |
| 139 | + |
| 140 | +#### `populate` |
| 141 | + |
| 142 | +Populate the base session so that it represents the initial state of the |
| 143 | +software. For example: |
| 144 | + |
| 145 | +- given a path to a simulation settings file, |
| 146 | + populate the session with entities |
| 147 | + descibing the contents of the file |
| 148 | +- populate the session with dataset |
| 149 | + individuals after connecting to a data |
| 150 | + repository |
| 151 | + |
| 152 | +```{eval-rst} |
| 153 | +.. autofunction:: simphony_osp.development.Wrapper.populate |
| 154 | +``` |
| 155 | + |
| 156 | +#### `commit` |
| 157 | + |
| 158 | +Reflect user's changes on the session in the software's data structure. For |
| 159 | +example: |
| 160 | + |
| 161 | +- configure a simulation's settings |
| 162 | +- update an SQL table |
| 163 | +- modify a file |
| 164 | + |
| 165 | +```{eval-rst} |
| 166 | +.. autofunction:: simphony_osp.development.Wrapper.commit |
| 167 | +``` |
| 168 | + |
| 169 | +The difference with respect to the `compute` method is that this method should |
| 170 | +not update the content's of the session itself. |
| 171 | + |
| 172 | +#### `close` |
| 173 | + |
| 174 | +Release the resources used by your software. For example: |
| 175 | + |
| 176 | +- terminate the running process |
| 177 | +- close the connection to a database |
| 178 | +- close files that are not needed |
| 179 | + |
| 180 | +```{eval-rst} |
| 181 | +.. autofunction:: simphony_osp.development.Wrapper.close |
| 182 | +``` |
| 183 | + |
| 184 | +#### `compute` _(optional)_ |
| 185 | + |
| 186 | +Perform a computation using the data currently present on the software's data |
| 187 | +structures and update the base session to reflect the changes afterwards. |
| 188 | +For example: |
| 189 | + |
| 190 | +- run a simulation |
| 191 | + |
| 192 | +```{eval-rst} |
| 193 | +.. autofunction:: simphony_osp.development.Wrapper.compute |
| 194 | +``` |
| 195 | + |
| 196 | +#### `__init__` _(optional)_ |
| 197 | + |
| 198 | +The `__init__` method allows the user to provide extra |
| 199 | +parameters in the form of JSON-serializable keyword arguments. |
| 200 | + |
| 201 | +```{note} |
| 202 | +This method does not appear on the flowchart for simplicity, but is executed |
| 203 | +before the `open` method. |
| 204 | +``` |
| 205 | + |
| 206 | +```{eval-rst} |
| 207 | +.. autofunction:: simphony_osp.development.Wrapper.__init__ |
| 208 | +``` |
| 209 | + |
| 210 | +### File manipulation methods |
| 211 | + |
| 212 | +#### `load` _(optional)_ |
| 213 | + |
| 214 | +Receive an identifier of a file individual and retrieve the corresponding file. |
| 215 | + |
| 216 | +```{eval-rst} |
| 217 | +.. autofunction:: simphony_osp.development.Wrapper.load |
| 218 | +``` |
| 219 | + |
| 220 | +#### `save` _(optional)_ |
| 221 | + |
| 222 | +Receive an identifier of a file individual and a file handle and save the |
| 223 | +contents somewhere. |
| 224 | + |
| 225 | +```{eval-rst} |
| 226 | +.. autofunction:: simphony_osp.development.Wrapper.save |
| 227 | +``` |
| 228 | + |
| 229 | +#### `delete` _(optional)_ |
| 230 | + |
| 231 | +Receive the identifier of a file individual and delete the stored file. |
| 232 | + |
| 233 | +```{eval-rst} |
| 234 | +.. autofunction:: simphony_osp.development.Wrapper.delete |
| 235 | +``` |
| 236 | + |
| 237 | +### RDF manipulation methods |
| 238 | + |
| 239 | +These methods operate at the RDF triple level. When a triple (or pattern) is |
| 240 | +added or removed, they can intercept the operation and decide whether the |
| 241 | +triple should go to the base graph or not when a commit operation is executed. |
| 242 | +The intercepted triples get stored in a buffer that is accessible during the |
| 243 | +commit operation. |
| 244 | + |
| 245 | +They are useful when one wants to prevent storing the same information twice |
| 246 | +(in the base graph and in the software's data structure). |
| 247 | + |
| 248 | +#### `add` _(optional)_ |
| 249 | + |
| 250 | +```{eval-rst} |
| 251 | +.. autofunction:: simphony_osp.development.Wrapper.add |
| 252 | +``` |
| 253 | + |
| 254 | +#### `remove` _(optional)_ |
| 255 | + |
| 256 | +```{eval-rst} |
| 257 | +.. autofunction:: simphony_osp.development.Wrapper.remove |
| 258 | +``` |
| 259 | + |
| 260 | +#### `triples` _(optional)_ |
| 261 | + |
| 262 | +```{eval-rst} |
| 263 | +.. autofunction:: simphony_osp.development.Wrapper.triples |
| 264 | +``` |
| 265 | + |
| 266 | +## Packaging template |
| 267 | + |
| 268 | +This page is meant to offer a mid-level view on what SimPhoNy Wrappers are |
| 269 | +and how do they work. If you are interested in developing one, you may find a |
| 270 | +template for building and packaging a wrapper in the |
| 271 | +[wrapper development repository](https://github.com/simphony/wrapper-development). |
| 272 | + |
| 273 | +```{warning} |
| 274 | +You are reading the documentation of a release candidate version of |
| 275 | +SimPhoNy. |
| 276 | +
|
| 277 | +Some details have not yet been fully documented. In particular, the |
| 278 | +contents of the |
| 279 | +[wrapper development repository](https://github.com/simphony/wrapper-development) |
| 280 | +are still outdated. Consider using the |
| 281 | +[SimLAMMPS wrapper code](https://github.com/simphony/simlammps) |
| 282 | +as a template instead until the repository is updated. |
| 283 | +``` |
0 commit comments