• Antitrust Policy Notice: Attendees are reminded to adhere to the meeting agenda and not participate in activities prohibited under antitrust and competition laws. Only members of ToIP who have signed the necessary agreements are permitted to participate in this activity beyond an observer role.
• New Members:
  • Kor Dwarshuis is working with Henk on KERIFIC.
  • Rob Aaron is joining for the first time to learn more about our work.

Any news and updates of general interest to CTWG members

• Henk van Cann announced a new version of kerific. In Chrome Webstore. Henk: Please forgive us some experimental features in the right click Options menu.
• Kevin Griffin shared that there is going to be a cleanup of ToIP repos. He asked about repos that are associated with CTWG and terms wikis.

ACTION: Drummond Reed to work with Kevin Griffin to decide which repos associated with CTWG and glossaries.

• ACTION: Drummond Reed to get back to Scott Perry regarding next steps for developing a glossary for the Issuer Requirements Guide.
• ACTION: Drummond Reed to have an offline meeting with his Technology Stack WG co-chair Darrell O'Donnell to discuss the essential tooling needed to add glossaries to the current and upcoming TSWG specifications and report back via Slack or no later than the next meeting.
• ACTION: Drummond Reed to schedule a "Putting TEv2 To Work" meeting to discuss how we can start using the TEv2 tooling with GitHub Markdown documents for ToIP deliverables. More details in earlier report. This meeting needs to be postponed as we think through our new glossary tooling. Suggestion: check the action ONHOLD.

Henk van Cann

Harmonizing Glossaries and Semantics (TEv2)
Interesting slide of the Issuer Requirements TF -> here. It says 'Needs to be harmonized with the ToIP glossary'.  
How does this relate to TEv2 principles? Notably Semantics. Are there more assumptions we need to be aware of? 

CTWG slide notes
"adopting terms from ToIP (or terms from any other glossary to the liking of authors or groups)
write/maintain your own definition of a (new) term, deliverable specific"

Henk explained that the use of a term may depend on the role or context of a specific group. He clarified these differences:

• Adopting a term means referencing an existing definition of a term in an existing glossary.
• Defining your own term means you are rewriting or separately defining a term in your own context.

Neil Thomson said that the latter case is typically refining or specializing a term. Otherwise you should define a new term.

Henk explained that the process may involve changing the criteria that has been established in other definition.

Henk then showed two screenshots (#2 and #3 below).

• Screenshot #2 shows how Spec-Up resolves references.
• Screenshot #3 shows the KERIFIC term how you can create a personal collection of terms that serve a particular purpose.

Darrell O'Donnell characterized Henk's demo of #3 as an "Explorer and Harvester" tool, and was very impressed by it. Drummond Reed agreed.

Darrell characterized three levels of terminology work:

1. Explore and harvest (what Henk showed).
2. Glossary management tools that enable curation of terminology (Darrell showed screenshot #5 to illustrate how hard this can get).
3. Spec editing tools that handle specific glossary management tasks within the spec writing process.

Neil Thomson noted that the situation to most try to avoid is when two terms communities arrive at different definition of the SAME term because they are using that term to refer to fundamentally different concepts. It would be much better to encourage one or the other to either choose a different term OR, if they agree on a base level of meaning, for one to specialize the term used by the other (by adding at least one word to it). For example, "identifier" could be be specialized as "federated identifier".

Henk van Cann Brian Richter 
Rieks Joosten 

Report on what progress (if any) took place over the past 2 weeks on either TEv2 or KERISSE tooling and code bases.

Rieks Joosten said he will get together with Henk and Kor. 

Henk did not think it would take another hour of Riek's time.

ACTION: Henk van Cann to arrange an offline meetiing with Rieks Joosten and Kor Dwarshuis to discuss the future evolution of TEv2 and KERISSE/Kerific.

• DECISION: We no longer need the Monday 9AM PT/17:00 UTC calls on TEv2 code development (except one more on Jan 29).

ACTION: Henk van Cann to send an email to Michelle Janata about removing the Monday 9AM PT/17:00 UTC meeting from the calendar after the Jan 29 meeting.

ALL

As Henk joins us as co-chair replacing Rieks Joosten, we are revisiting our plan for glossary management tooling.

Henk will share his thoughts first.

The following writeup from Drummond explains his proposal that grew out of screenshot #1 below.

First, to simplify the job of tech spec construction and editing, the Technology Stack WG has adopted the Spec-Up spec editing tool which is a DIF open source project. Spec-Up is currently being using by TSWG spec authros including Darrell O'Donnell (ToIP Trust Registry Protocol Specification), Drummond Reed (ToIP Technology Architecture Specification), and Lance Byrd (did:webs Method Specification) and Henk van Cann (WebofTrust kerific-spec). All of them need basic glossary management in these specs (the ToIP Technology Architecture Specification has been waiting for over a year to add a glossary).

Spec-Up already has a basic glossary feature: def tags for defining glossary entries and ref tags for marking up terms in the spec that refer to def-tagged terms. When Darrell and Drummond discussed it after the last CTWG meeting, we realized there are just two additional features we would need in Spec-Up to have “MVP” glossary management for all the specs coming out of TSWG over the next few months.

The first feature is to add Spec-Up code that detects dangling refs and defs. In other words, code that checks to see that: a) any ref tag defined in the spec has a corresponding def tag for the glossary entry, and b) every def tag defining a glossary entry has at least one ref tag pointing to it.

The second feature addresses a current limitation of Spec-Up: ref tags can only reference def tags in the same Spec-Up document. Darrell had the brilliant idea that the CTWG should begin publishing the ToIP Glossary as its own standalone Spec-Up specification, where every entry is properly formatted with a Spec-Up def tag. If we do that, then all we need for any TSWG specification to be able to include terms from the ToIP Glossary (without having to copy those 400+ terms over into its own glossary) is to enhance Spec-Up code to support remote refs.

The only difference between a local ref and a remote ref is that the former are always within the same Spec-Up document — they look like:

[[ref:term]]

The latter allow the author to reference a def in a different Spec-Up document. They look something like:

[[ref:doctag#term]] or [[ref-glossary1:term]]

doctag is a short unique tag assigned to the remote Spec-Up document containing the def for the term being referenced. So any Spec-Up document that uses remote refs would need to include a doctag section that looks something like this:

[[doctags:

[toip:https://trustoverip.github.org/cwtg/toip-glossary.md]

[hxwg:https://trustoverip.github.org/hxwg/hxwg-glossary.md]

]]

For example, a specification that includes a ref tag that looks like this: [[ref:toip#term]] would reference a def tag defined in the ToIP Glossary. Similarly, a ref that looks like [[ref:hxwg#term]] would reference a defined term in the (theoretical) HXWG glossary.

With this remote reference feature, all ToIP specifications (and any other deliverable written with Spec-Up) would be able to include linked glossary terms (including hover pop-up definitions) both from within its own glossary and from any referenced glossary in another document that also uses Spec-Up.

Brian Richter has estimated that he could add the necessary code to Spec-Up to support these two features within the budget remaining in the original CTWG TEv2 tooling bounty that Brian was awarded after it was approved by the ToIP Steering Committee.

The decision we need to make is whether to proceed with this new SOW.

Darrell O'Donnell explained more about updating the Spec-Up code base.

Kevin Griffin mentioned that the DIF Spec-Up code base has not had a lot of activity recently. Kevin noticed that ToIP also has a Spec-Up repo. 

ACTION: Kevin Griffin and Darrell O'Donnell to discuss their thoughs on the best way to evolve the Spec-Up code base with the modifications necessary to support: a) dangling "def" and "ref" tags, 2) remote "ref" tags and to communicate their conclusions to Brian Richter.

Henk van Cann explained that Web-of-Trust has already created a dangling ref management tool that operates against terms wikis. Henk feels strongly that the original sources should be in GitHub so that the provenance of each definition.

Drummond Reed explained the plan for publishing the ToIP Glossary as a Spec-Up document in GitHub so we can track provenance carefully. This is only a temporary step towards fully managed, individually versioned glossary management tooling such as being developed with TEv2 and KERISSE.

Judith Fleenor asked for Rieks Joosten viewpoint on this proposal for using Spec-Up refs and defs. He explained that the same features being discussed here were also added to TEv2. There is always tension between adding a lot of features and taking a long time, or keeping things very minimal. He pointed out that creating glossaries based on cherry-picking glossary entries based on personal preferences can be problematic because it doesn't actually establish shared understanding and criteria for defining terms. The larger the group involved, and the more varied their cultural backgrounds, the more problematic that can become. However, that doesn't mean we shouldn't start with tools that are actually working right now. Riek's personal preference is to use terminology that expresses the author's intentions clearly. For example, in reading the Spec-Up documentation, it was challenging for Rieks to understand it without more context.

Rieks Joosten would like to have several more sessions on TEv2 so we can still look at how we can use it for our terminology.

Judith Fleenor summarized Riek's feedback as saying that he's not opposed to enhancing Spec-Up for these features, but at the same time keeping TEv2 tooling in progress. 

Darrell O'Donnell clarified that he and Kevin will not delete any ToIP repos, but will only archive them.

Rieks Joosten concluded that we need to see what tools are actually needed by both authors and readers to help them comprehend the terms they use. He can also explore how TEv2 tooling can be used to produce Spec-Up definitions.

Judith Fleenor asked if we had a clear decision about Brian Richter to make the proposed changes to Spec-Up.

Drummond Reed asked if there were any objections.

Kevin Griffin was in favor of moving forward at the use of both types of tools (Spec-Up and TEv2) and will provide his input per his action item above.

Rieks Joosten was in favor of proceeding with these changes to Spec-Up, but also to continue the work on TEv2 to tackle larger issues of terminology management. He also pointed out this Confluence tool: https://marketplace.atlassian.com/apps/1219677/smart-terms-for-confluence-glossary?tab=overview&hosting=cloud 

DECISION: We will proceed to ask Brian Richter to make the proposed code contributions to Spec-Up to add the dangling ref/def and remote ref features as described in the 2024-01-29 CTWG meeting notes.

ACTION: Drummond Reed will notify Brian Richter (cc Judith Fleenor) that we will proceed make the proposed code contributions to Spec-Up to add the dangling ref/def and remote ref features as described in the 2024-01-29 CTWG meeting notes, with the additional Spec-Up coding guidance to come from Darrell O'Donnell and Kevin Griffin.

ACTION: Henk van Cann to propose the main agenda topic for the next CTWG meeting based on his discussions with Rieks Joosten and Kor Dwarshuis (and include one agenda topic for Brian Richter to report on his progress on his coding project as described above).