Features Reference
A structured checklist of what RDFArchitect does, organised by the role most likely to care about it. Each feature links to the full explanation in the User Guide where appropriate.
For electrical engineers and CIM modellers
Import a CGMES / ENTSO-E profile
Open .rdf, .ttl, or .nt files directly from the UI. Every file becomes one graph inside a workspace of your choice. Multiple profiles from the same release (EQ / TP / SSH / SV, or the different Network Code Profiles) can live side-by-side in one workspace.
Navigate a schema by package
The navigation tree mirrors the UML package structure of the profile. The diagram canvas always shows exactly the package you selected, with associations that cross into other packages drawn at the boundary.
Inspect a class in full
The class editor shows label, URI namespace, package, super class, stereotypes («enumeration», «CIMDatatype», «Primitive», «Compound», …), AsciiDoc comment, all attributes, all associations, enum entries if applicable, and class-level constraints (SHACL) — all on one page.
Create and edit classes, attributes, associations, enum entries
Full create/update/delete for every modelling element, with inline validation (duplicate label/namespace combinations, duplicate URIs, invalid characters, cardinality conflicts).
Attribute datatypes and ranges
Attribute datatypes and ranges can come from CIM primitive types, CIM datatypes, enumerations, or XSD base types.
Enum entries as first-class content
When a class carries the «enumeration» stereotype, its enum entries appear as an ordered list in the class editor. Each entry has label, URI, and comment and is exported as SHACL sh:in automatically.
Work with the profile header
Edit the ontology metadata block (title, version, conformsTo, keyword, license, description, …). A library of known ENTSO-E and DCAT fields can be added with one click.
UML-style diagrams
Diagrams render classes with full attribute and association detail, inheritance arrows, stereotypes, and cardinalities. SvelteFlow is the default renderer (pan/zoom/auto-layout); Mermaid is available as an alternative, for example for embedding in Markdown-based documentation.
Visualise SHACL constraints on the class you are looking at
Every attribute and association row in the class editor has a SHACL icon that opens exactly the constraints that target that property on that class. No need to grep through a SHACL file.
For software architects and schema maintainers
Workspace / graph / package model
Many in-memory workspaces, many graphs per workspace, many packages per graph. The hierarchy is enforced by the UI and by the REST API, and every edit is scoped by it.
Namespace management
Per-workspace namespace table with validation for unique prefixes. Prefixes can be added, renamed, and deleted. Export honours the active namespace table.
Undo, redo, and version history
Graph edits are journaled. Up to 256 versions per graph by default; older states are compressed as history grows. Undo and redo are global per graph and available via menu and keyboard shortcut.
Changelog view
A dedicated page that lists the change history of a graph: additions, updates, deletions, grouped by class, with full triple-level diff (green for additions, red for deletions) for each change.
Restore previous versions
Roll a graph back to any earlier tracked state from the changelog.
Schema comparison
Three-way compare: stored↔stored, upload↔stored, upload↔upload. Package-level and class-level summary with drill-down into attributes, associations, enum entries, and comments. Whitespace-normalised comment diffs avoid noise.
Schema migration wizard
A seven-step wizard that turns the difference between two schema versions into a SPARQL UPDATE script:
- Select source and target schemas, with the CGMES version of each side and an optional ignore prefixes mode for namespace bumps.
- Validate both schemas side by side.
- Confirm class renames.
- Confirm attribute / association / enum entry renames.
- Choose default values — literals for attributes, SPARQL target mappings for associations, replacement entries for deleted enum values. Datatype changes can be declared value-preserving, and a required default can be knowingly waived.
- Review all changes and comment them.
- Generate and download the artefacts.
The script can be run against any SPARQL 1.1 endpoint to migrate instance data from the source schema to the target. It is shipped as a package together with the generated SHACL of the target schema, so the migrated data can be verified immediately.
Migration report
Every migration can be exported as a Markdown migration protocol that records what the script does and why. It contains the validation state of both schemas, a count of added, deleted, and changed classes, and one section per class with its field changes spelled out as sentences, the comments entered during the review step, and explicit warnings — for example associations whose targets may have become invalid through a superclass change. Two variants are available: a summary that states each change once and names the affected concrete subclasses, and a detailed report that repeats inherited changes under every affected concrete class.
SHACL generation
SHACL shapes are generated automatically from the schema. They include, among other things, constraints for association multiplicities and attribute datatypes, and stay in sync with the current graph.
Custom SHACL side-by-side
Import the official SHACL of a CGMES/ENTSO-E release and store it next to the generated shapes. Custom SHACL can be edited freely and is not regenerated when the schema changes. Both sets are visible at graph level and at class level.
Read-only workspaces
A toggle that locks a workspace against all editing actions. Imported workspaces and snapshot views are read-only by default, and can be unlocked with Enable Editing when changes are needed.
Snapshots
One-click immutable copy of a workspace, stored in Fuseki, reachable by a URL with a base64 token. Anyone with the URL can load the full workspace — navigation, diagrams, SHACL — as a read-only workspace without installing anything. The loaded workspace can be made editable, but the stored snapshot is not modified.
Export
Every graph can be exported to RDF/XML, Turtle, or N-Triples, using the active namespace table and an optional auto-generated profile header placed as the first resource (matching ENTSO-E release conventions). SHACL can be exported separately as TTL.
Open REST API
Every feature in the UI is backed by a REST endpoint. Swagger UI is served at /swagger-ui.html on the backend and lists every operation with full request/response schemas. This makes RDFArchitect scriptable for CI pipelines (e.g. export a canonical representation on every commit, run a diff in a pull request, generate a release note from the changelog).
For project managers and product owners
Sharing and review
Snapshots let you hand a complete, navigable view of a profile to a stakeholder without installing software, without sending RDF files, and without risk of accidental edits. This is the primary feature for review cycles between modellers and non-modellers.
Changelog and release notes
Every tracked graph change is listed with the added, updated, or deleted content. The changelog view in the UI is directly usable as a starting point for release notes.
Compare releases
The compare view produces a structured difference between two schema versions that can be read at package level, at class level, or drilled down to attribute level. Suitable for a release readiness meeting.
Migration planning
The migration wizard externalises every decision that has to be made to migrate instance data from one profile version to the next: class renames, property renames, defaults for new fields. The output is a reviewable SPARQL script that can be run in a controlled way on staging data before touching production, plus a migration report — a Markdown protocol of every change and of the decisions and comments behind it. The report is directly usable as the migration section of a release note, as the document a migration is signed off against, and as the record kept with the migrated dataset.
No vendor lock-in
Apache 2.0 licence. Data is RDF throughout; imports and exports are standard W3C formats. Snapshots are stored in Apache Jena Fuseki. The generated migration scripts are plain SPARQL. Nothing in the tool chain is proprietary.
Predictable dependencies
Spring Boot backend, SvelteKit frontend, Apache Jena, Apache Jena Fuseki. All mature, widely adopted, and available as container images.
Feature-by-feature: where in the UI
| Feature | Location |
|---|---|
| Import schema (RDFS) | File → Import → Schema (RDFS) |
| Import SHACL | File → Import → Constraints (SHACL) |
| Export schema | File → Export → Schema (RDFS) |
| Export SHACL | File → Export → Constraints (SHACL) |
| Share snapshot | File → Share Snapshot |
| Delete schema | File → Delete → Schema |
| Delete workspace | File → Delete → Workspace |
| Rename workspace | Edit → Rename → Workspace |
| Rename schema | Edit → Rename → Schema |
| New class | Edit → New → Class |
| New package | Edit → New → Package |
| New empty schema | Edit → New → Schema |
| Edit profile header | Edit → Edit → Profile Header |
| Edit package | Edit → Edit → Package |
| Undo / Redo | Edit → Undo / Redo (Ctrl+Z / Ctrl+Y) |
| Enable / Disable editing | Edit → Enable / Disable Editing |
| Edit namespaces | Edit → Edit Namespaces |
| Delete profile header | Edit → Delete → Profile Header |
| Delete package | Edit → Delete → Package |
| Changelog | View → Changelog |
| Compare schemas | View → Compare Schemas |
| Migrate schema (7-step wizard) | View → Migrate Schema |
| Full SHACL view (generated+custom) | View → View Constraints (SHACL) |
| Help / feedback / about | Help menu |
| Search across the workspace | Search bar at the top |
| Property-specific constraints (SHACL) | Class editor → SHACL icon next to each row |
| Class-level constraints (SHACL) | Class editor → SHACL section |
| API documentation (Swagger UI) | http://<backend-host>:8080/swagger-ui.html |
Current limitations (as of 1.0.0)
- The migration script generator does not yet handle every edge case; multiplicity changes on associations in particular need manual review. It is strongly recommended to validate migrated data against the target profile's SHACL with an external validator after running the script. The migration report flags the cases it knows it cannot decide, such as association targets invalidated by a superclass change.
- Snapshots cannot currently be deleted via the UI.
- Access control is per-snapshot-link; there is no built-in user management. For multi-user deployments this is typically handled by putting the service behind an SSO-capable reverse proxy.