Page Comparison

...

1. New members – none on this call

2. ToIP Term tool internal data model: adding a Scope/Context object

   1. The purpose of this object is to define the following properties
      1. Purpose
      2. Description
      3. Governing entity name
      4. Governing entity URI
      5. Licensing type URI
      6. Licensing info (everything necessary to generate the Licensing Page), or a reference to such info
      7. Notes with any additional information
   2. Daniel had not considered some of these elements, but they could be included in a document at the root of the Scope directory for each scope.
   3. Rieks Joosten agreed that these were good properties to start out with.
      1. A purpose is needed because each concept should be fit or that purpose.He encourage (objectives) is needed to determine what concepts/terms are relevant/meaningful to be included.
      2. The governing entity specifies this purpose, and might account for the scope's contents.
      3. Rieks encourages us to keep an open mind about what this may be used orfor (it's a largely unexplored area).
   4. Michael Michael pointed out that if the same entity is contributing multiple scopes, it would be ideal if there was one reference to that scope definition.
   5. ACTION: Drummond Reed  to move the discussion to Slack to figure out the best way to add Scope properties to the data model (and to see whether Licensing Pages should be dealt with separately)
3. ToIP Term tool: question from Drummond Reed about scope-specific definitions
   1. What do we do if two scopes are using the same term with slightly different definitions?
   2. Example: the term "agent" in scope A and scope B having slightly different definitions.
   3. Daniel Hardman  and Rieks Joosten said that each would have its own definition of the concept associated with the term "agent" in its scopeTo harmonize them, , and that is fine since that's the whole purpose of having scopes (namespaces). 
   4. If and only if there is some value in harmonizing them, which is not at all self-evident, then the stewards for scope A and scope B could confer and decide if and how then to harmonize and point at one them. One of them could point to the other's definition, or they could create a new one that they both use.
   5. Daniel Hardman pointed out a subtlety that , if there are two different governing entities, one may not agree to defer to the other in perpetuity, rather it might agree to point to if a steward may decide to follow a specific version of a definition but reserve the right to evolve it independently in the future, or the 'latest' one. The choices have different consequences. However, a steward can always decide to change this as (s)he is 'in charge' of these definitions.
   6. Rieks Joosten pointed out that it is important for an author (of a white paper) to be able to link to the exact version of a definition, so that the semantics of what is said in the paper doesn't change over time and may even become inconsistent/incoherent as the meaning of its terms change.
   7. That raised the question of whether a term itself can be versioned
      1. Daniel Hardman gave an example of the term "organization" being changed to "organisation", or a change in punctuation.
      2. Rieks Joosten  shared  shared that it could be handled by the status of the term.
      3. Daniel Hardman  clarified  clarified that the original URI for the file is different from the representation of the term in the Markdown file. He proposed the following:
         1. DECISION: The URI of a term is intended to provide a persistent identifier for that term regardless of whether there are some slight revisions to the underlying representation of the term—the latter of which can be handled in the Markdown file.
      4. Daniel Hardman pointed out that we have the ability to point to an exact version of any file.
   8. This led us to a discussion of linking to versions. The author can link to:
      1. The most recent version of a term
      2. A specific version of a term at a point in time (which may need to be handled by ingestion-tools)
4. ToIP Term Tool bounty writeup — are we ready to approve?
   1. ACTION: Daniel Hardman will merge Rieks Joosten pull request #51 to the ToIP Term Tool bounty writeup
   2. ACTION: Daniel Hardman Created: https://github.com/trustoverip/tt , noting that we can rename it if needed
   3. ACTION: Steven Milstein to check with the Operations team about how we should proceed with a new repo
5. Placing the bounty - next steps
   1. ACTION: Drummond Reed to arrange a meeting with Seth Newberry to talk about placing the bounty with the Linux Foundation
   2. We discussed how broadly to disseminate word about the bounty
      1. DIF, W3C CCG, Sovrin Foundation, TNO were discussed
   3. ACTION: Daniel Hardman proposed to post information about the bounty to other relevant industry groups
   4. Michael Michael asked about the specific format for proposals
   5. Rieks Joosten suggested we might do a one-hour webinar to share info and have Q&A about the project
   6. ACTION: Drummond Reed follow up in Slack with agreeing to a timeline and a time for that meeting
6. Progress on the Good Health Pass Ecosystem Governance Framework Glossary
   1. This is proceeding very nicely and resulting in excellent feedback
   2. It also suggests the importance of referencing or importing external glossaries and concepts, which leads us to...
7. Can we/should we import the ESSIFeSSIF-Lab Glossary and Mental Models?
   1. Drummond Reed was highly complementary of this work, particularly the formal models such as the Parties, Actors, and Actions model
   2. He asked Rieks Joosten about how to reference such work in the GHP Glossary, and what the longer term plans were
   3. Rieks Joosten said to reference terms using URIs to the ESSIFthe eSSIF-Lab Glossary for now; his longer term plan once the ToIP Term tool is ready is to import it into the ToIP corpus.
   4. Drummond Reed asked about other planned mental models and their formal definitions, particularly identity building on the work of the Sovrin Glossary in that area. 
      1. Rieks Joosten pointed to the others listed on the eSSIF-Lab Terminology site (see the left-hand menu), but did not make any promises. 
8. Review of Decisions and Action Items and planning for next meeting
   1. In the next meeting we will share an update on the status of the ToIP Term tool bounty
   2. We will also dive into more detail about the SSIFeSSIF-Lab Terminology work, starting with the Parties, Actors, and Actions model
   3. ACTION: Drummond Reed to review the Parties, Actors, and Actions model with Scott Perry and the Governance Stack WG for their feedback prior to the next meeting

...