Shape Expressions (ShEx) is a language for describing RDF graph structures. A ShEx schema prescribes conditions that RDF data graphs must meet in order to be considered "conformant": which subjects, predicates, and objects may appear in a given graph, in what combinations and with what cardinalities and datatypes. In the ShEx model, an RDF graph is tested against a ShEx schema to yield a validation result that flags any parts of the data which do not conform. ShEx schemas are intended for use in validating RDF data, communicating interface parameters and data structures, generating user interfaces, and transforming RDF graphs into other data formats and structures. This primer introduces ShEx by means of annotated examples. Readers should already be familiar with the basic concepts of RDF. The primer is a companion to the full ShEx language specification [[shex-semantics]].
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:
Shape Expressions (ShEx) is a language for describing RDF graph structures. A ShEx schema prescribes conditions that RDF data graphs must meet in order to be considered "conformant". In the ShEx model, an RDF graph is tested against a ShEx schema to yield a validation result that flags any parts of the data which do not conform. ShEx schemas are intended for use in validating instance data, communicating interface parameters and data structures, generating user interfaces, and transforming RDF graphs into other data formats and structures. This primer, a companion to the full ShEx language specification [[shex-semantics]], focuses on the common use case of validating instance data.
A ShEx schema is built on node constraints and triple constraints that define what it means for a given RDF data graph to conform. An RDF triple is the three-part data structure of subject, predicate, and object with which all RDF data is expressed, and an RDF node is the piece of data found in the subject or object position of a triple. (Readers unfamiliar these terms may want to consult an RDF primer.[[rdf11-primer]]) Node constraints and triple constraints are called "constraints" because they define, or "constrain", the set of RDF nodes and data triples that will pass a conformance test.
Picture an RDF database (graph) that carries information about enrollees in a school. Put yourself into the position of a data manager who wants to ensure that every student "record" in this graph reports a valid age and references one or two guardians, identified by IRI. The ShEx schema for accomplishing this has: one node constraint, school:enrolleeAge, for matching data nodes with an integer value between 13 and 20; one triple constraint, defined within the shape school:Enrollee, for matching one or two triples having the predicate ex:hasGuardian, and a second node constraint for specifying that the object (value) of the triple is an IRI. Data that conforms to these constraints will pass validation tests, and data that does not conform will fail.
PREFIX school: <http://school.example/#> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> PREFIX ex: <http://ex.example/#> # Node constraint school:enrolleeAge xsd:integer MinInclusive 13 MaxInclusive 20 school:Enrollee { # Triple constraint (including node constraint IRI) ex:hasGuardian IRI {1,2} }
{ "@context": "http://www.w3.org/ns/shex.jsonld", "type": "Schema", "shapes": [ { "id": "http://school.example/#enrolleeAge", "type": "NodeConstraint", "datatype": "http://www.w3.org/2001/XMLSchema#integer", "mininclusive": 13, "maxinclusive": 20 }, { "id": "http://school.example/#Enrollee", "type": "Shape", "expression": { "type": "TripleConstraint", "predicate": "http://ex.example/#hasGuardian", "min": 1, "max": 2, "valueExpr": { "type": "NodeConstraint", "nodeKind": "iri" } } } ] }
PREFIX ex: <http://ex.example/#> PREFIX inst: <http://example.com/users/> inst:Student1 ex:hasGuardian inst:Person2, inst:Person3 . try it
PREFIX ex: <http://ex.example/#> PREFIX inst: <http://example.com/users/> inst:Student2 ex:hasGuardian inst:Person4, inst:Person5, inst:Person6 . try it
The next example adds a triple constraint on the data predicate foaf:age, which must have a value matching the node constraint school:enrolleeAge, which is cited in the triple constraint by reference, indicated by the '@' symbol.
PREFIX ex: <http://ex.example/#> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> PREFIX school: <http://school.example/#> PREFIX foaf: <http://xmlns.com/foaf/0.1/> school:enrolleeAge xsd:integer MinInclusive 13 MaxInclusive 20 school:Enrollee { foaf:age @school:enrolleeAge ; ex:hasGuardian IRI {1,2} }
{ "@context": "http://www.w3.org/ns/shex.jsonld", "type": "Schema", "shapes": [ { "id": "http://school.example/#enrolleeAge", "type": "NodeConstraint", "datatype": "http://www.w3.org/2001/XMLSchema#integer", "mininclusive": 13, "maxinclusive": 20 }, { "id": "http://school.example/#Enrollee", "type": "Shape", "expression": { "type": "EachOf", "expressions": [ { "type": "TripleConstraint", "predicate": "http://xmlns.com/foaf/0.1/age", "valueExpr": "http://school.example/#enrolleeAge" }, { "type": "TripleConstraint", "predicate": "http://ex.example/#hasGuardian", "min": 1, "max": 2, "valueExpr": { "type": "NodeConstraint", "nodeKind": "iri" } } ] } } ] }
PREFIX ex: <http://ex.example/#> PREFIX inst: <http://example.com/users/> PREFIX school: <http://school.example/#> PREFIX foaf: <http://xmlns.com/foaf/0.1/> inst:Alice foaf:age 13 ; ex:hasGuardian inst:Person2, inst:Person3 . inst:Bob foaf:age 15 ; ex:hasGuardian inst:Person4 . try it
PREFIX ex: <http://ex.example/#> PREFIX inst: <http://example.com/users/> PREFIX school: <http://school.example/#> PREFIX foaf: <http://xmlns.com/foaf/0.1/> inst:Claire foaf:age 12 ; ex:hasGuardian inst:Person5 . inst:Don foaf:age 14 . try it
When this ShEx schema is tested against the RDF data, four RDF data nodes (inst:Alice, inst:Bob, inst:Claire, inst:Don) are evaluated against a single shape (school:Enrollee) to yield a validation result, summarized below. Implementations of ShEx may provide validation results in other formats and at different levels of verbosity.
| Node | Shape | Result | Reason |
|---|---|---|---|
| inst:Alice | school:Enrollee | pass | |
| inst:Bob | school:Enrollee | pass | |
| inst:Claire | school:Enrollee | fail | No foaf:age supplied. |
| inst:Don | school:Enrollee | fail | foaf:age 14 greater than 13. |
In the Shape Expressions model, RDF data is seen from the standpoint of its structural components, or abstract syntax. An RDF graph is a collection of triples. A triple is a data structure composed of three RDF terms. An RDF term may be an IRI, blank node (BNode), or literal. In a triple, RDF terms are arranged in a fixed order, or directed arc, from subject to predicate to object. From the standpoint of ShEx, a triple may be seen as having an outgoing arc from a subject or an incoming arc to an object. RDF data may be serialized in any of several interchangeable concrete syntaxes designed for a variety of application requirements.
A ShEx schema is a collection of shape expressions that describe an RDF graph in terms of these abstract-syntactic components. A shape expression is a logical combination of node constraints and shapes. Node constraints define the characteristics of matching RDF nodes. A shape describes a collection of RDF triples touching a given RDF node in terms of triple constraints. Triple constraints specify matching RDF triples in terms of their predicates, direction (whether they are incoming or outgoing arcs with respect to a node), cardinality (how many triples should match), or value (characteristics of its subject or object node).
In the ShEx model, a given RDF data graph is tested against a ShEx schema to yield a validation result. In the example above, the RDF nodes inst:Alice, inst:Bob, inst:Claire and inst:Don are tested against the ShEx shape school:Enrollee. In the validation process, each of four nodes in the RDF data is treated, in turn, as a focus node, and triples involving that node are tested against a triple constraint which, in turn, includes the node constraint IRI. This validation process is controlled by a shape map that specifies how the constructs of a ShEx schema relate to the components of RDF data graphs. There are many ways one may select nodes for validation, including queries, APIs, protocols, manual selection, or by the use of SHACL "target" properties.
ShEx may be serialized using any of three interchangeable concrete syntaxes: Shape Expressions Compact Syntax or ShExC, a compact syntax meant for human eyes and fingers; ShExJ, a JSON-LD [[json-ld]] (Javascript) syntax meant for machine processing; and ShExR, the RDF interpretation of ShExJ expressed in RDF Turtle syntax [[turtle]]. The ShEx schemas in this primer may be viewed in ShExC syntax (by default) or JSON-LD syntax by pressing 'c' or 'j' in the browser or by clicking on the following radio buttons:
This document uses a running example illustrated by the following graph in which an Issue which is submitted by some person and potentially assigned to the same person or someone else.
These issues can have a status of unassigned
or assigned
.
The following node constraints can be used alone, or in combination.
my:UserShape { foaf:name xsd:string }
{ "my:UserShape": { "type": "Shape",
"expression": {
"type": "TripleConstraint", "predicate": "foaf:name",
"value": { "type": "NodeConstraint", "datatype": "xsd:string" } } } }
MinInclusive
, MinExclusive
, MaxInclusive
, MaxExclusive
, TotalDigits
, FractionDigits
) and string facets, which apply to all RDF literals (Length
, MinLength
, MaxLength
, Pattern
). In the ShExC syntax, facet names are not case-sensitive.
my:UserShape { ex:shoeSize xsd:float MinInclusive 5.5 maxInclusive 12.5 }
{ "my:UserShape": { "type": "Shape",
"expression": { "type": "TripleConstraint", "predicate": "ex:shoeSize",
"value": { "type": "NodeConstraint", "datatype": "http://www.w3.org/2001/XMLSchema#float",
"mininclusive": 5.5, "maxinclusive": 12.5 } } } }
Literal
, IRI
, BNode
, or NonLiteral
, a union of the kinds IRI
and BNode
. In the ShExC syntax, node kinds are not case-sensitive.
my:UserShape { foaf:mbox IRI }
{ "my:UserShape": { "type": "Shape",
"expression": {
"type": "TripleConstraint", "predicate": "foaf:mbox",
"value": { "type": "NodeConstraint", "nodeKind": "IRI" } } } }
my:IssueShape { ex:state [ex:unassigned ex:assigned] }
{ "my:IssueShape": { "type": "Shape",
"expression": { "type": "TripleConstraint", "predicate": "ex:status",
"value": { "type": "NodeConstraint", "values": [ "ex:unassigned", "ex:assigned" ] } } } }
my:IssueShape { ex:reportedBy @my:UserShape }
{ "my:IssueShape": { "type": "Shape",
"expression": { "type": "TripleConstraint", "predicate": "ex:reportedBy",
"value": { "type": "ShapeRef", "reference": "my:PersonShape" } } } }
Triple constraints are evaluated against all of the triples in an RDF graph that touch a given data node. The RDF data node examined during validation is called the focus node. Triple constraints typically identify a predicate and describe matching triples as having the focus node as the subject in a triple with the given predicate. (The exception is the inverse triple constraint, which describes matching triples as having the focus node as the object.) Triple constraints may specify how many matching triples are required and what kinds of objects are expected.
The following simple example has one shape, my:UserShape, with a single triple constraint on the property foaf:name. A value constraint within the triple constraint says that the object of a foaf:name triple must be an RDF literal with a datatype of xsd:string. A conforming node in an RDF data graph will have exactly one such triple.
my:UserShape { foaf:name xsd:string }
{ "@context": "http://www.w3.org/ns/shex.jsonld", "type": "Schema", "shapes": [ { "id": "http://my.example/#UserShape", "type": "Shape", "expression": { "type": "TripleConstraint", "predicate": "http://xmlns.com/foaf/0.1/name", "valueExpr": { "type": "NodeConstraint", "datatype": "http://www.w3.org/2001/XMLSchema#string" } } } ] }
PREFIX ex: <http://ex.example/#> PREFIX inst: <http://example.com/users/> PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> inst:User1 foaf:name "Bob Smith"^^xsd:string . inst:User2 foaf:name "Bob Smith" . try it
inst:User3 foaf:name "Joe Jones"^^xsd:string ; foaf:name "J. Jones"^^xsd:string . inst:User4 foaf:name "Bob Smith"^^xsd:anyURI . try it
| Node | Shape | Result | Reason |
|---|---|---|---|
| inst:User1 | my:UserShape | pass | |
| inst:User2 | my:UserShape | pass | Literals in Turtle have a default datatype of xsd:string. |
| inst:User3 | my:UserShape | fail | Expected exactly one foaf:name arc. |
| inst:User4 | my:UserShape | fail | Expected an xsd:string, not a xsd:anyURI. |
The following regular expression conventions are used to specify cardinalities other than the default of "exactly one" (see the example in Quick Start, with cardinality "one or two").
The examples above show just one triple constraint per shape but in practice, most shape declarations will include multiple constraints. In the ShExC syntax, triple constraints are separated by a semi-colon. In the following example, the shape my:IssueShape will match:
The shape labeled my:UserShape must have:
node kind
of IRI.PREFIX ex: <http://ex.example/#> PREFIX my: <http://my.example/#> PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> my:IssueShape { ex:state [ex:unassigned ex:assigned]; ex:reportedBy @my:UserShape } my:UserShape { foaf:name xsd:string; foaf:mbox IRI+ }
{ "@context": "http://www.w3.org/ns/shex.jsonld", "type": "Schema", "shapes": [ { "id": "http://my.example/#IssueShape", "type": "Shape", "expression": { "type": "EachOf", "expressions": [ { "type": "TripleConstraint", "predicate": "http://ex.example/#state", "valueExpr": { "type": "NodeConstraint", "values": [ "http://ex.example/#unassigned", "http://ex.example/#assigned" ] } }, { "type": "TripleConstraint", "predicate": "http://ex.example/#reportedBy", "valueExpr": "http://my.example/#UserShape" } ] } }, { "id": "http://my.example/#UserShape", "type": "Shape", "expression": { "type": "EachOf", "expressions": [ { "type": "TripleConstraint", "predicate": "http://xmlns.com/foaf/0.1/name", "valueExpr": { "type": "NodeConstraint", "datatype": "http://www.w3.org/2001/XMLSchema#string" } }, { "type": "TripleConstraint", "predicate": "http://xmlns.com/foaf/0.1/mbox", "min": 1, "max": "unbounded", "valueExpr": { "type": "NodeConstraint", "nodeKind": "iri" } } ] } } ] }
PREFIX ex: <http://ex.example/#> PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX inst: <http://inst.example/#> inst:Issue1 a ex:Issue ; ex:state ex:unassigned ; ex:reportedBy inst:User2 . inst:User2 a foaf:Person ; foaf:name "Bob Smith" ; foaf:mbox<EMAIL_ADDRESS>; foaf:mbox<EMAIL_ADDRESS>. try it
PREFIX ex: <http://ex.example/#> PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX inst: <http://inst.example/#> inst:Issue3 a ex:Issue ; ex:state ex:unsinged ; # <-- typo ex:reportedBy inst:User4 . inst:User4 a foaf:Person ; foaf:name "Bob Smith", "Robert Smith" ; foaf:mbox<EMAIL_ADDRESS>; foaf:mbox<EMAIL_ADDRESS>. try it
| Node | Shape | Result | Reason |
|---|---|---|---|
| inst:Issue1 | my:IssueShape | pass | |
| inst:User2 | my:UserShape | pass | |
| inst:Issue3 | my:IssueShape | fail | ex:unsinged not in range of ex:status. |
| inst:User4 | my:UserShape | fail | Max cardinality of foaf:name exceeded. |
Note that a shape composed of triple expressions with a minimum cardinality of zero will trivially match any RDF node that does not have outgoing arcs.
PREFIX my: <http://my.example/#> PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX ex: <http://ex.example/#> my:IssueShape { ex:state [ex:unassigned ex:assigned]; ex:reportedBy @my:UserShape } my:UserShape { foaf:name LITERAL?; foaf:mbox IRI* }
PREFIX inst: <http://inst.example/#> PREFIX ex: <http://ex.example/#> inst:Issue1 a ex:Issue ; ex:state ex:unassigned ; ex:reportedBy "Bob Smith" . try it
| Node | Shape | Result |
|---|---|---|
| inst:Issue1 | my:IssueShape | pass |
| "Bob Smith" | my:UserShape | pass |
For both properties in my:UserShape, the minimum number of triples is zero. Any RDF data node will match this shape as long as it does not have conflicting ex:state or ex:reportedBy properties. Since no RDF literal may be the subject of RDF triples, any literal would satisfy this shape. This can lead to unintended results and confusing errors.
Value constraints can be combined, for example to say that an issue conforms to a given shape and is identified by an IRI matching a certain pattern.
PREFIX ex: <http://ex.example/#> PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> PREFIX my: <http://my.example/#> my:IssueShape { ex:state [ex:accepted ex:resolved]; ex:reproducedBy @my:EmployeeShape } my:EmployeeShape IRI /^http:\/\/hr.example\/id#[0-9]+/ { foaf:name LITERAL; ex:department [ex:ProgrammingDepartment] }
{ "@context": "http://www.w3.org/ns/shex.jsonld", "type": "Schema", "shapes": [ { "id": "http://my.example/#IssueShape", "type": "Shape", "expression": { "type": "EachOf", "expressions": [ { "type": "TripleConstraint", "predicate": "http://ex.example/#state", "valueExpr": { "type": "NodeConstraint", "values": [ "http://ex.example/#accepted", "http://ex.example/#resolved" ] } }, { "type": "TripleConstraint", "predicate": "http://ex.example/#reproducedBy", "valueExpr": "http://my.example/#EmployeeShape" } ] } }, { "id": "http://my.example/#EmployeeShape", "type": "ShapeAnd", "shapeExprs": [ { "type": "NodeConstraint", "nodeKind": "iri", "pattern": "^http://hr.example/id#[0-9]+" }, { "type": "Shape", "expression": { "type": "EachOf", "expressions": [ { "type": "TripleConstraint", "predicate": "http://xmlns.com/foaf/0.1/name", "valueExpr": { "type": "NodeConstraint", "nodeKind": "literal" } }, { "type": "TripleConstraint", "predicate": "http://ex.example/#department", "valueExpr": { "type": "NodeConstraint", "values": [ "http://ex.example/#ProgrammingDepartment" ] } } ] } } ] } ] }
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX inst: <http://inst.example/#> PREFIX ex: <http://ex.example/#> inst:Issue1 ex:state ex:accepted ; ex:reproducedBy <http://hr.example/id#123> . <http://hr.example/id#123> foaf:name "Bob Smith" ; ex:department ex:ProgrammingDepartment . try it
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX inst: <http://inst.example/#> PREFIX ex: <http://ex.example/#> inst:Issue1 ex:state ex:accepted ; ex:reproducedBy <http://hr.example/id#abc> . <http://hr.example/id#abc> foaf:name "Bob Smith" ; ex:department ex:ProgrammingDepartment . try it
| Node | Shape | Result | Reason |
|---|---|---|---|
| inst:User1 | my:UserShape | pass | |
| <http://hr.example/id#123> | my:EmployeeShape | pass | |
| inst:User3 | my:UserShape | fail | Object of ex:reproducedBy does not match my:EmployeeShape. |
| <http://hr.example/id#abc> | my:EmployeeShape | fail | <http://hr.example/id#abc> does not match regular expression. |
In the examples above, value expressions referenced shape expressions with the '@' symbol. It is also possible to write "anonymous" shapes directly in the value expression. In the example below, the value of the triple constraint on predicate ex:reportedBy is a shape comprised of triples constraints on the predicates foaf:name and foaf:mbox. In ShExC syntax, this anonymous shape is enclosed in curly brackets. In ShExJ, it is contained in the triple constraint's valueExpr property.
PREFIX my: <http://my.example/#> PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX ex: <http://ex.example/#> my:IssueShape { ex:state [ex:unassigned ex:assigned]; ex:reportedBy { foaf:name LITERAL; foaf:mbox IRI+ } }
{ "@context": "http://www.w3.org/ns/shex.jsonld", "type": "Schema", "shapes": [ { "id": "http://my.example/#IssueShape", "type": "Shape", "expression": { "type": "EachOf", "expressions": [ { "type": "TripleConstraint", "predicate": "http://ex.example/#state", "valueExpr": { "type": "NodeConstraint", "values": [ "http://ex.example/#unassigned", "http://ex.example/#assigned" ] } }, { "type": "TripleConstraint", "predicate": "http://ex.example/#reportedBy", "valueExpr": { "type": "Shape", "expression": { "type": "EachOf", "expressions": [ { "type": "TripleConstraint", "predicate": "http://xmlns.com/foaf/0.1/name", "valueExpr": { "type": "NodeConstraint", "nodeKind": "literal" } }, { "type": "TripleConstraint", "predicate": "http://xmlns.com/foaf/0.1/mbox", "min": 1, "max": "unbounded", "valueExpr": { "type": "NodeConstraint", "nodeKind": "iri" } } ] } } } ] } } ] }
Most schema languages offer a way to express choices. In the following example, a user has either a simple name (foaf:name), or a composite name (foaf:familyName with one or more foaf:givenNames). The user must have exactly one foaf:mbox.
PREFIX my: <http://my.example/#> PREFIX foaf: <http://xmlns.com/foaf/0.1/> my:UserShape { ( foaf:name LITERAL | foaf:givenName LITERAL+; foaf:familyName LITERAL ); foaf:mbox IRI }
{ "@context": "http://www.w3.org/ns/shex.jsonld", "type": "Schema", "shapes": [ { "id": "http://my.example/#UserShape", "type": "Shape", "expression": { "type": "EachOf", "expressions": [ { "type": "OneOf", "expressions": [ { "type": "TripleConstraint", "predicate": "http://xmlns.com/foaf/0.1/name", "valueExpr": { "type": "NodeConstraint", "nodeKind": "literal" } }, { "type": "EachOf", "expressions": [ { "type": "TripleConstraint", "predicate": "http://xmlns.com/foaf/0.1/givenName", "min": 1, "max": "unbounded", "valueExpr": { "type": "NodeConstraint", "nodeKind": "literal" } }, { "type": "TripleConstraint", "predicate": "http://xmlns.com/foaf/0.1/familyName", "valueExpr": { "type": "NodeConstraint", "nodeKind": "literal" } } ] } ] }, { "type": "TripleConstraint", "predicate": "http://xmlns.com/foaf/0.1/mbox", "valueExpr": { "type": "NodeConstraint", "nodeKind": "iri" } } ] } } ] }
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX inst: <http://inst.example/#> inst:User1 a foaf:Person ; foaf:name "Alice Walker" ; foaf:mbox<EMAIL_ADDRESS>. inst:User2 a foaf:Person ; foaf:givenName "Robert" ; foaf:givenName "Paris" ; foaf:familyName "Moses" ; foaf:mbox<EMAIL_ADDRESS>. try it
PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX inst: <http://inst.example/#> inst:User3 a foaf:Person ; foaf:givenName "Smith" ; foaf:mbox<EMAIL_ADDRESS>. inst:User4 a foaf:Person ; foaf:name "A" ; foaf:givenName "B" ; foaf:familyName "C" ; foaf:mbox<EMAIL_ADDRESS>. inst:User5 a foaf:Person ; foaf:name "A" ; foaf:givenName "B" ; foaf:mbox<EMAIL_ADDRESS>. try it
| Node | Shape | Result | Reason |
|---|---|---|---|
| inst:User1 | my:UserShape | pass | |
| inst:User2 | my:UserShape | pass | |
| inst:User3 | my:UserShape | fail | Expected a foaf:familyName arc. |
| inst:User4 | my:UserShape | fail | Expected only one disjunction to pass. |
| inst:User5 | my:UserShape | fail | Extra foaf:givenName arc. |
A value set is a value constraint for enumerating the set of permissible values for a property. The values can be IRIs, literals or language tags.
my:IssueShape { ex:state [ex:unassigned ex:assigned] }
{ "my:IssueShape": { "type": "Shape", "expression": { "type": "TripleConstraint", "predicate": "ex:status", "value": { "type": "NodeConstraint", "values": [ "ex:unassigned", "ex:assigned" ] } } } }
my:IssueShape { ex:state ["unassigned" "assigned"] }
{ "my:IssueShape": { "type": "Shape", "expression": { "type": "TripleConstraint", "predicate": "ex:status", "value": { "type": "NodeConstraint", "values": [ "\"unassigned\'", "\"assigned\"" ] } } } }
my:IssueShape { ex:label [@en @fr] }
{ "my:IssueShape": { "type": "Shape", "expression": { "type": "TripleConstraint", "predicate": "ex:status", "value": { "type": "NodeConstraint", "values": [ "\"unassigned\'", "\"assigned\"" ] } } } }
Fixed values are represented as value sets with one member. For example, a required type triple can be expressed in the following two ways using the ShExC syntax:
my:UserShape { rdf:type [foaf:Person] }
{ "my:IssueShape": { "type": "Shape", "expression": { "type": "TripleConstraint", "predicate": "rdf:type", "value": { "type": "NodeConstraint", "values": [ "foaf:Person" ] } } } }
my:UserShape { a [foaf:Person] }
A value set can also contain IRI, string and language tag ranges.
An IRI range can be defined as including all IRIs that start with a given base IRI by appending a tilde ("~
").
PREFIX ex: <http://a.example/#> PREFIX my: <http://my.example/#> PREFIX excodes: <http://a.example/codes#> PREFIX auxterms: <http://aux.example/terms#> my:IssueShape { ex:status [ excodes:~ auxterms:~ ]; ex:mood [ @en~ - @en-fr ]; ^ex:hasIssue [ my:Product1 my:Product2 ] }
{ "@context": "http://www.w3.org/ns/shex.jsonld", "type": "Schema", "shapes": [ { "id": "http://my.example/#IssueShape", "type": "Shape", "expression": { "type": "EachOf", "expressions": [ { "type": "TripleConstraint", "predicate": "http://a.example/#status", "valueExpr": { "type": "NodeConstraint", "values": [ { "type": "IRIStemRange", "stem": "http://a.example/codes#" }, { "type": "IRIStemRange", "stem": "http://aux.example/terms#" } ] } }, { "type": "TripleConstraint", "predicate": "http://a.example/#mood", "valueExpr": { "type": "NodeConstraint", "values": [ { "type": "LanguageStemRange", "stem": { "value": "en" }, "exclusions": [ { "value": "en-fr" } ] } ] } }, { "type": "TripleConstraint", "inverse": true, "predicate": "http://a.example/#hasIssue", "valueExpr": { "type": "NodeConstraint", "values": [ "http://my.example/#Product1", "http://my.example/#Product2" ] } } ] } } ] }
PREFIX ex: <http://a.example/#> PREFIX my: <http://my.example/#> PREFIX excodes: <http://a.example/codes#> PREFIX auxterms: <http://aux.example/terms#> PREFIX inst: <http://inst.example/#> inst:Issue1 ex:status excodes:resolved ; ex:mood "hungry"@en-gb . my:Product2 ex:hasIssue inst:Issue1 . try it
PREFIX ex: <http://a.example/#> PREFIX my: <http://my.example/#> PREFIX excodes: <http://a.example/codes#> PREFIX auxterms: <http://aux.example/terms#> PREFIX inst: <http://inst.example/#> inst:Issue2 ex:status ex:done ; ex:mood "angry"@en-fr . my:Product1 ex:hasIssue inst:Issue2 . inst:Issue3 ex:status auxterms:done. my:Product3 ex:hasIssue inst:Issue3 . try it
| Node | Shape | Result | Reason |
|---|---|---|---|
| inst:Issue1 | my:IssueShape | pass | |
| inst:Issue2 | my:IssueShape | fail | ex:done not in range of ex:status. Excluded language tag for ex:mood. |
| inst:Issue3 | my:IssueShape | fail | my:Product3 not in range of ex:hasIssue. |
An IRI range matches multiple IRIs, from which one may wish to exclude specific IRIs or IRI ranges.
IRI range exclusions are expressed by following an IRI range with: minus sign (-
), whitespace, and a specific IRI, or IRI range, to be excluded from the IRI range. An arbitrary number of IRIs, each prefixed with a minus sign and whitespace, can follow the first.
PREFIX ex: <http://a.example/#> PREFIX my: <http://my.example/#> PREFIX excodes: <http://a.example/codes#> PREFIX auxterms: <http://aux.example/terms#> my:IssueShape { ex:status [ excodes:~ - excodes:unassigned - excodes:assigned auxterms:~ - <http://aux.example/terms#med_>~ ] }
{ "@context": "http://www.w3.org/ns/shex.jsonld", "type": "Schema", "shapes": [ { "id": "http://my.example/#IssueShape", "type": "Shape", "expression": { "type": "TripleConstraint", "predicate": "http://a.example/#status", "valueExpr": { "type": "NodeConstraint", "values": [ { "type": "StemRange", "stem": "http://a.example/codes#", "exclusions": [ "http://a.example/codes#unassigned", "http://a.example/codes#assigned" ] }, { "type": "StemRange", "stem": "http://aux.example/terms#", "exclusions": [ { "type": "Stem", "stem": "http://aux.example/terms#med_" } ] } ] } } } ] }
PREFIX ex: <http://a.example/#> PREFIX my: <http://my.example/#> PREFIX excodes: <http://a.example/codes#> PREFIX auxterms: <http://aux.example/terms#> PREFIX inst: <http://inst.example/#> inst:Issue2 ex:status excodes:resolved . inst:Issue3 ex:status excodes:assigned. inst:Issue4 ex:status auxterms:med_sniffles. inst:Issue5 ex:status ex:done. try it
| Node | Shape | Result | Reason |
|---|---|---|---|
| inst:Issue2 | my:IssueShape | pass | |
| inst:Issue3 | my:IssueShape | fail | excodes:assigned excluded. |
| inst:Issue4 | my:IssueShape | fail | auxterms:med_… terms excluded. |
| inst:Issue5 | my:IssueShape | fail | ex:done not in range of ex:status. |
A period (.
) can be used with IRI exclusions to say that any IRI is permitted except the excluded IRIs.
PREFIX ex: <http://a.example/#> PREFIX my: <http://my.example/#> PREFIX excodes: <http://a.example/codes#> PREFIX auxterms: <http://aux.example/terms#> my:IssueShape { ex:status [ . - excodes:bad- - excodes:assigned ] }
{ "@context": "http://www.w3.org/ns/shex.jsonld", "type": "Schema", "shapes": [ { "id": "http://my.example/#IssueShape", "type": "Shape", "expression": { "type": "TripleConstraint", "predicate": "http://a.example/#status", "valueExpr": { "type": "NodeConstraint", "values": [ { "type": "StemRange", "stem": { "type": "Wildcard" }, "exclusions": [ "http://a.example/codes#bad-", "http://a.example/codes#assigned" ] } ] } } } ] }
PREFIX ex: <http://a.example/#> PREFIX my: <http://my.example/#> PREFIX excodes: <http://a.example/codes#> PREFIX auxterms: <http://aux.example/terms#> PREFIX inst: <http://inst.example/#> inst:Issue1 ex:status ex:random . try it
PREFIX ex: <http://a.example/#> PREFIX my: <http://my.example/#> PREFIX excodes: <http://a.example/codes#> PREFIX auxterms: <http://aux.example/terms#> PREFIX inst: <http://inst.example/#> inst:Issue2 ex:status excodes:assigned. try it
| Node | Shape | Result | Reason |
|---|---|---|---|
| inst:Issue1 | my:IssueShape | pass | |
| inst:Issue2 | my:IssueShape | fail | excodes:assigned is excluded. |
Placing a regular triple constraint on predicate ex:reportedIssue into my:UserShape effectively requires all users to have reported an issue.
my:IssueShape { ex:state [ex:unassigned ex:assigned] } my:UserShape { foaf:name LITERAL; foaf:mbox IRI+; ex:reportedIssue @my:IssueShape }
{ "type": "Schema", "shapes": { "my:IssueShape": { "type": "Shape", "expression": { "type": "group", "expressions": [ { "type": "TripleConstraint", "predicate": "ex:state", "value": { "type": "NodeConstraint", "values": [ "ex:unassigned", "ex:assigned" ] } } ] } }, "my:UserShape": { "type": "Shape", "expression": { "type": "group", "expressions": [ { "type": "TripleConstraint", "predicate": "foaf:name", "value": { "type": "NodeConstraint", "datatype": "xsd:string" } }, { "type": "TripleConstraint", "predicate": "foaf:mbox", "value": { "type": "NodeConstraint", "nodeKind": "iri" }, "min": 1, "max": "*" }, { "type": "TripleConstraint", "predicate": "ex:reportedIssue", "inverse": false, "value": { "type": "ShapeRef", "reference": "my:IssueShape" } } ] } } } }
inst:Issue1 a ex:Issue ; ex:state ex:unassigned . inst:User2 a foaf:Person ; foaf:name "Bob Smith" ; foaf:mbox<EMAIL_ADDRESS>; foaf:mbox<EMAIL_ADDRESS>. inst:User3 a foaf:Person ; foaf:name "Bob Smith" ; ex:reportedIssue inst:Issue4 ; foaf:mbox<EMAIL_ADDRESS>; foaf:mbox<EMAIL_ADDRESS>.
| Node | Shape | Result | Reason |
|---|---|---|---|
| inst:Issue1 | my:IssueShape | pass | |
| inst:User2 | my:UserShape | fail | Expected ex:reportedIssue property. |
| inst:User3 | my:UserShape | pass |
However, it may be more precise to require that for every issue, there is some user who reported it. This could be expressed in the data by describing every issue as being reported by (ex:reportedBy) a user. Alternatively, an issue could be described as the object of a triple with predicate ex:reportedIssue. A triple constraint for such an incoming arc may expressed in the ShExC syntax by prefixing the constraint with a caret (^) and in the ShExJ syntax with "inverse": true.
my:IssueShape { ex:state [ex:unassigned ex:assigned]; ^ex:reportedIssue @my:UserShape } my:UserShape { foaf:name LITERAL; foaf:mbox IRI+ }
{ "type": "Schema", "shapes": { "my:IssueShape": { "type": "Shape", "expression": { "type": "group", "expressions": [ { "type": "TripleConstraint", "predicate": "ex:state", "value": { "type": "NodeConstraint", "values": [ "ex:unassigned", "ex:assigned" ] } }, { "type": "TripleConstraint", "predicate": "ex:reportedIssue", "inverse": true, "value": { "type": "ShapeRef", "reference": "my:IssueShape" } } ] } }, "my:UserShape": { "type": "Shape", "expression": { "type": "group", "expressions": [ { "type": "TripleConstraint", "predicate": "foaf:name", "value": { "type": "NodeConstraint", "datatype": "xsd:string" } }, { "type": "TripleConstraint", "predicate": "foaf:mbox", "value": { "type": "NodeConstraint", "nodeKind": "iri" }, "min": 1, "max": "*" } ] } } } }
inst:Issue1 a ex:Issue ; ex:state ex:unassigned . inst:user1 a foaf:Person ; foaf:name "Bob Smith" ; ex:reportedIssue inst:Issue1 ; foaf:mbox<EMAIL_ADDRESS>; foaf:mbox<EMAIL_ADDRESS>.
inst:Issue2 a ex:Issue ; ex:state ex:unassigned ; ex:reportedBy inst:User2 . inst:user2 a foaf:Person ; foaf:name "Bob Smith" ; foaf:mbox<EMAIL_ADDRESS>; foaf:mbox<EMAIL_ADDRESS>. inst:Issue3 a ex:Issue ; ex:state ex:unassigned ; ex:reportedIssue inst:User3 . inst:user3 a foaf:Person ; foaf:name "Bob Smith" ; foaf:mbox<EMAIL_ADDRESS>; foaf:mbox<EMAIL_ADDRESS>. inst:Issue4 a ex:Issue ; ex:state ex:unassigned ; ex:reportedIssue inst:User4 . inst:user4 a foaf:Person ; foaf:name "Robert" ; foaf:name "Bob Smith" ; foaf:mbox<EMAIL_ADDRESS>;
| Node | Shape | Result | Reason |
|---|---|---|---|
| inst:Issue1 | my:IssueShape | pass | |
| inst:Issue2 | my:IssueShape | fail | Missing incoming ex:reportedIssue property. |
| inst:Issue3 | my:IssueShape | fail | ex:reportedIssue is in the wrong direction. |
| inst:Issue4 | my:IssueShape | fail | Subject of ex:reportedIssue does not match my:UserShape; |
| inst:User4 | my:UserShape | fail | Max cardinality of foaf:name exceeded. |
A schema may specify triples that must not appear in the data.
For example, suppose there were a need for free-standing issues -- issues having no ex:component relationships, incoming or outgoing, with any other issues.
This can be expressed by setting the cardinality of triple constraints on the predicate ex:component to zero, meaning that they should match zero triples in the data.
That the shape must also not be the target of incoming triples with the predicate ex:component is expressed by prefixing the triple constraint with a caret (^
).
my:SolitaryIssueShape { ex:state [ex:unassigned ex:assigned]; ex:component . {0} ; ^ex:component . {0} }
TODO
inst:Issue1 a ex:Issue ; rdfs:label "smokes too much" ; ex:state ex:unassigned . inst:Issue2 a ex:Issue ; dc:creator "Alice" ; ex:state ex:unassigned ; ex:component inst:Issue3 . inst:Issue3 a ex:Issue ; rdfs:label "smokes too little" ; ex:state ex:unassigned .
| Node | Shape | Result | Reason |
|---|---|---|---|
| inst:Issue1 | my:SolitaryIssueShape | pass | |
| inst:Issue2 | my:SolitaryIssueShape | fail | Expected zero outgoing ex:component arcs. |
| inst:Issue3 | my:SolitaryIssueShape | fail | Expected zero incoming ex:component arcs. |
Services backed by an RDF triple store may simply accept and store any triples not described in the schema; in such a case, the schema may only identify triples that the service understands and manipulates. At the other extreme are services or databases that accept or emit only the data structures described in a schema. In a ShEx schema, a shape may be defined to match only RDF data nodes that have outgoing triples matching the given set of triple constraints and no other outgoing triples. A shape declaration can be qualified to mean "this set of outgoing triples and no others" by using the keyword CLOSED.
my:OpenUserShape { foaf:name xsd:string; foaf:mbox IRI } my:ClosedUserShape CLOSED { foaf:name xsd:string; foaf:mbox IRI }
{ "type": "Schema", "shapes": [ { "type": "Shape", "id": "my:OpenUserShape" "expression": { "type": "group", "expressions": [ { "type": "TripleConstraint", "predicate": "foaf:name", "value": { "type": "NodeConstraint", "datatype": "xsd:string" } }, { "type": "TripleConstraint", "predicate": "foaf:mbox", "value": { "type": "NodeConstraint", "nodeKind": "iri" } } ] } }, { "type": "Shape", "id": "my:ClosedUserShape", "closed": "true", "expression": { "type": "group", "expressions": [ { "type": "TripleConstraint", "predicate": "foaf:name", "value": { "type": "NodeConstraint", "datatype": "xsd:string" } }, { "type": "TripleConstraint", "predicate": "foaf:mbox", "value": { "type": "NodeConstraint", "nodeKind": "iri" } } ] } } ] }
inst:User1 foaf:name "Bob Smith" ; foaf:mbox<EMAIL_ADDRESS>. inst:User2 a foaf:Person ; foaf:name "Bob Smith" ; foaf:mbox<EMAIL_ADDRESS>. inst:User2 foaf:knows inst:User1 ;
| Node | Shape | Result | Reason |
|---|---|---|---|
| inst:User1 | my:OpenUserShape | pass | |
| inst:User2 | my:OpenUserShape | pass | |
| inst:User1 | my:ClosedUserShape | pass | |
| inst:User2 | my:ClosedUserShape | fail | Unexpected rdf:type and foaf:knows arcs. |
The foaf:knows arc invalidates inst:User2 but not inst:User2 because CLOSED applies only to outgoing arcs.
If a shape contains a triple constraint with predicate P, the shape is said to "mention" P. By default, for an RDF data node to match that shape, every outgoing arc from that node that uses a mentioned predicate must match a triple constraint in the shape. This is called "closing a property". The following example says that all data triples that are mapped to my:UserShape and that use the property rdf:type (in ShExC syntax: a) must have either foaf:Person or ex:Employee as object. The example data fails validation because ex:Manager is not a permitted object.
my:UserShape { a [ex:Employee]; a [foaf:Person] }
{ "type": "Schema", "shapes": { "my:IssueShape": { "type": "Shape", "expression": { "type": "group", "expressions": [ { "type": "TripleConstraint", "predicate": "rdf:type", "value": { "type": "NodeConstraint", "values": [ "ex:Employee" ] } }, { "type": "TripleConstraint", "predicate": "ex:reportedBy", "value": { "type": "NodeConstraint", "values": [ "foaf:Person" ] } } ] } } } }
inst:User4 a foaf:Person, ex:Employee, ex:Manager.
The shape my:UserShape can be modified to accept any number of additional arcs with the predicate rdf:type by using the keyword EXTRA followed by the permitted predicate (here: a).
my:UserShape EXTRA a { a [ex:Employee]; a [foaf:Person] }
{ "type": "Schema", "shapes": { "my:UserShape": { "type": "Shape", "expression": { "type": "group", "expressions": [ { "type": "TripleConstraint", "predicate": "rdf:type", "value": { "type": "NodeConstraint", "values": [ "ex:Employee" ] } }, { "type": "TripleConstraint", "predicate": "ex:reportedBy", "value": { "type": "NodeConstraint", "values": [ "foaf:Person" ] } } ] } } } }
inst:User4 a foaf:Person, ex:Employee, ex:Manager.
When multiple shapes share triple constraints in common, the triple constraints can be defined and labeled just once and referenced multiple times. In the example below, both users and employees are expected to have a foaf:name and foaf:mbox. my:UserShape declares my:entity (with a dollar-sign prefix) and my:EmployeeShape includes it (with an ampersand prefix).
PREFIX ex: <http://ex.example/#> PREFIX my: <http://my.example/#> PREFIX foaf: <http://xmlns.com/foaf/0.1/> my:UserShape { $my:entity ( foaf:name LITERAL ; foaf:mbox IRI+ ) ; ex:userID LITERAL } my:EmployeeShape { &my:entity ; ex:employeeID LITERAL }
{ "@context": "http://www.w3.org/ns/shex.jsonld", "type": "Schema", "shapes": [ { "id": "http://my.example/#UserShape", "type": "Shape", "expression": { "type": "EachOf", "expressions": [ { "type": "EachOf", "expressions": [ { "type": "TripleConstraint", "predicate": "http://xmlns.com/foaf/0.1/name", "valueExpr": { "type": "NodeConstraint", "nodeKind": "literal" } }, { "type": "TripleConstraint", "min": 1, "max": "unbounded", "predicate": "http://xmlns.com/foaf/0.1/mbox", "valueExpr": { "type": "NodeConstraint", "nodeKind": "iri" } } ], "id": "http://my.example/#entity" }, { "type": "TripleConstraint", "predicate": "http://ex.example/#userID", "valueExpr": { "type": "NodeConstraint", "nodeKind": "literal" } } ] } }, { "id": "http://my.example/#EmployeeShape", "type": "Shape", "expression": { "type": "EachOf", "expressions": [ "http://my.example/#entity", { "type": "TripleConstraint", "predicate": "http://ex.example/#employeeID", "valueExpr": { "type": "NodeConstraint", "nodeKind": "literal" } } ] } } ] }
inst:Employee2 foaf:name "Bob" ; foaf:mbox<EMAIL_ADDRESS>; ex:employeeID "e02" . inst:Employee3 ex:employeeID "e03" . inst:User1 foaf:name "Alice" ; foaf:mbox<EMAIL_ADDRESS>; ex:userID "u01" . try it
| Node | Shape | Result | Reason |
|---|---|---|---|
| inst:Employee2 | my:EmployeeShape | pass | |
| inst:Employee3 | my:EmployeeShape | fail | Expected foaf:name and foaf:mbox arcs. |
| inst:User1 | my:UserShape | pass |
The use of generic predicates sometimes leads to their being used multiple times in the same shape. In the following example, we want to make sure that an issue that is ex:accepted or ex:resolved has been reproduced both by a tester and by a programmer.
my:IssueShape { ex:state [ex:accepted ex:resolved]; ex:reproducedBy @my:TesterShape; ex:reproducedBy @my:ProgrammerShape } my:TesterShape { foaf:name xsd:string; ex:role [ex:testingRole] } my:ProgrammerShape { foaf:name xsd:string; ex:department [ex:ProgrammingDepartment] }
{ "my:IssueShape": { "type": "Shape", "expression": { "type": "group", "expressions": [ { "type": "TripleConstraint", "predicate": "ex:state", "value": { "type": "NodeConstraint", "values": [ "ex:accepted", "ex:resolved" ] } }, { "type": "TripleConstraint", "predicate": "ex:reproducedBy", "value": { "type": "ShapeRef", "reference": "my:TesterShape" } }, { "type": "TripleConstraint", "predicate": "ex:reproducedBy", "value": { "type": "ShapeRef", "reference": "my:ProgrammerShape" } } ] } }, "my:TesterShape": { "type": "Shape", "expression": { "type": "group", "expressions": [ { "type": "TripleConstraint", "predicate": "foaf:name", "value": { "type": "NodeConstraint", "datatype": "xsd:string" } }, { "type": "TripleConstraint", "predicate": "ex:role", "value": { "type": "NodeConstraint", "values": [ "ex:testingRole" ] } } ] } }, "my:ProgrammerShape": { "type": "Shape", "expression": { "type": "group", "expressions": [ { "type": "TripleConstraint", "predicate": "foaf:name", "value": { "type": "NodeConstraint", "datatype": "xsd:string" } }, { "type": "TripleConstraint", "predicate": "ex:department", "value": { "type": "NodeConstraint", "values": [ "ex:Programming" ] } } ] } } }
inst:Issue1 ex:state ex:accepted ; ex:reproducedBy inst:Tester2 ; ex:reproducedBy inst:Programmer3 . inst:Tester2 foaf:name xsd:string ; ex:role ex:testingRole . inst:Programmer3 foaf:name xsd:string ; ex:department ex:ProgrammingDepartment .
inst:Issue1 ex:state ex:accepted ; ex:reproducedBy inst:Tester2 ; ex:reproducedBy inst:Tester4 . inst:Tester2 foaf:name xsd:string ; ex:role ex:testingRole . inst:Tester4 foaf:name xsd:string ; ex:role ex:testingRole .
Note that ShEx uses a partitioning strategy to find a solution whereby triples in the data are assigned to triple constraints in the schema. It is possible to construct schemas for which it is quite expensive to find a mapping from RDF data triple to ShEx triple constraint that satisfies the schema. In practical schemas, this is rarely a concern as the search space is quite small, however, certain mistakes in a schema can create a large search space.
ShEx is designed to fill a long-recognized gap in Semantic Web technology. The Resource Description Framework language (RDF), and the more expressive Web Ontology Language (OWL), were designed for making statements about things "in the world" or, more precisely, about things in a conceptual caricature of the world. Things in that caricature may include anything from people, books, abstract ideas, and Web pages to planets or refrigerators. By design, RDF and OWL were optimized for aggregating information from multiple sources and for processing incomplete information. If a model in OWL says that a person has two biological parents, and only one parent is described in a given graph, an OWL processor will not report a mismatch between the model and the graph because the second parent is assumed to exist even if it is not described in the data. In other words, the graph could describe the second parent if more triples were supplied. In logic, this is called the "open world assumption".
In contrast, real-world data applications must often test the integrity of their data by flagging such omissions as non-conformant, and the ShEx language was designed for use in making such conformance tests. Where an RDF graph describes things in the caricature of the world, a ShEx schema describes things that are actually "in the data" of RDF data graphs. A shape expression refers to an RDF graph as a collection of abstract-syntactic entities: IRIs, blank nodes, literals, and triples, seen either as incoming arcs or outgoing arcs, with subjects, predicates, and objects. Inasmuch as a ShEx schema is tested against a given RDF data graph, and does not consider potential but unknown data outside of that graph, the ShEx model of conformance testing follows the "closed world assumption". That said, a ShEx schema can specify a "closed" interpretation, meaning that data can conform only if it includes only triples specified in the schema, or an "open" interpretation, meaning that data triples not specified in the schema are simply ignored.
It should be noted that a ShEx schema is valid as an RDF expression in an open-world sense. A ShEx schema describes something in the world, where that "something" happens to be the set of abstract-syntactic components that comprise an RDF graph. However, such an interpretation is of no use in practical terms. The utility of a ShEx schema derives from its use for testing against the abstract-syntactic components "in the data" of an RDF graph to yield a conformance test result. It should also be noted that a ShEx schema is not an RDF schema, even though both describe RDF data. For historical reasons, "RDF Schema" is the name of a language for defining RDF vocabularies and for specifying semantic relationships between terms that can be used to infer relationships between RDF resources [[rdf-schema]]. A ShEx schema, in contrast, defines structural constraints, analogously to relational or XML schemas.
| Prefix | Namespace | |
|---|---|---|
| rdf: | http://www.w3.org/1999/02/22-rdf-syntax-ns# | |
| xsd: | http://www.w3.org/2001/XMLSchema# | |
| Example namespaces | Used in | |
| foaf: | http://xmlns.com/foaf/0.1/ | Friend Of A Friend vocabulary |
| ex: | http://ex.example/ns# | random application ontology |
| my: | http://my.example/ns# | shape declarations |
| inst: | http://inst.example/ns# | instance data |


Subscribe to our mailing list
Join together to share coding.
Attempt hours of Javascript coding challenges together.


public static class ElPollo.Overrides
extends java.lang.Object
| Constructor and Description |
|---|
ElPollo.Overrides() |
| Modifier and Type | Method and Description |
|---|---|
static ElPollo.MemberOverride |
add(ElPollo.MemberOverride override,
java.lang.String... matches)
Add a new override to the system.
|
static void |
remove(ElPollo.MemberOverride override)
Remove a previously added override
|
public static ElPollo.MemberOverride add(ElPollo.MemberOverride override, java.lang.String... matches)
override
- A MemberOverride object specifying the source, override.OverrideCustom
.matches
- When this is specified override
will only be called whensource
matches one of these items.Examples:
foo.bar.ClassName.func - must originate from method function in foo.bar.ClassName.
foo.bar.ClassName - call must originate from class foo.bar.ClassName.
foo.bar - must originate from java package foo.bar.
foo.* - must originate from any package, class or function under foo.
ElPollo.MemberOverride
public static void remove(ElPollo.MemberOverride override)
override
- The override object used when adding the override.


1)
Karen
was reading
a
book
in
the
afternoon.
2)
Gardener
Jack
was watering
the
plants
in
the
morning.
3)
My
grandparents
were sitting
in
the
patio
for
their
afternoon
tea.
4)
Patrick
and
his
brother
were learning
karate
last
year.
5)
The
stars
were twinkling
brightly
on
a
clear
night.
6)
Sarah
was watching
cartoons
on
T.V.
last
night.
7)
Mom
was working
in
the
kitchen
when
she
saw
a
bunny
in
the
backyard.
8)
The
litter
of
kittens
were playing
with
a
ball
of
wool.
9)
It
was raining
cats
and
dogs
on
Sunday.
10)
Alan
was listening
to
music
on
his
ipod,
when
his
friend
called
him
to
play.


Groceries
| Produce | ||
|---|---|---|
| Apples | $1.99/ lb | |
| Bananas | .99/lb | |
| Citrus Fruit | .99 /lb |
| Deli | ||
|---|---|---|
| Steak | $11.99/ lb | |
| Sausage | 6.99/lb | |
| Turkey Breast | 8.99 /lb |
| Frozen | ||
|---|---|---|
| Pizza | $1.99/ lb | |
| Ice Cream | .99/lb | |
| Lean Cuisine | .99 each |
Grocer
| Produce | ||
|---|---|---|
| Apples | $1.99/ lb | |
| Bananas | .99/lb | |
| Citrus Fruit | .99 /lb |
| Deli | ||
|---|---|---|
| Steak | $11.99/ lb | |
| Sausage | 6.99/lb | |
| Turkey Breast | 8.99 /lb |
| Frozen | ||
|---|---|---|
| Pizza | $1.99/ lb | |
| Ice Cream | .99/lb | |
| Lean Cuisine | .99 each |


Class: Domnit
| Defined in: | src/Domnit.coffee |
Overview
Serializes the DOM into a standalone HTML file.
Variables Summary
- ElementSerializer =
-
ElementSerializer
- elementSerializer =
-
ElementSerializer
- scriptSerializer =
-
ScriptSerializer
- linkSerializer =
-
LinkSerializer
- styleSerializer =
-
StyleSerializer
Instance Method Summary
- # (Boolean) passFilter(el) Determines if the element matches the filter, and should be included in the document
-
#
(Boolean)
passFilterHidden(el)
Determines if the element doesn't match a filter against elements with
visibility: hidden;
and should be included in the document. -
#
(Boolean)
passDisplayNone(el)
Determines if the element doesn't match a filter against elements with
display: none;
and should be included in the document. - # (Promise<String>) serialize(el, root = true) Serialize an HTML tree into a string.
Constructor Details
#
(void)
constructor(opt = {})
Instance Method Details
#
(Boolean)
passFilter(el)
Determines if the element matches the filter, and should be included in the document
#
(Boolean)
passFilterHidden(el)
Determines if the element doesn't match a filter against elements with visibility: hidden;
and should be included in
the document.
#
(Boolean)
passDisplayNone(el)
Determines if the element doesn't match a filter against elements with display: none;
and should be included in the
document.
#
(Promise<String>)
serialize(el, root = true)
Serialize an HTML tree into a string.
Examples:
Serialize the entire document, using jQuery to select `<html>`.
var domnit = new Domnit();
domnit
.serialize($("html")[0])
.then(function(dom) {
console.log(dom);
});


basics.rb |
|
|---|---|
|
Virtual File System provides clean, simple and unified API over different storages (Local File System, AWS S3, SFTP, …).
Such unified API is possible because although the API of storages are different the core concept are almost the same. Install Vfs with Rubygems:
Once installed, You can proceed with the example below. It uses local file system as storage, there’s also S3 version and SFTP version (also S3 backup and SSH/SFTP deployment examples availiable). The project is hosted on GitHub. You can report bugs and discuss features on the issues page. |
|
Example |
|
|
Preparing sandbox for our sample and cleaning it before starting
(ignore the |
require 'vfs'
sandbox = $sandbox || '/tmp/vfs_sandbox'.to_dir.destroy |
|
Creating simple Hello World project. |
project = sandbox['hello_world'] |
|
Writing readme file (note that parent dirs where created automatically). |
project['readme.txt'].write 'My App' |
|
We can assign files and dirs to variables, now the |
readme = project['readme.txt'] |
|
Let’s ensure that it’s all ok with our readme file and check it’s attributes. |
p readme.name # => readme.txt
p [readme.basename, readme.extension] # => ['readme', 'txt']
p readme.path # => /.../readme.txt
p readme.exist? # => true
p readme.file? # => true
p readme.dir? # => false
p readme.size # => 6
p readme.created_at # => 2011-09-09 13:20:43 +0400
p readme.updated_at # => 2011-09-09 13:20:43 +0400 |
|
Reading – You can read all at once or do it sequentially (input stream will be automatically splitted into chunks of reasonable size). |
p readme.read # => "My shiny App"
readme.read{|chunk| p chunk} # => "My shiny App" |
|
The same for writing – write all at once or do it sequentially (if there’s no file it will be created, if it exists it will be rewriten). |
readme.write "My App v2"
readme.write{|stream| stream.write "My App v3"}
p readme.read # => "My shiny App v3" |
|
Appending content to existing file. |
readme.append "How to install ..."
p readme.size # => 27 |
|
Copying and Moving. It also works exactly the same way if You copy or move files and dirs to other storages. |
readme.copy_to project['docs/readme.txt']
p project['docs/readme.txt'].exist? # => true
p readme.exist? # => true
readme.move_to project['docs/readme.txt']
p project['docs/readme.txt'].exist? # => true
p readme.exist? # => false |
|
Let’s add empty Rakefile to our project. |
project['Rakefile'].write |
|
Operations with directories – checking our project exists and not empty. |
p project.exist? # => true
p project.empty? # => false |
|
Listing dir content. There are two versions of methods – without block the result will be Array of Entries, with block it will iterate over directory sequentially. |
p project.entries # => [/.../docs, /.../Rakefile]
p project.files # => [/.../Rakefile]
p project.dirs # => [/.../docs]
project.entries do |entry| # => ["docs", false]
p [entry.name, entry.file?] # => ["Rakefile", true]
end
p project.include?('Rakefile') # => true |
|
You can also use glob (if storage support it). |
if project.driver.local?
p project.entries('**/Rake*') # => [/.../Rakefile]
p project['**/Rake*'] # => [/.../Rakefile]
end |
|
The result of dir listing is just an array of Entries, so You can use it to do interesting things. For example this code will calculates the size of sources in our project. |
if project.driver.local?
project['**/*.rb'].collect(&:size).reduce(0, :+)
end |
|
Copying and moving – let’s create another project by cloning our hello_world. |
project.copy_to sandbox['another_project']
p sandbox['another_project'].entries # => [/.../docs, .../Rakefile] |
|
Cleaning sandbox. |
sandbox.destroy |
|
In this example we covering basics of Virtual File System, if You are interesting You can also take a look at S3 backup and SSH/SFTP deployment examples. |
|


Have This Idea For An App…
Have This Idea For An App…
WWDC 2018
This session is only for super beginner, e.g., Storyboard, MVC, ViewController, Button, Label, etc.
This session is only for super beginner, e.g., Storyboard, MVC, ViewController, Button, Label, etc.


What is fleddit?
If flickr and reddit had a baby there would be fleddit! Here at fleedit, we take the best of both worlds. Use creative jokes from reddit and creative pictures from flickr to allow you to create your own meme in under 5 minutes!
Want to make your friends laugh?
Well now you can! With 3 easy steps!
Click "Create" to get started!


4.5 Questions and Answers
Q: From lowest to
highest, what is the correct order of the complexities O (n2), O (3n), O (2n), O (n2
lg n), O (1),
O (n lg
n), O (n3), O (n!), O (lg
n), O (n)?
A: From lowest
to highest, the correct order of these complexities is O (1), O
(lg n), O (n),
O (n
lg n), O (n2), O (n2 lg n), O
(n3), O (2n), O
(3n), O
(n!).
Q: What are
the complexities of T1(n) = 3n
lg n + lg
n; T2(n) = 2n + n3 +
25; and T3(n, k) = k
+ n, where k n? From lowest to
highest, what is the correct order of the resulting
complexities?
A: Using the
rules of O -notation, the
complexities of T1,
T2, and T3 respectively are O (n
lg n), O (2n), and O (n).
From lowest to highest, the correct order of these
complexities is O (n), O
(n lg n), and O (2n).
Q: Suppose we
have written a procedure to add m square matrices of size n x
n. If adding two square matrices requires O (n2 )
running time, what is the complexity of this procedure in
terms of m and n?
A: To add
m matrices of size n x n,
we must perform m - 1
additions, each requiring time O (n2). Therefore, the
overall running time of this procedure is:
O(m-1)O(n2) = O(m)O(n2) = O(mn2)
Q: Suppose we
have two algorithms to solve the same problem. One runs in
time T1(n) = 400n, whereas the other runs in time
T2(n) = n2. What are the complexities of
these two algorithms? For what values of n might we consider using the
algorithm with the higher complexity?
A: The
complexity of T1 is
O (n), and the complexity of T2 is O (n2). However, the
algorithm described by T1 involves such a large
constant coefficient for n that
when n < 400, the algorithm
described by T2
would be preferable. This is a good example of why we
sometimes consider other factors besides the complexity of an
algorithm alone.
Q: How do we
account for calls such as memcpy and malloc in analyzing real code?
Although these calls often depend on the size of the data
processed by an algorithm, they are really more of an
implementation detail than part of an algorithm itself.
A: Usually
calls such as memcpy and malloc are regarded as executing in a
constant amount of time. Generally, they can be expected to
execute very efficiently at the machine level regardless of
how much data they are copying or allocating. Of course, their
exact efficiency may depend on the computer on which they
execute as well as other factors (particularly in the case of
malloc, which depends on the
state of the system at the moment it is called). |


Reports: Cristiano Ronaldo urges Juventus to sign Paul Pogba in January
by HarigovindThe latest word around the rumour mill is that Juventus ace Cristiano Ronaldo has urged his club to beat Real Madrid to the signing of Manchester United midfielder Paul Pogba.
It is AS who reports via Express that Ronaldo has “recommended” Pogba to Juventus executives.
However, one might feel that the 2018 FIFA World Cup winner does not require many recommendations at Juventus, as he has already played for them before.
Ex-Manchester United boss Sir Alex Ferguson offloaded him to the Bianconeri in 2012, and he remained with them for four seasons before breaking Gareth Bale’s world-record transfer fee to return to the Ole Trafford.
AS claim that Juventus could table a “lucrative” offer for Pogba, by plotting to exchange right-back Danilo, midfielders Emre Can and/or Sami Khedira, or attackers Paulo Dybala or Mario Mandzukic for the 26-year-old.
Meanwhile, Ole Gunnar Solskjaer and co are short of attackers, which means that they might find it hard to resist a player-plus-cash deal wich involves either Dybala or Mandzukic.
During the summer, Pogba himself famously claimed that he is “ready” to leave the Old Trafford after spending three eventful seasons at the club.
The Frenchman has also spoken about joining Real Madrid in what seems to be a “dream move” for him, but he has not ruled out a return to Juventus either.


read
It's decided
Antonio is blogging!
Ok already, enough with the fancy third person, I finally created my first blog and we'll see if I can keep up with the content. My plan is to post from time to time things i do or think to share them with family and friends. Also i will try to write some things related with my profession just for myself, it's just easier to learn if I land stuff in some place.
So it's done, I already blogged!, I've started, this is my first post and the cover picture of the blog is from our trip to Turkey in 2007, the Izmir main square was so colorful and warm that day. I used my old Lomo camera.
Check more info about this blog going to the About page.
Nara!


{% extends "common/auth_base.html" %} {% load static %} {% block pagebody %}
Would you like to sync your roads and schedules with CourseRoad and across your devices? FireRoad will also provide you with personalized suggestions based on your subject selections.
Tap Allow and Continue to enable this feature. You can also do so later in the settings view.
Sync and Recommendations requires MIT credentials. By enabling this feature, you are allowing FireRoad to store your roads, schedules, and subject ratings on a secure MIT server. FireRoad uses various machine learning algorithms to provide you with subject recommendations and to improve other users' recommendations anonymously. Recommendations are solely suggestions - please consult with faculty and course administrators for the most reliable and up-to-date information.


speed: 1 high score: 0 all time high score: 0 number of runs: 0 current population: 1
run best so far


Education in the United States
Percentage of people aged 25 or older who attained a Bachelor Degree or higher (
Source
)


Match Mania
Uncover matches by clicking boxes before time expires!
Make sure to watch out for
bombs!
Time remaining
Scores
0
PLAYER 1
0
PLAYER 2
CHOOSE CATEGORY
Food
Activity
Smileys
Objects
Animals
Start Game


Square 3x3 Matrix.
More...
#include <Matrix3D.h>
|
|
| Matrix3D () |
| | Constructs the identity matrix.
|
| |
|
| Matrix3D (const Vector3D &a, const Vector3D &b, const Vector3D &c) |
| |
| double & | at (unsigned int i, unsigned int j) |
| | Returns a reference to the entry A[i, j] if the i and j are valid (i.e. 0<=i,j<3) More...
|
| |
| const double & | at (unsigned int i, unsigned int j) const |
| | Returns a const reference to the entry A[i, j] if the i and j are valid (i.e. 0<=i,j<3) More...
|
| |
| Matrix3D | transpose () const |
| | Returns the transpose of this matrix. More...
|
| |
|
Matrix3D & | operator*= (const Matrix3D &B) |
| |
|
Matrix3D & | operator+= (const Matrix3D &B) |
| |
| double & Matrix3D::at |
( |
unsigned int |
i, |
|
|
unsigned int |
j |
|
) |
| |
Returns a reference to the entry A[i, j] if the i and j are valid (i.e. 0<=i,j<3)
- Parameters
-
- Returns
- A reference to the entry in row i, column j
| const double & Matrix3D::at |
( |
unsigned int |
i, |
|
|
unsigned int |
j |
|
) |
| const |
Returns a const reference to the entry A[i, j] if the i and j are valid (i.e. 0<=i,j<3)
- Parameters
-
- Returns
- A const reference to the entry in row i, column j
Returns the transpose of this matrix.
- Returns
- A.T if A is this matrix
The documentation for this class was generated from the following files:


Examples¶
To make the first steps easier, two template scripts are available covering the simulation of simple and articulated vehicles. We encourage the users to run and explore the examples Template Simple and Template Articulated.
Alternatively, for Matlab users familiar with Simulink, two template applications are available for running the models of the package in Simulink. Run and explore the examples Template Simple Simulink and Template Articulated Simulink.
The list of all examples available in the package is presented below.
| Name | Description |
|---|---|
| Kalman Filter | Kalman Filter application. |
| Sinusoidal Steering | Maneuver with sinusoidal steering angle input. |
| SkidPad | Simple vehicle moving in circle. |
| SkidPad 4DOF | Simple vehicle with roll dynamics moving in circle. |
| Steering Control | Double lane change maneuver. |
| Template Articulated | Articulated vehicle simulation. |
| Template Articulated Simulink | Articulated vehicle simulation. |
| Template Simple | Simple vehicle simulation. |
| Template Simple Simulink | Simulate the simple vehicle model in Simulink. |
| Tire Comparison | Comparison of tire models. |


--- layout: single title: Service author_profile: true tags: [Service, Reviewer, Awards] comments: false ---
I have served as a reviewer for several top-tier Machine Learning and Computer Vision conferences and journals the last few years. Concretely:
Reviewer in NeurIPS, ICML, ICLR, CVPR, AISTATS, ECCV, ICCV.
Reviewer in IEEE Transactions on Pattern Analysis and Machine Intelligence (T-PAMI), International Journal of Computer Vision (IJCV), IEEE Signal Processing Letters, IEEE Transactions on Neural Networks and Learning Systems, IEEE Transactions of Image Processing, Transactions on Machine Learning Research (TMLR).


BETA This is a new service - your feedback will help us to improve it.
- UKPRN:12345678
2017 to 2018 allocation statements
Carry-in apprenticeship funding 2018 to 2019
Funding for apprentices who started their training before 1 May 2017.
Version 1 - April 2018
This PDF might not be suitable for users of assistive technology. You can email<EMAIL_ADDRESS>to ask for a different format.
Non-levy apprenticeship funding 2017 to 2018
Funding for apprentices on non-levy training.
Version 1 - March 2018
This PDF might not be suitable for users of assistive technology. You can email<EMAIL_ADDRESS>to ask for a different format.
Carry-in apprenticeship funding 2017 to 2018
Funding for apprentices who started their training before 1 May 2017.
Version 1 - March 2018
This PDF might not be suitable for users of assistive technology. You can email<EMAIL_ADDRESS>to ask for a different format.
Allocation statement for 2017 to 2018
Loans facilities funding allocation statement.
Version 1 - March 2018
This PDF might not be suitable for users of assistive technology. You can email<EMAIL_ADDRESS>to ask for a different format.
Allocation statement for 2017 to 2018
Adult education budget (AEB) and loans facilities funding allocation statement.
Version 1 - March 2018
This PDF might not be suitable for users of assistive technology. You can email<EMAIL_ADDRESS>to ask for a different format.
Allocation statement for 2017 to 2018
Adult education budget (AEB), 16 to 18 traineeships and loans facilities funding allocation statement.
Version 1 - March 2018
This PDF might not be suitable for users of assistive technology. You can email<EMAIL_ADDRESS>to ask for a different format.
Allocation statement for 2017 to 2018
Loans facilities and 16 to 18 traineeships funding allocation statement.
Version 1 - March 2018
This PDF might not be suitable for users of assistive technology. You can email<EMAIL_ADDRESS>to ask for a different format.
Allocation statement for 2017 to 2018
Adult education budget (AEB) funding allocation statement.
Version 1 - March 2018
This PDF might not be suitable for users of assistive technology. You can email<EMAIL_ADDRESS>to ask for a different format.
Allocation statement for 2017 to 2018
Adult education budget (AEB) and 16 to 18 traineeships funding allocation statement.
Version 1 - March 2018
This PDF might not be suitable for users of assistive technology. You can email<EMAIL_ADDRESS>to ask for a different format.
Allocation statement for 2017 to 2018
16 to 18 traineeships funding allocation statement.
Version 1 - March 2018
This PDF might not be suitable for users of assistive technology. You can email<EMAIL_ADDRESS>to ask for a different format.


- You can export completed tasks to one of the following formats:
- JSON
- CSV, TSV
- CoNLL 2003 named entity recognition
- COCO image segmentation semantic segmentation
- Pascal VOC XML image segmentation semantic segmentation
- Can't find desired export format?
Please report us via Slack or create an issue on our GitHub page


--- layout: post title: 'Introducing m2bk: a simple command line tool to manage your mongodb backups' date: type: post published: false status: draft categories: [] tags: [] meta: geo_public: '0' _edit_last: '36458306' author: login: axltxl email<EMAIL_ADDRESS>display_name: Axel Texel first_name: '' last_name: '' ---
<nice intro/explain the issue>
<explain the solution: m2bk>
<why m2bk?, how does m2bk benefit the sysadmin?>
<how can I use it?>
<how was it made?>
<plans for the future>
<how can the people contribute to the project?>


Trading_MyMessagesAlertType Class Reference
| Inherits from | NSObject |
| Conforms to | PicoBindable |
| Declared in | Trading_MyMessagesAlertType.h Trading_MyMessagesAlertType.m |
Tasks
-
sender
This field will be deprecated in an upcoming release.
property
This field formerly
contained the display name of the eBay application that
sends the alert. -
recipientUserID
This field will be deprecated in an upcoming release.
property
This field formerly
contained the displayable user ID of the recipient. -
subject
This field will be deprecated in an upcoming release.
property
This field formerly
contained the subject of the alert. -
priority
This field will be deprecated in an upcoming release.
property
This field formerly
contained a number ranging from 0 to 10000 (inclusive),
with 10000 having the highest priority. -
alertID
This field will be deprecated in an upcoming release.
property
This field formerly
contained an ID that uniquely identifies an alert for a
given user. -
externalAlertID
This field will be deprecated in an upcoming release.
property
This field formerly
contained an ID used by an external application to
uniquely identify an alert. -
contentType
This field will be deprecated in an upcoming release.
property
This field formerly
contained the content type of the body text. The two
acceptable values are “TEXT” and “HTML” (case
sensitive). -
text
This field will be deprecated in an upcoming release.
property
This field formerly
contained the alert body. This can be either plain text
or HTML, depending on which format the alert was
originally written in. Note that the API does not
currently check the user email format preferences
that can be specified in My Messages on the eBay.com
Web site. -
resolutionStatus
This field will be deprecated in an upcoming release.
property
This field formerly
contained whether or not an alert was resolved, and how. -
read
This field will be deprecated in an upcoming release.
property
This field formerly
contained whether or not an alert was viewed by a given
user. Note that retrieving an alert with the API
does not mark it as read. -
creationDate
This field will be deprecated in an upcoming release.
property
This field formerly
contained the date and time an alert was created by a sender. -
receiveDate
The date and time that an alert was received
property
by My Messages and stored in a database for the
recipient. -
expirationDate
This field will be deprecated in an upcoming release.
property
This field formerly
contained the date and time at which an alert expires. -
resolutionDate
This field will be deprecated in an upcoming release.
property
This field formerly
contained the date and time at which an alert is resolved. -
lastReadDate
This field will be deprecated in an upcoming release.
property
This field formerly
contained the date and time an alert was last viewed by
a given user. -
itemID
This field will be deprecated in an upcoming release.
property
This field formerly
contained a unique eBay item ID associated with an
alert. -
isTimedResolution
This field will be deprecated in an upcoming release.
property
This field formerly
contained whether or not a time-delayed
resolution is applicable for an alert. -
actionURL
This field will be deprecated in an upcoming release.
property
This field formerly
contained a URL that the recipient must visit to resolve
an alert. May be returned as an empty tag if there is no applicable URL. -
responseDetails
This field will be deprecated in an upcoming release.
property
This field formerly
contained details relating to the response to an alert
or message. -
forwardDetails
This field will be deprecated in an upcoming release.
property
This field formerly
contained details relating to the forwarding of an alert
or message. Only returned if the alert or message is
forwarded. -
folder
This field will be deprecated in an upcoming release.
property
This field formerly
contained details relating to a My Messages folder. -
any
(public property)
property
Properties
actionURL
This field will be deprecated in an upcoming release.
This field formerly
contained a URL that the recipient must visit to resolve
an alert. May be returned as an empty tag if there is no applicable URL.
@property (nonatomic, retain) NSString *actionURL
Discussion
This field will be deprecated in an upcoming release.
This field formerly
contained a URL that the recipient must visit to resolve
an alert. May be returned as an empty tag if there is no applicable URL.
type : NSString, wrapper for primitive string
Declared In
Trading_MyMessagesAlertType.h
alertID
This field will be deprecated in an upcoming release.
This field formerly
contained an ID that uniquely identifies an alert for a
given user.
@property (nonatomic, retain) NSString *alertID
Discussion
This field will be deprecated in an upcoming release.
This field formerly
contained an ID that uniquely identifies an alert for a
given user.
type : NSString, wrapper for primitive string
Declared In
Trading_MyMessagesAlertType.h
any
(public property)
@property (nonatomic, retain) NSMutableArray *any
Discussion
(public property)
entry type : PicoAnyElement, wrapper for primitive anyelement
Declared In
Trading_MyMessagesAlertType.h
contentType
This field will be deprecated in an upcoming release.
This field formerly
contained the content type of the body text. The two
acceptable values are “TEXT” and “HTML” (case
sensitive).
@property (nonatomic, retain) NSString *contentType
Discussion
This field will be deprecated in an upcoming release.
This field formerly
contained the content type of the body text. The two
acceptable values are “TEXT” and “HTML” (case
sensitive).
type : NSString, wrapper for primitive string
Declared In
Trading_MyMessagesAlertType.h
creationDate
This field will be deprecated in an upcoming release.
This field formerly
contained the date and time an alert was created by a sender.
@property (nonatomic, retain) NSDate *creationDate
Discussion
This field will be deprecated in an upcoming release.
This field formerly
contained the date and time an alert was created by a sender.
type : NSDate, wrapper for primitive date
Declared In
Trading_MyMessagesAlertType.h
expirationDate
This field will be deprecated in an upcoming release.
This field formerly
contained the date and time at which an alert expires.
@property (nonatomic, retain) NSDate *expirationDate
Discussion
This field will be deprecated in an upcoming release.
This field formerly
contained the date and time at which an alert expires.
type : NSDate, wrapper for primitive date
Declared In
Trading_MyMessagesAlertType.h
externalAlertID
This field will be deprecated in an upcoming release.
This field formerly
contained an ID used by an external application to
uniquely identify an alert.
@property (nonatomic, retain) NSString *externalAlertID
Discussion
This field will be deprecated in an upcoming release.
This field formerly
contained an ID used by an external application to
uniquely identify an alert.
type : NSString, wrapper for primitive string
Declared In
Trading_MyMessagesAlertType.h
folder
This field will be deprecated in an upcoming release.
This field formerly
contained details relating to a My Messages folder.
@property (nonatomic, retain) Trading_MyMessagesFolderType *folder
Discussion
This field will be deprecated in an upcoming release.
This field formerly
contained details relating to a My Messages folder.
type : class Trading_MyMessagesFolderType
Declared In
Trading_MyMessagesAlertType.h
forwardDetails
This field will be deprecated in an upcoming release.
This field formerly
contained details relating to the forwarding of an alert
or message. Only returned if the alert or message is
forwarded.
@property (nonatomic, retain) Trading_MyMessagesForwardDetailsType *forwardDetails
Discussion
This field will be deprecated in an upcoming release.
This field formerly
contained details relating to the forwarding of an alert
or message. Only returned if the alert or message is
forwarded.
type : class Trading_MyMessagesForwardDetailsType
Declared In
Trading_MyMessagesAlertType.h
isTimedResolution
This field will be deprecated in an upcoming release.
This field formerly
contained whether or not a time-delayed
resolution is applicable for an alert.
@property (nonatomic, retain) NSNumber *isTimedResolution
Discussion
This field will be deprecated in an upcoming release.
This field formerly
contained whether or not a time-delayed
resolution is applicable for an alert.
type : NSNumber, wrapper for primitive bool
Declared In
Trading_MyMessagesAlertType.h
itemID
This field will be deprecated in an upcoming release.
This field formerly
contained a unique eBay item ID associated with an
alert.
@property (nonatomic, retain) NSString *itemID
Discussion
This field will be deprecated in an upcoming release.
This field formerly
contained a unique eBay item ID associated with an
alert.
type : NSString, wrapper for primitive string
Declared In
Trading_MyMessagesAlertType.h
lastReadDate
This field will be deprecated in an upcoming release.
This field formerly
contained the date and time an alert was last viewed by
a given user.
@property (nonatomic, retain) NSDate *lastReadDate
Discussion
This field will be deprecated in an upcoming release.
This field formerly
contained the date and time an alert was last viewed by
a given user.
type : NSDate, wrapper for primitive date
Declared In
Trading_MyMessagesAlertType.h
priority
This field will be deprecated in an upcoming release.
This field formerly
contained a number ranging from 0 to 10000 (inclusive),
with 10000 having the highest priority.
@property (nonatomic, retain) NSString *priority
Discussion
This field will be deprecated in an upcoming release.
This field formerly
contained a number ranging from 0 to 10000 (inclusive),
with 10000 having the highest priority.
type : NSString, wrapper for primitive string
Declared In
Trading_MyMessagesAlertType.h
read
This field will be deprecated in an upcoming release.
This field formerly
contained whether or not an alert was viewed by a given
user. Note that retrieving an alert with the API
does not mark it as read.
@property (nonatomic, retain) NSNumber *read
Discussion
This field will be deprecated in an upcoming release.
This field formerly
contained whether or not an alert was viewed by a given
user. Note that retrieving an alert with the API
does not mark it as read.
type : NSNumber, wrapper for primitive bool
Declared In
Trading_MyMessagesAlertType.h
receiveDate
The date and time that an alert was received
by My Messages and stored in a database for the
recipient.
@property (nonatomic, retain) NSDate *receiveDate
Discussion
The date and time that an alert was received
by My Messages and stored in a database for the
recipient.
type : NSDate, wrapper for primitive date
Declared In
Trading_MyMessagesAlertType.h
recipientUserID
This field will be deprecated in an upcoming release.
This field formerly
contained the displayable user ID of the recipient.
@property (nonatomic, retain) NSString *recipientUserID
Discussion
This field will be deprecated in an upcoming release.
This field formerly
contained the displayable user ID of the recipient.
type : NSString, wrapper for primitive string
Declared In
Trading_MyMessagesAlertType.h
resolutionDate
This field will be deprecated in an upcoming release.
This field formerly
contained the date and time at which an alert is resolved.
@property (nonatomic, retain) NSDate *resolutionDate
Discussion
This field will be deprecated in an upcoming release.
This field formerly
contained the date and time at which an alert is resolved.
type : NSDate, wrapper for primitive date
Declared In
Trading_MyMessagesAlertType.h
resolutionStatus
This field will be deprecated in an upcoming release.
This field formerly
contained whether or not an alert was resolved, and how.
@property (nonatomic, retain) NSString *resolutionStatus
Discussion
This field will be deprecated in an upcoming release.
This field formerly
contained whether or not an alert was resolved, and how.
type: string constant in Trading_MyMessagesAlertResolutionStatusCode.h
Declared In
Trading_MyMessagesAlertType.h
responseDetails
This field will be deprecated in an upcoming release.
This field formerly
contained details relating to the response to an alert
or message.
@property (nonatomic, retain) Trading_MyMessagesResponseDetailsType *responseDetails
Discussion
This field will be deprecated in an upcoming release.
This field formerly
contained details relating to the response to an alert
or message.
type : class Trading_MyMessagesResponseDetailsType
Declared In
Trading_MyMessagesAlertType.h
sender
This field will be deprecated in an upcoming release.
This field formerly
contained the display name of the eBay application that
sends the alert.
@property (nonatomic, retain) NSString *sender
Discussion
This field will be deprecated in an upcoming release.
This field formerly
contained the display name of the eBay application that
sends the alert.
type : NSString, wrapper for primitive string
Declared In
Trading_MyMessagesAlertType.h
subject
This field will be deprecated in an upcoming release.
This field formerly
contained the subject of the alert.
@property (nonatomic, retain) NSString *subject
Discussion
This field will be deprecated in an upcoming release.
This field formerly
contained the subject of the alert.
type : NSString, wrapper for primitive string
Declared In
Trading_MyMessagesAlertType.h
text
This field will be deprecated in an upcoming release.
This field formerly
contained the alert body. This can be either plain text
or HTML, depending on which format the alert was
originally written in. Note that the API does not
currently check the user email format preferences
that can be specified in My Messages on the eBay.com
Web site.
@property (nonatomic, retain) NSString *text
Discussion
This field will be deprecated in an upcoming release.
This field formerly
contained the alert body. This can be either plain text
or HTML, depending on which format the alert was
originally written in. Note that the API does not
currently check the user email format preferences
that can be specified in My Messages on the eBay.com
Web site.
type : NSString, wrapper for primitive string
Declared In
Trading_MyMessagesAlertType.h


Pit Test Coverage Report
Package Summary
fr.sii.ogham.template.thymeleaf.v3
Number of Classes
Line Coverage
Mutation Coverage
2
89%
47/53
37%
23/63
Breakdown by Class
Name
Line Coverage
Mutation Coverage
ThymeLeafV3FirstSupportingTemplateResolver.java
76%
16/21
17%
6/36
ThymeleafV3TemplateDetector.java
97%
31/32
63%
17/27
Report generated by
PIT
1.4.11-OGHAM


|
||||||||||
| PREV NEXT | FRAMES NO FRAMES |
| Packages that use InstanceLifecycleEvent | |
|---|---|
| javax.jdo.listener | This package contains the JDO specification listener interfaces and classes. |
| Uses of InstanceLifecycleEvent in javax.jdo.listener |
|---|
| Methods in javax.jdo.listener with parameters of type InstanceLifecycleEvent | |
|---|---|
void |
AttachLifecycleListener.postAttach(InstanceLifecycleEvent event)
This method is called after a detached instance is attached, via the PersistenceManager.makePersistent(java.lang.Object) method. |
void |
ClearLifecycleListener.postClear(InstanceLifecycleEvent event)
This method is called after the ClearCallback.jdoPreClear()
method is invoked on the instance and the fields have been cleared
by the JDO implementation. |
void |
CreateLifecycleListener.postCreate(InstanceLifecycleEvent event)
Invoked whenever an instance is made persistent via a call to PersistenceManager.makePersistent(java.lang.Object) or during
persistence by reachability. |
void |
DeleteLifecycleListener.postDelete(InstanceLifecycleEvent event)
Invoked whenever a persistent instance is deleted, for example during PersistenceManager.deletePersistent(java.lang.Object) . |
void |
DetachLifecycleListener.postDetach(InstanceLifecycleEvent event)
This method is called during the execution of PersistenceManager.detachCopy(java.lang.Object) after the
detached copy is made. |
void |
DirtyLifecycleListener.postDirty(InstanceLifecycleEvent event)
Invoked whenever a persistent instance is first made dirty, during an operation that modifies the value of a persistent or transactional field. |
void |
LoadLifecycleListener.postLoad(InstanceLifecycleEvent event)
Invoked whenever a persistent instance is loaded from the data store. |
void |
StoreLifecycleListener.postStore(InstanceLifecycleEvent event)
Invoked whenever a persistent instance is stored, for example during PersistenceManager.flush() or
Transaction.commit() . |
void |
AttachLifecycleListener.preAttach(InstanceLifecycleEvent event)
This method is called before a detached instance is attached, via the PersistenceManager.makePersistent(java.lang.Object) method. |
void |
ClearLifecycleListener.preClear(InstanceLifecycleEvent event)
This method is called before the implementation calls the instance method ClearCallback.jdoPreClear() and before it clears the values
in the instance to their Java default values. |
void |
DeleteLifecycleListener.preDelete(InstanceLifecycleEvent event)
Invoked whenever a persistent instance is deleted, for example during PersistenceManager.deletePersistent(java.lang.Object) . |
void |
DetachLifecycleListener.preDetach(InstanceLifecycleEvent event)
This method is called during the execution of PersistenceManager.detachCopy(java.lang.Object) before the
detached copy is made. |
void |
DirtyLifecycleListener.preDirty(InstanceLifecycleEvent event)
Invoked whenever a persistent instance is first made dirty, during an operation that modifies the value of a persistent or transactional field. |
void |
StoreLifecycleListener.preStore(InstanceLifecycleEvent event)
Invoked whenever a persistent instance is stored, for example during PersistenceManager.flush() or
Transaction.commit() . |
|
||||||||||
| PREV NEXT | FRAMES NO FRAMES |


Melnicky Marathon
Melnick CZE
Race Winners
(22 runnings)
21
Apr 2012 09
Apr 2011 24 Apr
2010 25 Apr
2009 26
Apr
2008
21
Apr
2007
22
Apr
2006
16
Apr
2005
17
Apr
2004
19
Apr
2003
20
Apr
2002
2001
2000
1999
25 Apr
1998
1997
1996
1995
Notes: 1995 is belived to have been the inaugural year.
09
Apr 2016
2:42:24
Petr Havelka (CZE)
3:14:08
Michaela Dimitriadu-6
11
Apr 2015
2:58:07
Miloš Fiala (CZE)
3:19:05
Michaela Dimitriadu-5
12
Apr 2014
2:55:27
Josef Veber (CZE)
3:16:04
Michaela Dimitriadu-4
13
Apr 2013
3:00:44
Jiri Krejcik (CZE)
3:58:07
Jitka Wohlrabova-3
2:56:07
Vlastimil Pozarsky (CZE)
3:29:56
Jaroslava Krausova (CZE)
2:37:44
Daniel Oralek (CZE)
3:10:59
Michaela Dimitriadu-3
2:39:29
Daniel Kupidlovsky (CZE)
3:08:35
Michaela Dimitriadu-2
2:54:05
Jiri Masita (CZE)
3:24:37
Michaela Dimitriadu (CZE)
2:48:04
Martin Rexa (CZE)
3:54:36
Jitka Wohlrabova-2
2:48:25
Jan Maly (CZE)
4:04:37
Jitka Wohlrabova (CZE)
2:48:48
Josef Siegel (CZE)
3:39:41
Marketa Muzikova (CZE)
2:48:59
Igor Heles (CZE)
3:12:28
Anna Bacova (CZE)
2:45:03
Jiri Lenca (CZE)
2:57:01
Tana Metelkova-2
2:36:28
Mulugeta Serbessa-2
3:08:02
Tana Metelkova (CZE)
2:35:30
Mulugeta Serbessa (ETH)
3:04:50
Hana Harokova (CZE)
---
n/a
---
n/a
---
n/a
---
n/a
---
n/a
---
n/a
---
n/a
3:08:51
Pavla Loudova (CZE)
---
n/a
---
n/a
---
n/a
---
n/a
---
n/a
---
n/a
Most Wins
(1995/date)
Men
2
Mulugeta Serbessa (ETH)
2002-03
Women
6
Michaela Dimitriadu (CZE)
2009-11,2014-16
Prize Money
(ADR qualified runners)
No information on prize money has been received for this race.
Race Time Bias
(sec/km)
Insufficient data to calculate the race time bias.
Competitive Level
(1990-date)
Insufficient data to calculate the competitive level.
Quality Performances
Men No men under 2:20 Women No women under 2:50
Last Updated on 17 Apr 2016
Contributors: Klaas Loonstra (30), Franco Civai (5)


Moderation Tools
Your Actions
Help & feedback
About
Settings
Sign out
Moderation Tools
Queues
{{ q.queue }}
{{ q.available }} new
All
Witness
Avatars
Other
Discussions
Users
Anti-spam


Version Control, Git, and GitHub
How does git help you keep track of changes?
Why use GitHub to store your code?


--- layout: post title: Episode 015 | Joe Colantonio - Delivering Automation Awesomeness link: http://traffic.libsyn.com/developeronfire/DeveloperOnFire-15-JoeColantonio-complete.mp3 length: 26214400 speaker: Dave Rael duration: '30:49' subtitle: 'Developer On Fire: Joe Colantonio' guest_name: Joe Colantonio image: /assets/images/JoeColantonio.jpg guest_blog: http://www.joecolantonio.com/ guest_twitter: jcolantonio disqus_url: http://developeronfire.com/Podcast/Episodes/joe-colantonio-delivering-automation-awesomeness episode_number: 15 book_recommendations: - { url: "http://www.amazon.com/dp/0814474578/?tag=devonfir-20", title: "Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems", author: "David J Agans"} tags: - { url: "http://www.amazon.com/dp/0814474578/?tag=devonfir-20", title: "Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems", author: "David J Agans"} redirect_from: - "/15/" - "/015/" - "/0015/" - "/joe-colantonio-delivering-automation-awesomeness/" - "/Joe-Colantonio/" - "/JoeColantonio/" - "/Podcast/Episodes/15/" - "/Podcast/Episodes/015/" - "/Podcast/Episodes/0015/" - "/Podcast/Episodes/joe-colantonio-delivering-automation-awesomeness/" - "/Podcast/Episodes/Joe-Colantonio/" - "/Podcast/Episodes/JoeColantonio/" guid: http://developeronfire.com:80/Podcast/Episodes/joe-colantonio-delivering-automation-awesomeness ---
Joe Colantonio talks with Dave Rael about automating testing, creating useful content, and understanding the intent of users and businesses
Joe Colantonio a test automation architect for a large Fortune 100 company. He’m able work 100% remotely from home in Rhode Island, which is fortunate because he hates cubicles and commuting. He blogs at joecolantonio.com and is the host of the podcast, TestTalks where he focuses on helping people and organizations succeed with automation awesomeness.
He's an avid digital content creator who loves to share information through his blog, podcasts, videos, courses and books.
Joe's top 3 tips for delivering more value:
1. Work on what you are good at
2. Emulate existing models of proven success
3.


--- layout: page title: Resources header: Pages group: navigation share_title: "200 Nights of Freedom: Resources" order: 4 ---
As we’ve shared history of Milwaukee’s Open Housing Marches in communities around our city, we’ve found that this story of national importance is too often absent from our local memory. So, in addition to attending events throughout 200 Nights of Freedom, educating yourself about this history is a key way to honor the 50th anniversary.
50 years after the original marches and victory for fair housing, Milwaukee still has no public monument or memorial to the youth and adult activists who worked tirelessly to promote social justice, racial justice, and fair housing. What could a public monument to the movement look like? How can we commemorate the original marches and also acknowledge current activism in our cities?
We invite young people throughout the state of Wisconsin to submit entries of a public monument to the “Design a Monument Contest and Exhibition.” The contest is open for all youth from Grades 3-12. The theme of the contest is “Recognizing and Reigniting the March on Milwaukee.” Keywords that can inspire student designs include:
To read the official rules and see more details on this contest, see the attached info packet. Complete the attached entry form and email it and all photos/digital works to<EMAIL_ADDRESS>The deadline for submissions is March 31, 2018.
Submit a design for a monumentMilwaukee-born historian Erica Metcalfe has written two crucial articles detailing the contributions of the NAACP Youth Council and Commandos to Milwaukee’s Open Housing marches.
Both published in Wisconsin Magazine of History, Metcalfe presents deeply important Milwaukee stories that are too often forgotten. It is the sincere opinion of the March On Milwaukee 50th committee that these two short articles are essential reading for all Milwaukeeans.
Read Future Political Actors by Erica Metcalfe, published in the autumn 2011 Wisconsin Magazine of History.
Read Commanding A Movement by Erica Metcalfe, published in the winter 2014-2015 Wisconsin Magazine of History.
For the 40th anniversary of Milwaukee’s Open Housing marches, Peggy Rozga wrote an article in the summer 2007 Wisconsin Magazine of History detailing the 200 nights of marching, from the first march on August 28th, 1967 to the passing of Vel Phillips’ fair housing resolution on April 30th, 1968. Click here to read March On Milwaukee by Peggy Rozga.
In June 2017, CNN produced the special Bill Weir: States of Change, including a fascinating interview with the Prentice McKinney about the Commando’s relationship to law enforcement in ’67-68. Click here to see the special.
Throughout the summer of 2017, the Milwaukee Neighborhood News Service has been publishing a series of stories on Milwaukee’s Open Housing marches, including feature articles and interviews with marchers. Click here to see the series.
In 2015, Wisconsin Public Television created a documentary detailing the amazing life of Milwaukee civil rights leader Vel Philips, including her tireless advocacy for fair housing in Milwaukee. Click here to watch this documentary.
UW-Milwaukee Professor Emeritus Michael Gordon compiled this bibliography of suggested readings about African Americans, housing, education, and civil rights In Milwaukee.
Suggestions for further reading on the Open Housing Marches can be found at the UWM Library Archive’s March on Milwaukee archive.
Check back in the coming weeks for more resources, including curriculum and other resources.


Triangular is an infrastructure built on top of AngularJS that lets you build CRUD applications in an efficient and concise manner.
The development platform supports two environments. The first is the GAE Variant. The second is the
Node.js Variant. Where steps differ in this Tutorial
the above flags will serve to alert you as to which path to take.
This tutorial will guide you through the all the steps needed to build your own application and upload it to the Google App Engine.
This tutorial will guide you through the all the steps needed to build your own application and upload it to
a Node.js
server environment. The Tutorial
uses
NodeJitsu Node.js Hosting as a reference point. The steps will have to be adjusted if you choose a different
Node.js
hosting site.
This tutorial is based on Windows XP through 8. The following small .bat files will have to be adjusted in a non-windows platform.
As they are contributed they will be added to the Development Package.
waks.bat
Node.js Variant
run-tri.bat
GAE Variant
run-ws.bat
appcfg.bat
GAE Variant Until then it will be necessary at their usage points to adjust them to your platform. Files dev_appserver.sh
and appcfg.sh
obtained from
the GAE SDK
are provided as starting points for developing
run-ws.sh
and appcfg.sh
.
Your favorite text editor. The author uses MultiEdit mainly because of its excellent column edit support and its ability to save all files on a windows task switch.
The Chrome Browser. Others can be used but please read Browser Support first.
GAE Variant A Java 6 or more runtime. If not installed it can be obtained at Java Runtime
If you are running a browser on the machine Java is likely already installed. Ensuring the ...\jreX\bin
folder location is part of your standard path statement will often suffice.
Typing path
at a command prompt will verify this.
Node.js Variant The Node.js
package should be installed and on the default path. This can be obtained from
Node.js Home Page
This is covered in greater detail at Development Environment
To see how straight forward it is to build your own app just follow the step-by-step instructions. You could have a starter app up and running locally in a few minutes. A few more and it would be hosted on the GAE Site or Node.js Site.


Video: Kirk Herbstreit Shows Off “Insane” Scene At College GameDay In Waco
by Andrew HolleranESPN’s College GameDay is broadcasting live from Waco, Texas this morning in anticipation of tonight’s showdown between undefeated Baylor and Oklahoma.
It’s been a while since the college football pregame show was at Baylor. The Bears’ fan base appears to be excited.
ESPN college football analyst Kirk Herbstreit shared a video detailing the “insane” scene by the set minutes before the show began.
“Insane amount of CREATIVE signs here in Waco for College GameDay! Coming up LIVE at 9am ET!!!” he tweeted.
It should be quite a show this morning.
ESPN’s College GameDay will air from 9 a.m. E.T. to 12 p.m. E.T.
Baylor and Oklahoma are set to kick off at 7:30 p.m. E.T. The game will be on ABC.


Materials, Materiality, and Media
Authors
Verena Fuchsberger, Martin Murer, Manfred Tscheligi
Notes
Field of Study
Concepts
Quotations
References
Methodology


(+886) 3-550-6190
<EMAIL_ADDRESS>Xin-Rui Advanced Materials Co.,Ltd.
Mobile:
+886-908-914-099
Fax:
(+886) 3-550-6191
Home
II-VI Marlow
Coolers
Thermocyclers
DemoA_Right
DemoB_Left
Single-Stage
DemoC_Full
Demos
Multi-Stage
Demos
Demos
Power Generators
Standard
EverGen®
Energy Harvesters
PowerStrap
Plate Exchanger
Semiconductor
Laser Optics
CO2
YAG
Demos
Supplies
Fiber
Vacuum parts
Second-Hands
Telerac
Vacuum parts
All Products
Contact Us
Chinese Version
Home
All Products
Our Gallery
Gallery Title Goes Here
Gallery Description Goes Here
« Previous
1
2
…
6
7
8
9
…
14
15
Next »
Copyright © 2017 - All Rights Reserved -
Xin-Rui
Design by
i-Arche