KOI Pond | FAQ

Eventually, we aim to incorporate all of the knowledge generated by Metagov, such as scholarly articles, blog posts, Slack messages, meeting notes, governance documentation, etc. However, defining the bounds of Metagov's community knowledge remains an open question. We encourage community involvement in these discussions as we collaborate over which knowledge objects to include, as well as how to define and organize them within Metagov's KOI. Together, we will co-produce the boundaries of our collective knowledge.

In the initial stages of development and testing, Metagov's KOI is utilizing data from our semi-public Slack channels. However, as the system stabilizes, we will be more judicious about the types of Slack data that are visible to the KOI. We anticipate that the Telescope bot will play a significant role in curating which knowledge objects are incorporated into the system. You can read more about the Telescope bot on this Medium blog.

Our first library-a-thon will involve the incorporation of Govbase Labs’ Airtables. Stay tuned for updates!

If you would not like your Slack data to be included in the early testing and development phases, adjust your Data Export Consent preferences in your Metagov Slack profile. See the #start-here channel for visual step-by-step instructions on how to do this.

As the lead developer of Metagov’s KOI, Luke Miller is currently the only individual with the keys to access the system’s backend. It may be useful to know that the back-end system, in this case, is not a repository of information, but a set of instructions pointing to knowledge objects and their associated metadata (information contained in the reference IDs - see What are RIDs? below). For instance, KOI accesses Slack messages in their original location. 

Knowledge objects are the building blocks of the Knowledge Management System that underpins Metagov's KOI. They represent the bits of organizational knowledge that Metagov's KOI can draw from when responding to a query. Knowledge objects can capture any type of data that is transformable into text, including Slack messages, Zoom call transcripts, Govbase Airtables, by-laws, meeting notes, academic publications, etc. Knowledge objects can also be defined with varying degrees of granularity. For instance, within the Slack ecosystem, channels, users, and individual posts can all be represented as knowledge objects within Metagov's KOI. 

Relationships between knowledge objects are indicated by drawing connections between them. Together, these knowledge objects ("nodes") and the connections between them ("edges") comprise Metagov's knowledge network, which is stored in a Neo4j graph database. As a community, Metagov will need to set norms for how to understand and define knowledge objects and the relationships between Metagov's knowledge network. For more information about how knowledge objects are defined and referenced, reference What are RIDs? below.

Relationships between knowledge objects (which are themselves knowledge objects) can be categorized along two different axes. The first axis makes the distinction between relations and assertions. Relations are immutable, meaning that they cannot be modified once created, although they can be deleted. Conversely, assertions are mutable, therefore that their properties can be altered. Changes to assertions are tracked in a transaction record, enabling version control and the ability to fork these objects. The second axis classifies relationships as either directed or undirected. Directed structures connect discrete sets of knowledge objects, while undirected structures map one set of objects to another.

Conceptually, a knowledge object represents computable knowledge as both a resource and a service. That is, it contains a description of what it does, and the code to do it. Also, in order to make the object findable, accessible, interoperable, and reusable (FAIR), the KOI has enough metadata to describe itself as both resource and service. - https://kgrid.org/guides/tutorial/ko/overview.html

RIDs, short for Reference Identifiers, offer a versatile way to index and interact with knowledge objects within Metagov's KOI. While conceptually similar to URIs (Universal Resource Identifier)s (of which URLs are a subset), RIDs operate on a broader scope. Not only can RIDs be used to reference URIs, but they can also point to knowledge objects located on your local machine (such as PDFs) as well as objects that exist offline (such as a printed publication). Thus, RIDs do not replace other reference systems, but instead unify several different reference systems under the same schema. If URIs represent a type of reference system, the RID system is a type system for references.

The basic elements of the RID system are means of references (or simply "means"), references, and associated actions. Means define the type of object an RID is pointing to, while the reference assigns a unique identifier to the knowledge object under the specified means. Together, the means and the reference form an RID for a given knowledge object, represented as means:reference.

For example, an RID referring to a Slack message could take the following form:

URL:https://metagov.slack.com/archives/C034GUA938W/p1645798649785169

In this example, URL is the means that describes the type of knowledge object that the reference (https://metagov.slack.com/archives/C034GUA938W/p1645798649785169) is pointing to. 

Associated actions are functions that interact with, on, or through an RID in some capacity. For instance, a transform function can be called upon the RID listed above to define the same knowledge object with an alternative means. For instance, we could also represent the knowledge object above using a slack_message means, which would look like the following:

slack_message:metagov/C034GUA938W/p1645798649785169

slack_message("metagov/C034GUA938W/p1645798649785169")

For more information about RIDs, refer to the following resources:

“RIDs define digital objects as references which point to referents. References also have a method, or way of referencing, their referent(s). A single referent may be referenced by any number of digital objects, in a wide variety of ways. RIDs are an important innovation because they provide the basis for triangulating complex referents through many perspectives, which also enables communication across contexts where different references are used to describe the same referent.

We applied the concept of RIDs when we built software to collect and curate a library of digital objects. We organized our library into a graph database in order to explore its items and the relationships between them. By using RIDs, we eliminate the need to replicate knowledge objects distributed across various platforms in order to make use of the knowledge that these objects refer to. When necessary, we can “dereference” these RIDs by applying their method of retrieval in order to recover their contents. Our graph database is like a card catalogue, a node in the graph is like a card for specific book, and dereferencing is akin to taking a book out of the library.”

Source: https://medium.com/block-science/towards-knowledge-networks-3232b82eca4a

See also:

1. Flexibility

One of the main affordances of the RID system provides Metagov's KOI is the flexibility to structure and manipulate knowledge objects, depending on the use case.

For example, the RID system enables knowledge objects of vastly different scales to be represented within the KOI's Knowledge Management System. Consider a Govbase Airtable. Not only can the different rows, columns, and cells that comprise the table each be represented as their own distinct objects, but the table can also stand alone as a knowledge object in and of itself. Furthermore, the relationships between these different knowledge objects can be captured by their connections in the underlying graph database in which the KOI's knowledge objects are stored.

The RID system also embeds flexibility into Metagov's KOI by enabling the same knowledge object to simultaneously be assigned different RIDs (see What are RIDs? above for an example). As a result, a knowledge object can be equipped with distinct sets of tools, each of which can be indexed through its unique reference.

Overall, the RID system, integrated with a graph database, allows communities to organize knowledge objects in a way that doesn't conform to a fixed data structure. Thus, the KOI architecture is not a single-purpose tool, but rather a versatile infrastructure can be tailored to specific operational contexts. In order to optimize the functionality of its KOI, Metagov must collectively determine the types of knowledge that will inhabit its KOI, establish norms for defining and interpreting these knowledge object (and the relationships between them), and outline the intended uses of the KOI both within the community and by external entities.

2. Ability to Reference Knowledge Objects without Accessing Them

Another key affordance that the RID system offers Metagov's KOI is the ability to reference a knowledge object, regardless of whether the knowledge it contains is accessible. This capability allows the underlying graph database to function like a library's card catalogue, where each card points to a specific book. Like a catalogue card that remains in the library even if the book has been checked out, an RID continues to reference a knowledge object, such as a Slack post, even if the KOI cannot access its contents, either due to permission restrictions or deletion. the knowledge it contains, either because it does not have the restricted permissions or deletion.

This distinction between the reference and the referent affords better permissioning and  privacy. According to Michael Zargham & Ilan Ben-Meir at BlockScience, "[D]ifferentiating reference from referent makes it possible for organizations to have internality on the technical level — which, in turn, makes it possible for organizations to communicate with other organizations about their internalities (that is, their organization’s knowledge), without having to also grant outsiders access to its inner workings." 

Another benefit of distinguishing the reference from the referent is that knowledge objects do not need to be duplicated across platforms in order to make use of their contents. Instead, the system it observes and points to data where it already exists in the world.

3. Voice Plurality

Unlike most technical systems which operate on the basis of a "ground truth", Metagov's KOI embraces subjectivity and supports plurality. Because the RID system and graph database offer the freedom to skirt the confines of fixed data structures, Metagov's KOI does not need a unified representation of a knowledge object or their relationships. Instead, it allows for the organization of knowledge into various sets that reflect different perspectives throughout the community. For instance, the community could decide to construct a 'core' Metagov identity within the KOI, which could include Metagov's code of conduct, by-laws, governance policies, and other official Metagov documentation. Similarly, sub-communities, such as those subscribed to #ostromnauts could create a knowledge set with knowledge objects that relate to polycentricity, commons theory, neo-institutional economics, etc. In this way, Metagov's KOI should be (this one of our hypotheses) able to capture the plurality of perspectives within the community, while also projecting a unified organizational voice.

The KOI is designed to be a flexible tool that can be used towards a variety of different use cases. However, the potential uses of this tool will become clearer as we begin to experiment with its capabilities. Due to its ability to catalogue knowledge, we initially intend to use the tool for the purposes of onboarding and knowledge retrieval. We also envision KOI as a reflexivity tool through which Metagov can better understand its identity, its functions, and its processes as an organization. However, we hope to expand to more creative and experimental use cases in the future. For instance, some team members have imagined Metagov’s KOI as a tool for governance LARPing, while others envisage its utility for building out contribution systems.

There are many ways that you can contribute to Metagov’s KOI development. To start, try playing around with the system in the #koi-tank channel. This will give the developers a sense of how the community uses (or would like to use) the system. (Please be sure to review the channel rules before posting here.)

If you are interested in getting involved in curating the knowledge objects that are visible to Metagov’s KOI, stay tuned for more information about upcoming library-a-thons, where we will begin to co-produce the boundaries of Metagov’s knowledge.

Most of the discussions surrounding the progression of Metagov’s KOI occurs in the #koi-pond and #govbase-labs channels. Both of these channels are open to anyone in the community that would like to get more involved in the project. We also strongly encourage interested community members to join our weekly team calls which occur every Thursday from 5pm-6pm GMT-4. 

Important governance decisions and processes will be discussed and debated within all of the forums listed above. The more engaged the community is in these decisions, the better we will be able to tailor the system to our needs. Through your contributions, we hope to build out shared norms, rules, and codes of conduct surrounding how and where the system is used.

As the base architecture is being integrated into Metagov's ecosystem, technical decisions are largely made at the developers' discretion. However, given that design is governance, the developers will increasingly confer with the Metagov community to negotiate such technical decisions as the system becomes more stable.

Decisions regarding Metagov's research goals, experimental approaches, initial use cases for the KOI have largely been informally guided by participants in our weekly team calls which occur every Thursday from 5pm-6pm GMT-4. Because Metagov lacks a policy for working group decision-making, those who show initiative tend to drive these decisions.  However, as the system matures, we hope to codify governance procedures to guide the development, experimentation, and use of the system.

Reach out to the team in either the #koi-pond or #govbase-labs channels, and we will do our best to address your questions or concerns.