The
Shape
Expressions
(ShEx)
language
describes
RDF
nodes
and
graph
structures.
A
node
constraint
describes
an
RDF
node
(
IRI
,
blank
node
or
literal
)
and
a
shape
describes
the
triples
involving
nodes
in
an
RDF
graph
.
These
descriptions
identify
predicates
and
their
associated
cardinalities
and
datatypes.
ShEx
shapes
can
be
used
to
communicate
data
structures
associated
with
some
process
or
interface,
generate
or
validate
data,
or
drive
user
interfaces.
This
document
defines
the
ShEx
language.
See
the
Shape
Expressions
Primer
for
a
non-normative
description
of
ShEx.
Status
of
This
Document
This
is
a
preview
Do
not
attempt
to
implement
this
version
of
the
specification.
Do
not
reference
this
version
as
authoritative
in
any
way.
Instead,
see
https://shexspec.github.io/spec/
for
the
Editor's
draft.
This
is
an
editor's
draft
of
the
Shape
Expressions
specification.
ShEx
2.x
differs
significantly
from
the
W3C
ShEx
Submission.
The
July
2017
publication
included
a
definition
of
validation
which
implied
infinite
recursion.
This
version
explicitly
includes
recursion
checks.
No
tests
changed
as
a
result
of
this
and
no
implementations
or
applications
are
known
to
have
been
affected.
If
you
wish
to
make
comments
regarding
this
document,
please
raise
them
as
GitHub
issues.
There
are
separate
interfaces
for
specification
,
language
and
test
issues.
Only
send
comments
to
public-shex@w3.org
(
subscribe
,
archives
)
if
you
are
unable
to
raise
issues
on
GitHub.
All
comments
are
welcome.
1.
Introduction
The
Shape
Expressions
(
ShEx
)
language
provides
a
structural
schema
for
RDF
data.
This
can
be
used
to
document
APIs
or
datasets,
aid
in
development
of
API-conformant
messages,
minimize
defensive
programming,
guide
user
interfaces,
or
anything
else
that
involves
a
machine-readable
description
of
data
organization
and
typing
requirements.
ShEx
can
be
represented
in
JSON
structures
(
ShExJ
)
or
a
compact
syntax
(
ShExC
).
The
compact
syntax
is
intended
for
human
consumption;
the
JSON
structure
for
machine
processing.
This
document
defines
ShEx
in
terms
of
ShExJ
and
includes
a
section
on
the
ShEx
Compact
Syntax
(ShEx)
.
2.
Notation
The
JSON
[
rfc7159
]
Syntax
serves
as
a
serializable
proxy
for
an
abstract
syntax.
literals
with
the
datatype
http://www.w3.org/2001/XMLSchema#string
are
represented
with
the
value
property,
e.g.
{
"value":
"abc"
}
.
language-tagged
strings
are
represented
with
an
additional
language
property,
e.g.
{
"value":
"hello
world",
"langague":
"en-US"
}
datatyped
literals
are
represented
with
an
additional
datatype
property,
e.g.
{
"value":
"123",
"datatype":
"http://www.w3.org/2001/XMLSchema#integer"
}
2.1
JSON
Grammar
This
specification
uses
a
JSON
grammar
to
describe
the
set
of
JSON
documents
that
can
be
interpreted
as
a
ShEx
schema.
ShEx
data
structures
are
represented
as
JSON
objects
with
a
member
with
the
name
"
type
"
(i.e.
an
object
with
a
type
attribute):
{
"type":
"typeName",
member
0…n
}
These
are
expressed
in
JSON
grammar
as
typeName
{
member*
}
.
RFC7159
Section
2
provides
syntactic
constraints
for
JSON
—
the
grammar
constraining
those
to
valid
ShExJ
constructs
is
composed
of:
typeName
is
the
name
of
the
typed
data
structure.
Types
are
referenced
in
the
definitions
of
object
members
and
in
the
definitions
of
the
semantics
for
those
data
structures.
member*
is
a
list
of
zero
or
more
terminals
or
references
to
other
typeExpressions.
A
typeExpression
is
one
of:
typeName
—
an
object
of
corresponding
type
array
:
[
typeExpression+
]
—
an
array
of
one
or
more
JSON
values
matching
the
typeExpression.
choice
:
typeExpression1
|
typeExpression2
|
…
—
a
choice
between
two
or
more
typeExressions.
Cardinalities
are
represented
as
by
the
strings
?
,
+
,
*
following
the
notation
in
the
XML
specification
[
XML
]
or
{m,}
to
indicate
a
that
at
least
m
elements
are
required.
The
following
examples
are
excerpts
from
the
definitions
below.
In
the
JSON
notation,
Not
captured
in
this
JSON
syntax
definition
is
the
rule
that
every
shapeExpr
nested
in
a
schema's
shapes
must
have
an
id
and
no
other
shapeExpr
may
have
an
id
.
The
JSON
syntax
definitition
simplifies
this
by
adding
id
:
shapeExprLabel
?
to
every
shapeExpr
.
This
example
includes
a
nested
shape.
Nested
shapes
are
not
permitted
to
have
ids
.
The
shape
expressions
in
a
schema
are
expressed
as
a
list
of
shape
expressions
with
id
attributes
because
JSON-LD
1.0
has
no
provision
for
defining
as
JSON
object
as
representing
a
map
of
URL→object.
Drafts
of
JSON-LD
1.1
include
this
expressivity
and,
once
JSON-LD
1.1
exits
Candidate
Recommendation,
future
versions
of
ShExJ
will
likely
adopt
it
while
requiring
backard-compatibility
with
the
list
of
shape
expressions
with
id
attributes.
2.3
Document
style
JSON
examples
are
rendered
in
a
.json
CSS
style.
Partial
examples
include
ranges
in
a
.comment
CSS
style
to
indicate
text
which
would
be
substituted
in
a
complete
example.
For
example
{
"type":
"ShapeAnd",
"shapeExprs":
[
SE
1
,
…
]
}
indicates
that
both
SE
1
and
…
would
be
substituted
in
a
complete
example.
In
javascript-enabled
browsers,
schemas
with
a
button
can
be
converted
between
the
JSON
representation
and
the
compact
syntax
by
clicking
the
button.
The
button
text
indicates
the
currently
shown
representation.
Selecting
the
example
and
pressing
"j"
or
"c"
converts
the
example
to
the
JSON
(ShExJ)
or
compact
form
(ShExC).
Pressing
"shift
J"
or
"shift
C"
converts
all
such
examples
to
ShExJ
or
ShExC.
2.4
Graph
access
The
validation
process
defined
in
this
document
relies
on
matching
triple
patterns
in
the
form
(subject,
predicate,
object)
where
each
position
may
be
supplied
by
a
constant,
a
previously
defined
term,
or
the
underscore
"
_
",
which
represents
a
previously
undefined
element
or
wildcard.
This
corresponds
to
a
SPARQL
Triple
Pattern
where
each
"_"
is
replaced
by
a
unique
blank
node
.
Matching
such
a
triple
pattern
against
a
graph
is
defined
by
SPARQL
Basic
Graph
Pattern
Matching
(BGP)
with
a
BGP
containing
only
that
triple
pattern
.
2.5
Validation
process
ShEx
validation
is
defined
in
this
document
by
the
isValid
function.
This
process
takes
as
input
a
shapes
schema
,
an
RDF
graph
,
and
a
fixed
ShapeMap
(abbreviated
as
"ShapeMap"
in
this
document).
ShEx
validation
results
may
be
reported
as
a
result
ShapeMap
[
shape-map
].
For
illustration
purposes
in
this
specification,
both
the
fixed
ShapeMap
input
and
the
result
ShapeMap
output
are
represented
in
a
table
with
four
columns:
node
:
a
ShapeMap
nodeSelector,
shape
:
a
ShapeMap
shapeLabel,
result
:
"
pass
"
(for
"conformant"
status)
or
"
fail
"
("nonconformant"
status),
and
an
optional
reason
:
an
informal,
human-readable
explanation.
node
shape
result
reason
<node1>
<Shape1>
pass
<node2>
<Shape1>
fail
no
ex:state
supplied.
3.
Terminology
Shape
expressions
are
defined
using
terms
from
RDF
semantics
[
rdf11-mt
]:
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
words
MAY
,
MUST
,
MUST
NOT
,
and
SHOULD
NOT
in
this
document
are
to
be
interpreted
as
described
in
BCP
14
[
RFC2119
]
[
RFC8174
]
when,
and
only
when,
they
appear
in
all
capitals,
as
shown
here.
Conformance
criteria
are
relevant
to
authors
and
authoring
tool
implementers.
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.
isValid
:
For
a
graph
G
,
a
schema
Sch
and
a
fixed
ShapeMap
ism
,
isValid(
G
,
Sch
,
ism
)
indicates
that
for
every
RDFnode/shapeLabel
pair
(n,
sl)
in
ism
,
the
node
n
satisfies
the
shape
expression
identified
by
sl
.
The
latter
is
captured
by
the
expression
satisfies(
n
,
s
,
G
,
Sch
,
completeTyping
(
G
,
Sch
))
.
The
function
satisfies
is
defined
for
every
kind
of
shape
expression
.
The
validation
of
an
RDF
graph
G
against
a
ShEx
schema
Sch
is
based
on
the
existence
of
completeTyping(
G
,
Sch
)
.
For
an
RDF
graph
G
and
a
shapes
schema
Sch
,
a
typing
is
a
set
of
pairs
of
the
form
(n,
s)
where
n
is
a
node
in
G
and
s
is
a
Shape
that
appears
in
some
shape
expression
in
the
shapes
mapping
of
Sch
.
A
correct
typing
is
a
typing
such
that
for
every
RDFnode/shape
pair
(n,s)
in
typing
,
matchesShape(
n
,
s
,
G
,
Sch
,
typing
)
holds.
completeTyping(
G
,
Sch
)
is
a
unique
correct
typing
that
exists
for
every
graph
and
every
ShEx
schema
that
satisfies
the
schema
requirements
.
completeTyping
:
the
definition
of
completeTyping(
G
,
Sch
)
is
based
on
a
stratification
of
Sch
.
The
number
of
strata
of
Sch
is
the
number
of
maximal
strongly
connected
components
of
the
dependency
graph
of
Sch
.
A
stratification
of
a
schema
Sch
with
k
strata
is
a
function
stratum
that
associates
with
every
Shape
in
Sch
a
natural
number
between
1
and
k
such
that:
If
s1
and
s2
belong
to
the
same
maximal
strongly
connected
component,
then
stratum(
s1
)
=
stratum(
s2
)
.
If
there
is
a
reference
from
s1
to
s2
and
s1
and
s2
do
not
belong
to
the
same
maximal
strongly
connected
component,
then
stratum(
s2
)
<
stratum(
s1
)
.
The
existence
of
a
stratification
for
every
schema
is
guaranteed
by
the
negation
requirement
.
Given
a
stratification
stratum
of
Sch
with
k
strata,
defines
inductively
the
series
of
k
typings
completeTypingOn(
1
,
G
,
Sch
)
…
completeTypingOn(
k
,
G
,
Sch
)
.
completeTypingOn(
1
,
G
,
Sch
)
is
the
union
of
all
correct
typings
that
contain
only
RDFnode/shape
pairs
(n,s)
with
stratum(
s
)
=
1
;
for
every
i
between
2
and
k
,
completeTypingOn(
i
,
G
,
Sch
)
is
the
union
of
all
correct
typings
that:
contain
only
RDFnode/shape
pairs
(n,s)
with
stratum(
s
)
≤
i
are
equal
to
completeTypingOn(
i
-1,
G
,
Sch
)
when
restricted
to
their
RDFnode/shape
pairs
(n1,s1)
for
which
stratum(
s1
)
<
i.
Then
completeTyping(
G
,
Sch
)
=
completeTypingOn(
k
,
G
,
Sch
)
.
The
schema
Sch
might
have
several
different
stratifications
but
completeTyping(
G
,
Sch
)
is
the
same
for
all
these
stratifications.
This
property
is
reminiscent
of
the
use
of
stratified
negation
in
Datalog.
In
order
to
decide
isValid(Sch,
G,
m),
it
is
sufficient
to
compute
only
a
portion
of
completeTyping
using
an
appropriate
algorithm.
A
shape
expression
is
composed
of
four
kinds
of
objects
combined
with
the
algebraic
operators
And,
Or
and
Not:
a
node
constraint
(
NodeConstraint
)
that
defines
the
set
of
allowed
values
of
a
node.
These
include
specification
of
RDF
node
kind,
literal
datatype,
XML
String
and
numeric
facets
and
enumeration
of
value
sets.
a
shape
constraint
(
Shape
)
that
defines
a
constraint
on
the
allowed
neighbourhood
of
a
node,
that
is,
the
allowed
triples
that
contain
this
node
as
subject
or
object.
an
external
shape
(
ShapeExternal
)
which
is
an
extension
mechanism
to
externally
define
e.g.
functional
shapes
or
prohibitively
large
value
sets.
IRI AND
(
@<http://schema.example/#IssueShape>
OR NOT { … }
)
In
this
ShapeOr's
shapeExprs
,
"http://schema.example/#IssueShape"
is
a
reference
to
the
shape
expression
with
the
id
"http://schema.example/#IssueShape".
5.3.2
Semantics
satisfies
:
The
expression
satisfies(
n
,
se
,
G
,
Sch
,
t
)
indicates
that
a
node
n
and
a
graph
G
satisfy
a
shape
expression
se
with
typing
t
for
schema
Sch
.
notSatisfies
:
Conversely,
notSatisfies(
n
,
se
,
G
,
Sch
,
t
)
indicates
that
n
and
G
do
not
satisfy
se
with
the
given
typing
t
.
satisfies(
n
,
se
,
G
,
Sch
,
t
)
is
true
if
and
only
if:
For
a
node
n
and
constraint
nc
,
satisfies2(
n
,
nc
)
if
and
only
if
for
every
nodeKind
,
datatype
,
xsFacet
and
values
constraint
value
v
present
in
nc
nodeSatisfies(
n
,
v
)
.
The
following
sections
define
nodeSatisfies
for
each
of
these
types
of
constraints:
Note
that
<issue2>
fails
not
because
of
a
nodeKind
violation
but
instead
because
of
a
Cardinality
violation
described
below.
5.4.3
Datatype
Constraints
For
a
node
n
and
constraint
value
v
,
nodeSatisfies(
n
,
v
)
if
n
is
a
Literal
with
the
datatype
v
and,
if
v
is
in
the
set
of
SPARQL
operand
data
types
[
sparql11-query
],
an
XML
schema
string
with
a
value
of
the
lexical
form
of
n
can
be
cast
to
the
target
type
v
per
XPath
Functions
3.1
section
19
Casting
[
xpath-functions
].
The
lexical
form
and
numeric
value
(where
applicable)
of
all
datatypes
required
by
SPARQL
XPath
Constructor
Functions
MUST
be
tested
for
conformance
with
the
corresponding
XML
Schema
form.
ShEx
extensions
MAY
add
support
for
other
datatypes.
RDF
1.0
included
RDF
literals
with
no
datatype
or
language
tag.
These
are
called
"
simple
literals
"
in
SPARQL11[
sparql11-query
].
In
RDF
1.1,
these
literals
have
the
datatype
http://www.w3.org/2001/XMLSchema#string
.
Let
len
=
the
number
of
unicode
codepoints
in
lex
For
a
node
n
and
constraint
value
v
,
nodeSatisfies(
n
,
v
)
:
for
"
length
"
constraints,
v
=
len
,
for
"
minlength
"
constraints,
v
>=
len
,
for
"
maxlength
"
constraints,
v
<=
len
,
for
"
pattern
"
constraints,
v
is
unescaped
into
a
valid
XPath
3.1
regular
expression
[
xpath-functions-31
]
re
and
invoking
fn:matches
(
lex
,
re
)
returns
fn:true
.
If
the
flags
parameter
is
present,
it
is
passed
as
a
third
argument
to
fn:matches
.
The
pattern
may
have
XPath
3.1
regular
expression
escape
sequences
per
the
modified
production
[10]
in
section
5.6.1.1
as
well
as
numeric
escape
sequences
of
the
form
'u'
HEX
HEX
HEX
HEX
or
'U'
HEX
HEX
HEX
HEX
HEX
HEX
HEX
HEX.
Unescaping
replaces
numeric
escape
sequences
with
the
corresponding
unicode
codepoint.
ex:submittedBy
expected
to
be
>=
10
characters,
3
characters
found.
Note
Access
to
blank
node
identifiers
may
be
impossible
or
unadvisable
for
many
use
cases.
For
instance,
the
SPARQL
Query
and
SPARQL
Update
languages
treat
blank
nodes
in
the
query,
labeled
or
otherwise,
as
variables.
Lexical
constraints
on
blank
node
identifiers
can
only
be
implemented
in
systems
which
preserve
such
labels
on
data
import.
found
"
\U0001D4B8
"
instead
of
"
𝒸
"
(codepoint
U+1D4B8).
5.4.5
XML
Schema
Numeric
Facet
Constraints
Numeric
facet
constraints
apply
to
the
numeric
value
of
RDF
Literals
with
datatypes
listed
in
SPARQL
1.1
Operand
Data
Types
[
sparql11-query
].
Numeric
constraints
on
non-numeric
values
fail.
totaldigits
and
fractiondigits
constraints
on
values
not
derived
from
xsd:decimal
fail.
Let
num
be
the
numeric
value
of
n
.
For
a
node
n
and
constraint
value
v
,
nodeSatisfies(
n
,
v
)
:
for
"
fractiondigits
"
constraints,
v
is
less
than
or
equals
the
number
of
digits
to
the
right
of
the
decimal
place
in
the
XML
Schema
canonical
form
[
xmlschema-2
]
of
the
value
of
n
,
ignoring
trailing
zeros.
vsv
is
a
Wildcard
with
exclusions
excls
and
there
is
no
x
in
excls
such
that
nodeIn(n,
excl)
.
nodeIn
:
asserts
that
an
RDF
node
n
is
equal
to
an
RDF
term
s
or
is
in
a
set
defined
by
a
IriStem
,
LiteralStem
or
LanguageStem
.
The
expression
nodeIn(
n
,
s
)
is
satisfied
if:
A
value
set
can
have
a
single
value
in
it.
This
is
used
to
indicate
that
a
specific
value
is
required,
e.g.
that
an
ex:state
must
be
equal
to
<http://schema.example/#Resolved>
or
the
rdf:type
of
some
node
must
be
foaf:Person.
5.5
Shapes
and
Triple
Expressions
Triple
expressions
are
used
for
defining
patterns
composed
of
triple
constraints.
Shapes
associate
triple
expressions
with
flags
indicating
whether
triples
match
if
they
do
not
correspond
to
triple
constraints
in
the
triple
expression
.
A
triple
expression
is
composed
of
TripleConstraint
and
tripleExprRef
objects
composed
with
grouping
and
choice
operators.
The
semantics
of
the
matchesShape
function
are
based
on
the
matches
function
defined
below
.
For
a
node
n
,
shape
S
,
graph
G
,
a
ShExSchema
Sch
,
and
typing
m
,
matchesShape(
n
,
S
,
G
,
Sch
,
m
)
if
and
only
if:
neigh
(
G
,
n
)
can
be
partitioned
into
two
sets
matched
and
remainder
such
that
matches(
matched
,
expression
,
m
)
.
If
expression
is
absent,
remainder
=
neigh
(
G
,
n
)
.
Let
outs
be
the
arcsOut
in
remainder
:
outs
=
remainder
∩
arcsOut
(
G
,
n
)
.
Let
matchables
be
the
triples
in
outs
whose
predicate
appears
in
a
TripleConstraint
in
expression
.
If
expression
is
absent,
matchables
=
Ø
(the
empty
set)
.
The
complexity
of
partitioning
is
described
briefly
in
the
ShEx2
Primer
.
There
is
no
triple
in
matchables
which
matches
a
TripleConstraint
in
expression
.
Let
unmatchables
be
the
triples
in
outs
which
are
not
in
matchables
.
matchables
∪
unmatchables
=
outs
.
There
is
no
triple
in
matchables
whose
predicate
does
not
appear
in
extra
.
closed
is
false
or
unmatchables
is
empty.
matches
:
asserts
that
a
triple
expression
is
matched
by
a
set
of
triples
that
come
from
the
neighbourhood
of
a
node
in
an
RDF
graph
.
The
expression
matches(
T
,
expr
,
m
)
indicates
that
a
set
of
triples
T
can
satisfy
these
rules:
expr
has
semActs
and
matches(
T
,
expr
,
m
)
by
the
remaining
rules
in
this
list
and
the
evaluation
of
semActs
succeeds
according
to
the
section
below
on
Semantic
Actions
.
expr
has
a
cardinality
of
min
and/or
max
not
equal
to
1,
where
a
max
of
-1
is
treated
as
unbounded,
and
T
can
be
partitioned
into
k
subsets
T
1
,
T
2
,…
T
k
such
that
min
≤
k
≤
max
and
for
each
T
n
,
matches(
T
n
,
expr
,
m
)
by
the
remaining
rules
in
this
list.
matches(
T,
{
"type":
"OneOf",
"shapeExprs":
[
te
1
,
te
2
,
…
],
"min":
2,
"max":
3
}
(
te
1
|
te
2
…
)
{2,3}
,
m)
evaluates
as:
Let
e
=
{
"type":
"OneOf",
"shapeExprs":
[
te
1
,
te
2
,
…
]
}
(
te
1
|
te
2
…
)
(
matches(T
1
,
e,
m)
and
matches(T
2
,
e,
m)
and
T
=
T
1
∪
T
2
)
or
(
matches(T
1
,
e,
m)
and
matches(T
2
,
e,
m)
and
matches(T
3
,
e,
m)
and
T
=
T
1
∪
T
2
∪
T
3
)
expr
is
a
OneOf
and
there
is
some
shape
expression
se2
in
shapeExprs
such
that
matches(
T
,
se2
,
m
)
.
expr
is
an
EachOf
and
there
is
some
partition
of
T
into
T
1
,
T
2
,…
such
that
for
every
expression
expr
1
,
expr
2
,…
in
shapeExprs
,
matches(
T
n
,
expr
n
,
m
)
.
Both
the
shape
expression
<PersonShape>
and
the
triple
expression
<nameExpr>
are
in
scope.
schema2
's
<nameExpr>
is
referenced
in
schema1
's
<EmployeeShape>
Redundant
imports
are
treated
as
a
single
import.
This
includes
circular
imports:
<http://schema.example/schema1#S1>
has
conflicting
definitions
and
an
included
schema
has
a
start
directive
and
the
reference
to
<http://schema.example/schema1#S3>
is
not
resolvable
after
imports.
5.7
Schema
Requirements
The
semantics
defined
above
assume
three
structural
requirements
beyond
those
imposed
by
the
grammar
of
the
abstract
syntax.
These
ensure
referential
integrity
and
eliminate
logical
paradoxes
such
as
those
that
arrise
through
the
use
of
negation.
These
are
not
constraints
expressed
by
the
schema
but
instead
those
imposed
on
the
schema.
Additionally,
a
shapeExprLabel
cannot
refer
to
itself
through
a
shape
reference
either
directly
or
recursively.
The
shapeExprRef
closure
of
a
shape
expression
se
is
the
set
of
shape
expression
labels
used
as
references
in
se
.
The
shapeExprLabel
sl
belongs
to
shapeExprRefClosure(
se
)
if
and
only
if:
Additionally,
a
tripleExprLabel
cannot
refer
to
itself
through
a
triple
expression
reference
either
directly
or
recursively.
The
tripleExprRef
closure
of
a
triple
expression
te
is
the
set
of
triple
expression
labels
used
as
references
in
te
.
The
tripleExprLabel
tl
belongs
to
tripleExprRefClosure(
te
)
if
and
only
if:
The
set
of
atomic
shapes
of
a
shapeExpr
se
contains
a
Shape
s
if
s
or
its
id
appears
either
directly
or
by
shapeExprRef
in
se
.
That
is,
s
belongs
to
atomicShapes(
se
)
if
and
only
if
s
appears
as
an
atomic
shape
in
se
,
or
sid
is
the
id
of
s
and
sid
appears
as
an
atomic
shapeExprRef
in
se
,
or
s
belongs
to
atomicShapes(se2)
for
some
shape
expression
se2
such
that
the
id
of
se2
belongs
to
the
shapeExprRefClosure
of
se
.
The
set
of
atomic
triple
constraints
of
a
tripleExpr
te
includes
every
TripleConstraint
tc
that
appears
directly
or
by
tripleExprRef
in
te
.
That
is,
tc
belongs
to
atomicTripleConstraints(
te
)
if
and
only
if:
there
is
a
triple
constraint
tc
that
belongs
to
atomicTripleConstraints(
s1
.
expression
)
,
and
tc
.
valueExpr
is
present,
and
s2
belongs
to
atomicShapes(
tc
.
valueExpr
)
.
The
reference
from
s1
to
s2
is
a
negated
reference
if
s2
appears
under
an
odd
number
of
ShapeNot
in
the
shapeExprRef
closure
of
tc
.
valueExpr
,
or
tc
has
predicate
p
and
s1
has
extra
p
.
The
dependency
graph
of
the
schema
Sch
is
the
graph
which
vertices
are
all
the
Shape
s
that
appear
in
some
shape
expression
in
the
shapes
of
Sch
,
and
that
has
two
kinds
of
edges:
negative
and
positive.
There
is
a
negative
edge
from
s1
to
s2
if
s1
has
a
negated
reference
to
s2
.
There
is
a
positive
edge
from
s1
to
s2
if
s1
has
a
reference
but
not
a
negated
reference
to
s2
.
Annotations
provide
a
format-independent
way
to
provide
additional
information
about
elements
in
a
schema.
They
appear
in
lists
in
Shape
,
OneOf
,
EachOf
and
TripleConstraint
's
annotations
.
Annotations
do
not
affect
whether
a
node
conforms
to
some
shape.
Because
they
are
part
of
the
structure
of
the
schema,
they
can
be
parsed
in
one
ShEx
format
and
emitted
in
that
format
or
another.
This
document
uses
this
nested
tree
convention
to
indicate
that
the
dependency
of
an
evaluation
on
those
nested
inside
it.
Nesting
is
expressed
as
indentation.
Here,
the
evaluation
of
satisfies
NodeConstraint
("30"^^xsd:integer,
S1,
G,
m)
depends
on
satisfies2
NodeConstraint
("30"^^xsd:integer,
S1)
.
Validate
"30"^^<http://www.w3.org/2001/XMLSchema#integer>
as
IntConstraint
:
Validating
a
shape
requires
evaluating
it's
triple
expression
as
well
as
the
variables
and
functions
neigh
(G,
n)
,
matched
,
remainder
,
outs
,
matchables
and
unmatchables
:
matchables
=
Ø
/*
There
are
no
remaining
arcs
out
of
<Alice>
with
predicates
appearing
in
tc1.
*/
unmatchables
=
Ø
/*
There
are
no
other
arcs
out
of
<Alice>.
*/
closed
is
false
/*
The
Shape
's
closed
paramater
has
a
value
of
false.
*/
It
is
quite
common
that
Shapes
will
constrain
their
nested
TripleConstraints
with
NodeConstraints.
Here
is
an
example
including
that,
extra
triples
and
a
closed
shape:
Any
mixure
of
foaf:name
with
foaf:givenName
or
foaf:familyName
will
fail
to
satisfy
the
schema
as
there
will
be
a
matchable
triple
t3
that's
not
used
in
the
triple
expression
te1
.
Setting
the
maximum
cardinality
of
a
TripleConstraint
with
predicate
p
to
zero
(i.e.
"max":
0
in
ShExJ
or
{0}
or
{0,
0}
in
ShExC
)
asserts
that
matching
nodes
must
have
no
triples
with
predicate
p
.
The
ShEx
Compact
Syntax
expresses
ShEx
schemas
in
a
compact,
human-friendly
form.
Parsing
ShExC
transforms
a
ShExC
document
into
an
equivalent
ShExJ
structure.
This
is
defined
as
a
BNF
which
accepts
ShExC
followed
by
instructions
for
tranlating
the
rules
in
the
BNF
production
into
their
corresponding
ShExJ
objects.
For
example,
"
shapeExprDecl
returns
shapeExpression
"
indicates
that
the
result
of
matching
the
shapeExprDecl
production
is
the
object
produced
by
parsing
the
shapeExpression
production.
Shape
expressions
are
logical
combinations
of
shape
atoms.
Inline
variants
of
shape
expressions
are
used
in
tripleConstraint
s
and
are
not
permitted
to
have
annotations
or
semantic
actions.
If
the
right
shapeAnd
matches
one
or
more
times,
the
result
is
a
ShapeOr
object
with
shapeExprs
containing
the
first
shapeAnd
followed
by
the
ordered
list
from
the
second
shapeAnd
:
If
the
right
shapeNot
matches
one
or
more
times,
the
result
is
a
ShapeAnd
object
with
shapeExprs
containing
the
first
shapeNot
followed
by
the
ordered
list
from
the
second
shapeNot
:
The
literal
has
a
lexical
form
of
the
first
rule
argument,
String
.
If
the
'^^'
iri
rule
matched,
the
datatype
is
iri
and
the
literal
has
no
language
tag
.
If
the
langString
rule
matched,
the
datatype
is
rdf:langString
and
the
language
tag
is
extracted
from
langTag
.
If
neither
matched,
the
datatype
is
xsd:string
and
the
literal
has
no
language
tag
.
The
characters
between
"<"
and
">"
are
taken,
with
the
numeric
escape
sequences
unescaped,
to
form
the
unicode
string
of
the
IRI.
Relative
IRI
resolution
is
performed
per
Turtle
Section
6.3
.
When
used
in
a
prefixDecl
production,
the
prefix
is
a
potentially
empty
unicode
string
matching
the
first
argument
of
the
rule
and
serves
as
a
key
into
the
prefixes
map
.
A
potentially
empty
prefix
is
identified
by
the
first
token,
PNAME_NS
.
The
prefixes
map
MUST
have
a
corresponding
namespace
.
The
unicode
string
of
the
IRI
is
formed
by
unescaping
the
reserved
characters
[
rfc7159
]
in
the
second
argument,
PN_LOCAL
,
and
concatenating
this
onto
the
namespace
.
A
potentially
empty
prefix
is
identified
by
the
second
token,
PNAME_NS
.
The
prefixes
map
MUST
have
a
corresponding
namespace
.
The
unicode
string
of
the
IRI
is
formed
by
unescaping
the
reserved
characters
[
rfc7159
]
in
the
third
token,
PN_LOCAL
,
and
concatenating
this
onto
the
namespace
.
pattern
is
a
unicode
string
formed
from
the
characters
between
the
outermost
'/'s
by
unescaping
matches
of
'\\'
'/'
in
the
terminal
pattern
as
well
as
the
numeric
escape
sequences
matched
by
UCHAR
.
The
remaining
escape
sequences
are
included
verbatim
in
pattern
,
e.g.
^\/\t\\\U0001D4B8$
would
become
^/\t\\\U0001D4B8$
.
flags
is
a
sequence
of
the
characters
[smix]
if
any
were
matched.
Otherwise
no
flags
attribute
is
returned.
The
characters
between
the
outermost
"'''"s
are
taken,
with
numeric
and
string
escape
sequences
unescaped,
to
form
the
unicode
string
of
a
lexical
form.
The
characters
between
the
outermost
'"""'s
are
taken,
with
numeric
and
string
escape
sequences
unescaped,
to
form
the
unicode
string
of
a
lexical
form.
The
characters
between
the
outermost
"'"s
are
taken,
with
numeric
and
string
escape
sequences
unescaped,
to
form
the
unicode
string
of
a
lexical
form.
The
trailing
LANGTAG
is
used
to
create
a
language-tagged
string
.
The
characters
between
the
outermost
'"'s
are
taken,
with
numeric
and
string
escape
sequences
unescaped,
to
form
the
unicode
string
of
a
lexical
form.
The
trailing
LANGTAG
is
used
to
create
a
language-tagged
string
.
The
characters
between
the
outermost
"'''"s
are
taken,
with
numeric
and
string
escape
sequences
unescaped,
to
form
the
unicode
string
of
a
lexical
form.
The
trailing
LANGTAG
is
used
to
create
a
language-tagged
string
.
The
characters
between
the
outermost
'"""'s
are
taken,
with
numeric
and
string
escape
sequences
unescaped,
to
form
the
unicode
string
of
a
lexical
form.
The
trailing
LANGTAG
is
used
to
create
a
language-tagged
string
.
This
section
aggregates
the
JSON
grammar
rules
defined
above
and
includes
terminals
referenced
above.
A
ShExJ
document
is
a
JSON-LD
[
JSON-LD
]
document
which
uses
a
proscribed
structure
to
define
a
schema
containing
shape
expressions
and
triple
expressions
.
A
ShExJ
document
MAY
include
an
@context
property
referencing
http://www.w3.org/ns/shex.jsonld
.
In
the
absense
of
a
top-level
@context
,
ShEx
Processors
MUST
act
as
if
a
@context
property
is
present
with
the
value
http://www.w3.org/ns/shex.jsonld
.
A
ShExJ
document
can
also
be
thought
of
as
the
serialization
of
an
RDF
Graph
using
the
Shape
Expression
Vocabulary
[
shex-vocab
]
which
conforms
to
the
shape
defined
in
§
B.
ShEx
Schema
for
ShEx
.
Processors
MAY
interpret
a
ShExJ
document
as
an
RDF
Graph.
Processors
may
also
transform
arbitrary
RDF
Graphs
conforming
to
§
B.
ShEx
Schema
for
ShEx
into
ShExJ
using
a
mechanism
not
described
within
this
specification.
In
ShExJ,
the
unbounded
cardinality
constraint
is
-1
,
rather
than
"*"
.
This
section
has
been
submitted
to
the
Internet
Engineering
Steering
Group
(IESG)
for
review,
approval,
and
registration
with
IANA.
text/shex
Type
name:
text
Subtype
name:
shex
Required
parameters:
None
Optional
parameters:
None
Encoding
considerations:
8-bit
text
ShEx
Compact
Syntax
(ShExC)
is
a
text
language
which
is
encoded
in
UTF-8.
Security
considerations:
Given
that
ShExC
allows
the
substitution
of
long
IRIs
with
short
terms,
ShExC
documents
may
expand
considerably
when
processed
and,
in
the
worst
case,
the
resulting
data
might
consume
all
of
the
recipient's
resources.
Applications
should
treat
any
data
with
due
skepticism.
Any
programming
environment
that
requires
the
exchange
of
directed
graphs.
Implementations
of
ShEx
have
been
created
for
JavaScript,
Python,
Ruby,
and
Java.
Revealing
the
structure
of
an
RDF
graph
can
reveal
information
about
the
content
of
conformant
data.
For
instance,
a
schema
with
a
predicate
to
describe
cancer
stage
indicates
that
conforming
graphs
describe
patients
with
cancer.
The
process
of
testing
a
graph's
conformance
to
a
schema
may
involve
many
detailed
queries
which
could
draw
resources
to
respond
to
API
calls
or
SPARQL
queries.
ShEx
has
an
extension
mechanism
which
can,
in
principle,
evalute
arbitrary
code,
possibly
as
some
trusted
agent.
Such
extensions
should
not
be
executed
if
they
don't
come
from
a
trusted
source.
Since
ShEx
is
intended
to
be
a
pure
data
exchange
format
for
validating
RDF
graphs
,
the
ShExJ
serialization
SHOULD
NOT
be
passed
through
a
code
execution
mechanism
such
as
JavaScript's
eval()
function
to
be
parsed.
An
(invalid)
document
may
contain
code
that,
when
executed,
could
lead
to
unexpected
side
effects
compromising
the
security
of
a
system.