build details

Show: section status errors & todos local changes recent changes last change in-page changes feedback controls

The Knowledge and Activity Graph Environment

Modified 2020-03-04 by Susi


Modified 2020-03-04 by Susi

Every page, on every book, should have a ‘Knowledge Box’ - also called ‘Knowledge and Activity Graph’. It’s the blue box you see above. In markdown, a knowledge box looks like this:

<div class='requirements' markdown="1">

Requires: Important prerequisite XY

Requires: ...

Results: Infinite wisdom



Modified 2020-03-04 by Susi

Knowledge boxes give structure to the duckumentation. How do you know where to start? For example by following back links in knowledge boxes! Or by having an automated system follow back those references for you.

Also, imagine if dead references or circular dependencies were detected automatically. Authors could fix this right away, and you would have an easier time navigating the duckumentation. So: Add a knowledge box!


Modified 2020-03-04 by Susi

Here are dos and don’ts how to write useful knowledge boxes:

One knowledge box per page. (Might change in the future.)

Organize your pages in a way that one knowledge box per page makes sense. Optimally, one page should be about one distinct topic, or describe how to create one distinct thing. You can use most of the existing duckumentation as reference for a good “topic granularity”.

Use ‘Requires:’, ‘Recommended:’ and ‘Results:’ markers.

Start each line in a knowledge box with one of them.

In “Requires:” lines, link to pages that provide the requirement whenever possible.

Link only to CSS-identifiers of other pages, not specific sections on that page. (This might change in the future.)

One requirement or result per line.

A list of multiple requirements in one line.

Do not: Unit C-3 - Setup Duckiebot SD Card

Use short descriptive texts, with good keywords that identify the requirement or result.

Optimal: Use the same description as in other knowledge boxes, when referring to the same entity. (Exception: If the other page’s description violates these guidelines.)

Long texts, with many unrelated keywords.

Do not:

Results: A correctly configured Duckiebot SD card in configuration DB18. After assembling the Duckiebot, this will allow you to start it, connect to the internet, and get going.

Requires: Software-X, with all requirements for the ROS example

Put all text that does not directly describe the requirement between round brackets **. Omit unnecessary words.


Results: A configured Duckiebot SD card in configuration DB18. (After assembling the Duckiebot, this will allow you to start it, connect to the internet, and get going.)

Requires: Software-X ( with all requirements for the ROS example)

For estimated time needed, use a ‘Requires:’ marker.

For example:

 Requires: Approximately 1 hour 30 minutes.

(“1h30”, or “1h, 30 min” works as well.)

If you want, you can use the instructions here to pick a name of an entity that the EOD system knows already, from the data files, or add a new entity there via pull request.

** This might change in the future.

‘How to speak the language of the graph’

Modified 2020-03-04 by Susi

To refer to an entity that is already known by the knowledge-box parsing algorithm:

  • 1) First, open one of two files:

  • topics.yaml if you want to refer to a specific topic

  • stuff.yaml if you want to refer to an object (like a Duckiebot) or a piece of software.

  • 2) Scan that file for the thing you are looking for. (ctrl-F for a few keywords.)

    • 2a) If it exists:

      • Copy the string after name: into your knowledge box line, after a Requires: or Results: marker (possibly in addition to a link to a page).
      • You can add the keyword “installed” or “installation” to refer to a (software) item. Add the word “knowledge” to ensure to refer to a topic. (This is crucial, for example, to distinguish knowing ROS vs. having ROS installed. )
      • In case you opened the second .yaml file in step 1: If your “item” needs to have one of the options listed after all_possible_options:, add the text of those options to your knowledge box line.
    • 2b) If what you are looking for does not exist yet:

      • Edit the respective file on GitHub, topics.yaml or stuff.yaml, to add the entity you need. Put something unique as shortname (only lowercase letters, numbers and underscores) and a good, short-ish name for it.
      • Open a pull request with your change. Write me at kellersu -at- student -dot- ethz -dot- ch in case it is not accepted soon.
      • Refer to the entity as described in 2a).


  • The knowledge boxes are parsed into a graph. This can happen in multiple ways.
  • Because text matching is currently fairly unreliable, a previous version of the graph is stored in .yaml and .csv files. This graph can be matched to the current knowledge boxes, to update it so that it maps the current version of the book.
  • The data entries in “topics” (knowledge) and “items” (mostly physical objects or software) are what is matched to requirements and results in knowledge boxes. If you use the exact name of an entity listed there (the “name” field), plus the exact wording of any item options that you want to refer to, it is certain to be recognized by the system as that entity.
  • To visualize the graph, see here (and here).

Suggestion for an alternative knowledge box format

Modified 2020-03-04 by Susi

See here