@shexjs/neighborhood-rdfjs

Implementation of @shexjs/neighborhood-api over an in-memory RDF/JS store (e.g. N3.js's Store) — the data interface @shexjs/validator walks when your graph is already loaded in memory.

Install

npm install @shexjs/neighborhood-rdfjs

Quick start

const {ctor: RdfJsDb} = require("@shexjs/neighborhood-rdfjs");
const {ShExValidator} = require("@shexjs/validator");
const {Store, Parser} = require("n3");
const base = "http://a.example/";

const schema = require("@shexjs/parser").construct(base).parse(`
<S1> { <p1> [1 2] }`);
const graph = new Store(new Parser({baseIRI: base}).parse(`
<n1> <p1> 1 .`));

const validator = new ShExValidator(schema, RdfJsDb(graph));
const results = validator.validateShapeMap(
  [{node: base + "n1", shape: base + "S1"}]);
console.log(results[0].status);  // "conformant"

ctor(store, queryTracker?)

Wraps the store for the Neighborhood API. The store must implement the RDF/JS match(subject, predicate, object, graph) interface, returning quads of RDF/JS terms synchronously — N3.js's Store does, as does anything implementing the RDF/JS Store match semantics synchronously.

A validation is a walk: for each node it reaches, the validator asks this db for the node's neighborhood — the arcs out of (and, for inverse constraints, into) the node — which is two match calls. The optional queryTracker hears about each ask, which is how the WebApp paints what a validation touched.

Because the store is local and complete, every kind of constraint works here — CLOSED shapes, inverse arcs, blank-node focus nodes — which is why the shexTest suite runs over this module, and other neighborhoods (SPARQL, Wikibase) measure themselves against it.

@shexjs/neighborhood-rdfjs is one of the shex.js packages; installing shex pulls in the whole suite, and its README maps them.