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.
This document has been developed by the
Shape Expressions Community Group. The specification has undergone significant development since the 1.0 version.
This version of the document represents a Candidate Release, with stable features. Comments and implementations are solicited prior to an eventual Final 2.0 Release.
The Shape Expressions language is expected to remain stable with the exception of:
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 describes RDF graph [RDF11-CONCEPTS] structures as sets of potentially connected Shapes. These constrain the triples involving nodes in an RDF graph.
Node Constraints constrain RDF nodes by constraining their node kind (IRI, blank node or Literal), enumerating permissible values in value sets, specifying their datatype, and constraining value ranges of Literals. Additionally, they constrain
lexical forms of Literals, IRIs and labeled blank nodes.
Shape Expressions schemas share blank nodes with the constrained RDF graphs in the same way that graphs in RDF datasets [rdf11-concepts] share blank nodes.
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 [rfc4627] Syntax serves as a serializable proxy for an abstract syntax. This specification uses a simple grammar to describe the set of JSON documents that can be interpreted
as a ShEx schema.
Typed data structures are represented as JSON objects:
typeName { member* } RFC4627 Section 2.2 provides syntactic constraints for JSON — this grammar constrains those to valid ShExJ constructs.
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.
Terminals are JSON strings and are indicated by all-caps, e.g. IRI. For brevity, RDF nodes are represented as JSON strings composed as:
IRI: the lexical form of the IRI, e.g. "http://example.org/resource"
datatyped literal: U+005E U+005E ('^^') and the lexical form of the datatype URI, e.g. "\"123\"^^http://www.w3.org/2001/XMLSchema#integer"
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.
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.
The following examples are excerpts from the definitions below. In the JSON notation,
signifies that a NodeConstraint has a nodeKind of one of the four literals followed by any number of xsFacet and an
xsFacet is either a stringFacet or a numericFacet.
2.1 References
ShExJ is a dialect of JSON-LD [JSON-LD] and the member id is used as a node identifier.
An object may be represented inline or referenced by its id which may be either a blank node or an IRI.
Not captured in this JSON syntax definition is the rule that every shapeExpr referenced by 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.
2.2 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": [ SE1, … ] } indicates that both SE1 and … would be substituted in a complete example.
2.3 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.4 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" (conformant) or "fail" (nonconformant), 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 are to be interpreted as described in [RFC2119].
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: The expression isValid(G, m) indicates that for every nodeSelector/shapeLabel pair (n, s) in m, s has a corresponding shape expressionse and satisfies(n, se, G, m).
satisfies is defined below for each form of shape expression.
Note
Validation of a graphG does not necessarily require the construction of a ShapeMap with every node in G. The validation semantics defined below imply a set of dependencies for validating some node as a shape. A validation process that tests every node in a graph against every shape in a schema can be considered to have an input ShapeMap associating each node with the set of all shapes in the schema.
Validation of a node against a shape in a schema requires that there is a consistent mapping from node to
shape for every node and shape visited during a validation process. The remainder of this document uses m to indicate such a mapping.
5.3 Shape Expressions
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.
a shape reference (shapeExprLabel) identifies another shape in the schema.
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, m) indicates
that a node n and graphG satisfy a shape expressionse with shapeMapm. notSatisfies: Conversely, notSatisfies(n, se, G, m) indicates that n and G do not satisfy se with the given shapeMapm.
notSatisfies(n, se, G, _) indicates that no shapeMap would allow n and G to satisfy se.
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 ncnodeSatisfies(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 an 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].
Only datatypes supported by SPARQL MUST be tested but 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 exclusionsexcls 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.
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 T1, T2,…Tk such that min ≤ k ≤ max and for each Tn, matches(Tn, expr, m) by the remaining rules in this list.
The schema has a shape se2 with the id "http://schema.example/PersonShape"
satisfies(n, se2, G, m)
5.6 Schema Requirements
The semantics defined above assume two 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.
An shapeExprRefMUST appear in the schema's shapes map and the corresponding triple expressionMUST be a Shape with a shapeExpr. The function shapeExprWithId(shapeExprRef) returns the shape's shapeExpr.
The reference is negated if SE2 appears within an odd number of negations inside SE1.
If SE2 appears within the valueExpr of a TripleConstraint with predicatep inside a Shape with extrap, there is an additional reference from SE1 to SE2 with the opposite sense of negated.
Note
One strategy for detecting negated cycles is stratified negation.
ex:T {ex:p @ex:S}
ex:S NOT (NOT @ex:T AND @ex:U)
ex:U .
This is a negated self-reference of ex:T (indirectly through ex:U) and violates the negation requirement. More precisely, ex:T refers to the negation of ex:U through NOT @ex:S, and ex:U refers to the negation of ex:T trough ex:S.
Semantic actions serve as an extension point for Shape Expressions. They appear in lists in Schema's startActs and
Shape, OneOf, EachOf and TripleConstraint's semActs.
A semantic action is a tuple of an identifier and some optional code:
The evaluation semActsSatisfied on a list of SemActs returns success or failure. The evaluation
of an individual SemAct is implementation-dependent.
5.7.2 Use - informative
A practical evaluation of a SemAct will provide access to some context. For instance, the http://shex.io/extensions/Test/ extension requires access to the subject, predicate and object of a triple matching a TripleConstraint.
These are used in a print function.
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.
Here the shape identified by http://schema.example/IntConstraint is a shape expression consisting of a single NodeConstraint.
Per Shape Expression Semantics, "30"^^<http://www.w3.org/2001/XMLSchema#integer> satisfies IntConstraint.
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:
matchables = Ø, unmatchables = [t5], closed is false
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 expressionte1.
Setting the maximum cardinality of a TripleConstraint with predicatep to zero (i.e. "max": 0 in ShExJ or {0} or {0, 0} in ShExC)
asserts that matching nodes must have no triples with predicatep.
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 tripleConstraints
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:
Shape defintions associate a triple expression with a closed flag and a list of partially constrained (extra) predicates. Any predicate appearing in a triple expression is fully constrained unless it appears in the list of extras.
If the right groupTripleExpr matches one or more times, the result is a OneOf object with
expressions containing the first groupTripleExpr followed by the ordered list from the second groupTripleExpr:
If "." matches and exclusion matches one or more times, all matched items must be consistently iri, literal, or language. valueSetValue returns either a IriStemRange, LiteralStemRange, or LanguageStemRange object with exclusions equal to the set of results of exclusion:
If iri and "~" match and iriExclusion matches one or more times,
iriRange returns a IriStemRange object with exclusions equal to the set of results of iriExclusion:
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 mapMUST have a corresponding namespace. The unicode string of the IRI is formed by unescaping the reserved characters 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 mapMUST have a corresponding namespace. The unicode string of the IRI is formed by unescaping the reserved characters 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 defines a set of properties and permitted values for describing Shape Expressions in JSON [RFC7159], and how these properties should be interpreted by applications.
A ShExJ document is a JSON-LD [JSON-LD] document uses a proscribed structure which holds an object at the top level. This object describes a schema containing
shape expressions and triple expressions. A ShExJ document
MUST include a @context property referencing http://www.w3.org/ns/shex.jsonld, and MAY include additional contexts and term definitions. 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 Shape. Processors MAY choose to interpret a ShExJ
document as an RDF Graph and process using RDF Graph semantics. Processors may also transform arbitrary RDF Graphs conforming to B.ShEx Shape into ShExJ using a mechanism not described within this specification.
In ShExJ, the unbounded cardinality constraint is -1, rather than "*".
INTEGER# a JSON string matching the lexical form of an integer
DECIMAL
:
DECIMAL# a JSON string matching the lexical form of an decimal
DOUBLE
:
DOUBLE# a JSON string matching the lexical form of an double
STRING
:
'"' .* '"' # a JSON string starting and ending with the U+0022 (") character
DATATYPE_STRING
:
'"' .* '"' ( [^#0000- <>\"{}|^`\\] | UCHAR )* # a JSON string starting with U+0022 ("), followed by the lexical form of the string, then U+0022 U+005E U+005E ("^^) and the IRI of the datatype
LANG_STRING
:
'"' .* '"@' LANGTAG# a JSON string starting with U+0022 ("), followed by the lexical form of the string, then U+0022 U+0040 ("@) and the LANGTAG
B. ShEx Shape
This section is non-normative.
The following schema describes the form of an RDF Graph conforming to a Shape Expression schema,
consisten with the description of ShExJ.
Example 1: ShExR Shape Expression Schema
PREFIX sx: <http://www.w3.org/ns/shex#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
BASE <http://www.w3.org/ns/shex#>
start=@<Schema><Schema> CLOSED {
a [sx:Schema] ;
sx:startActs @<SemActList1Plus>? ;
sx:start @<shapeExpr>?;
sx:shapes @<shapeExpr>*
}
<shapeExpr> @<ShapeOr> OR @<ShapeAnd> OR @<ShapeNot> OR @<NodeConstraint> OR @<Shape> OR @<ShapeExternal><ShapeOr> CLOSED {
a [sx:ShapeOr] ;
sx:shapeExprs @<shapeExprList2Plus>
}
<ShapeAnd> CLOSED {
a [sx:ShapeAnd] ;
sx:shapeExprs @<shapeExprList2Plus>
}
<ShapeNot> CLOSED {
a [sx:ShapeNot] ;
sx:shapeExpr @<shapeExpr>
}
<NodeConstraint> CLOSED {
a [sx:NodeConstraint] ;
sx:nodeKind [sx:iri sx:bnode sx:literal sx:nonliteral]?;
sx:datatype IRI ? ;
&<xsFacets> ;
sx:values @<valueSetValueList1Plus>?
}
<Shape> CLOSED {
a [sx:Shape] ;
sx:closed [true false]? ;
sx:extra IRI* ;
sx:expression @<tripleExpression>? ;
sx:semActs @<SemActList1Plus>? ;
}
<ShapeExternal> CLOSED {
a [sx:ShapeExternal] ;
}
<SemAct> CLOSED {
a [sx:SemAct] ;
sx:name IRI ;
sx:code xsd:string?
}
<Annotation> CLOSED {
a [sx:Annotation] ;
sx:predicate IRI ;
sx:object @<objectValue>
}
# <xsFacet> @<stringFacet> OR @<numericFacet><facet_holder> { # hold labeled productions
$<xsFacets> ( &<stringFacet> | &<numericFacet> )* ;
$<stringFacet> (
sx:length xsd:integer
| sx:minlength xsd:integer
| sx:maxlength xsd:integer
| sx:pattern xsd:string ; sx:flags xsd:string?
);
$<numericFacet> (
sx:mininclusive @<numericLiteral>
| sx:minexclusive @<numericLiteral>
| sx:maxinclusive @<numericLiteral>
| sx:maxexclusive @<numericLiteral>
| sx:totaldigits xsd:integer
| sx:fractiondigits xsd:integer
)
}
<numericLiteral> xsd:integer OR xsd:decimal OR xsd:double
<valueSetValue> @<objectValue> OR @<IriStem> OR @<IriStemRange>
OR @<LiteralStem> OR @<LiteralStemRange>
OR @<LanguageStem> OR @<LanguageStemRange><objectValue> IRI OR LITERAL # rdf:langString breaks on Annotation.object
<IriStem> CLOSED { a [sx:IriStem]; sx:stem xsd:anyUri }
<IriStemRange> CLOSED {
a [sx:IriStemRange];
sx:stem xsd:anyUri OR @<Wildcard>;
sx:exclusion @<objectValue> OR @<IriStem>*
}
<LiteralStem> CLOSED { a [sx:LiteralStem]; sx:stem xsd:string }
<LiteralStemRange> CLOSED {
a [sx:LiteralStemRange];
sx:stem xsd:string OR @<Wildcard>;
sx:exclusion @<objectValue> OR @<LiteralStem>*
}
<LanguageStem> CLOSED { a [sx:LanguageStem]; sx:stem xsd:string }
<LanguageStemRange> CLOSED {
a [sx:LanguageStemRange];
sx:stem xsd:string OR @<Wildcard>;
sx:exclusion @<objectValue> OR @<LanguageStem>*
}
<Wildcard> BNODE CLOSED {
a [sx:Wildcard]
}
<tripleExpression> @<TripleConstraint> OR @<OneOf> OR @<EachOf><OneOf> CLOSED {
a [sx:OneOf] ;
sx:min xsd:integer? ;
sx:max xsd:integer? ;
sx:expressions @<tripleExpressionList2Plus> ;
sx:semActs @<SemActList1Plus>? ;
sx:annotation @<Annotation>*
}
<EachOf> CLOSED {
a [sx:EachOf] ;
sx:min xsd:integer? ;
sx:max xsd:integer? ;
sx:expressions @<tripleExpressionList2Plus> ;
sx:semActs @<SemActList1Plus>? ;
sx:annotation @<Annotation>*
}
<tripleExpressionList2Plus> CLOSED {
rdf:first @<tripleExpression> ;
rdf:rest @<tripleExpressionList1Plus>
}
<tripleExpressionList1Plus> CLOSED {
rdf:first @<tripleExpression> ;
rdf:rest [rdf:nil] OR @<tripleExpressionList1Plus>
}
<TripleConstraint> CLOSED {
a [sx:TripleConstraint] ;
sx:inverse [true false]? ;
sx:negated [true false]? ;
sx:min xsd:integer? ;
sx:max xsd:integer? ;
sx:predicate IRI ;
sx:valueExpr @<shapeExpr>? ;
sx:semActs @<SemActList1Plus>? ;
sx:annotation @<Annotation>*
}
<SemActList1Plus> CLOSED {
rdf:first @<SemAct> ;
rdf:rest [rdf:nil] OR @<SemActList1Plus>
}
<shapeExprList2Plus> CLOSED {
rdf:first @<shapeExpr> ;
rdf:rest @<shapeExprList1Plus>
}
<shapeExprList1Plus> CLOSED {
rdf:first @<shapeExpr> ;
rdf:rest [rdf:nil] OR @<shapeExprList1Plus>
}
<valueSetValueList1Plus> CLOSED {
rdf:first @<valueSetValue> ;
rdf:rest [rdf:nil] OR @<valueSetValueList1Plus>
}
C. IANA Considerations
This section has been submitted to the Internet Engineering Steering Group (IESG) for review, approval, and registration with IANA.
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.
Interoperability considerations:
Not Applicable
Published specification:
http://www.w3.org/TR/json-ld
Applications that use this media type:
Any programming environment that requires the exchange of directed graphs. Implementations of ShEx have been created for JavaScript, Python, Ruby, and Java.
Additional information:
Magic number(s):
Not Applicable
File extension(s):
.shex
Macintosh file type code(s):
TEXT
Person & email address to contact for further information:
Eric Prud'hommeaux <eric@w3.org>
Intended usage:
Common
Restrictions on usage:
None
Author(s):
Eric Prud'hommeaux, Iovka Boneva, Jose Labra Gayo, Gregg Kellogg, Niklas Lindström
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.