Skip to content
Mahesh Maan edited this page Aug 5, 2021 · 4 revisions

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).

Component layer

The bottom layer contains individual components, each of which do one particular thing. One of these components, for example, is the patent database. Other examples are patent classifiers, rankers, consolidators, etc.

Each component does one well-defined operation. One of the simplest component could be a publication date filter. Give it a list of patents and a cut-off date and it will let only those patents pass through which are published before (or after, depending on how it has been configured) the given cut-off date.

Components, for the most part, are agnostic about other components. They are supposed to act like lego bricks - not too useful on their own but can be strung together to make something useful.

In the PQAI code, the components can be found in the /core/ folder.

Plugin layer

This layer houses plugins. Plugins make use of components from the bottom layer to do something meaningful, e.g., prior-art search.

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.

In PQAI code, the plugins can be found in the /plugins/ folder.

API layer

This layer is like a reception counter. 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.

Clone this wiki locally