Specs for initial compiler script #3

New Issue

ronent · 2023-08-28T07:49:52-05:00

ronent commented

2023-08-28 07:49:52 -05:00

Background

The idea is to set up a first version of the compiler script that will take as input a Discourse Graph folder, and will output (1) a compilation log with errors and warnings if the input isn’t valid (2) the output artifact. For the initial version, the output artifact will be simply a Markdown file with the graph rendered as text.

Later on we can add various DGF layers like flags, curation, votes, etc.

Input

cmd line params

npm run compile_script --TARGETDIR --CONFIG

For the example below, TARGETDIR=dgraph/Example Graph (we should probably remove the space chars from Example Graph)
CONFIG will have the different param settings (possibly empty for now)
Perhaps there should also be a grammar file that lists the valid node and edge types and syntax

Output

Compilation log: warnings, errors - in this case all clear and conforms to grammar
Markdown version of Discourse Graph:

- {QUE} Example Question
    - informed-by {CLM} Example Claim
        - opposed-by {EVD} Example Evidence 2
        - supported-by {EVD} Example Evidence
            - from-source {SRC} Example Source 1
    - informed-by {CLM} Example Claim 2
- {QUE} Example Question 2
    - generated-by {CLM} Example Claim 2

Notes:

For all the relations, I flipped the relation direction from Obsidian - in Obsidian we have CLM informs QUE, EVD supports CLM, etc. For the markdown version it’s more legible to have the opposite direction, QUE informed-by CLM, etc. That way we have the QUE nodes on the top which is easiest reading order.
As to the order we should cycle through QUE nodes (what order should they appear in the markdown file) - QUE with generated-by come after QUE that don’t, otherwise I think we don’t have constraints on order. Ideally if there is a dependency between questions, we want that reflected in the markdown version. (dependent questions come after the questions they’re dependent on)
We can assume for now that there are no subdirectories in the folder, that will probably change as we advance.

### Background The idea is to set up a first version of the compiler script that will take as input a Discourse Graph folder, and will output (1) a compilation log with errors and warnings if the input isn’t valid (2) the output artifact. For the initial version, the output artifact will be simply a Markdown file with the graph rendered as text. Later on we can add various DGF layers like flags, curation, votes, etc. ### Input cmd line params ```bash npm run compile_script --TARGETDIR --CONFIG ``` - For the example below, `TARGETDIR=dgraph/Example Graph` (we should probably remove the space chars from `Example Graph`) - `CONFIG` will have the different param settings (possibly empty for now) - Perhaps there should also be a grammar file that lists the valid node and edge types and syntax ### Output 1. Compilation log: warnings, errors - in this case all clear and conforms to grammar 2. Markdown version of Discourse Graph: ```markdown - {QUE} Example Question - informed-by {CLM} Example Claim - opposed-by {EVD} Example Evidence 2 - supported-by {EVD} Example Evidence - from-source {SRC} Example Source 1 - informed-by {CLM} Example Claim 2 - {QUE} Example Question 2 - generated-by {CLM} Example Claim 2 ``` **Notes:** - For all the relations, I flipped the relation direction from Obsidian - in Obsidian we have CLM informs QUE, EVD supports CLM, etc. For the markdown version it’s more legible to have the opposite direction, QUE informed-by CLM, etc. That way we have the QUE nodes on the top which is easiest reading order. - As to the order we should cycle through QUE nodes (what order should they appear in the markdown file) - QUE with generated-by come after QUE that don’t, otherwise I think we don’t have constraints on order. Ideally if there is a dependency between questions, we want that reflected in the markdown version. (dependent questions come after the questions they’re dependent on) - We can assume for now that there are no subdirectories in the folder, that will probably change as we advance.

ronent commented

2023-08-28 16:37:20 -05:00

Posting @Chegele 's questions from Slack so we have it here on record:

Looks good. I have a few questions.

Can a claim inform multiple questions?

Can evidence support/oppose multiple claims?

Yes to both. In such cases we would want it to appear multiple times for each relevant CLM/QUE, here's an updated version of the example with such a case:

- {QUE} Example Question
    - informed-by {CLM} Example Claim
        - **opposed-by {EVD} Example Evidence 2**
        - supported-by {EVD} Example Evidence
            - from-source {SRC} Example Source 1
    - informed-by {CLM} Example Claim 2
- {QUE} Example Question 2
    - generated-by {CLM} Example Claim 2
				- **supported-by {EVD} Example Evidence 2**

Assuming that each of these nodes would have additional data. Should we expect the data to follow a specific template, and will it be included in the compiled output?

They will have additional data but for now we can assume they do not. For example, in the future we might add a metadata field for each node.

Posting @Chegele 's [questions from Slack](https://daogovernance.slack.com/archives/C05KPNDN3FE/p1693254928481909) so we have it here on record: > Looks good. I have a few questions. > Can a claim inform multiple questions? > Can evidence support/oppose multiple claims? Yes to both. In such cases we would want it to appear multiple times for each relevant CLM/QUE, here's an updated version of the example with such a case: ```markdown - {QUE} Example Question - informed-by {CLM} Example Claim - **opposed-by {EVD} Example Evidence 2** - supported-by {EVD} Example Evidence - from-source {SRC} Example Source 1 - informed-by {CLM} Example Claim 2 - {QUE} Example Question 2 - generated-by {CLM} Example Claim 2 - **supported-by {EVD} Example Evidence 2** ``` > Assuming that each of these nodes would have additional data. Should we expect the data to follow a specific template, and will it be included in the compiled output? They will have additional data but for now we can assume they do not. For example, in the future we might add a metadata field for each node.

Sign in to join this conversation.