Ontological commoning — initial ideas

2023-02-22

This promises to be a significant piece of work, so all I will do here is to outline the way that I imagine we currently intend to address it.

There are three aspects that may benefit from introduction:

• ontology
• commons
• motivation

We will look at the two sides of ontology, from the computational sciences and from philosophy. The reason for choosing the word “ontology” rather than “vocabulary” or “taxonomy” is that it emphasizes the importance of relationships between things, on a par with the kinds of things that exist. We may include a short note on ontology as it exists in computational sciences.

The philosophical aspect is not intended to be technical philosophy, but more in line with natural language. It will be explained how people construe any complex world in their own personal ways, and how that affects their models of what is significant in what exists (and the significant relationships between different things that exist), and therefore their personal (usually unconscious) ontology.

In order to implement understandable computational information systems, I assume that the more straightforward the mapping is between (the relevant level of) the computational ontology and the human ontology, the easier the human will understand and be able to use the information system.

We will briefly note the history of the concept of the commons, along with its intellectual pioneers like Elinor Ostrom. The choice of the term “commoning” rather than the plain noun “commons” reflects our belief that it is an ongoing process that is necessary here, not a fixed product, as the late Silke Helfrich did, as shown on the P2P Foundation blog. As Ostrom notes that a commons is governed by the commoners that use the commons, the creation and maintenance of an ontology held in common really needs to be governed by those who use it. Thus, ontological commoning refers on the one hand to the ongoing collective process of organic development of an ontology, and on the other hand to the principle that the ontology itself is about the concepts that are recognized in common, and the common language used to talk about those concepts, and the differences between different ontological perspectives.

Here we will set out why ontological commoning is vital on the human side for effective collaboration, and on the technical side for effective interoperability between cooperating information systems. We may note some difficulties that we have seen arising in the development of interoperability standards where there has been no ontological commoning, or difficulties arising in human collaboration, similarly.

I say “We may note some difficulties…”, and we would be truly grateful for any live examples of problems and difficulties with collaboration or interoperability that we may use for illustration.

Note that ontology, as it has been normally seen both in computational science and philosophy in the past and up to the present, has been at best very weakly related to psychology. Here we will clarify our understanding that complex domains are inevitably conceptualized in different ways by different individuals; and while this may simply be a matter of habit and convenience, there is also a strong possibility that personal choice of how a complex world may be simplified – enough to grasp and act within – may also be affected by family patterns, adverse experiences or even psychological trauma. People may, for understandable reasons, be resistant to seeing the world in a way that the aspects that are salient to them are ignored or downplayed.

In the light of this, any robust methodology for ontological commoning needs to include trauma-awareness, and the possibility of the need to deepen emotional work at any point, as those points may be quite unexpected and unpredictable. The open question is then, what techniques can we use, which are likely to be effective across a community that includes both system “users” and the designers and builders of the software that implements those information systems? To our knowledge, this is not an area that has been investigated to date. As I see it at present, IFS gives the richest and most appropriate model for us to use in this context.

There are many communities of practice based around various forms of dialogue, of communication, of personal development, etc., where many practices have been tried out and often reliably established as helping to work through interpersonal issues that arise. There are a very few outstanding and groundbreaking networks where technical collaboration is done with this kind of emotional awareness. But the challenge we see is, can we contribute to a much wider porting of these dialogue practices to the world of collaboration in technical development and interoperability? We see this as vital to the long-term success of the mission of the CTA.

That brings us to the more purely technical dimension. If we focus back on technical systems, it is clear to us that if we take “commoning” seriously as an iterative process, the ontological underpinnings will need to be alive and flexible, allowing an ongoing organic development. We are not sure that current ontology tools are suitable for allowing this kind of ongoing development, while keeping track of previous developmental stages. So here we will set out some ideas on how this might be done. This is an area where Marc-Antoine Parent has specialist expertise.

Conversation between Marc-Antoine and myself has to date given this outline, which we will elaborate and modify in the coming days. This is only a very provisional snapshot of where we are at the time of writing.

1. Some parties want to collaborate, and recognise a need to negotiate an ontology, to make certain assumptions explicit. A good starting point can be natural language in text or speech from all parties separately, explaining the domain, their aims and objectives in their own terms. So, for example, a team from a community of practice can be asked to respond to the prompt: “tell us about how you see regeneration happening through your platform?” This can be audio recorded and transcribed, and from that we will identify candidate entity types and relationships, which will then be passed back to that team for verification and to clarify definitions as they see them.
2. This forms the basis of elements of definitions, and/or formal models. The parties identify concepts that appear to be the same or closely similar, until or unless some discrepancy becomes apparent. After doing the previous step, two or more teams from different communities of practice can be asked: “looking at the definitions from other teams, how do you relate those to your own definitions?”
3. Someone expresses discomfort with some aspect of a concept definition, because they feel some kind of mismatch with their own way of thinking. They may ask for help to articulate the source of the discomfort, perhaps working in a smaller group where others can practice reflective listening to ensure the focal person feels fully heard, and thus able to participate in open co-creative dialogue. “Where exactly do you feel that the definitions don't match up?”, and this question is deepened in the following step.
4. One member from each team with mismatched definitions can participate in a process of dialogue around any area identified as not fully comfortable, identifying cases that they feel could be misrepresented by the concept definitions as proposed by others. (This could include: false positives; false negatives; ambiguous cases…) and, more importantly, why it matters to them. They are helped to distill those cases into narratives that can be brought to the larger group, while maintaining sufficient confidentiality to stay within a safe working space. One useful focus could be, “what are the relationships between the concepts, in each case?”
5. The whole group engages in dialogue with the aim of establishing a shared understanding of the relative importance of the original and new cases. This can be iterative; and may involve any of the parties shifting or enriching their own perspectives. Something like, “what could be a good way of integrating or modifying these definitions so that the important interests of all are served?” Naturally, what is “important” is a matter to be considered and agreed, not imposed.
6. In the context of the whole group, new concept definitions may emerge from the set of agreed-upon use cases. This is a more formal process, where the original proposed definition is broadened (through an abstraction of some defining characteristic) or narrowed (through the introduction of a new distinction) or both; or completely rewritten. “Can we all agree on a common set of terms and definitions, including entity types and relationships?”
7. The resulting set of definitions and characteristics is linked to previous definitions explicitly, with translation procedures if possible. The motivations for the definitions are also made explicit. “How can we clarify how the common ontology that we now agree on, relates to the previous or separate ones that were brought into the process?”
8. The resulting live ontology is used as the basis for ongoing software development with built-in readiness for interoperability. As the ontology develops, the records enable relatively straightforward upgrade paths. We can ask, “Can this ontology now be detailed so as to be used effectively in software engineering, sufficiently precisely to enable interoperability?”
9. There may be steps that need to be revisited, to consider whether to rework any concepts that seem unnecessarily hard to implement technically. Suggestions for ways of representation that offer more technical convenience can be fed back to the communities of practice, to establish whether or not they are happy with any variation, but without any assumption that technically convenient ways will suit other stakeholders.

These ideas have been developed in the context of the CTA's “Collabathon”, in early 2023, where this is a proposed project.

The idea is that the project team will enter into dialogue with the other projects, and especially projects aimed at interoperability and collaboration, to see whether, and how, this approach could be helpful. In this way we hope to end up with a series of case studies, to form a realistic basis for an ongoing, developing, methodology for ontological commoning. Naturally, we intend this to be part of our shared commons, and to be governed by an active participating community focused around the CTA and other groups, networks and initiatives with compatible visions and values.

We also hope that this will serve as a contribution to other initiatives that want to take a more holistic view of technical collaboration, development and interoperability.

I hope to develop this into a full, potentially academic, article, which I am calling What is Ontological Commoning. Please get in touch if you feel strongly resonant with the idea, or could use it. Go there if you would like to contribute as a co-author.

My thanks to Roberto Valenti and Simona Rossi out of whose conversation, at Liminal Village, these ideas grew.

• dialogue