...
- Dan ran through the high-level process. The key open questions are:
- After ingestion (left side of the diagram), what is the refinement and publication process?
- Are we going to use the GitHub file system as the storage system?
- Scott noted: "If we agree on the definition another org has for a term AND they have published it in their glossary, why would we talk about “investing” a definition (and thus create an on-going maintenance task) and instead not just reference it? If we disagree with their definition, we can certainly create our own, and we can also add to it in our glossary. That should be “injesting”". As an example, we could refer to IEEE's extensive glossary work.
- Open Issue: references to external terms.
- First decision: do we include one?
- Second decision: do we need to modify/refine it? Or just reference it?
- Drummond proposed to discuss next steps to get to a "minimum viable system"
- Dan asked if we can just start with "flat-file" Markdown files in GitHub.
- Scott: terms are going to have a state, and so at a minimum we need to track that state
- We are also going to need to track language
- We are going to need tooling to do that
- Rieks: there are so many terminology tools to choose from, and it's hard to get agreement
- This applies both to tools and terms
- General terms can lead to endless discussions
- So we should let terms be decided by specific scopes/stakeholders
- The value that we can add is to provide tools that the stakeholders can use
- We can also define criteria for this process for submitting, defining, and maintaining these terms
- So our job can be to find out about the tooling we can use and recommend to these groups
- Then we can add value by going over these terminology stores to see if we can help map and harmonize terms to achieve "terminology interoperability"
- We could start out with one particular group to see if we can get it working for them
- Dan agreed that it would good to start with one group, and that we've already started it with the Utility Foundry WG
- But the open question is how to handle that group
- Rieks: what we haven't agreed on is the validation process
- Suggests can ask the group what states they want to see
- Dan disagrees and suggests that we need to define a process that all WGs can use
- Rieks suggests that we start very simply
- Take in the terms as GitHub submissions
- Make sure the submission is complete and valid by the template
- Tag and link the Markdown file
- Publish it
- Dan: is there an existing tool we can use?
- Rieks: let's get it running with the simplest process we can
- Dan: will take the action item to research such tools
- Feels that we need to find the simplest tool that we can start working with
- Showed an example of a glossary produced by Mkdocs from Markdown docs in GitHub
- But we need to have something that adds the next level of functionality: state, tags, links
- Rieks: We need to define a data model that can be used by the other WGs
- Dan: if the tooling we end out selecting has a data model, can we live with it
- Drummond: Conclusions
- Our next step is to identify the tooling we need to establish a "minimum viable process" for terminology ingestion, refinement, and publication
- Dan has taken the action item to identify candidate open source tools for this
- We will discuss via our Slack channel between now and the next meeting
- At the next meeting we will (hopefully) make a decision about the initial tooling to use
Action items
- Rieks Joostenwill copy his Glossarist report to this Notes page for retention
- Dan Gisolfi will investigate open source tools available for terminology and will talk to Daniel Hardman about such tooling
- Drummond Reed will notify Daniel Hardman and also publish an update to our Slack channel
## What Can `Glossarist` Do For ToIP?
...