Architecture
PQAI has a 3-layer architecture. Think of them as a vertical stack with one layer at the bottom (component layer), one in the middle (plugin layer), and one on the top (web API layer). The top layer depends on the middle layer, which in turn depends on the bottom layer.
Let’s look at each of these layers one by one, starting from the bottom-most layer, i.e. the component layer.
This layer houses individual components. They are nothing but Python modules. In the PQAI codebase, they reside in the /core/ directory.
Each module takes the form of a single Python file, and in some cases, some assets such as ML models. The assets are all stored in the /models/ directory and that is where the components look for them.
Each component does one specific thing. For instance, one of the components is a patent database. As the name suggests, it abstracts a patent data storage. Other examples of modules are patent classifiers, rankers, consolidators, etc.
The components are defined by their input-output characteristics. Example: a publication date filter components. Give it a set of patents, plus a cut-off date, and it will return a subset of patents, which will have only those patents which were published before the given date.
The most important thing about components is that for the most part, they are agnostic about other components. They are supposed to act like Lego bricks - they can be strung together to make a number of different things.
This layer houses plugins, which reside in the /plugins/ directory in the PQAI codebase. Think of a plugin as a “system” which combines components in a specific manner. Data flows from one component to another is dictated by the plugin code.
Each plugin resides in its own directory. Plugins represent self-contained apps, e.g., a prior-art search tool. They use components from the bottom to do their job, but they can have any amount of their own code too. They expose their functionality to the upper layer (API layer) by exposing Flask routes.
This layer is like a reception counter. Technically, it’s a Flask server. It exposes a web API though which the plugins can be accessed through HTTP requests. Each plugin defines one or more routes which are read and incorporated by the API layer.
In the PQAI code, this layer is defined by the server.py file.
Different modules and plugins read global set-up parameters from a common configuration file. This file is present in the /config/ directory in the PQAI codebase and is named config.py. Different flags or variables can be set in here to control how the modules or plugins work. One example of configuration is to force (or avoid) use of GPU. Other configuration include access control parameters, for example.