Approaches like Model-Driven Engineering (MDE) involve various activities and tasks where conceptual models serve as the foundation for designing, using, analyzing, and transforming artifacts throughout the software development process. These modeling activities are often collaborative, involving multiple stakeholders with different knowledge, expertise, and domain backgrounds.

However, while several modeling frameworks support collaborative work, they typically require all users to utilize the same tool. This greatly limits the collaboration by imposing restrictions on all actors (not only on the tool to be used, but also on the modeling language and even the syntax), forcing all participants to learn those even if, due to their profile, each participant would prefer to use a different tool and language.

Motivation

As an example, consider a collaboration scenario aimed at creating a common model to formalize the Digital Product Passport (DPP) initiative. Designing a structural data model for the DPP requires foundational knowledge from several sectors and user profiles. For example, these three key areas covered by a distinct profile:

• Materials: Modeling product composition, including raw materials, recycled content, and hazardous substances. This must be led by a materials scientist.
• Manufacturing and Supply Chain: Representing processes, carbon footprint, certifications, and traceability. This knowledge is provided by an industrial engineer.
• Knowledge and management of DPP: Review the overall structure of the DPP data model, ensure consistency, and manage collaboration between various industry experts. This includes knowledge of the DPP regulations, data governance, and interoperability requirements. An IT expert or DPP data manager can fulfill this role, acting as a DPP model administrator.

To collaborate effectively, these profiles need a space where each can use their preferred tool to describe relevant model parts. They should also only see the parts necessary to them to avoid information overload and prevent unauthorized changes.

Our approach aims to provide this collaborative space. With a vision similar to ActivityPub and the Fediverse, but focused on model federation, we propose ModelFed and Modelverse, a decentralized ecosystem that enables collaborative modeling across different platforms.

If you are interested, you can read the full paper here. Our work, will be presented at the 44th International Conference on Conceptual Modeling (ER 2025).

Modelverse

We call Modelverse the federated ecosystem of distributed modeling platforms interconnected through ModelFed, a protocol specifically designed for collaborative modeling.

Unlike centralized solutions, Modelverse enables decentralized collaboration by allowing multiple users to concurrently edit shared models without relying on a central server. This configuration is illustrated in the following figure, which shows our DPP example as a potential Modelverse configuration, where three platforms joined the Modelverse and talk to each other via the ModelFed protocol. In this scenario, users collaboratively design the model at runtime, using different notation: the Admin and the Industrial engineer work graphically, while the Materials scientist interacts through a tabular view. This heterogeneity is naturally supported by Modelverse, where each platform manages its own concrete syntax and user interface for model representation. Additionally, platforms can store and maintain their local representation of the complete model or specific portions, depending on the user’s needs.

Fig 1. Collaborative modeling in Modelverse

ModelFed Vocabulary

Communication between modeling platforms in Modelverse is based on JSON-LD messages structured using the ModelFed vocabulary, an extension of the ActivityStreams vocabulary. Our vocabulary focuses on defining a JSON-LD syntax for structural conceptual models, drawing inspiration from the UML specification. The following figure illustrates the main concepts and relationships of the vocabulary.

Fig 2. ModelFed Vocabulary

• ModelElement, which inherits from Object, is an abstract concept that serves as a general representation of any element within a model. This includes fundamental constructs like Classes, Enumerations, Associations, and Generalizations.

• Activities are among the most important concepts in Modelverse, as they allow the specification of actions performed on any Object. ModelFed defines or reuses five activities: Create, Update, Delete, Reclassify, and Clone. Each Activity links to one Object (on which the action is performed), one or more Actors who execute the action, and a list of Actors to federate the activity to. Check the following example that creates the attribute ‘UID’ for the ‘ProductPassport’ class.

Fig 3. Example of Create Activity

• Actors represent persons, organizations, services, or applications with the capacity to perform Activities on a model. Grants specify which actors are authorized to perform certain types of activities on specific model elements.

Runtime Implementation of ModelFed

The integration of modeling platforms within the Modelverse is mediated by a Platform Connector, which orchestrates bidirectional synchronization of modeling activities. The following figure details the connector’s architecture, specifying the core components required for implementation:

Fig 4. Platform connector architecture

The platform-to-platform communication in Modelverse is handled by RESTful inbox and outbox endpoints for exchanging JSON-LD activities. The Activity Transformer bridges platform-specific events and the federation protocol, featuring a Serializer that converts internal events into standardized ModelFed JSON-LD activities and a Deserializer that translates incoming activities back into platform-specific API calls.

To ensure security and reliability, an Access Validator enforces authorization by checking actor grants against target model elements. For fault tolerance, a Retry Handler manages delivery failures by queuing activities and retrying with an exponential backoff policy, logging errors and notifying users after repeated failures.

Validation

To validate ModelFed, we conducted two experiments simulating a real-world collaborative modeling scenario based on the Digital Product Passport (DPP).

The first experiment assessed interoperability and consistency. We simulated three experts (an Admin, a Materials Scientist, and an Industrial Engineer) using two different modeling platforms (BESSER and PyEcore) to collaboratively build a model through 50 modeling actions. Despite varying the order of actions across eight test sequences, the protocol successfully federated all activities, and all platforms consistently maintained an identical and correct final model, demonstrating effective cross-platform collaboration.

The second experiment evaluated performance and scalability under stress. We measured the processing time while increasing both the number of modeling activities and federated users. Results showed that performance remains strong (under 500ms) for realistic loads of up to 50 concurrent activities with 20 users. Performance only degrades at very high, unrealistic volumes of activity, confirming the protocol’s efficiency for practical human-driven modeling tasks.

Summary

In summary, our research demonstrates that ModelFed is a practical protocol for enabling real-time collaboration between different modeling platforms. It allows tools to maintain their own interfaces and data while synchronizing changes effectively.

For a deeper look at the technical details of ModelFed, the validation experiments, or how the protocol could be adapted for other domains, the full paper provides comprehensive information.