# Day 5 EN course 2024 ### Easy fixes - For it to be ... - Although, ideally, ... - The more important criteria are: This [chapter of the Terminology Governance Guide](https://trustoverip.github.io/ctwg-terminology-governance-guide/#how-to-write-definitions-in-your-terminology) explains the challenge with examples. Here are a few term definitions that could be altered / amended. ### MIME type https://weboftrust.github.io/WOT-terms/docs/glossary/media-type?level=2 Criteria: IANA classification present? Elaboration: https://chatgpt.com/share/55860d2f-8bb1-46ba-8543-c6f4720afd71 first interaction ### NFT https://weboftrust.github.io/WOT-terms/docs/glossary/non-fungible-token?level=2 Criteria: On blockchain anchored with monetary value? ChatGPT: https://chatgpt.com/share/55860d2f-8bb1-46ba-8543-c6f4720afd71 second interaction ### Ambient Verifiability https://weboftrust.github.io/WOT-terms/docs/glossary/ambient-verifiability?level=2 Criteria: NOT anyone or NOT anywhere or NOT anytime -> NOT Ambient Verifiable Verifiable by anyone, anywhere, at anytime. Although this seems a general term, it was first used in the context of KERI by Sam Smith. An example of ambient verifiability is Ambient Duplicity Detection that describes the possibility of detecting duplicity by anyone, anywhere, anytime. ### Race condition https://weboftrust.github.io/WOT-terms/docs/glossary/race-condition?level=2 Criteria: other events are controllable? ChatGPT: https://chatgpt.com/share/55860d2f-8bb1-46ba-8543-c6f4720afd71 third interaction ### SSI System https://weboftrust.github.io/WOT-terms/docs/glossary/ssi-system?level=2 Criteria: decentralised, to what extent? ChatGPT: https://chatgpt.com/share/55860d2f-8bb1-46ba-8543-c6f4720afd71 fourth interaction ## Conversation on Soc. Media - check grammar and punctuation I support the approach as long as we try to: 1. avoid copying full files of terms but instead let git *versioning* do the job 2. automate creation, maintenance and reference of specific versions whenever we can 3. keep a complete git history, consistently available, of each spec-up repo involved in any combination of def, ref and xref usage. The reason I'd like to stick to these constraints is because we need: a. a single point of definition and reference b. consistency c. to avoid manual labour (for example on dead links). At least for the time being I'd also like to focus on implementing [Drummond's point 3](https://trustoverip.slack.com/archives/C01BBNGRPUH/p1716356848969529) with my constraints above. I'm convinced it's possible to offer functionality that creates and manages snapshots with git and github and at the same time avoids "hell", as Darrell described it a few weeks ago. Drummond's Point 2 is not Kor's design - nor mine; that'd be too much honour. One term per file stems from TEv1, Wiki-based term defs, and TEv2. The Spec-Up based ToIP main glossary took a different turn: one file, many terms. We now only try to bring the one-term-per-file principle back in Spec-Up-based source management of term defs and (x)refs, plus the consecutive generation of specification documents, glossaries and dictionaries. The fundamental building block associated with this is "one term per file" with an unbroken strain of commit hashes all the way back through its relevant history. If things are easier than I think and more production-ready than I know, I would welcome Pull Requests that tap into those available resources straight away. @Rieks Joosten "have individual files comply with the TEv2 specifications for curated texts" -> we will definitely look into this, after step 2 has been taken (back) into production: *one term per file*. However, I will do so with the constraints mentioned above in mind, if you don't mind. I recall TEv2 creating explicit copies of files to support its versioning strategy. Am I right? 'overwrite such files' would leave a git commit trail and that's what we're looking for 10:51 I mean a diff-able commit trail: you can pick any two commit hashes in the strain and do a diff or git checkout to them 10:54 in normal human language: we could follow Drummond's approach above to offer meaningful version numbers and set snapshots and adhere to my constraints to not create "hell" on the way. 11:04 AM TEv2 is complex to me, but we'll continue making the effort to study the tooling and give full acknowledgement to TEv2 if it already has everything readily available, that we need and that we are stupidly reinventing (my words!). Apart from this, imo there's no better way of demonstrating, that TEv2 can easily do it, than to offer PRs to any related development around Spec-Up on github, from a working example on another github user account.