Skip to main content Link Search Menu Expand Document (external link)

Architecture and Implementation Overview

Two Services

The Ontology Manager is made of two servers/services:

  1. A Postgres Database
  2. A web backend made of:
    • A Nuxt app, using Apollo as GraphQL client
    • A Nuxt Server Middleware that is trifid-core, see trifid
    • A Nuxt Server Middleware implemented as an Express API
      • This is where the forge-specific functionality (GitHub, GitLab, …) is implemented
      • Configurable via nuxt.config.js
    • A Nuxt Server Middleware serving a GraphQL API backed by Postgres, schema generated by introspecting the pg schema


The Trifid middleware is used to allow ontology content dereferencing, meaning that if is an IRI in your ontology, you will be able to get N-Triples via content negotiation: curl -H 'Accept: application/n-triples'.

Database Objects


  • thread.headline: the PR title and proposal title used in proposals lists
    • Sample value: Change property 'wheelCount'
  • thread.iri: the IRI of the object from which the proposal originated
    • Sample value:
  • thread.body: the motivation for this proposal
    • Sample value: wheelCount currently has no type although it should be an integer
  • thread.thread_type:
    • Value: proposal
  • thread.status: a new proposal is always open, admins can then set it to one of: resolved, rejected, hidden
    • Sample value: open
  • thread.is_draft: TRUE until the proposal author submits their proposal
    • Sample value: FALSE
  • thread.proposal_object: the actual proposal content in a serialized format, cf. proposalSerializer and proposalDeserializer
  • thread.branch_name:
    • Sample value: 2019-03-12T140521.151Z

Proposals are handled by one of these two store modules depending on their type:

These store modules are responsible for loading a proposal from the DB, saving a proposal to the DB, etc.


  • A thread can either be a discussion or a proposal.
  • A thread with discussion type is a conversation, messages belong to a thread.

Extending the Ontology Manager


The only forge supported at the moment is GitHub. Implementing other forges was planned from the get-go so the project is not tightly coupled with GitHub.

Whenever the manager needs to interact with GitHub, the frontend hits the API which then deals with the GitHub API. (This strategy also prevents leaking the credentials used to connect to the forge.)

./api/ contains two forge implementations:

  • github, used in the demo
  • e2e-test, a dummy implementation used by the end-to-end tests

A new backend API could be started by copying the github API and adapting the implementation of each endpoint to the new forge.

Depending on the manager configuration, the manager loads the appropriate backend.

There are a few places where this separation of forge implementations bleeds into other files, namely all the startup config things: the new forge should be detectable in nuxt config, the “env migrator” responsible for loading env variables config into the database config table, and the dummy config loaded by default.