Introduction

The Concepts & Terminology Working Group (CTWG) helps ToIP members and communities to express themselves in ways that enable others to understand what that communication intends to convey to whatever level of precision is needed.

This is important, because contributors

Mission and Scope

Contributors/users in ToIP come from many different backgrounds, have different expertise, and work in different domains. So we expect to see situations of "language confusion", i.e. in which people use words or phrases, the intension (not: intention) of which differs from the interpretation of some listeners/readers. In most cases, language confusion issues get resolved fairly easily with or without the help of a dictionary. But when it really matters, e.g. in specifications or contracts, we need more than a set of definitions. This WG aims to provide whatever support may be needed to facilitate people in the ToIP community to understand one another to the extent (level of precision) that they seek.

Conveners (add your name if you are interested to become one of the convenors)

• <we need a convenor-lead name here>
• Rieks Joosten

Interested Members (add your name and organization if you may be interested in joining this proposed WG)

• Drummond Reed
• Daniel Hardman
• Oskar van Deventer
• Scott Perry
• Shashishekhar S
• Philippe Page
• Paul Knowles
• Taylor Kendal
• Scott Whitmire
• Arjun Govind
• Vinod Panicker
• sankarshan
• Steven Milstein

Description

Context

The primary focus of the ToIP Foundation is not just on technology (e.g. cryptography, DIDs, protocols, VCs, etc.), but also on governance and on business, legal and social aspects. It is a complex and daunting mission to "construct, maintain and improve a global, pervasive, scalable and interoperable infrastructure for the (international) exchange of verified and certified data". This not only requires technology to be provided, but also actual business value to be created, and capabilities for complying with rules and requirements from different legal contexts and societies. 

C&T WG Mission

A major difficulty that ToIP seeks to overcome is "language confusion", which is perhaps the most pervasive impediment for working together across all of these domains. Many stories about this exist in various cultures, and anyone that enters the EU parliament building in Strasbourg, is reminded of this difficulty (because that building resembles the Tower of Babel as painted by Pieter Brueghel).

The mission of the proposed C&T WG is to identify and address the issues that relate to ways of thinking (mental/conceptual models) and terminology that may be an impediment for the overall mission of the ToIP Foundation.

C&T WG Fit-for-Purpose

In a similar way that the ToIP stack must be fit for purpose, the deliverables of this WG must also be fit for purpose. This means the WG needs to understand what stakeholders actually need in terms of concepts, terms and glossaries, and how such stakeholders will actually use it. Many such artifacts already exist, e.g. glossaries (of NIST, or Sovrin), terminology sections in standards (e.g. W3C VC, DID), yet this does not seem to be satisfactory: Aries RFCs can define their own terms, the CCG has recently initiated a new 'glossary effort'. 

While the currently existing artifacts are useful for people to learn about specific topics, they have no track record of resolving terminological discussions. We regularly see such discussions (e.g. in issues, e.g. did-core #4, #122) and they are lengthy, do not always get resolved, and arguments do often not refer to any glossary at all. If we want people from the different disciplines (tech, business, legal, ...) to work together, we may need a way to actually ascertain that such discussions can be resolved.

Pragmatically useful and Theoretically Sound

The fact that many glossaries exist, and initiatives keep popping up to create more, proves there is a need. At the same time, it shows that earlier efforts have not brought the benefits that people hoped for, or expected. The WG should support such initiatives in a pragmatic way, e.g. by supporting the creation of a Common Glossary that describes relevant words. Perhaps such an effort can be undertaken in concert with the aforementioned CCG effort. 

Theorists/philosophers have noted that "far too much stock has been placed in the supposed efficacy and utility of defining our terms", and provide a theory for dictionaries, definitions, and meaning. Applying such theories and adopting the results of that work has proven helpful where people, especially from different backgrounds, try to work efficiently and effectively together. The WG should therefore support the creation and maintenance of relevant, and theoretically sound conceptual models and associated terminologies.

At a later stage, when the pragmatic and theoretical work have started and progressed to some extent, the WG should propose ways in which to bring these two together.

Contributions and Example Outputs

For our purposes, we leverage a prior collaboration between Daniel Hardman of Evernym and  Rieks Joosten of TNO as well as large parts of the ToIP Glossary WG proposal from Dan Gisolfi at IBM (see the details in further sections below). A model for some of the deliverables of this WG is one or more websites that would resemble the Legal Dictionary. This site not only provides a definition of various terms, but also a brief description of their backgrounds, various use-cases that exemplify the relevance of (and distinctions made by) the terms, and other useful information.

C&T WG Tasks

The envisaged tasks of this WG consist of

• creating and maintaining a list of stakeholders, their objectives, the issues they face regarding concepts and terminology, and the products or services that they might use for resolving such issues.
• specifying, creating and maintaining a product framework, inspired by the Legal Dictionary, that can include content helpful to understanding specific concepts and terminology.
• specifying and operating a process for maintaining and improving the contents of that framework (a proposal for which is under construction).
• specify other products/services that the WG will provide, or organize to be provided, so as to help stakeholders to address their issues.
• specifying and operating processes for maintaining (the contents of) such products/services.

Governance

The C&T WG will have a governing committee (GC) that shall:

1. oversee the work that is being done to further/fulfill its mission as described above, which consists at least of the following:
   1. function, at least initially, as a modeling committee (see below) for the mental model on 'Mental Models', and how to CRUD (create, read, update, delete) them. 
   2. define the artefacts that constitute the 'body of knowledge' (BoK) of the C&T WG, which document all mental models and terminology that the WG governs.
   3. define artefacts that may be considered for CRUDding the BoK of the C&T WG mental models, as well as criteria that must be satisfied in order for such artefacts to be considered.
   4. define the process that considers  such artefacts (that satisfy the criteria), and produces a decision saying whether or not to update the BoK, and if so, how the BoK will be updated.
   5. define concrete artefacts (e.g. web pages, ...) that are to be generated from the BoK. Such artefacts are part of the results/products that the C&T WG aims to produce.
   6. ensure that technology is available that automatically generates and updates such artefacts from the BoK (particularly as it is changed).
2. connect/liaise to the other WGs within ToIP as well as groups/organizations outside ToIP, e.g. relevant W3C groups, DIF, etc. for the purpose of furthering the work of both the ToIP C&T WG and that of the other groups, insofar that is considered useful.

The C&T WG will have at least one modeling committee (MC) that shall:

1. oversee the construction and maintenance of mental models that are relevant within ToIP, consisting of carefully defined concepts, relations between them and the constraints involved.
2. choose labels for these models that are appropriate within the scope of the MC's own work. 
3. associated each mental model with stories (visions, use-cases, ...) that explain it, identify pitfalls, etc.  in terms of what is understandable in other domains (e.g. legal, business, social, and so on), using labels that exist in that context if they nicely map onto concepts or relations, or otherwise introducing/suggesting other labels.

Working Group Charter

1. Develop and maintain a high-quality corpus of terminology (CoT) that covers the needs of the ToIP community.
2. Develop a process whereby this corpus can be:
1. Curated, based on evidence and using expert opinion, such that concepts, relations between concepts and constraints can be
   1. carefully defined,
   2. assigned an identifier (name/number/label) to distinguish it from any other concept in the corpus,
   3. mapped onto terms that are defined and/or commonly accepted in various relevant domains/contexts,
   4. their usage and relevance documented from organic sources,
   5. their status adjudicated into working, preferred, accepted, superseded and deprecated
2. Enhanced in a collaborative, open, and fair manner by interested community members.
3. Versioned.
4. Published in different ways (e.g. as a glossary, concept map, use-case stories ...), for specific purposes (e.g. education, reference, , ...) by different means (e.g. a PDF, a website, presentations/webinars, ...) and as needed by different audiences/stakeholders or domains (e.g. business domains, architectural domains, ...)
5. Promoted as a valuable public resource and an influence for convergence and excellence.
3. Train and organize volunteers so the initiative develops sustainable long-term momentum.
4. Disseminate/promote the work accross ToIP WGs, and other relevant audiences.

Requirements

The Corpus of Terminology MUST have:

1. Source control and build processes managed in github.
2. A well defined syntax for contributing concepts/relations, and for each of them an identifier by which it can be identified within the scope of the Corpus.
3. A well defined syntax for attributing terms to such (established) concepts/relations for specific contexts/domains.
4. A well defined CI/CD process that includes auto sorting of terms and concepts. (??? RJ: I'm not sure what this means.)
5. A simple process for contributing further content.
6. A simple publicly accessible website, containing at least the Corpus-identifiers and their definitions, possibly inspired by the 'Legal Dictionary'.
7. A PDF document for every published version, containing at least the Corpus-identifiers and their definitions.

The Corpus MUST NOT have:

1. A skill requirement on programming knowledge as that will reduce contributors.

The Corpus SHOULD be:

1. Reusable and easy to leverage in TIP repos.
2. Usable for language translation via separate self-organized language specific repos. These repos should be aggregators of the baseline glossary and any TIPs.
3. Usable for mapping its identifiers/terms to those in use in other contexts/domains.
4. Consumable at the RAW content level (.md files) by external groups who wish to render content in a different manner.

Solution Approaches

We SHOULD:

1. Use a github repo to manage the corpus.
1. Consider using a Creative Commons license instead of an Apache license; it may be more appropriate.
2. Require DCO/IPR for contributors to the repo. Anybody who complies with the DCO/IPR requirements can submit to the corpus by raising a PR.
3. No need to manually maintain metadata about who edited what, when. We have commit history and git praise/blame.
4. Use github issues to debate decisions about term statuses. Anybody can raise an issue.
2. Use existing pervasive opens source documentation tools such as mkdocs, Docusaurus, or GitHub Pages:
1. Each concept is described in a separate markdown doc that conforms to a simple template (see below). Concepts link to related concepts.
2. Each term is a separate markdown doc that conforms to a different simple template (see below again). Terms label concepts; links from concepts to terms remain implicit in the markdown version of the data, to avoid redundant editing. Having terms and concepts as separate documents that cross-link allows for synonyms, antonyms, preferred and deprecated and superseded labels for the same concept, localization, and so forth. They also allow for the peaceful co-existence of multiple terminologies (= sets of terms, namespaces, …)
3. Each context glossary is a separate markdown doc that conforms to another different simple template (see below once again). A glossary is an alphabetic list of terms relating to a specific subject, or for use in a specific domain, with explanations. The markdown document specifies the scope of the glossary, and the selection criteria for terms. 
4. Provides extendable CI/CD pipeline for the repo, and write unit tests to enforce any process rules, quality checks, and best practices the WG adopts.
5. CI/DI process should enable live website and refreshed PDF document after each approved and merged PR.
3. Define the criteria for giving a term the statuses. What are grounds for saying it is deprecated, superseded, etc. (Criteria are published in a doc in the repo, so debating changes to criteria means a PR and github issue.)
4. Create a release process guidelines.
1. Define difference between live glossary and a “blessed version”. Suggest once per quarter, with names like “2019v1” (where 1 is a quarter). This format is not semver-compatible, because we have no need to wrestle issues of forward and backward compatibility--but it is easy to understand, parse, and reference in a URI.
5. Establish a ToIP website level access experience
1. Access to main Glossary in all language versions
2. Access to TIP Glossaries

We MAY:

...

1. Browsable static html that’s copied to a website, glossary.decentralized.foundation. The website should be indexed by Google and have search based on elasticsearch.
2. A .zip file of the static html that could be copied to other web sites.
3. An ebook format (e.g., epub).
4. Possibly, occasionally, a JIT-printed SKU published on kdp.amazon.com.

...

various backgrounds. Their culture may not be Western. English may not be their native tongue. They may be experts in non-technological topics that are relevant for ToIP. Working with one another presumes a setting where participants have some level of shared understanding. Often, sharing one's understanding at a superficial level suffices. Other situations require that underlying concepts are shared in a more in-depth fashion. It's like cars: people buying, selling, or driving cars do not need in-depth shared knowledge about cars, whereas (maintenance or construction) engineers or liability lawyers need to share a deeper knowledge of how cars do (or do not) work.

We expect to see situations of "language confusion", i.e. in which people use words or phrases, the intension (not: intention) of which differs from the interpretation of some listeners/readers. CTWG aims to provide means to resolve that. Sometimes a casual glance at a dictionary or glossary is the solution. In other cases, deeper understanding matters, e.g. in when drafting specifications or contracts. Then we need more than a set of definitions. 

Scope

The scope of CTWG is to assist ToIP working groups (WGs), task forces (TFs), and other communities of interest or communities of practice that exist both within and outside of the ToIP Foundation to develop the concepts and terms they need for  themselves or for particular projects, and make them available to the public. This includes developing artifacts and tools for discovering, documenting, defining, and (deeply) understanding the concepts and terms used within ToIP. Key deliverables include ways to define terms (e.g. terms wikis), maintain a corpus of data underlying these terms, and provide ways to query the corpus to obtain terms e.g. for the creation of glossaries and other artifacts. The data that underlies the terms typically consists of (formally modeled) concepts, plus their relations and constraints, and will encompass perspectives from technical, governance, business, legal and other realms. Although CTWG will maintain this corpus of data via repositories that all ToIP WGs and TFs can contribute to and inherit from, this does not preclude WGs or TFs from maintaining their own specialized glossaries if they require. Such specialized glossaries, together with other generators of concepts and terminology elsewhere in the industry, are expected to feed back into the glossaries and corpus of data maintained by CTWG in a cycle of continuous improvement.

Meetings

Schedule:

Meetings are bi-weekly, every second Monday from 10:00-11:00 PT / 17:00-18:00 UTC. See the ToIP Calendar for full meeting details including Zoom links.

See our Meeting Pages for agendas, notes, and links to recordings of all meetings.

Deliverables

The table below lists all CTWG deliverables that have been approved to move beyond Pre-Draft status.

The overall scope of the CTWG includes the following activities:

1. Develop and maintain a high-quality corpus of terminology that covers the needs of the ToIP community.
2. Develop a process whereby this corpus can be:
1. Curated, based on evidence and using expert opinion, such that concepts, relations between concepts and constraints can e.g. be
   1. carefully defined,
   2. assigned an identifier (name/number/label) to distinguish it from any other concept in the corpus,
   3. mapped onto terms that are defined and/or commonly accepted in various relevant domains/contexts,
   4. their usage and relevance documented from organic sources,
   5. their status adjudicated into e.g. 'working', 'preferred', 'accepted', 'superseded' and 'deprecated'.
2. Enhanced in a collaborative, open, and fair manner by interested community members.
3. Versioned.
4. Published in different ways (e.g. as a glossary, concept map, use-case stories ...), for specific purposes (e.g. education, reference, , ...) by different means (e.g. a PDF, a website, presentations/webinars, ...) and as needed by different audiences/stakeholders or domains (e.g. business domains, architectural domains, ...)
5. Promoted as a valuable public resource and an influence for convergence and excellence.
3. Train and organize volunteers so the initiative develops sustainable long-term momentum.
4. Disseminate/promote the work across ToIP WGs and other relevant audiences.

Chairs / Leads

• Co-Chairs:  Drummond Reed, Henk van Cann 
• Former Co-Chairs: Rieks Joosten, Daniel Hardman

How to Join

You can join this WG by signing up for the Foundation mailing list at lists.trustoverip.org. Our mailing list is concepts-terminology-wg@lists.trustoverip.org.

Members as well as observers are welcome (see the caveat below).

Participation

For the protection of all Members, participation in working groups, meetings and events is limited to members of the Trust over IP Foundation (including their employees) who have signed the membership documents and thus agreed to the intellectual property rules governing participation. If you or your employer are not a member, we ask that you not participate in meetings by verbal contribution or otherwise take any action beyond observing.

Intellectual Property Rights (Copyright, Patent, Source Code)

The WG inherits the IPR terms from the JDF Charter. These include:

• Copyright mode: Creative Commons Attribution 4.0. 
• Patent mode: W3C Mode (based on the W3C Patent Policy).
• Source code: Apache 2.0, available at http://www.apache.org/licenses/LICENSE-2.0.html. The GSWG TA TF is not expected to produce source code.

Core Concepts

Context

The primary focus of the ToIP Foundation is not just on technology (e.g. cryptography, DIDs, protocols, VCs, etc.), but also on governance and on business, legal and social aspects. Its mission to construct, maintain and improve a global, pervasive, scalable and interoperable infrastructure for the (international) exchange of verified and certified data is quite complex, and daunting". This not only requires technology to be provided (which is, or should be the same for everyone, i.e. an infrastructure). It also requires that different businesses with their different business models can use it for their specific, subjective purposes. And that each individual business and user is provided with capabilities that facilitate its compliance with the rules, regulations and (internal and external) policies that apply to that entity - the set of such rules, regulations and policies being different for every such entity, and dependent on the society, the legal jurisdictions and individual preferences. All this is to be realized by people and organizations from different backgrounds - different cultures, languages, expertise, jurisdictions etc., all of whom have their own mindset, objectives and interests that they would like to see served.

The aim of this WG is to enable people in the ToIP community to actually understand what someone else means, to the extent and (in-depth) precision that they need, and facilitating this by producing deliverables/results/products that are fit for  the purposes that they pursue. Initially, we expected to see the development of a common glossary, that lists (and summarizes) the basic words we use in the ToIP community. It would include terms defined within as well as outside of ToIP (e.g. by NIST, Sovrin, W3C's VC, DID standards, and others). 

However, the minutes on a IIW meeting topic 'glossary effort' showed that developing a common glossary is quite difficult. This is underlined by a post of Eugene Kim (2006). But even when an effort to establish a 'common glossary' were to be successful, that doesn't imply that the 'commonality' extends beyond the set of its creators. The idea itself of establishing a terminology and subsequently (cautiously, but nevertheless forcefully) imposing it on others, is a highly centralistic way of doing things. And it doesn't work (it never has).

The WG recognizes that different groups use (slightly or quite) different terminologies, and acknowledges their 'sovereignty' in doing this. Thus, such groups will be enabled to define their own terms, yet at the same time facilitated to use terms defined elsewhere. As each group curates its own terminology, they each have the ability to decide to what extent they will adopt the terms of other groups into their own terminology. We trust that the various ToIP WGs and TFs will work together and the need to harmonize terminology will arise as their cooperation takes on more solid forms. 

We expect subgroups of the ToIP community (e.g. WGs, TFs, TIPs) to create their own specific terminologies that help them serve their needs as they focus on specific objectives (thus facilitating domain/objective-specific jargon). The CTWG will assist them where appropriate, and ensure that (in the midterm|) glossaries can be generated from each such terminology. 

Also, we expect to include more precise (theoretical?) specifications of underlying concepts, e.g. in terms of conceptual/mental models. Such models help to obtain a more in-depth understanding of ideas that are worth and necessary to be shared within one or more community sub-groups. They may also facilitate the learning process that (new) community members go through as they try to understand what it is we're actually doing. And they may help to 'spread the word' in specifically targeted (e.g. business and legal) audiences. A specific focus of this WG is to establish relations between the concepts of the mental models and the terms defined in the various glossaries.

A model for some of the deliverables of this WG is one or more websites that would resemble the Legal Dictionary. This site not only provides a definition of various terms, but also a brief description of their backgrounds, various use-cases that exemplify the relevance of (and distinctions made by) the terms, and other useful information.

Finally, we expect to see results that we haven't thought of yet, the construction of which will be initiated as the need arises, by (representatives of) those that need such results for a specific purpose. Perhaps we might produce a method for resolving terminological discussions that can be lengthy and do not always get properly resolved (e.g. as in id-core issues #4, #122). Here, we leverage a prior collaboration between Daniel Hardman (Evernym) and  Rieks Joosten (TNO).

Requirements

The Corpus of Terminology MUST have:

1. Source control and build processes managed in github.
2. A well defined syntax for contributing concepts/relations, and for each of them an identifier by which it can be identified within the scope of the Corpus.
3. A well defined syntax for attributing terms to such (established) concepts/relations for specific contexts/domains.
4. A well defined CI/CD process.
5. A simple process for contributing further content.
6. A simple publicly accessible website, containing at least the Corpus-identifiers and their definitions, possibly inspired by the 'Legal Dictionary'.
7. A PDF document for every published version, containing at least the Corpus-identifiers and their definitions.

The Corpus MUST NOT have:

1. A skill requirement on programming knowledge as that will reduce contributors.

The Corpus SHOULD be:

1. Reusable and easy to leverage in ToIP repos.
2. Usable for language translation via separate self-organized language specific repos. These repos should be aggregators of the baseline glossary and any TIPs.
3. Usable for mapping its identifiers/terms to those in use in other contexts/domains.
4. Consumable at the RAW content level (.md files) by external groups who wish to render content in a different manner.

Solution Approaches

We SHOULD:

1. Use a github repo to manage the corpus.
1. Consider using a Creative Commons license instead of an Apache license; it may be more appropriate.
2. Require DCO/IPR for contributors to the repo. Anybody who complies with the DCO/IPR requirements can submit to the corpus by raising a PR.
3. No need to manually maintain metadata about who edited what, when. We have commit history and git praise/blame.
4. Use github issues to debate decisions about term statuses. Anybody can raise an issue.
2. Use existing pervasive opens source documentation tools such as Spec-Up, Docusaurus, and/or GitHub Pages:
1. Each concept is described in a separate markdown doc that conforms to a simple template (see below). Concepts link to related concepts.
2. Each term is a separate markdown doc that conforms to a different simple template (see below again). Terms label concepts; links from concepts to terms remain implicit in the markdown version of the data, to avoid redundant editing. Having terms and concepts as separate documents that cross-link allows for synonyms, antonyms, preferred and deprecated and superseded labels for the same concept, localization, and so forth. They also allow for the peaceful co-existence of multiple terminologies (= sets of terms, namespaces, …)
3. Each context glossary is a separate markdown doc that conforms to another different simple template (see below once again). A glossary is an alphabetic list of terms relating to a specific subject, or for use in a specific domain, with explanations. The markdown document specifies the scope of the glossary, and the selection criteria for terms. 
4. Provides extendable CI/CD pipeline for the repo, and write unit tests to enforce any process rules, quality checks, and best practices the WG adopts.
5. CI/DI process should enable live website and refreshed PDF document after each approved and merged PR.
3. Define the criteria for giving a term the statuses. What are grounds for saying it is deprecated, superseded, etc. (Criteria are published in a doc in the repo, so debating changes to criteria means a PR and github issue.)
4. Create a release process guidelines.
1. Define difference between live glossary and a “blessed version”. Suggest once per quarter, with names like “2019v1” (where 1 is a quarter). This format is not semver-compatible, because we have no need to wrestle issues of forward and backward compatibility--but it is easy to understand, parse, and reference in a URI.
5. Establish a ToIP website level access experience
1. Access to main Glossary in all language versions
2. Access to TIP Glossaries

We MAY:

1. Leverage existing CI/DI approaches (sample code repos) for incorporating Spec-Up, Docusaurus, and/orGitHub Pages.
2. Suggest to the tech WG that they may write a generator tool that walks the repo, building in memory a semantic network of concepts that are cross-linked to terms, and emitting various incarnations of the content:
1. Browsable static html that’s copied to a website, glossary.decentralized.foundation. The website should be indexed by Google and have search based on elasticsearch.
2. A .zip file of the static html that could be copied to other web sites.
3. An ebook format (e.g., epub).
4. Possibly, occasionally, a JIT-printed SKU published on kdp.amazon.com.
3. Create a crawler process that collects terminology from various sources (contexts), for the purpose of mapping terminology as is used and/or defined in that context onto the concepts/relations in our Corpus
4. Create a process for pulling new content (terms, concepts) from the MM_WG

1. A source is declared in a config file that’s committed to the repo. This means anybody can propose a source by submitting a PR and debating its validity in a github issue.
2. Sources could include W3C Respec docs, IETF RFCs, Aries RFCs, DIDComm specs hosted at DIF, etc. Corporate websites wouldn’t work because A) they’re too partisan; B) they’d require random, browser-style web crawling, which is too hard to automate well.
3. Crawler pulls docs and scans them, looking for regexes that allow it to isolate term declarations, their associated definitions, and examples that demonstrate their usage.
4. Output from crawler is a set of candidate terms that must be either admitted to a pipeline, or rejected, by human judgment. Candidates that are already in the corpus are ignored, so this just helps us keep up to date with evolving term usage in our industry.

Content Templates: Archived

1. A source is declared in a config file that’s committed to the repo. This means anybody can propose a source by submitting a PR and debating its validity in a github issue.
2. Sources could include W3C Respec docs, IETF RFCs, Aries RFCs, DIDComm specs hosted at DIF, etc. Corporate websites wouldn’t work because A) they’re too partisan; B) they’d require random, browser-style web crawling, which is too hard to automate well.
3. Crawler pulls docs and scans them, looking for regexes that allow it to isolate term declarations, their associated definitions, and examples that demonstrate their usage.
4. Output from crawler is a set of candidate terms that must be either admitted to a pipeline, or rejected, by human judgment. Candidates that are already in the corpus are ignored, so this just helps us keep up to date with evolving term usage in our industry.

Content Templates

Concept Template (to be further developed on github)

...

Concept ID: 12345 (this is a 5-digit number that’s embedded in the filename, such as c-12345.md)

Criterion

en text: <text that allows the reader to evaluate whether or not something qualifies as an instance of the concept in every (yes, every) relevant use-case>

Definition

en text: blah blah blah

<other language code> text: lorem ipsum cu prorat

links to media (diagrams, audio, video)

Links to any discussions in github issues

Notes

history and theory of the concept in its larger mental model

implications

Related Concepts

Tags

Term Template (to be further developed on github)

...

Term: faster than light

Short form:

Acronym: FTL

Language: en

Labels concept: c-12345 (filename for this term would be t-12345.x.md, where 12345 comes from the concept, and x is 1-3 digits that uniquely identify the term in the context of its concept)

Links to any discussions in github issues

Notes

metaphors or mental/conceptual models (or namespaces) that inform the choice of this label for the concept

implications

Examples of usage

Scope: (description of the scope of application)

Tags

Glossary Template (to be further developed on github)

...

Language: en

Scope: (description of the scope and purpose for which the glossary is supposed to be used.)

Taglist: (any term that has a tag from this list will be included in this glossary)

Links to any discussions in github issues

...