You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Meeting Date

  •  

Zoom Meeting Link / Recording

Attendees

Main Goal of this Meeting

Review our mental model for terminology and agree on next steps for putting the ToIP Core terms wiki into production.

Agenda Items and Notes (including all relevant links)

TimeAgenda ItemLeadNotes
5 min
  • Start recording
  • Welcome & antitrust notice
  • Introduction of new members
  • Agenda review
Chairs
  • 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:
5 minReview of previous action itemsChairs
  • ACTION: Rieks Joosten and Daniel Hardman to arrange a meeting to discuss how this hyperlinking should work with ToIP Term Tool V1 and our current terms wikis.
  • ACTION: Rieks to incorporate feedback and publish revisions to his mental model diagram for the relationship of CTWG terminology and ToIP terminology.
  • ACTION: ALL to review and comment on Rieks' draft proposal defining the objectives, ingestion policies, and curation policies for the ToIP terms community.
  • ACTION: ALL to review the ISO Guide to IT Terminology
5 minUpdate on hyperlinking format discussion

Report on the outcome of the first action item above.

  • --
5 minUpdate on ToIP Term Tool progressDaniel Hardman

Daniel's notes from Slack:

15 minDecision on ToIP Core terms wiki process

Rieks Joosten proposal (from our Slack channel):

I suggest that we enable toip-groups to add terminology stuff to their existing repo's, requiring them to:

  1. specify a location (URL) where they publish (rendered) documents (papers, documentation, ...), by default at trustoverip.github.io/reponame, which would include trustoverip.github.io/reponame/glossary for its (rendered) glossary. This allows people to quickly find stuff, and authors of GDocs, Confluence pages and the like will have stable URLs to link to. We should start out by ONLY using the default location.
  2. specify a location where they maintain the 'raw docs' from which they render the stuff, by default at github.com/trustoverip/reponame/docs. This allows people to contribute to the groups documents by means of issues and pull requests to the repo. We should start out by ONLY using the default location.
  3. specify a location where they curate their terminology, from which they produce their 'raw glossary' (putting the result in the 'docs' folder, which is subsequently rendered and published as a usable glossary), by default in the subdirectory docs/terms of the repo. This allows people to contribute to the group's terminology by means of issues and pull requests. We should start out by ONLY using the default location.
  4. consider using the wiki of the repo as a terms-wiki like we do now.
  5. consider some practical conventions for facilitating group members to contribute to the development of their terminology, e.g. by making specific issue-labels and/or templates. This would be (near-)future work.
  6. read the documents (such as which you are drafting) that support repo admins in doing terminology. Of course, the 'raw text' would then reside at github.com/trustoverip/ctwg/docs, and it would be viewable at trustoverip.github.io/ctwg/doc-id. That would be the link that could be linked to from confluence pages, GDocs, etc.

Daniel Hardman's counter-proposal:

  1. Rename the current repos that have -terms in their name into the name without that suffix: ctwg-terms becomes ctwg, for example. This would mean we would have a glossary published at https://trustoverip.github.io/ctwg/glossary.html. A permalink. I am in favor of this proposal but want the WG to ratify it. An analogous URL, with a different group name, would be the canonical location for any group within TOIP.
  2. Accept the limitation that the glossary URL has to end in .html.
  3. Implement your suggestions 1 and 2  and 5 and 6 as written.
  4. Unlike your #4, require a terms wiki. We have no tooling that supports anything else, and we have no plans to produce any such tooling.

Daniel adds: I have now enabled automatic glossary generation on terms wiki edit, so any time someone changes a page in the terms wiki for either of the active repos, the glossary is automatically rebuilt (on about a 60-second delay).

10 minReview Rieks' updated mental model for TerminologyRieks Joosten

See the Terminology Pattern on the eSSIF-Lab site. The mental model diagram is also copied below as #1. The text also refers to the (updated) Notations and Conventions.

  • Drummond Reed has a question as to whether "terms community" is needed or whether "community" by itself would be sufficient
10 minUpdate on Rieks' proposed ToIP Core terminology processRieks Joosten

See the ToIP Core Terminology Management Process section of the ToIP Core terms wiki README.md

  • --
5 mins
  • Review decisions/action items
  • Plan for next meeting 
Drummond Reed

Discuss concrete next steps for putting the ToIP Core terms wiki into production.

  • The Governance Stack WG is ready to start adding terms.

Screenshots/Diagrams (numbered for reference in notes above)

#1 — eSSIF-Lab Terminology Pattern

Conceptual model of the 'terms-community' pattern

The figure itself is not a complete representation of the model - the texts in the section 'formalized model' must also be considered. One of the reasons is that some constraints of the formalized model cannot be represented in the figure. Here are two exmples: 

  1. "A term that is part of a given scope refers to precisely one definition and the single concept that this definition defines."  So a single term can refer to different definitions/concepts, but only within different scopes. Within a scope, there is no ambiguity of terms.
  2. "If a definition is part of a scope, then there is a terminology that is part of that scope, and it contains a term that refers to this definition". Loosely rephrased: "All definitions in a scope are part of its terminology". And consequently: additional terms may exist in a terminology that refer to definitions outside the scope (as well as within the scope, e.g. enabling aliasing for its own definitions).

Decisions

  • Sample Decision Item

Action Items

  • Sample Action Item


  • No labels