Architectural Clarifications in the SEMIC Style Guide
Architecture provides the structure for building robust and interoperable systems. It turns ideas into clear rules and standards so that people, systems, and machines can understand and use the same data.
The SEMIC Style Guide, developed by the European Commission, provides a rigorous and practical framework to ensure that semantic data specifications are clear and actionable across EU Member States.
As Meaningfy was privileged to contribute to this guide, I’ll walk you through its architectural clarifications and the practical principles and methodologies that enable SEMIC’s standards to serve business users, developers, and systems seamlessly.
This section introduces 7 foundational concepts you need to know:
1. Understanding the Consumer Context
How SEMIC aligns business users, developers, and systems to “speak the same language.”
2. Understanding the Editorial Context
The role of editors is to create data specifications that are clear, usable, and maintainable.
3. Separation of Concerns
Why addressing different needs—domain, technical, and validation—ensures precision without confusion.
4. Addressing the Editorial Synchronization Problem
How SEMIC uses UML conceptual models as the single source of truth to keep all artefacts in sync.
5. Transforming UML Conceptual Models
How the single source of truth (SSOT) simplifies maintenance and delivers reliable, consistent outputs for different needs.
6. Artefacts and Data Specification Types
A closer look at Core Vocabularies (CVs), Application Profiles (APs), and the artefacts that make them work.
7. Connecting the Semantic and Technical Layers
How SEMIC bridges meaning with implementation, ensuring systems remain interoperable regardless of technology.
Each section builds on the last, explaining how the SEMIC framework ensures semantic clarity, seamless integration, and system-wide consistency. By the end, you’ll see how these architectural clarifications are helping EU systems to share and interpret data reliably without ambiguity or errors.
1. Understanding the Consumer Context
The SEMIC Style Guide is designed with three core consumer groups in mind:
➡️ Business Users and Domain Experts (the people who need to understand the concepts, processes, and real-world context).
➡️Technical Experts (the software engineers and architects who are responsible for implementing those concepts into working systems).
➡️Machines (the systems themselves that need to exchange, interpret, and act on data).
The challenge is ensuring all three groups “speak the same language.”
This is why we use semantic data specifications. By clearly defining concepts, relationships, and rules, SEMIC ensures that:
➡ Business experts define what is expected.
➡ Developers translate these expectations into systems.
➡ Machines deliver results that match the original intent.
🟢 Standardized data ensure that systems can share, reuse, and interpret it accurately, preserving its meaning throughout. This is true interoperability in action.
2. Understanding the Editorial Context
The purpose of this style guide is to ensure that data specifications are clear, consistent, and usable for everyone, whether it’s domain experts, developers, or the systems themselves. It’s primarily designed for those who create and manage these specifications, like semantic engineers, data architects, and knowledge modeling specialists.
To achieve this synergy, SEMIC emphasizes:
➡ Graphical Representations – Conceptual models (like UML diagrams) make it easier to bring domain experts and editors onto the same page.
➡ Clear Documentation – Well-articulated specifications help both developers and business users understand what the data means and how it can be used.
🟢 This editorial process ensures that the final specification is machine-readable and human-understandable. This is an essential step toward adoption and reuse.
3. Separation of Concerns
George Box famously said, “All models are wrong, but some are useful.” In practice, a single model cannot address all concerns at once. Different stakeholders, like domain experts, editors, and developers, require different levels of detail.
To solve this, the SEMIC Style Guide adopts the principle of separation of concerns, inspired by the OMG Model-Driven Architecture (MDA):
➡ Conceptual Models – Represent the domain knowledge. These are expressed in UML to capture the shared conceptualization of terms and relationships.
➡ Ontologies – Translate these models into machine-readable specifications using OWL 2, enabling systems to process and interpret them.
➡ Data Shapes – Add constraints to ensure data validity and consistency. These are expressed in SHACL.
➡ Documentation – Human-readable guides, usually in HTML, make the specification accessible and actionable for stakeholders.
🟢 When we address these concerns separately, we ensure that both humans and machines get precisely what they require while maintaining consistency and avoiding any confusion.
4. Addressing the Editorial Synchronization Problem
Managing multiple artefacts, such as conceptual models, ontologies, data shapes, and documentation, can easily become a maintenance nightmare. A single change in one artefact could ripple across all the others, creating inconsistency and errors.
To solve this, SEMIC proposes using UML conceptual models as the single source of truth.
The UML model serves as the pivot representation.
Other artefacts (ontologies, SHACL constraints, HTML documents) are derived from this source.
Updates are made in one place and propagated automatically.
This method:
➡ Reduces errors.
➡ Simplifies maintenance.
➡ Ensures all artefacts remain synchronized.
🟢 Imagine updating the definition of “Public Organisation” in a UML conceptual model. With this approach, the change flows into the OWL ontology, SHACL constraints, and HTML documentation without manual intervention.
5. Transforming UML Conceptual Models into Single Source of Truth (SSOT)
The single source of truth distills the core elements of a domain into one clear, consistent model. From there, it can be transformed into different representations, each serving a specific purpose or audience without losing coherence or meaning.
SEMIC uses UML conceptual models as the starting point because they are expressive enough to serve domain experts while structured enough to allow for the automatic generation of artefacts.
The conceptual model ensures alignment instead of creating artefacts separately and risking inconsistencies. When the UML model is updated, the changes propagate automatically to derived artefacts like ontologies (OWL), data shapes (SHACL), and specification documents (HTML).
This approach reduces manual effort, eliminates errors, and ensures that all components stay synchronized over time.
🟢 Imagine a “Location“ concept defined in UML. From this single model:
➡ OWL defines the machine-readable ontology, describing “Location” as a formal class.
➡ SHACL applies constraints, such as requiring a mandatory “City“ name.
➡ HTML generates the documentation explaining the concept in human-readable terms.
6. Artefacts and Data Specification Types
The SEMIC Style Guide organizes data specifications into two main types:
➡ Core Vocabularies (CVs) – Lightweight, reusable models for broad contexts.
➡ Application Profiles (APs) – Context-specific refinements that add constraints and rules for specific use cases.
Each data specification consists of a set of artefacts, including:
➡ Conceptual Models – UML diagrams for clarity.
➡ Ontologies – OWL 2 specifications for machines.
➡ Data Shapes – SHACL constraints for validation.
➡ Documentation – HTML guides for humans.
🟢 Publishing artefacts in multiple formats ensures that data specifications are both reusable and implementable across diverse systems and contexts.
7. Connecting the Semantic and Technical Layers
While the semantic layer defines meaning and relationships (like concepts, ontologies, and constraints), the technical layer deals with implementation specifics and how data is represented, transmitted, and accessed.
The SEMIC Style Guide harmonise these two layers using standards like:
➡ RDF for Semantic Web-based implementations.
➡ JSON-LD for aligning JSON structures with semantic models.
➡ XML and XSD for XML-based systems.
🟢Aligning semantic meaning with technical implementation ensures systems remain interoperable, regardless of the technology stack.
Conclusion
The SEMIC Style Guide’s architectural principles provide a structured, scalable approach to building semantic data specifications. It is straightforward and no-nonsense. It separates the key concerns, keeps everything aligned, and ensures all the pieces stay in sync. The result? Systems across the EU can share data, interpret it correctly, and work together without setbacks.
The European Commission created the SEMIC Style Guide, and at Meaningfy, we’re proud to have been involved in developing this framework.
Meaningfy continues to support the European Commission’s initiatives, leading the charge toward a transparent, efficient, and interconnected European public sector. If you represent a European Institution or a public company that needs to implement an interoperability solution, contact us for tailored support and effective implementation.