SHACL, the Shapes Constraint Language, is a language for describing the structure
of RDF graphs.
SHACL may be used for a variety of purposes such as validating, inferencing,
modeling domains, generating ontologies to inform other agents, building user
interfaces, generating code, and integrating data.
SHACL Rules provides inferencing with the generation of new RDF data from a
combination of a set of rules and a base data graph. Rules can be expressed as RDF
or in the SHACL Rules Language (SRL).
This section describes the status of this
document at the time of its publication. A list of current W3C
publications and the latest revision of this technical report can be found
in the
W3C standards and drafts index.
Publication as
a Working Draft does not imply endorsement
by W3C and its Members.
This is a draft document and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to cite this document as other
than a work in progress.
Future updates to this upcoming Recommendation may incorporate
new features.
This document was produced by a group
operating under the
W3C Patent
Policy.
W3C maintains a
public list of any patent disclosures
made in connection with the deliverables of
the group; that page also includes
instructions for disclosing a patent. An individual who has actual
knowledge of a patent that the individual believes contains
Essential Claim(s)
must disclose the information in accordance with
section 6 of the W3C Patent Policy.
defines the use of SHACL for profiling data, including SHACL data
Note
Implementers can partially check their level of conformance with the above specifications by successfully passing
the test cases of the SHACL 1.2 test suite.
Note, however, that passing all the tests in the test suite does not imply complete conformance to the specifications.
It only implies that the implementation conforms to the aspects tested by the test suite.
1. Introduction
This document introduces inference rules for SHACL 1.2, a mechanism for
deriving new RDF triples from existing RDF data through declarative rules.
The document defines the syntax and semantics of rule-based inference.
Implementations of SHACL Rules provide two operations.
The infer operation that applies the rules to a given
base graph and produces an inference graph containing the
RDF triples derived by rule execution.
Combining the inference graph with the base graph is optional and
left to users. The query operation determines whether a
given goal pattern can be derived from the base graph using the rules
The inference graph may contain RDF triples with IRIs, blank nodes or
literals that were not present in the base graph. Users are responsible to
ensure that iterative applications of rules that generate new blank nodes or
literals do not result in infinite loops.
SHACL Rules also support constructs, such as negation as failure,
that could lead to different inferred graphs depending on the order in which
rules are executed. To avoid this, rules are evaluated using the technique
of stratification, which establishes a single, implicit ordering
among rules, ensuring that the same inference graph is always produced.
1.1 Terminology
Editor's note
Connect to definitions in RDF 1.2 Concepts.
The following definitions from other specifications are used in this document: @@
1.2 Document Conventions
Some examples in this document use Turtle [turtle].
The reader is expected to be familiar with SHACL [shacl]
and SPARQL [sparql-query].
Within this document, the following namespace prefix bindings are used:
Prefix
Namespace
rdf:
http://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfs:
http://www.w3.org/2000/01/rdf-schema#
sh:
http://www.w3.org/ns/shacl#
srl:
http://www.w3.org/ns/shacl-rules#
shnex:
http://www.w3.org/ns/shacl-node-expr#
xsd:
http://www.w3.org/2001/XMLSchema#
ex:
http://example.com/
Throughout the document, color-coded boxes containing RDF graphs in
Turtle will appear. These fragments of Turtle documents use the prefix
bindings given above.
2. Conformance
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key word MUST NOT in this document
is to be interpreted as described in
BCP 14
[RFC2119] [RFC8174]
when, and only when, it appears in all
capitals, as shown here.
@@Needs adjusting and links
This specification defines conformance criteria for:
A conforming
Shapes Rules Language Document is an
RDF string that
conforms to the grammar, starting with the
RuleSet
production, and conforming to the additional constraints defined in
7. Shapes Rules Language Grammar
Note
This specification does not define how SHACL Rules processors handle non-conforming input documents.
3. SHACL Rules
This section is non-normative.
SHACL rules infer new triples given a base graph and a rule set.
The output of evaluation is an inference graph containing the derived
triples that do not appear in the base graph.
Each rule has a pattern, called the body, and a result
template, called the head.
A rule is executed by finding the values for variables in the body
so that the body matches the combined base graph and
any inferred triples from the execution up to this point.
These values are then used to instantiate the triple templates
in the rule head to produce new inferred triples.
The rules are executed until no more triples are inferred,
and rules may be executed more than once as new inferred triples
become available.
SHACL Rules execution is defined so that the order of rule execution
does not lead to to different outcomes when creating new RDF terms,
including new blank nodes, nor in the testing for the absence of a
pattern. In other words, the same inference graph is produced
regardless of the order of rule execution.
3.1 Basic Usage
In this first example, we have the following data graph and rule set:
This last rule is a recursive rule, the body of the rule
depends on the head of the rule.
3.3 Filtering
We can use expressions in the body of rules to restrict the values of variables
in the matching of the body.
For example, given data about towns and their populations,
we can infer a class for towns with a population greater than 1500:
FILTER evaluates an expression and keeps the current
set of variable bindings if the expression evaluates to true, and it discards the
current set of variable bindings if the expression evaluates to false.
This is the same as the
FILTER operation of SPARQL
and SHACL Rules provides many of the same functions and operators as SPARQL.
3.4 Negation
Negation allows you to specify a pattern that must not match.
This is called "negation as failure".
In order to evaluate a negation element, the rules evaluation algorithm
ensures that all the rules that could produce triples matching the pattern
in the negation element have been completed. This is called
stratification and ensures that the negation is based
on all the relevant possible triples, whether from the data or inferred
from other rules.
RULE { ?x rdf:type :UnclassifiedSize } WHERE {
?x rdf:type :Place .
NOT { ?x :population ?p . }
}
:X3 rdf:type :UnclassifiedSize .
3.5 Assignment and Creating RDF Terms
Assignment allows you to assign the result of an expression to a variable
in the body of a rule. This can be used to create new RDF terms based
on the data.
This can be combined with testing for the absence of a triple
already recording the distance in kilometers.
RULE { ?x :distanceKm ?kilometers }
WHERE {
?x :distanceMiles ?miles
NOT { ?x :distanceKm ?km }
SET ( ?kilometers := ?miles * 1.60934 )
}
Rules involving assignment are run-once rules. Rules with assignment
are run after all the rules that could produce the data that they depend on
and before any rules that depend on the data they produce.
Rules that involve blank node in the rule head are also creating new
RDF terms and are run-once rules.
This condition ensures that rules that create RDF terms do not generate new terms
multiple times, with potentially different outcomes and also that such rules do not
loop back to themselves and cause an unbounded number of RDF terms.
3.6 Importing rules
A SHACL rule set can incorporate other rule sets by
including their URLs in the rule imports of the rule set.
This allows rules to be structured into libraries shared between rule sets.
The IMPORTS statements of a rule set are processed before any of the rules
in the rule set are evaluated. During the importing step, if an imported rule set
has its own imports, those are also processed recursively.
Traversing IMPORTS statements during the processing of rule sets may lead to
cyclic imports. A rule set is imported only once;
cycles in the import statements graph does not lead to infinite loops.
SHACL Rules and SPARQL have a close relationship. SHACL Rules are designed to be compatible
with SPARQL, and many of the constructs in SHACL Rules are inspired by SPARQL.
However, there are some differences:
@@ RULES have additional well-formedness conditions that ensure
variables are always bound before use.
@@ RULE and CONSTRUCT - RULE have a restricted body syntax
and output to the inference graph.
@@ SET and BIND - different error handling
@@ NOT and SPARQL EXISTS,NOT EXISTS - NOT has a restricted negation body
@@ Restricted property paths (no arbitrary length operators * and +)
@@ Restricted functions. No COALESCE, BOUND (rules well-formedness ),
RAND (different result each time) and no hash functions. NOW() is permitted
and is defined to return the same point in time through a rule set evaluation,
as it does in SPARQL.
3.9 Rule Tuples
Issue 752: Rule tuples - workspace during rule evaluation Rules
At risk:
Rule tuples are disjoint from triples.
They are tuples of RDF terms (no variables) and exist only during
evaluation of a rule set.
They can be used to record intermediate results during rule evaluation
and to pass data between rules.
Syntax of tuple patterns, templates and tuples:
TUPLE(termOrVar , ...)
Shorthand: $(termOrVar , ...)
Often, the first argument will be a fixed name.
There is a tuple store which holds tuples for the lifetime of the
evaluation. The tuple store holds duplicate data tuples (unlike
an RDF graph which is a set).
4. Shape Rules Abstract Syntax
The Shape Rules Abstract Syntax is the logical structure of SHACL Rules.
It is used to define the execution algorithm of SHACL Rules.
Each of the two concrete syntax forms of SHACL Rules, the SHACL Rules Language (SRL)
and the RDF syntax (SRL/RDF), provides a way to express the abstract syntax.
/p>
Query is the operation that determines whether a given goal
pattern can be derived from a base graph using the
rule set.
In a triple pattern or a triple template,
position 1 of the tuple is informally called the subject,
position 2 is informally called the predicate, and
position 3 is informally called the object.
4.2 Well-formedness Conditions
Well-formedness is a set of conditions on the abstract syntax of
SHACL rules. Together, these conditions ensure that a variable in the
head of a rule has a value defined in the body of the rule;
that each variable in an condition element
or assignment expression
has a value at the point of evaluation; and that each
assignment in a rule introduces a new variable,
one that has not been used earlier in the rule body.
A rule is a well-formed rule if all of the following
conditions are met:
A rule set is "well-formed" if and only if all of the rules of the
rule set are "well-formed".
4.3 Rule Dependency
A rule R1 depends on a rule R2 if the output of the second rule
affects the evaluation of the body of the first rule. That is, the head of R2
has a triple template that might generate a triple that matches
a triple pattern in the body of R1,
either as a triple pattern element or inside a negation element.
There are two kinds of dependencies:
a closed rule dependency
and an open rule dependency.
A closed dependency requires that rule R2
has generated all its possible output before rule R1 can be executed.
This happens when R1 has a triple pattern in a negation element
that matches a triple template of R2 in a negation element,
or if R1 has any matching triple pattern depending on R2
and R1 has an assignment element, or R1 has any matching triple pattern
that matches a triple template of R2 that has a blank node.
If a rule dependency is not closed, it is an open dependency
which allows the first rule R1 to be executed
while the rule R2 might be run again to generate further triples
which can then cause R1 to be reevaluated with the new triples from R2.
Triple pattern matching
A triple pattern matches a triple template if
the triple template may generate a triple that matches the triple pattern.
In addition, if any pair of ts, tp, and to are the same variable,
then the corresponding pair of s, p, and o must be the same.
4.3.1 Dependency Graph
The dependencies between rules are represented as a directed graph,
called the dependency graph.
The vertices of the graph are the rules of the rule set, and the edges
are labeled either open or closed according to
whether the dependency is an open dependency or a closed dependency.
Dependency graph
A dependency graph of a rule set is a directed graph where each
vertex is a rule in the rule set, and an edge exists from rule R1
to rule R2 if R1 depends on R2.
The edge is labeled either open
or closed according whether the dependency
is an open dependency or a closed dependency.
The dependency graph is not affected by the data graph.
4.3.2 Dependency Graph Algorithm
The following algorithm gives one
possible method for constructing the dependency graph from a
rule set. Conformance depends on producing a dependency graph
that meets the definitions of a dependency graph,
not on the use of this procedure.
definemergeLabel(oldLabel,newLabel):## Closed dependency overrides open dependency.ifoldLabel=="open"andnewLabel=="open":return"open"else:return"closed"endifenddefine## output -- Dependency graph with rule vertices and labeled edges.define buildDependencyGraph(ruleSet):## edgeLabelMap maps (R1, R2) to "open" or "closed"letedgeLabelMapbeamapfrompair(rule,rule)tolabelforeach rule R1 in ruleSet:## Classify each triple pattern TP in the rule as requiring "open" or "closed"## depending on whether it is in a negation element or not.letbodyDependencies= {}
foreach rule body element RBE in the body of R1:if RBE is a negation element:foreach triple pattern TP in RBE:letitembeapair(TP,"closed")additemtobodyDependenciesendforelse if RBE is a triple pattern element of triple pattern TP:letitembeapair(TP,"open")additemtobodyDependencieselse if RBE is a condition element:## Do nothingelse if RBE is an assignment element:## Do nothingendifendforforeachpair(triplepatternTP,depLabel) in bodyDependencies:if R1 has an assignment element:setdepLabelto"closed"endifif R1 has a triple template with a blank node:setdepLabelto"closed"endif## Find depenencies for this triple pattern element or negation element.foreach rule R2 in ruleSet:foreach triple template TT in head of R2:## "possibly generate" / matching is defined in## section 3.3 if TT can possibly match triple pattern TP:letkey=(R1,R2)if edgeLabelMap contains key:letoldLabel=edgeLabelMap.get(key)letmerged=mergeLabel(oldLabel,depLabel)edgeLabelMap.set(key,merged)else:edgeLabelMap.set(key,depLabel)endifendifendforendforendforendforletDP= { }
foreachentry((R1,R2),label) in edgeLabelMap:addedge(R1->R2)labeledlabeltoDPendfortheresultisDPenddefine
A stratification process may also be used to make other evaluation
decisions. This document describes the necessary conditions for
consistent evaluation and gives one possible way to form a
stratification. Implementations need to meet the conditions
described here in order to get compatible behavior but they are not
required to implement the algorithm as presented.
Stratification layer
A stratification layerSL, is a pair of disjoint sets of
rules (SL.once, SL.general) .
SL.once contains run-once rules, which are
rules that use assignment elements or produce
blank nodes in the rule head; these rules are each evaluated exactly
once at the start of evaluation of the stratification layer.
SL.general contains the remaining rules, which are evaluated
until no new triples are inferred.
Stratification is only defined when the following condition is
satisfied. If a rule set does not meet this condition, then this
specification does not define an outcome for the evaluation of
such a rule set.
In other words, there is no NOT or run-once rule (assignment or rule triple template
involving a blank node) in any transitive dependency cycle of the dependency graph.
4.4.2 Stratification Algorithm
The following algorithm gives one possible stratification based solely
on the rule set.
## output -- Map: Integer -> Set of rules.define stratification(ruleSet):letDP=Dependencygraphfortheruleset.letstratumMapbeamapfromruletointeger## The dependency graph should satisfy the stratification condition.## The check for unbounded stratification is a guard ## due to a violation of the stratification condition.letlimit=numrules+1letmaxStratum=0## initialize stratumMapforeach rule in ruleSet:stratumMap.set(rule,0)endforbooleanchanged=true;while changed:changed=false;foreach edge E in DP:## Edge from pRule to qRule with a labelletpRule=sourceofedgeletqRule=destinationoftheedgeletlabel=edgelabeliflabel=="open":ifstratumMap.get(pRule)<stratumMap.get(qRule) :stratumMap.set(pRule,stratumMap.get(qRule))changed=true;endifendififlabel=="closed":ifstratumMap.get(pRule)<=stratumMap.get(qRule) :letxStratum=1+stratumMap.get(qRule)if(xStratum>limit)## Stratification requirement violatederror"Stratification error"endifstratumMap.set(pRule,xStratum)maxStratum=max(maxStratum,xStratum)changed=true;endifendifendforendwhile## Initialize the result map.letstratumRulesbeamapfromintegertorules.fori=0tomaxStratumstratumRules.set(i, {})endfor## Gather rules in stratumMap with the same level numberfor rule R in map stratumMap:letstratumNum=stratumMap.get(R)addRtostratumRules.get(stratumNum)endfor## Partition each level into once and generalletstratumLevelsbeasequenceofpairsofsetsofrules.fori=0 to maxStratum:letrules=stratumLevels.get(i)letonce= { Rinrules|Risarun-oncerule }
letgeneral=rules\oncestratumLevels.set(i,pair(once,general))endfortheresultisstratumLevelsenddefine
This section defines the outcome of evaluating a rule set on given data.
It does not prescribe the algorithm as the method of implementation.
An implementation can use any algorithm that generates the same outcome.
Inputs: data graph G, called the base graph, and a rule set RS.
Output: an RDF graph GI of inferred triples
The inferred triples do not include triples present in the set
of triples of the base graph.
A Solution mapping,
μ, is a partial function
μ : V → T,
where V is the set of all variables
and T is the set of all RDF terms.
The domain of μ is denoted
by dom(μ), and it is the subset
of V for which μ is defined. We use the term
solution where it is clear that a solution mapping is meant.
Write μ0 for the solution mapping, such that
dom(μ0) is the empty set.
A graph match finds the ways to
map a triple pattern onto triples in an RDF Graph.
Let G be an RDF graph and TP be a triple pattern.
The function graphMatch(G, TP) returns a set of all possible
solutions that,
when applied to the triple pattern, produce a triple that is in the
evaluation graph
A solution sequence is a multi-set of solutions.
There is no defined order to the sequence.
It is equivalent to an unordered list and it can contain duplicates.
Solution merge
If two solutions are compatible, the merge of two solutions is the solution
that maps variables of each solution to the RDF term
from one or other of the solutions.
Let μ1, μ2
be solution mappings, and S1 and S2 be solution sequences.
merge(μ1,μ2)= { μ|
μ(v) = μ1(v) if v in dom(μ1)
μ(v) = μ2(v) otherwise }
merge(S1,S2)= { μ|
μ1 in S1, μ2 in S2
and compatible(μ1, μ2)
μ(v) = merge(μ1, μ2)
Editor's note
Say the domain is dom(S1) ∪︀ dom(S2).
Say that two solutions that have no variables in common are compatible.
6.2 Preparation for Evaluation
The first step in evaluating a rule set is to prepare a single,
valid rule set. This involves gathering all imported rule sets, building
a single, combined rule set, and then calculating the stratification for
the combined rule set.
6.2.1 Process Imports
@@Walk imports - visit only once@@
Editor's note
@@ TODO: consider defining a rule set as having two components and a
separate set of imports. i.e. imports are in the parsing and sorted out
to give a usable "rule set" of "rules + data"
A rule set has three components: R.rules, R.data, and R.imports.
The rule set merge of two rule sets, RS1 and RS2,
is a rule set, MR, defined as follows:
define imports(rule set RS, set ofURLs V), returning rule set
let I = the set ofimportURLs declared for the rule set RSletRS2 = RS
foreach URL x inI:
if x ∉ V:
V = V ∪︀ { x }
read rule set RS3fromURL x
RS2 = rulesetMerge(RS2, imports(RS3, V))
endif
endfor
result is RS2
enddefine
letRS be a rule set
let V = {}
ifRS has a location, V = { location ofRS }
result is imports(RS, V)
@@ReferenceSPARQLexpressionevaluationExpressionEvaluation@@ReferenceSPARQLEBVEffectiveBooleanValue(EBV)defineevalFunction(F,μ):let [x/μ] beifxisanRDFterm,then [x/row] isxifxisavariable,then [x/row] isμ(x)## By well-formedness, it is an error if x is not in the row.returnevalFunction(F(expr1,expr2...),row)=F(evalFunction(expr1,row),evalFunction(expr2,row),...)if an error is returned by evalFunction:returnerrorreturnevalFunction(FF(expr1,expr2),row)=...thingsthatarenotfunctionslike`IF`
6.4 Evaluation of a Rule
letRbeawell-formedrule.letruleR=(H,B)whereHisthesequenceoftripletemplatesintheheadBisthesequenceoftriplepatternelements,conditionelements,negationelements,andassignmentelementsinthebody# Solution sequence of one solution that does not map any variables.let SEQ0:Solutionsequence= { μ0 }
letG=evaluationgraph# Evaluate rule body# This function returns a sequence of solutionsdefineevalRuleElements(B,SEQ,G):for each rule element rElt in B:if rElt is a triple pattern TP:X=graphMatch(G,TP)SEQ1= {}
foreachμ1in X:foreachμ2in SEQ:ifcompatible(μ1,μ2)μ3=merge(μ1,μ2)addμ3toSEQ1endifendforendforendifif rElt is a condition element with expression F:SEQ1= {}
foreachsolutionμin SEQ:letx=evalFunction(F,μ)if x is true:addμtoSEQ1endifendforendifif rElt is a negation expression with body elements N:SEQ1= {}
foreachsolutionμin SEQ:S=sequence{μ}NEG=evalRuleElements(N,S,G)ifNEGisemptyaddμtoSEQ1endifendforendififrEltisanassignmentwithvariableVandexpressionexprSEQ1= {}
for each solution S in SEQ:letx=evalFunction(expr,S)if x is not an error:add(V,x)toSaddStoSEQ1else# Error: drop solution SendifendforendififSEQ1isemptySEQ= {}
returnSEQendifSEQ=SEQ1endforreturnSEQenddefineletSEQ=evalRuleElements(B,SEQ0,G)# Evaluate rule headletH=emptysetforeachμin SEQ:letS= {}
foreachtripletemplateTTinheadlettriple=subst(μ,TT)AddtripletoSendforH=HunionSendforresulteval(R,G)isH
Note that H may contain triples that are also in the data graph.
6.5 Evaluation of a Rule Set
letG0betheinputbasegraphletRSbetherulesetletDbethegraphofallDATAtriplesinRSApplystratificationtoRSletLSbethesequenceoflayersafterstratification# Inference graphletGI= { t∈D|t∉G0 }
# Evaluation graph.letGE=G0∪︀Dfor each stratum ST in LS:for each rule R in ST.once:letX=eval(R,GE)letY= { t∈X|t∉GE }
GI=Y∪︀GIGE=Y∪︀GEendforletfinished=falsewhile!finished:finished=truefor each rule R in ST.general:letX=eval(R,GE)letY= { t∈X|t∉GE }
if Y is not empty:finished=falseGI=Y∪︀GIGE=Y∪︀GEendifendforendwhileendfortheresultisGI
White space
(production WS) is used
to separate two terminals which would otherwise be (mis-)recognized as one
terminal. Rule names below in capitals indicate where white space is
significant; these form a possible choice of terminals for constructing a
Shapes Rules Language parser.
White space is significant in the production
String.
A Unicode code point
in the ranges U+0000 to U+D7FF
and U+E000 to U+FFFF,
corresponding to the value encoded by the four hexadecimal digits interpreted
from most significant to least significant digit.
A Unicode code point
in the ranges U+0000 to
U+D7FF
and U+E000 to U+10FFFF,
corresponding to the value encoded by the eight hexadecimal digits
interpreted from most significant to least significant digit.
A string escape sequence represents a character traditionally escaped in string literals:
Escape sequence
Unicode code point
\t
U+0009
\b
U+0008
\n
U+000A
\r
U+000D
\f
U+000C
\"
U+0022
\'
U+0027
\\
U+005C
A reserved character escape sequence consists of a
\ followed by
one of these characters ~.-!$&'()*+,;=/?#@%_, and
represents the character to the right of
the \.
Context where each kind of escape sequence can be used
%-encoded sequences are in the
character range for IRIs
and are explicitly allowed in local names.
These appear as a %
followed by two hex characters and represent that
same sequence of three characters. These sequences are not
decoded during processing.
A term written as <http://a.example/%66oo-bar>
designates the IRI http://a.example/%66oo-bar
and not IRI http://a.example/foo-bar.
A term written as ex:%66oo-bar with a prefix
PREFIX ex: <http://a.example/>
also designates the IRI http://a.example/%66oo-bar.
7.5 Grammar
The EBNF used here is defined in XML 1.0
[EBNF-NOTATION].
Notes:
Keywords are case-insensitive except for
'a'
which is case-sensitive.
Escape sequences UCHAR
and ECHAR
are case sensitive.
When tokenizing the input and choosing grammar rules, the longest match is chosen.
The Shapes Rules Language grammar is LL(1) and LALR(1) when the rules with uppercased names
are used as terminals.
This document uses some specific terminal literal strings
[EBNF-NOTATION]. To clarify the Unicode code points used for these
terminal literal strings, the following table describes specific
characters used in this section.
Code
Glyph
Description
U+000A
LF
Line feed
U+000D
CR
Carriage return
U+0023
#
Number sign
U+0025
%
Percent sign
U+005C
\
Backslash
A. Internet Media Type, File Extension and Macintosh File Type
Editor's note
@@see the Turtle registration for format
The Internet Media Type (formerly known as MIME Type) for @@ is "text/shape-rules".
The information that follows has been submitted to the Internet Engineering
Steering Group (IESG) for review, approval, and registration with IANA.
Type name:
application
Subtype name:
shape-rules
Required parameters:
None
Optional parameters:
@@version, @@profile
Encoding considerations:
The syntax of the SHACL Rules Language is expressed over code points in Unicode
[UNICODE]. The encoding is always UTF-8 [RFC3629].
Unicode code points may also be expressed using an \uXXXX (U+0 to U+FFFF) or
\UXXXXXXXX syntax (for U+10000 onwards) where X is a hexadecimal digit [0-9A-F]
A SHACL rules file may have the string 'PREFIX'
(case independent) near the beginning
of the document.
File extension(s):
".srl"
Base URI:
The SHACL Rules 'BASE <IRIref>' term can change the
current base URI for relative IRIrefs in the query language that
are used sequentially later in the document.
Macintosh file type code(s):
"TEXT"
Person & email address to contact for further information:
Data Shapes Working Group <public-shacl@w3.org;
Intended usage:
COMMON
Restrictions on usage:
None
Author/Change controller:
The SHACL 1.2 Rules specification is a work product of the World
Wide Web Consortium's Data Shapes Working Group. The W3C has change
control over these specifications.