In computer science, an ontology is a map that enables machines to manage information for humans. An ontology that is flexible enough to administer voluntary human interactions, useful and simple enough to attract users, and compact enough for us to build and promote.
The figure above represents my first attempt to sketch a comprehensive ontology. There are Other Ontologies For Human Transactions. Apparently, none of those are designed to operate with self-sovereign principles such as are foundational to distributed governance. So I will happily scribble out this WikiWe first draft ontology mostly in intellectual isolation, and consider neighboring ontologies after the core attributes are better defined.Ontological Hierarchy for Notes v1
⚠ Switch to EXCALIDRAW VIEW in the MORE OPTIONS menu of this document. ⚠
Text Elements
Note
Hash-Address Issuer-Source Domain Entry Date
Referent(s)
Adopted Note
Adopter Adoption Date
Original (Directed)
CLASS
ESSENTIAL METADATA
Recipient(s) Status
Supplement
Signature Signature Date Channel ID
Comment
Revocation
Acceptance
Witness
Etc.
Agreement
License
Subject Access Key
Description
Template
Etc.
Content
Debt Note
Trust
Story
Etc.
Beneficiary Subject Administrator
Compact
Charter
Amount Terms Payment Address
Administrator Neutral Equity Token
Etc.
Etc.
Administrator
Property
Tool
Person
Link to original
The root of the ontology is a class “Note” (drawn as the solid green box in the figure), which is a “package” consisting of a Markdown document “payload” accompanied by metadata. The payload can be anything expressible in Markdown. We could generalize the ontology to other formats by adding metadata defining the format of the payload, but assuming Markdown as the payload format suffices for the human-readable purpose at hand. The ontology is not inherently limited to Markdown payloads, even if our first implementations will be.
Nodes in the ontology are arranged in a graph according to their metadata, i.e., in a tree. Each downstream or “child” node inherits the metadata labels of its immediate upstream or “parent” node. Therefore, each node is defined by a unique collection of metadata labels. In practice, this means that any payload can be located in the ontology based solely on its collection of metadata labels. Conversely, any payload can be provisioned with appropriate metadata labels once it is located by its function in the ontological tree. Example to follow later in this devnote.
Metadata labels signify the meaning of particular metadata items. Labels can be explicit or implicit. Some items of metadata are mandatory, meaning that the package is incomplete and therefore excluded from the ontology until a valid value is associated with the label. Other items of metadata are optional, meaning that the package can be placed in the ontology even if no value is associated with the label. However, it may sometimes be impossible to process the package if optional values are missing.
For the root Note, the mandatory labels should include the package address, its payload hash, its package hash, and perhaps others. The package hash is attached to an exterior of the package and is not itself hashed. The root Note is also assigned a collection of labels for optional metadata items, for example, Author, Creation Date, Parent ID, Public Key, Disclosable Domain, License, and perhaps others. A label should be included in a node’s metadata set only if it is applicable to all downstream nodes.
Notes are either signed or unsigned. All signed notes include as mandatory metadata a signature for a person “adopting” the note, and the date of adoption. To “adopt” means to confirm, accept, declare or otherwise come into relation with the payload of the note. Unsigned notes are not adopted by any signature.
Unsigned notes may be divided into categories of Content and Description, used for reference but not for documenting transactions. Examples of downstream Content packages may include templates, short stories, blog posts, essays, novels, screenplays, and a great many other types of payloads designed to be used but not adopted. Description packages describe some non-Markdown thing or resource, for example, a property, a tool, a person, and so forth. As is true throughout the ontology, notes are ontologically distinct only to the extent that their metadata label sets are distinct.
Signed notes are used for transactions. These may be divided into two broad classes: original signed notes and supplemental signed notes. Original signed notes require and allow only one signature, that of the original adopter. Some original signed notes are not directed to any recipient or group, for example, a simple attestation of fact: “this happened.” But most original signed notes are directed to some recipient, which may be an individual, entity, or group. Examples include offers, pledges, social promises, grants of trust, wills and testaments, debt notes, and so forth. To be ontologically distinct, each of these must be characterized by different metadata.
Supplemental signed notes are where most of the transactional magic happens. Offers are transformed into agreements by coupling to an acceptance note. Pledges are revoked when no longer applicable. Statements of fact are augmented by signed comments or endorsements. But why divide supplemental and original notes this way? Why not just combine both into one note? First, because every signature has its own significance. Second, because time and space means every signature is separate by nature. The supplemental note adds a signature and optionally a communication channel ID for the signatories to discuss any matters related to their joint
Notes can be merged into a single record that inherits the metadata of both parents. For example, an agreement results from a merger of an offer and an acceptance. It’s metadata values include all those inherited from the generic root note, the signature metadata from the Signed Note, the recipient (meaning the person to who the offer is made) and a status (e.g., open, accepted, expired, revoked) from the Directed Note, and signature metadata and channel ID from the Acceptance. The merged Agreement may have other metadata depending on the type of agreement. For example, the License may additionally include a subject property and an access key, a Compact may include an Administrator, and so forth.
The details remain to be filled in, but this framework for an ontology meets the criteria of facilitating voluntary human interactions in a flexible and adaptive manner, being readily implementable using existing resources, and being elegantly compact. I am interested to see where it goes.
🗄️ Licensed under CC BY-SA 4.0 by WikiWe™ Commons • Updated on 2024-02-17