![[Devnote0003_Nodes_Image.png]] A useful ontology for distributed governance is simple, easily configured, and easily implemented with existing technology. # Context An "ontology" describes possible relationships between agents and objects of a system. For example, an ontological concept labeled "note " might be used to describe a relationship between a set of data and a person, recognizing that a relationship of authorship-content exists between an agent (the issuer) and the set of data. In a system of distributed governance, the ultimate agents are people. Because people are open and evolving, so must be their ontologies. But here, we are concerned about a system of machines useful for distributed governance. We are talking about the bare minimum machine and human-readable ontology needed to support all the complex and variable concepts embedded in the abstract ideas of ordered governance and justice. A compact core ontology provides both simplicity and flexibility. It begins with a root concept that can expand into a tree, the branches of which can bear any kind of fruit, such as social media, collaborative works, offers, acceptances, agreements, settlements, wills, trusts, multi-party compacts, social promises, judgments, and anything else useful for facilitating cooperation among equals, all in a distributed manner, without centralizing of records. # Root Governance runs on documents. Beliefs and trust are naturally more importance than these, but every governance system for groups larger than a small village requires records, and even small groups often find records useful. The root data object is the simplest record that is useful for governance and capable of augmentation for any desired use. Here are the essential record requirements for a useful governance system. First, each record needs to have significance in a system of governance. In other words, it must have some meaning in a system for determining rights and obligations based on reason. Second, each record must originate from some identifiable source, even if that source is anonymous, so that credibility can be assessed. Likewise, it should be authenticatable; there should be reliable means for determining whether the record is what it purports to be. The most significant governance records are intentional human expressions, so we'll somewhat arbitrarily call the root records "notes." However, notes are not necessarily human expressions. Some might contain machine generated payloads, instead of or in addition to human expressions. Each note includes a payload and metadata. The payload of the note may be the content itself, or an address pointing to the content. The essential metadata for each note are a [hash](https://computersciencewiki.org/index.php/Hashing), an issuer or source ID, and an entry date. Necessarily supported optional metadata include links to related notes, here called "referents." A hash can also function as a content address, or as part of a content address. ### Issuer-Source ID The issuer or source ID are supplied by the person or device by which the record is released to its repository. The [the prior devnote](devnote0002.md) described the general structure of these repositories in a distributed data system. For example, the record can be encrypted by a person's private key, which identifies the issuer as the person holding the private key paired to the public key by which the content is decrypted. Other means for identifying an issues or source are possible, which should not be less secure ### Hash A hash is a unique identifier for data, produced by processing the data with a hashing algorithm. Our note contains a hash of everything the note contains except for the hash itself. Thus, the hash is part of the note but also separated from it by a data divider. The issuer or anyone else in possession of the note can record the hash in a public blockchain ledger or distributed hash table, causing the hash to be immutably linked to a timestamp. The hash record can then be used to prove that the note existed and has not been changed since recorded in the ledger. Even if the hash is not recorded in an immutable ledger or table, it can still be useful for proving authenticity of the note between private parties, so long as each party has a copy of the hash with a receipt date in records under their sole control. If the payload of the note will only be used once, there is no reason to hash the payload separately from the metadata. Conversely, if the payload will be reused in multiple notes, a separate hash for the payload and its original metadata can be supplied using a referent. The payload can be empty with the content provided by the referent. In other cases, the payload may supplement information supplied by the referent, such as information completing a form. ### Entry Date #### System of Record #### Entry Date #### Mutability & Deletion ### Referent(s) # A Key Distinction 🗄️ Licensed under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) by [WikiWe™](https://wikiwe.org/) Commons • Updated on 2024-03-22