Page History

...

The Concepts & Terminology Working Group (CTWG) helps TOIP 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/users in TOIP ToIP come from 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 TOIPToIP. 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.

...

The scope of CTWG is to assist TOIP working 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 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 TOIPToIP. 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 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.

...

1. Develop and maintain a high-quality corpus of terminology that covers the needs of the TOIP 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 across ToIP WGs and other relevant audiences.

...

Context

The primary focus of the TOIP 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 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 ToIP community. It would include terms defined within as well as outside of TOIP ToIP (e.g. by NIST, Sovrin, W3C's VC, DID standards, and others). 

...

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 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 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. 

...

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 ToIP website level access experience
1. Access to main Glossary in all language versions
2. Access to TIP Glossaries

...