Useful discussion is bubbling about the possible evolution of Murmurations schema. This includes, among other topics, what's included in the base schema, how add-on schemas are defined and used, and the relationship to other vocabularies, ontologies, and standards.

This post discusses some of the thoughts and objectives that lead to the current Murmurations schema structure. I hope this will add some additional context to the discussion.

Murmurations was conceived with a fairly specific objective in mind: enabling greater visibility of organisations and projects that are working to make the world a better place. This objective came from working with organisations that hold directory and map data, and who are in the business of collecting that sort of data and trying to make it available to users. The organisations and projects that try to do this face some predictable obstacles, which Murmurations attempts to alleviate. There are numerous other potential applications, but for the initial design this basic use case was and continues to be primary.

This lead to some design priorities that shaped the development so far. These include, in approximate order of precedence:

Ease of adoption for nodes
Without adoption, a protocol is useless. Knowing that the groups we were hoping to serve are not necessarily well equipped technically or financially, we wanted to make it as easy as possible for nodes to join the network. This lead to:

Developing a plugin for the most widely used platform among the target audience as our first implementation of Murmurations
Building this plugin to extract as much as possible of the required node data from the host website
Aiming to make the plugin's user interface as smooth and flexible as possible
Avoiding fields that would be complicated or onerous for nodes to fill

Ease and effectiveness of adoption for network orgs
Another key audience is those who run networks (the groups that hold directory or map or aggregator sites that will be using Murmurations data). There needs to be a smooth path for a network to adopt Murmurations and invite its members to host data about themselves, including the fields required for the network's use.

Interoperability and respect for existing data standards
From the start, we have been cautious about reinventing the wheel. Schema.org and ESS-Global vocabularies and the JSON-LD specification in general should be leveraged as much as possible to make Murmurations data interoperable.

Simplicity of architecture
Ideally, the protocol can be adopted in all sorts of ways, for node and aggregator implementations in various programming languages and on various platforms, as well as new kinds of implementations that we haven't thought of yet. In order for this to be easy, the architecture has to be kept as simple as possible, so that a fully functional node interface or aggregator back-end is not a major software project to build.

Flexibility
A good standard paves the way for unexpected beneficial uses. We can't predict how a node will want to describe itself, or what information a network will need from its members.

Design implications

These principles have lead to design approaches that in turn lead to features of the current schema structure and mechanisms.

Design the schema with interfaces in mind.
Include a sufficient set of fields in the base schema so that even nodes using only this schema will provide relevant information for a map or directory.
Allow networks to define their custom schemas (using a larger field library), giving Murmurations the simplest possible role in making decisions about vocabularies and ontologies. It is between networks and their nodes to define relevant fields.
Where possible, use nudges, such as free text fields with auto-fills (in the case of nodes), or the library schema (in the case of networks) to encourage and support interoperability while allowing diversity, rather than using strict enumeration fields or fully constrained vocabularies. Otherwise, we have to force users into our version of what's important for them to describe about themselves. (Little more background on my personal perspective on this is in this Edgeryders post)
Build minimal features to allow a few implementations, and plan on using these as pilots to test the model, and then tweak as needed. Don't try to get everything perfect first, because we don't know the users as well as they know themselves.

Murmurations is very provisional at this point. There are no live networks using it at scale, so at this point we have freedom to tweak as appropriate. That said, I would like to encourage us to consider the points above in our conversations about schema development, make the user experience primary in our discussions. I would go so far as to put my opinion on this in bold: updates to the schema and mechanism must be driven by tangible and plausible benefits for users.

Who are these users? In the initial conception of Murmurations, we can clump these in three groups: the nodes in the network, who benefit from the greater visibility of their work; the aggregators, hubs, or network organizations, who benefit from easier access to better quality data about nodes and node activities; and people who want to find or learn about nodes, who benefit from more and better quality node data available in more places. (Of course in reality these groups overlap, and many people and organizations will belong to all three.)

Though this structure was what we had in mind when initially designing Murmurations, it's not necessarily a fixed limitation. It may be that other use cases are equally or more important. It's possible some of you are thinking of these other use cases, and that the discussion of schema development should be driven by those use cases as well. It's an open discussion, and there are no hard limits on what we can design and implement.

I hope this background is useful, and I'm really excited to see the enthusiasm and skills and experience that are currently supporting this project. Let's move it forward!

Cheers,
Adam