Overview & privacy

RDF Lens reads ENTSO-E CIM / NC profile vocabularies in RDFS (RDF/XML) and helps explore, search, compare, validate and build instance files.

• Parsing, comparison, SHACL validation and the Visual Builder all run inside the browser.
• Imported profiles are stored in this browser's local database (IndexedDB), not uploaded to a server. Removing them in Import deletes them locally.
• Files dropped in RDF Comparison → Folders and in SHACL Validation are processed locally and are not added to the Library.
• Data and backup exports everything stored locally to a JSON backup file and can restore it. Restore merges, it does not wipe existing data.

Import — how a profile is read

Import reads one or more RDF/XML vocabulary files into the browser's local Library and groups them by the version declared inside each file.

• Accepted input is well-formed RDF/XML files (.rdf/.xml) up to 15 MB each. Anything that is not valid XML is rejected with an error.
• Every top-level element of the file is one resource. Relative identifiers are resolved against the file's xml:base.
• Classes typed rdfs:Class or owl:Class are recorded as defined classes. Types that are only referenced — used as rdf:type but never declared — are kept as referenced classes.
• Attributes and associations are attached to a class through rdfs:domain. For each one, the app reads label, description, data type or range, multiplicity, stereotypes and association information (AssociationUsed, inverse role).
• Required means a multiplicity starting with at least 1, for example M:1..1, M:1..n. M:0..1 and M:0..n are optional.
• An item is an association when it has an inverse role or AssociationUsed; it is an attribute when it has a data type or the “attribute” stereotype. The stereotype deprecated marks deprecated items.
• Profile metadata comes from the header (owl:Ontology or md:FullModel): version from owl:versionInfo, profile name from dcterms:title (or dcterms:conformsTo), and the coordinated release token such as NC24v18 found in conformsTo.
• The Import page groups files by that declared version. A file without a header shows under No version detected.
• Duplicates are checked by content, not by file name: a file identical to one already imported is skipped; a file with the same profile and the same declared version but different content asks whether to replace the existing one, keep both or skip. Duplicates imported earlier are flagged in Import with a Remove duplicates action that keeps the first imported copy.

Explorer

Explorer shows one imported profile at a time. It is the main view for reading a class definition, its inherited properties and its local data records.

• Pick an imported profile; the class list can be filtered by kind and searched by name or URI.
• Kinds are datatype (stereotype CIMDatatype, or used as the data type of an attribute in that profile), enumeration (enumeration stereotype), primitive (Primitive stereotype), otherwise class.
• Class detail shows the description, superclass and full inheritance path, attributes and association ends, the original XML of the definition, and data records found in the same file (first 50 rows, first 5 columns).
• Inherited attributes are included by walking up the superclass chain, also across other imported profiles. A child's declaration overrides an inherited one with the same name. Each attribute says which class declares it.
• Attribute filters: required, optional, not included (AssociationUsed = No), relationships, deprecated. Multiplicities are shown in plain words, for example M:1..1 → “Exactly one value required”, M:0..1 → “One value allowed”, M:0..n → “Multiple values allowed”.
• If a more complete definition of the same class exists in another imported profile, the Explorer offers to open it.
• The connections graph shows the selected class, its superclass and subclasses (inheritance), associations in and out, and where it is used as a datatype. Association ends not used in this profile are shown dashed and can be hidden. Classes referenced but not imported are greyed out.

Global search

Global search looks across every imported profile at once, for class-level and attribute-level text matches.

• Searches class names, URIs, descriptions and stereotypes, plus attribute names, URIs, descriptions, ranges and data types. Matching is “contains”, case-insensitive.
• Ranking puts exact name matches first, then names starting with the query, then URI matches, then matches in other fields. Classes rank slightly above attributes at the same level.
• The result list shows the first 250 results while the counter shows the total. Filters are all, classes and types, and attributes and relationships.

RDF Comparison — Imported versions

This mode compares two imported version groups from the Library, profile by profile. It is a structural comparison for a quick review, not a full line-by-line diff.

• Compares two imported versions (the version groups from Import). A profile can only be selected if the other version contains the same profile; selecting a file selects its counterpart automatically.
• Profiles are paired by the profile name in the header with the version number removed, falling back to the file name.
• Compares structure: classes added or removed, attributes added, removed or moved between classes, namespace changes, superclass changes, and attribute definition changes (data type, multiplicity, required, deprecated, attribute vs association).
• It does not compare descriptions, labels, stereotypes, packages or header metadata, and a renamed class appears as removed plus added. Use Folders mode for a complete, line-by-line comparison.

RDF Comparison — Folders

Folders mode compares two entire folders, such as two ENTSO-E release packages. It pairs profiles by content and reports every changed RDF statement.

Loading and pairing

• Drop or choose two whole folders. Sub-folders are read; only .rdf/.xml files that define at least one class are used. Profile descriptors (PROF), ENTSO-E diff files, SHACL (.ttl), PDFs and spreadsheets are ignored and listed as such.
• Profiles are paired by content, never by file name: by the ontology title (dcterms:title), or the ontology IRI without version, or, as a last resort, the set of class names.
• If a folder contains the same profile twice, the highest declared version is kept and a warning lists what was discarded.
• Direction: the app always compares older → newer, whichever slot each folder was dropped in. It decides which folder is older from the versions declared inside paired profiles, using the dcterms:modified date as a tie-break. It shows a notice and lets you force the slot order (A → B).

Profile status

Each paired profile gets a status, and warnings are shown when version numbers and content do not move together.

Identical

Same content (all triples), even if file names differ.

Header only

Only the ontology header changed (version, identifier, dates, conformsTo); the vocabulary itself is identical.

Changed

The vocabulary differs between the two folders.

Only in older / newer folder

The profile exists in one of the two releases only.

• Warnings include content changed without version bump and version bumped, vocabulary unchanged.
• This is what reveals that a release package can still ship an older version of a profile.

The diff

• The diff is line by line at RDF triple level: every added or removed statement of every class, attribute, enumeration value, package and the header. A changed value appears as old → new.
• The result is validated against ENTSO-E's official RDFS comparison files: for all 18 NCP profile pairs published with release 2.5 the diff reproduces every official row. Where the official file differs (rows repeated, or a value reported as added although it exists unchanged in both versions), the difference is in the official file and is reported separately during validation.
• For readability, text changes show only the words that changed, and many items with exactly the same change are grouped, for example Same change on 27 items.

Renamed items

• An item removed under one identifier (IRI) and added under another is shown as one modified item with an IRI (renamed) line when the match is unambiguous: packages and classes with the same label, attributes with the same name in the same owner class, enumeration values with the same Enum.value.
• Example: ae:Package_AssessedElementProfile → ae:AssessedElementProfile.
• Lines that only point to something renamed, such as a class's package, are tagged follows rename.

Filters

• Inside a profile, combinable filters cover Change (new / removed / modified), Item (classes, attributes, enumeration values and packages, header), and Impact.
• The +N / −N / ~N counters and the impact counts on each profile row are shortcuts to these filters.

Operational impact

Each change line is classified, and an item takes its most severe level. This classification is RDF Lens's own; ENTSO-E does not publish an impact classification.

Only operational impact hides profiles whose changes are all editorial.

Global moves

Global moves, in Folders mode, looks across all profiles in both folders at once to explain what happened to things that disappeared.

• A move pairs something that disappeared in the older folder with something that appeared in the newer folder with the same name or IRI.
• Evidence includes: same IRI, same data type, same multiplicity, similarity of the description (shared words), whether the name is generic (for example name and mRID appear in many classes), and class context. Moving up to a superclass or down to a subclass counts in favour; leaving a class that still exists for an unrelated class with no inheritance link counts against and is never high.
• Pairs are assigned one-to-one, best evidence first.
• High confidence means strong evidence and no near-equal alternative. Possible means weaker evidence or alternatives — review those. When several attributes take the same class-to-class route and their multiplicity matches, they confirm each other.
• Class moves: a class whose attributes went together to a new class is shown as renamed / replaced, with those attributes nested under it. Example: PowerCapacity in Steady State Instruction → GridPowerCapacityRegularSchedule in State Instruction Schedule, with 8 attributes. Namespace-only changes are shown too.
• Hierarchy changes: same class, same profile, new superclass (moved in the hierarchy), plus superclass added or removed. These match ENTSO-E's official change files (KGCL “move” entries) 8/8 for Equipment Reliability 2.4.2 → 2.5.
• The profile flow diagram links profiles, sized by the number of moved items. Blue links cross profiles, amber links stay inside one profile. Click a link to list its moves.
• Dropped from a profile but still defined elsewhere lists items that left one profile but still exist in others.

SHACL Validation

SHACL Validation checks RDF/XML instance files against the ENTSO-E SHACL shapes bundled with the app.

• Instance files can be up to 15 MB. There are simple and complex shape variants per profile; complex also includes shared global shapes.
• The profile of each file is detected from its dcterms:conformsTo. If it is not detected, you pick it before validating.
• You can upload your own shapes (.ttl), either replacing or adding to the bundled ones for a profile. Uploaded shapes are stored only in this browser.
• Validation runs in background workers in the browser, up to 4 in parallel.
• Results are counted by severity: Violation, Warning, Info. Following the SHACL specification, only Violations make a file non-conforming; warnings and infos are shown but do not fail it.
• If the shape version does not match the profile version, a warning says the results may not fully apply.

Visual RDF Builder

The Visual RDF Builder creates example RDF/XML instance files from an imported profile, either guided step by step or freely on a canvas.

• Only concrete classes can be created; abstract classes, datatypes and enumerations cannot.
• Connections are only allowed when the target class matches the association's range, including subclasses, and multiplicity maximums are enforced.
• It uses the selected profile plus the related profiles it depends on from the same release (same NC release token), keeping one version per profile.
• Output is one RDF/XML document per profile involved, with a md:FullModel header (identifier, dates, conformsTo of the source profile and its version) and rdf:ID / mRID per object.
• Values are placeholders that describe the expected type, for example “String (free text)”. The export is a template, not a real exchange document.
• Checks before download: required values, minimum connections, external references (System Operator references must be a 16-character EIC code starting with 10X or an absolute URI — format check only), plus SHACL validation of the generated files. Download is blocked while errors remain.

CSA Mapping

CSA Mapping works on the CSA Mapping workbook (.xlsx).

• The UseCases sheet defines the scenarios (CorNET_… rows) and which profiles each scenario uses (USED / NOT DECISIVE / NOT USED / NEEDED); per-profile sheets list classes and attributes.
• Workbook profiles are cross-checked against the imported RDF profiles by matching class and attribute names, normalised to letters and digits only, case-insensitive.
• Viewers can open their own workbook read-only. It is processed locally and nothing is saved.
• Users propose changes with a justification (Send for approval). Moderators review and approve or reject, and maintain the approved base. A request based on an older approved version cannot be approved and must be resubmitted.

Limitations

RDF Lens reports what is written in the files. Some interpretations are heuristic and are labelled as such.

• The tool reads what the files say; it does not know the modelling intent behind a change.
• Name-based matching used for rename pairing, moves and the CSA cross-check is a heuristic. Possible confidence and the evidence chips show how confident a result is.
• Only RDF/XML is read for profiles; Turtle is used for SHACL shapes only. Maximum file size is 15 MB.