Skip to content

libis/cdi-viewer

Folders and files

NameName
Last commit message
Last commit date

Latest commit

Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 

Repository files navigation

JSON-LD Viewer & Editor with SHACL Validation

A powerful, browser-based JSON-LD editor and SHACL validator for any RDF vocabulary

Interactive viewer and editor for JSON-LD metadata with real-time SHACL validation. Originally developed for DDI-CDI (Data Documentation Initiative - Cross Domain Integration) and CDIF (CDI Foundation), but works with any JSON-LD vocabulary and SHACL shapes including schema.org, DCAT, DataCube, SKOS, and custom ontologies.

Provides real-time validation, property classification, complex object editing, and array management directly in the browser. Perfect for researchers, data curators, and developers working with semantic web standards.

Live Demo License GitHub Topics

πŸ“š What is DDI-CDI?

  • DDI Alliance = International membership organization (since 2003) including:
  • DDI = Data Documentation Initiative - the metadata standard they maintain
  • CDI = Cross Domain Integration - the newest DDI specification (Version 1.0 released January 2025)
    • Designed for cross-domain interoperability (not just social sciences anymore)
    • Built on semantic web technologies (RDF, JSON-LD) - machine-readable and linkable
    • Enables data from different domains to be combined and compared

Why DDI-CDI Matters

  • Authoritative standard - backed by major institutions who actually use it
  • FAIR data principles - helps make data Findable, Accessible, Interoperable, Reusable
  • Future-proof - semantic web approach means data stays meaningful over time
  • Growing adoption - increasingly required by funders and data repositories

The Problem This Solves

  • JSON-LD files are complex nested structures - hard to edit manually
  • SHACL validation typically requires command-line tools or enterprise software
  • No easy way to visually see if your metadata is valid
  • Existing tools are either too simple (text editors) or too complex (enterprise RDF tools)
  • Dataverse gap - While Dataverse supports the DDI Codebook metadata standard, there's no built-in support for the newer DDI-CDI semantic web format

What is CDI-Viewer?

  • Browser-based JSON-LD editor with real-time SHACL validation
  • Works with any vocabulary (DDI-CDI, schema.org, DCAT, SKOS, etc.)
  • No installation required - runs entirely in the browser
  • Can integrate with Dataverse or work standalone

🎯 Why This Tool?

The problem: Most JSON-LD editors are either too simple (plain text editors) or too complex (enterprise RDF tooling). Validating against SHACL shapes often requires command-line tools or separate validation services.

This solution:

  • ✨ Visual editing - See and edit your JSON-LD structure as nested, collapsible cards
  • βœ… Instant validation - Real-time SHACL validation with color-coded feedback
  • 🎨 Smart UI - Input fields adapt to SHACL constraints (dates, numbers, enumerations)
  • πŸ”— Complex objects - Create nested objects and references with modal helpers
  • πŸ“Š Array support - Convert between single/array values, manage reference lists
  • πŸš€ No installation - Runs entirely in the browser, no server needed
  • πŸ”Œ Extensible - Integrate with Dataverse or use as standalone tool

Perfect for:

  • Data curators working with schema.org Dataset markup
  • Researchers creating DDI-CDI metadata
  • Developers testing SHACL validation rules
  • Anyone editing complex JSON-LD with nested structures

✨ Features

🌐 Generic JSON-LD Support

  • Any JSON-LD vocabulary - schema.org, DCAT, DataCube, SKOS, FOAF, Dublin Core, and more
  • Custom SHACL shapes - Load validation shapes from any URL or local file
  • Standard JSON-LD processing - Uses W3C JSON-LD algorithms (jsonld.js)
  • Vocabulary-agnostic editing - Works with any RDF ontology
  • Namespace flexibility - Handles prefixed and expanded forms

✏️ Advanced Editing Capabilities

  • Smart input types based on SHACL datatype constraints (text, number, date, URI, etc.)
  • Complex object support with nested node creation and inline editing
  • Reference management - Link to existing nodes or create new blank nodes
  • Array operations:
    • Convert single value ↔ array
    • Add/remove array items
    • Support for both value arrays and reference arrays
  • Property management with searchable SHACL-based dropdowns
  • Cardinality enforcement respecting SHACL min/maxCount
  • Delete protection for required fields (SHACL sh:minCount > 0)
  • Custom properties - Add properties not defined in SHACL shapes
  • Namespace management:
    • View and add custom namespace prefixes
    • Remove custom namespaces (built-in protected)
    • Integration with property/node creation
  • Document creation - Create new JSON-LD documents from scratch with shape-specific contexts
  • Unified add component - Consistent UX for adding properties and root nodes

βœ… Validation

  • Real-time SHACL validation using Core SHACL features
  • Visual indicators showing validation status
  • Detailed reports with actionable feedback
  • Property suggestions for missing fields

πŸ” Advanced Search & Filter

  • Enhanced search:
    • Search counter ("X of Y matches")
    • Case-sensitive and regex modes
    • Previous/Next navigation
    • Keyboard shortcuts (F3, Shift+F3, Enter)
    • Current match highlighting
  • Comprehensive filters:
    • Node type filter
    • Validation status filter
    • Property status filter (SHACL/extra)
    • Hide empty properties
    • Search scope selection (names/values/IDs/types)
  • State persistence - Filter settings saved across sessions

πŸ’Ύ Data Management

  • Load local files for standalone editing
  • Load from Dataverse with URL parser (6 formats supported)
  • Save to Dataverse with smart visibility:
    • Standalone mode: Always visible (can save to Dataverse anytime)
    • Embedded mode: Visible only when changes exist (already viewing from Dataverse)
    • Reactive updates via change tracking
  • Export JSON-LD with all modifications
  • Change tracking with visual indicators

πŸš€ Quick Start

Try It Now (No Installation)

Live demo: https://libis.github.io/cdi-viewer/

Quick workflow (DDI-CDI mode - default):

  1. Click "Load Local File" β†’ select any JSON-LD file
  2. DDI-CDI shapes are preloaded automatically
  3. Click "Enable Edit Mode" to start editing
  4. Add/edit/delete properties with visual feedback
  5. Click "Export JSON-LD" to download your changes

For other vocabularies:

Common Use Cases

Vocabulary Use Case SHACL Shapes
schema.org Dataset markup for Google Dataset Search Built-in or custom
DDI-CDI Social science data documentation ddi-cdi-official (built-in)
DCAT-AP EU open data catalog metadata dcat-ap-3.0 (built-in)
DataCube Statistical data cubes w3c-datacube (built-in)
SKOS Thesauri and taxonomies skos (built-in)
Custom Your own ontology Provide SHACL URL

Example Workflow: Editing schema.org Dataset

# 1. Start with minimal JSON-LD
{
  "@context": "https://schema.org/",
  "@type": "Dataset",
  "@id": "http://example.org/dataset/1",
  "name": "My Dataset"
}

# 2. Load in the viewer
# 3. Add properties via the dropdown: description, keywords, creator
# 4. Create nested objects: creator β†’ Person with name, affiliation
# 5. Validate against schema.org SHACL shapes
# 6. Export complete, validated JSON-LD

Example Files

The demo includes DDI-CDI examples in the examples/cdi/ directory:

  • SimpleSample.jsonld - Minimal DDI-CDI example
  • se_na2so4-XDI-CDI-CDIF.jsonld - X-ray spectroscopy data
  • ESS11-subset_DDICDI.jsonld - Comprehensive example

Configuration

Automatic DDI-CDI Mode

The viewer automatically detects DDI-CDI shapes and enables DDI-CDI specific features:

  • When you load SHACL shapes containing ddialliance.org/Specification/DDI-CDI namespace, DDI-CDI mode is enabled
  • This activates legacy context handling, DDICDIModels normalization, and default namespace resolution
  • For other vocabularies (schema.org, DCAT, etc.), the tool operates in generic JSON-LD mode

Detection is version-agnostic and protocol-agnostic - works with any DDI-CDI version (1.0, 2.0, etc.) over http or https.

Manual Configuration (Optional)

You can manually override the default namespace in js/core.js if needed:

// For DDI-CDI:
window.defaultTypeNamespace =
  "http://ddialliance.org/Specification/DDI-CDI/1.0/RDF/";

// For schema.org:
window.defaultTypeNamespace = "http://schema.org/";

// For DCAT:
window.defaultTypeNamespace = "http://www.w3.org/ns/dcat#";

This allows type names without prefixes to be resolved automatically.

Adding Legacy Context Mappings

If you need to handle legacy context URLs (redirecting old URLs to local copies), edit LEGACY_CONTEXT_URLS in js/cdi-json-ld-helpers.js:

const LEGACY_CONTEXT_URLS = {
  "https://old-url.org/context.jsonld": "shapes/local-context.jsonld",
  // Add more mappings as needed
};

Development

Local Development

# Clone the repository
git clone https://github.com/libis/cdi-viewer.git
cd cdi-viewer

# Install dependencies
npm install

# Run tests
npm test

# Check code quality
npm run lint

# Build for production
npm run build

# Start development server
npm run dev
# Open http://localhost:8000

Development with Example File

Load test files via URL parameter:

# Default: DDI-CDI mode (official shapes preloaded automatically)
http://localhost:8000/

# Generic mode (no shapes preloaded - for any JSON-LD vocabulary)
http://localhost:8000/?shacl=generic

# CDIF mode (CDIF Discovery shapes preloaded)
http://localhost:8000/?shacl=cdif-core

# DCAT-AP mode (EU DCAT Application Profile)
http://localhost:8000/?shacl=dcat-ap-3.0

# DataCube mode (W3C RDF Data Cube)
http://localhost:8000/?shacl=w3c-datacube

# SKOS mode (Simple Knowledge Organization System)
http://localhost:8000/?shacl=skos

# Local fallback (built-in DDI-CDI shapes for offline use)
http://localhost:8000/?shacl=local-fallback

Note: Since version 1.0, the viewer defaults to DDI-CDI mode (matching the cdi-viewer name). Use ?shacl=generic for a clean start with any vocabulary.

Testing the Production Bundle

The project includes a test page for the bundled version:

http://localhost:8000/test-bundle.html

This loads dist/cdi-viewer.min.js (44KB minified) instead of individual JS files.

πŸ“– Documentation

Comprehensive documentation is available in the docs/ directory:

πŸ”§ Technical Stack

Libraries

  • jQuery 3.7.1 - DOM manipulation
  • Bootstrap 3.3.7 - UI components
  • N3.js v1.16.x (~150KB) - RDF/Turtle parsing
  • jsonld.js (~130KB) - JSON-LD processing
  • shacl-engine (~1.1MB) - Core SHACL + SPARQL validation

Development Tools

  • Jest - Testing framework with JSDOM
  • Rollup - Module bundler (44KB output)
  • ESLint + Prettier - Code quality and formatting
  • npm scripts - Build automation

NPM Scripts

npm run dev           # Start development server (port 8000)
npm run build         # Build production bundle (dist/cdi-viewer.min.js)
npm test              # Run all tests (26 tests)
npm run test:watch    # Run tests in watch mode
npm run test:coverage # Generate coverage report
npm run lint          # Check code quality (ESLint + Prettier)

Architecture Overview

  • Core SHACL + SPARQL - Full SHACL validation with SPARQL constraints (~1.1MB)
  • ES6 modules - Modern code with proper imports (like shacl-engine examples)
  • Dual bundles - Validation (1.1MB) + App logic (38KB)
  • Modular structure - Separated concerns, incremental ES6 migration
  • Production ready - Configurable logging, clean code
  • Dual deployment - Standalone (GitHub Pages) + Dataverse integration
  • Test coverage - 26 tests preventing regressions

Data Flow & State Management

The editor uses a manual synchronization pattern without automatic data binding frameworks. This design prioritizes simplicity, transparency, and control over edit operations.

Core Data Structures

State Management (state.js):

{
  jsonData: Object|null,      // Current working copy of JSON-LD document
  originalData: Object|null,  // Immutable snapshot for reset functionality
  changedElements: Set,       // Tracks modified properties (composite IDs)
  // ... 12 other state properties
}
  • jsonData - The live working copy that gets modified as users edit
  • originalData - Immutable backup created when loading/creating documents (never modified)
  • changedElements - Persistent Set storing composite IDs like "nodeId.propertyKey"

One-Way Data Flow

The editor follows a unidirectional data flow pattern:

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚  jsonData   β”‚  (Source of truth in state.js)
β””β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”˜
       β”‚
       β–Ό  render.js: createTree()
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚  DOM Tree   β”‚  (Visual representation)
β””β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”˜
       β”‚
       β–Ό  User edits inputs
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚  Modified   β”‚  (Changed properties tracked in Set)
β”‚  DOM State  β”‚
β””β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”˜
       β”‚
       β–Ό  data-extraction.js: collectChangesFromDOM()
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚  jsonData   β”‚  (Synchronized back before save/export)
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

Key Points:

  1. No automatic binding - Changes in DOM don't instantly update jsonData
  2. Explicit sync - Must call collectChangesFromDOM() to sync DOM β†’ jsonData
  3. Change tracking - Modified properties are tracked in a persistent Set
  4. Sync timing - Synchronization happens before save, export, or mode toggle

Change Tracking Implementation

When a property is edited:

// event-handlers.js: Property change handler
$(document).on("change", ".property-input", function () {
  const $propertyRow = $(this).closest(".property-row");
  const nodeId = $propertyRow.attr("data-node-id");
  const propertyKey = $propertyRow.attr("data-property");

  // Mark as changed in UI
  $propertyRow.addClass("changed");

  // Track in persistent Set with composite ID
  addChangedElement(`${nodeId}.${propertyKey}`);
  updateChangedIndicator(); // Show "X unsaved changes"
});

Composite ID structure: "nodeId.propertyKey"

  • Example: "_:b0.name", "http://example.org/dataset/1.description"
  • Allows precise tracking of which properties on which nodes were modified
  • Prevents duplicate tracking (Set automatically handles uniqueness)

Synchronization Process

When to sync - collectChangesFromDOM() is called before:

  1. Save to Dataverse (saveToDataverse())
  2. Export JSON-LD (exportData())
  3. Toggle Edit Mode (from edit β†’ view)

Sync implementation:

// data-extraction.js: collectChangesFromDOM()
function collectChangesFromDOM() {
  // 1. Check if any changes exist
  if (getChangedElementsCount() === 0) return;

  // 2. Parse composite IDs from Set
  const changedIds = getAllChangedElements(); // Returns Set<string>
  // ["_:b0.name", "http://example.org/1.description"]

  // 3. Group changes by nodeId
  const changesByNode = new Map();
  // Map { "_:b0" => Set{"name", "age"}, ... }

  // 4. For each changed property:
  for (const [nodeId, propertyKeys] of changesByNode) {
    const node = getNodeById(nodeId); // Find node in jsonData
    const $card = $(`.node-card[data-node-id="${nodeId}"]`);

    for (const key of propertyKeys) {
      const $input = $card.find(`[data-property="${key}"] input`);
      const value = $input.val(); // Read current DOM value

      // 5. Mutate jsonData directly
      node[key] = value; // In-place update
    }
  }

  // jsonData is now synchronized with DOM edits
  // Note: Changed tracking persists until save/export completes
}

After successful save/export:

// Clear visual indicators and tracking
$(".property-row.changed").removeClass("changed");
clearChangedElements(); // Empty the Set

Why Manual Sync?

Advantages:

  • βœ… Explicit control - Clear when data flows between DOM and state
  • βœ… Performance - No overhead of automatic observers/dirty checking
  • βœ… Transparency - Easy to debug (single sync point)
  • βœ… Simple architecture - No framework complexity, minimal dependencies
  • βœ… Batched updates - Collect all changes at once before sync

Trade-offs:

  • ⚠️ Must remember to call collectChangesFromDOM() before operations that need current data
  • ⚠️ DOM state can diverge from jsonData until explicit sync
  • ⚠️ Requires careful tracking to know when sync is needed

This pattern is ideal for document editing workflows where users make multiple changes before saving, rather than real-time collaborative editing scenarios.

Critical Architectural Rule

⚠️ DO NOT read property values directly from jsonData during editing - the DOM is the source of truth for current values until collectChangesFromDOM() is called.

Correct patterns:

// βœ… Before save/export: sync first
collectChangesFromDOM();
const currentData = getJsonData(); // Now accurate

// βœ… During rendering: read from jsonData (render creates DOM from data)
function renderNode(node) {
  // node comes from jsonData
  createInputForValue(node.propertyKey); // Creates DOM from data
}

Incorrect patterns:

// ❌ WRONG: Reading jsonData during editing without sync
function validateCurrentData() {
  const data = getJsonData(); // Outdated! DOM has unsaved changes
  validateData(data); // Will validate old values
}

// βœ… CORRECT: Sync first, then read
function validateCurrentData() {
  collectChangesFromDOM(); // Sync DOM β†’ jsonData
  const data = getJsonData(); // Now current
  validateData(data);
}

πŸ“ Project Structure

cdi-viewer/
β”œβ”€β”€ index.html              # Main entry point (standalone mode)
β”œβ”€β”€ css/
β”‚   └── cdi-preview.css     # Styles (includes search/filter styles)
β”œβ”€β”€ src/
β”‚   └── jsonld-editor/
β”‚       β”œβ”€β”€ advanced-search.js        # Enhanced search (~240 lines)
β”‚       β”œβ”€β”€ advanced-filter.js        # Filter system (~340 lines)
β”‚       β”œβ”€β”€ unified-add-component.js  # Add UI component
β”‚       β”œβ”€β”€ namespace-manager.js      # Namespace management
β”‚       β”œβ”€β”€ state.js                  # State management
β”‚       β”œβ”€β”€ core.js                   # Initialization
β”‚       β”œβ”€β”€ validation.js             # SHACL validation
β”‚       β”œβ”€β”€ cdi-shacl-loader.js       # Shape loading
β”‚       β”œβ”€β”€ cdi-shacl-helpers.js      # Property classification
β”‚       β”œβ”€β”€ cdi-json-ld-helpers.js    # JSON-LD processing
β”‚       β”œβ”€β”€ cdi-graph-helpers.js      # Graph manipulation
β”‚       β”œβ”€β”€ render.js                 # UI rendering
β”‚       β”œβ”€β”€ property-suggestions.js   # Property suggestions
β”‚       β”œβ”€β”€ data-extraction.js        # Export pipeline
β”‚       └── event-handlers.js         # Event wiring
β”œβ”€β”€ dist/
β”‚   β”œβ”€β”€ cdi-app.bundle.js           # App logic (38KB)
β”‚   └── cdi-validation.bundle.js    # SHACL validation (1.1MB)
β”œβ”€β”€ shapes/
β”‚   β”œβ”€β”€ ddi-cdi-official.ttl    # DDI-CDI 1.0 shapes
β”‚   └── cdif-core.ttl           # CDIF Discovery shapes
β”œβ”€β”€ examples/cdi/
β”‚   └── *.jsonld                # Sample files
└── docs/
    β”œβ”€β”€ CDI_PREVIEWER.md
    └── CDIF_DISCOVERY_SHAPES_FIX.md

🎯 Use Cases

Any JSON-LD Vocabulary

Perfect for:

  • Research data metadata - DDI-CDI, DCAT, DataCite
  • Schema.org datasets - Validate and edit Dataset markup
  • Library metadata - BIBFRAME, Dublin Core
  • Domain-specific ontologies - Any RDF vocabulary with SHACL shapes

Standalone Mode

Perfect for:

  • Exploring any JSON-LD metadata files offline
  • Testing SHACL validation with custom shapes
  • Educational purposes (learning JSON-LD, SHACL)
  • Quick metadata inspection and editing

Dataverse Integration

Ideal for:

  • Direct editing within Dataverse installations
  • API-based metadata updates for any vocabulary
  • Production metadata management
  • Institutional repositories

πŸ”Œ Dataverse Integration

The viewer can be registered as an external tool in Dataverse for any JSON-LD content type:

curl -X POST -H 'Content-Type: application/json' \
  http://localhost:8080/api/admin/externalTools \
  -d '{
    "displayName": "JSON-LD Viewer",
    "description": "View and edit JSON-LD metadata with SHACL validation",
    "toolName": "jsonldViewer",
    "scope": "file",
    "type": "explore",
    "hasPreviewMode": true,
    "toolUrl": "https://libis.github.io/cdi-viewer/",
    "toolParameters": {
      "queryParameters": [
        {"fileid": "{fileId}"},
        {"siteUrl": "{siteUrl}"},
        {"key": "{apiToken}"},
        {"datasetid": "{datasetId}"},
        {"datasetversion": "{datasetVersion}"}
      ]
    },
    "contentType": "application/ld+json"
  }'

Note: Originally developed for DDI-CDI, but works with any JSON-LD vocabulary.

πŸ› οΈ Configuration

SHACL Shapes

The viewer supports multiple shape sources via the "Select SHACL shapes" dropdown:

  1. DDI-CDI 1.0 Official - Full DDI-CDI shapes from ddi-cdi.github.io
  2. CDIF Discovery Core - Browser-compatible schema.org Dataset validation
  3. DCAT-AP 3.0 - EU DCAT Application Profile for open data catalogs
  4. W3C DataCube - RDF Data Cube vocabulary for statistical data
  5. SKOS - Simple Knowledge Organization System for thesauri and taxonomies
  6. Local Fallback - Built-in DDI-CDI shapes for offline use
  7. Custom URL - Load any Core SHACL shapes file (Turtle format) from a URL you provide

Using Custom SHACL Shapes

The Custom URL option allows you to load SHACL shapes for any vocabulary:

  1. Select "Custom URL" from the dropdown
  2. Enter the full URL to your Turtle (.ttl) file
  3. Click "Load Custom Shapes"

Popular standards with published SHACL shapes:

Note: Only Core SHACL features are supported (no SPARQL-based constraints).

Creating Custom SHACL Shapes

If you need to create your own SHACL shapes for validation:

Learn SHACL:

Generate SHACL from Ontologies:

Validate Your Shapes:

Publishing Your Shapes:

  • Host the .ttl file on GitHub Pages (free, static hosting)
  • Use raw GitHub URLs: https://raw.githubusercontent.com/username/repo/main/shapes.ttl
  • Ensure CORS is enabled for browser access
  • Use permanent URLs when possible (DOI, w3id.org, etc.)

Requirements:

  • Save as Turtle format (.ttl)
  • Use only Core SHACL features (no SPARQL constraints)
  • Test with pySHACL or SHACL Play! before publishing
  • Include namespace declarations and shape definitions

Debug Mode

Enable detailed logging with ?debug=true:

https://libis.github.io/cdi-viewer/?debug=true

🀝 Contributing

Contributions are welcome! This project is maintained by LIBIS @ KU Leuven.

Please read CONTRIBUTING.md for details on our development process, testing requirements, and code style guidelines.

Quick Contribution Guide

  1. Fork and clone the repository
  2. Install dependencies: npm install
  3. Make your changes in src/ (ES6 modules) or js/ (legacy scripts)
  4. Build: npm run build (or npm run build:watch for development)
  5. Run tests: npm test
  6. Check linting: npm run lint
  7. Test locally: npm run dev (starts server on http://localhost:8000)
  8. Submit a pull request

Development Structure

The project uses a hybrid architecture during migration to ES6 modules:

src/                    # Modern ES6 modules (new code)
β”œβ”€β”€ validation.js       # βœ… SHACL validation (proper imports)
β”œβ”€β”€ index.js           # Entry point (future: all modules)
└── README.md          # Module documentation

js/                     # Legacy plain scripts (being migrated)
β”œβ”€β”€ core.js            # Initialization and config
β”œβ”€β”€ render.js          # UI rendering
└── ...                # Other modules

dist/                   # Built bundles for browser
β”œβ”€β”€ cdi-validation.bundle.js  # 1.1MB - SHACL with SPARQL
└── cdi-app.bundle.js        # 38KB - App logic

Build Process:

# Write code with ES6 imports (like validation.js)
import Validator from 'shacl-engine/Validator.js';

# Rollup bundles all dependencies into browser files
npm run build

# Two bundles created automatically:
# - dist/cdi-validation.bundle.js (ES6 module + dependencies)
# - dist/cdi-app.bundle.js (legacy scripts concatenated)

Why ES6 Modules?

  • βœ… Write clean Node.js-style code with import/export
  • βœ… Same pattern as shacl-engine, jsonld.js, n3.js
  • βœ… Better IDE support, type checking, debugging
  • βœ… Single minimized bundle for production
  • βœ… Incremental migration (legacy + modern code coexist)

See src/README.md for details on the ES6 module structure and migration plan.

Architecture Documentation

For detailed technical documentation, see:

πŸ“ License

This project is licensed under the Apache License 2.0 - see the LICENSE file for details.

πŸ›οΈ Credits

Developed by LIBIS @ KU Leuven (Katholieke Universiteit Leuven)

Originally created for DDI-CDI metadata, but designed as a generic JSON-LD viewer and editor that works with any vocabulary and SHACL shapes.

Part of the broader Dataverse ecosystem:

πŸ“§ Support

πŸ”— Links


Made with ❀️ by LIBIS @ KU Leuven

Originally built for DDI-CDI metadata, evolved into a powerful general-purpose JSON-LD editor. Works with any RDF vocabulary!

About

Interactive JSON-LD viewer and editor with SHACL validation for any RDF vocabulary (DDI-CDI, schema.org, DCAT, etc.)

Topics

Resources

License

Contributing

Stars

Watchers

Forks

Packages

No packages published