/Knowledge-Base

This repository is intended for sharing our current understanding and getting feedback on the proposed architecture, structure and functionalities of the KB as well as related look & feel. Comments and issues related to the Knowledge Base shall be provided via issue tracker of this repository

FAIRiCUBE Knowledge Base

This repository is intended for sharing our current understanding and getting feedback on the proposed architecture, structure and functionalities of the KB as well as related look & feel. Comments and issues related to the Knowledge Base shall be provided via issue tracker of this repository

Scope of the KB

Based on needs, experience and understanding of project use cases (UC), the Knowledge Base is a toolkit to enable appropriate knowledge of how to apply algorithms and ML techniques to solve UC’s and similar demands.
The core task of the Knowledge Base (KB) is to provide to the community a set of tools, documents, algorithms, code, tips and tricks, mistakes to avoid, examples of use and so on.
Users interact with the KB via user interface (can read static content, use the query tool to retrieve KB resources and access related metadata). Authorized users (currently only partners) can provide descriptions of their resources through MD form.

Structure of the KB

KB structure

Governance of the KB content:

During the project lifetime:

  • Only EPSIT has write access for web page static content.
  • Regarding the partners’contributions:
    • Documentation of a/p resources (algorithms, pipelines, preprocessing etc) shall be provided through related a/p metadata. While currently this happens through a dedicated GitHub form, we are now creating a web form for the a/p MD ingestion (this will also be helpful in possible uptake from other projects e.g., easily provide authentication)
    • Other documentation shall be provided opening issues in this repository (e.g., with text and highlights to include in the UCs section, links to own repositories’ documentation etc...)

After the end of the project:

  • Long-term exploitation of the KB will be clearer once the long-term exploitation of the HUB has been agreed.
  • In our current vision the contributions by other projects should follow procedure described above:
    • authenticated users’ description of a/p resources via metadata web form. The MD will mandate information about the metadata author to easily differentiate project partners resources from other contributions.
    • Other documentation provided via issues in a dedicated GitHub repository (e.g., linked by the KB landing page)