Glossary folder structure

[balteravishay]

This PR proposes an initial folder structure and a set of definitions, for the foundation's glossary.

The intent is to merge the glossary content to the SKF Knowledge Graph, hence the structure should be easy to traverse using automation script and indexed within the SKF platform.

[copying @ran-dall 's comment]: The design we propose here is a directory structure (no more than 1 ~ 2 levels deep) that ends with a directory for the term (e.g., Application Security/Web/Cross-Site Scripting (XSS)/OSWAP.md) with one markdown file named per source.

In response to some of the comments on this PR, we're starting a discussion around style guide for the glossary with the following google doc: https://docs.google.com/document/d/1AWhip4fGj7Ms1-YD3eeHh-2M_nWT_4BamW3dBwg91tA/edit

[thiswayman]

It looks like the approach is a folder per term and then a file per each source.

I expected a single file per term with all sources in that single file.

If we have some front end for someone to use or a file that pulls all these terms together, that expectation probably doesn't matter. However, it does seem to result in a lot of similarly named files that might be prone to error, and without the front-end experience, a lot of clicking for the user.

Just wanted to make sure this is the intent as well as understand the interaction from a user standpoint. Happy to continue review of the actual content beyond this though.

[ran-dall]

Sorry, I meant to comment on the other PR yesterday.

@jwayman Yes, this was the intention. After confirming with the SKF team, this intends to be merged into the SKF Knowledge Graph...however, that requires us to think about this atomically. So I suggested to @balteravishay that we establish a directory structure (no more than 1 ~ 2 levels deep) that ends with a directory for the term (e.g., Application Security/Web/Cross-Site Scripting (XSS)/OSWAP.md) with one markdown file named per source.

FWIW yesterday, it also was brought to my attention that the directory structure might also be a point of friction or confusion. I think it's a valid concern; however, I think that the directory structure is intended to be extremely straightforward and pre-established to the point where I hope this doesn't become a stopper for folks.

[antonyfaris]

+1 to the proposed organization in this PR. Tomorrow I will try to generate some json/yml files from this for the glossary frontend.