Brian Richter Rieks Joosten

Rieks reported that it has deviated a little bit due to "professionality of code maintenance". TNO has a group that manages tools for ontology development. They would like to have a tool for terminology. In order to get our tools into the TNO suite requires some refactoring of the code that has been developed. 

A term ref is decoupled from the conversion of the term ref into a final artifact to be included in the output. 

Rieks expects the human-readable glossary generator tool will be ready around the end of the year.

The current HRG tool can only import glossaries in the same format at the output. 

Rieks referred to the NIST-CSRC glossary that is regenerated daily as a JSON file as one we would want to support with TEv2.

Rieks said that the existing TEv2 tooling can be used now, but please use the issues to add new issues.

Brian has been experimenting with ingesting the ToIP Glossary. He has been converting it to HTML and then reviewing the tags. Henk has already done a smilar conversion that Henk has done.

We discussed that the ToIP Glossary is in a very structured format, so it is explicitly designed for machine-ingestion.

ACTION: Drummond Reed to put the topic of "hardening the ToIP Glossary" on the agenda of the next meeting.

Drummond Reed Rieks Joosten Brian Richter 

Are we close enough yet to plan for when we can apply the TEv2 tooling to: a) the generation of a glossary for the ToIP Technology Architecture Specification, and b) automated markup of terms in the ToIP Technology Architecture Specification? If so, what are realistic dates?

Rieks said that for documents in Markdown, tools are already in place. They may have bugs, but if the markdown is straightforward, it should work. The generation of glossaries, if the corpus is in place, also works. The key is whether you can import the glossary terms. 

Rieks said he can show how the tools work from the command line so the curator does not have to use GitHub Actions. It can also be set to do the markup automatically.

The one missing piece is the human-readable glossary generator.

ACTION: Drummond Reed to work with the TSWG Task Forces to prepare the Markdown documents to be used with the TEv2 tooling and then scheduling a tutorial session (ideally in the evening Pacific Time so that it will be in the morning for Rieks).

Neil made the point that authors of the different deliverables may need to 

Henk gave us this this presentation. the latest progress on the KERISSE glossary for KERI related terms and discuss how to realize the maximum synergy with TEv2 and the ToIP Glossary.  

To filter glossaries, they have added Type and Form categories to all terms. Type is for classifying the term, and Form is the part of speech.

All terms are also classified by expertise level (3 = KERI expert, 2 = SSI expert, 1 = Novice).

A key to the numbered screenshots below:

1. A view of the raw spreadsheet form (the entire KERI glossary is stored as a  Google sheet).
2. View of a glossary entry ("agent") in the KERISSE tool.
3. View of a glossary entry ("agent") in the ToIP terms wiki.
4. View of a glossary entry with additional metadata fields.
5. View of an imported definition from the ToIP Glossary.
6. Example of the filtering  (by Type, Form, and Level of Experise) that KERISSE supports.

@Henk van Cann: You could perhaps use the TEv2 MRG-importer, and then find out where MRGs live, so that you no longer need to scrape, but you use the MRG-Entry information in machine-readable format. Would that be an idea?

Riels said to @Henk van Cann: You could perhaps use the TEv2 MRG-importer, and then find out where MRGs live, so that you no longer need to scrape, but you use the MRG-Entry information in machine-readable format. Would that be an idea?

Neil:

• Expertise level(s) available on any term for readers (high, more depth, expert).
• Terms that are aimed at a given level of technical expertise (might be different for KERI vs Trust Spanning).
• One last point - where different glossaries/domains define the same term/word for different meanings - we need to figure out how to resolve that.