Mapping the Cyberismo content to a logic program
How to generate a logic program
To request the Cyberismo tool to generate a logic program, execute the following command in a Cyberismo project directory:
$ cyberismo calc generateThis command will generate a modular logic program in the .calc directory.
Once the logic program has been generated, all command line commands and all operations in the Cyberismo app will automatically keep the logic program up to date.
Representing a card as a logic program
The bulk of the generated logic program consists of card-speficic files that declare the fields, labels and links of the card as facts.
The attributes of cards are declared as logic program facts using a field term:
field(<card key>, <field name>, <field value>).Card keys work directly as constants in ASP encodings. Fields names are encoded as strings, and field values either as strings or integers.
If the card is not directly under the card root, a parent term is generated to declare the card key of the card in the parent directory:
parent(<child card key>, <parent card key>).Cards may be tagged with a label in the index.json file of the card. This results in the following term to be generated for each label:
label(<card key>, <label>).Finally, links between cards are declared with the link term. There are two variants of this term, one for link types that use link descriptions and another for link types that do not use link descriptions
link(<source card key>, <destination card key>, <link type name>, <link description>). (1)
link(<source card key>, <destination card key>, <link type name>). (2)| 1 | This version is used if the link type uses link descriptions |
| 2 | This version is used if the link type does not use link descriptions |
For example, the the following logic program could be generated from a card with the card key example_2. This card is a child card of example_1, and it is of the card type internal-control, it has a custom field controlImplementer, it has a label, and it is linked to another card:
field(example_2, "title", "An example control").
field(example_2, "cardType", "moduleName/cardTypes/internalControl").
field(example_2, "workflowState", "Not Required").
field(example_2, "moduleName/fieldTypes/controlImplementer", "Security champion").
parent(example_2, example_1).
label(example_2, "adoption-step-1").
link(example_2, example_3, "base/linkTypes/relatesTo").Common definitions
The logic program includes basic definitions in the file base.lp. The most important common definitions define the ancestor relationships present in the directory structure. The following common definitions are added to the logic program to make the ancestor term available for user-configured calculations, to refer to cards that are children, grandchildren, parents, or grandparents of a card in any degree.
The term
ancestor(<descendant card key>, <ancestor card key>)means that the first card is a descendant of the second card, the ancestor.
This has been implemented as follows:
ancestor(A, C) :- parent(A, C), card(A), card(B).
ancestor(A, C) :- parent(A, B), ancestor(B, C), card(A), card(B), card(C).The card term is used above to specify that the intended arguments are card keys. It is implemented by extracting keys in use from the type declarations always present for all cards:
card(C) :- field(C, "cardType", _).