3.1 RDF Terms

All RDF terms (IRIs, blank nodes and literals) are represented using JavaScript Objects that have attributes as described in the following three subsections. The following table summarizes key functions to create and operate on RDF term Objects:

Note that the attributes in the table above are only defined for Objects that have matching types. For example, the result of querying the uri of a blank node is undefined.

Each of these Objects must have a function .equals(other) that takes another term Object as its only parameter and returns true exactly if the underlying RDF terms are equal, and false otherwise.

3.2 Triples

An RDF triple is represented by a JavaScript Triple Object with three read-only attributes subject, predicate and object, each of which has exactly one RDF term as its value. Furthermore, triples must provide an equals function that takes an Object other as its only parameter and returns a boolean. equals returns true exactly if other has values for its attributes subject, predicate and object that return true when compared using equals() against the corresponding attribute values of the first triple, and false otherwise.

3.3 Graphs

An RDF graph is represented by a JavaScript Graph Object that has a function find which takes three parameters of type Object, all of which are optional. The result of the find function is an Iterator object with two functions:

• next() either returns a Triple or null if the iteration has been exhausted.
• close() terminates the Iterator and releases any resources allocated by it. Once close() has been called, further calls to next() cause an exception. The close() function MUST always be called unless the iterator has already been walked to completion.

The following JavaScript snippet assumes that the current data graph is represented by the variable $data and gets the first label of a given resource where the label is an english literal.

function getEnglishLabel(resource) {
	var labelProperty = TermFactory.namedNode("http://www.w3.org/2000/01/rdf-schema#label");
	var labels = $data.find(resource, labelProperty, null);
	for(;;) {
		var labelTriple = labels.next();
		if(!labelTriple) {
			return null;
		}
		var label = labelTriple.object;
		if(label.isLiteral() && label.language.startsWith("en")) {
			labels.close();
			return label.value;
		}
	}
}

3.4 Validating Nodes via JavaScript

SHACL-JS processors must provide a JavaScript function with the following signature:

1. node: The RDF term Object of the node to validate
2. shape: The RDF term Object of the shape to validate the node against

The result of this function is true if and only if node conforms to the shape, and false otherwise.

This function is needed because the implementation of some of the constraint components such as sh:NotConstraintComponent requires the ability to spawn off a new SHACL validation process. It may also be used as entry point into the validation engine by custom code.

4.1 sh:jsFunctionName

Every JavaScript executable must have exactly one value for the property sh:jsFunctionName. The values of sh:jsFunctionName are literals with datatype xsd:string.

The semantics of how arguments are passed into the provided function depend on the specific type of executable, as described in later sections.

4.2 sh:jsLibrary

Every JavaScript executable must have at least one value for the property sh:jsLibrary. The values of the property sh:jsLibrary are IRIs or blank nodes. The values of the property sh:jsLibrary are well-formed SHACL instances of the class sh:JSLibrary.

4.3 sh:JSLibrary

The class sh:JSLibrary can be used to declare JavaScript libraries. A library can be understood as a pointer to zero or more JavaScript files that need to be executed before a JavaScript executable can be evaluated. Libraries may depend on each other by declaring further sh:jsLibrary triples.

The values of the property sh:jsLibraryURL are literals with datatype xsd:anyURI.

6.2 Validation with JavaScript-based Constraints

This section defines the validator of sh:JSConstraintComponent.

6.3 Mapping of JavaScript Results to Result Properties

The following rules define how to construct validation results from a given JavaScript function result R in the context of a given constraint C in a shape S, a focus node F and a value node V.

1. If R is a JavaScript String: Create a validation result ?r. Add a triple ?r sh:resultMessage ?s where ?s is an xsd:string literal with the JavaScript String as its lexical form. Add a triple ?r sh:value ?v where ?v is the current value node V.
2. If R is a JavaScript Array: For each member of the Array R apply the rule for JavaScript Objects.
3. If R is a JavaScript Object (not a String): Create a validation result ?r. If R.value is an RDF term object ?v, add a triple ?r sh:value ?v. If R.message is a JavaScript String, add a triple ?r sh:resultMessage ?s where ?s is an xsd:string literal with the given String as its lexical form. Otherwise, add triples ?r sh:resultMessage ?m from the shape S following the rules defined by [shacl]. If the shape S is a node shape and R.path is an RDF NamedNode object ?path, add a triple ?r sh:resultPath ?path.
4. If R is the JavaScript Boolean false: Create a validation result ?r. Add a triple ?r sh:value ?v where ?v is the current value node V. Add triples ?r sh:resultMessage ?m from the shape S following the rules defined by [shacl].

To create a validation result ?r, create a triple ?r rdf:type sh:ValidationResult using the provided focus node F as value for sh:focusNode, deriving sh:resultSeverity from the sh:severity of the shape S in the shapes graph (using sh:Violation as default), and setting the sh:resultPath, sh:sourceConstraintComponent and sh:sourceShape following the rules defined by [shacl]. If the result is produced by a JavaScript-based constraint, then set sh:sourceConstraint to the value of sh:js of the constraint C in the shapes graph.

7.2 Syntax of JavaScript-based Constraint Components

The declaration of JavaScript-based Constraint Components in a shapes graph is very similar to SPARQL-based Constraint Components. In particular, components declare their parameters using sh:parameter. In fact, the same constraint component may serve as a declaration of both a SPARQL-based and a JavaScript-based constraint component, assuming that validators have been declared for both cases. Where SHACL-SPARQL uses the classes sh:SPARQLSelectValidator and sh:SPARQLAskValidator, SHACL-JS uses the class sh:JSValidator, which is a subclass of sh:JSExecutable. Each SHACL-JS validator is also a JavaScript executable and therefore has a value for sh:jsFunctionName.

7.3 Validation of JavaScript-based Constraint Components

This section defines the validator of JavaScript-based constraint components.

8.2 Syntax and Semantics of JavaScript-based Functions

The syntax of JavaScript-based functions is very similar to SPARQL-based functions. Each SHACL instance of sh:JSFunction in a shapes graph, that is an IRI, declares one function. The IRI identifies the function, for example, in SPARQL queries. The function parameters are declared using sh:parameter in the same way as the parameters of constraint components are declared. The optional property sh:returnType can be used to specify the type of results produced by the function. Finally, sh:JSFunction is a subclass of sh:JSExecutable, and the syntax rules of JavaScript executables apply to functions, too. In particular, each JavaScript-based function has one value of sh:jsFunctionName. This is the name of the JavaScript function that is executed whenever the (SHACL) function is called.

The JavaScript result R of the execution of the function is turned into an RDF node using the following rules:

1. If R is a String: return an xsd:string literal with the string as its lexical form
2. If R is an Object representing an RDF node: return R
3. If R is a Number and the function declares a sh:returnType T and the Number can be converted to a well-formed literal with datatype T: return a literal with datatype T and the given value as lexical form
4. If R is a Number that can be converted to a well-formed literal with datatype xsd:decimal: return an xsd:decimal literal with the given value as lexical form
5. If R is a Boolean: return an xsd:boolean literal with the given value as lexical form
6. Otherwise: return no result

During the execution of a JavaScript function, the variable $data can be used to access the current query graph, while the variable $shapes is undefined.

9.2 Execution Instructions for JavaScript Rules

1. If O is an Array: Infer a new triple with subject O[0], predicate O[1] and object O[2].
2. If O is another Object: Infer a new triple with subject O.subject, predicate O.predicate and object O.object.

In other words, each member of the Array returned by the JavaScript function must either be another Array with three members (for subject, predicate and object), of a JavaScript Object with three fields subject, predicate and object.

10.1 JavaScript-based Targets (sh:JSTarget)

Custom targets that are SHACL instances of sh:JSTarget are called JavaScript-based targets.

JavaScript-based targets have the same syntax rules as JavaScript executables (e.g., requires a sh:jsFunctionName). The function must return a JavaScript Array where each member is an RDF term Object.

10.2 JavaScript-based Target Types (sh:JSTargetType)

Very similar to SPARQL-based target types, there is a class sh:JSTargetType declared as rdfs:subClassOf sh:TargetType for JavaScript-based target types.

JavaScript-based target types have the same syntax rules as JavaScript executables (e.g., requires a sh:jsFunctionName). The function must return a JavaScript Array where each member is an RDF term Object.