Manifests of examples

Run the examples of a manifest

1. Open the demo with the URL of the manifest in manifestURL:

   https://rudof-project.github.io/web-demo/?manifestURL=https://example.org/my-examples.yaml

   The URL can be relative to the page, for example ?manifestURL=examples.yml for a manifest next to the demo. Try the manifest of the ISWC 2026 tutorial.

2. Above the tabs, the demo shows Examples from the manifest, and a list of its examples. Each example is named by its comment (or its dataLabel), and the examples are grouped by schemaLabel. ✓ and ✗ mark the examples whose status is conformant or nonconformant.

3. Choose an example. The demo opens the tab of its action and puts its inputs in the editors:

   • validate: the Validate tab of its engine (ShEx, SHACL, DCTAP or PGSchema). Press Validate to validate it: the verdict says whether the result is the one of its status (“as the manifest expects”).
   • query: the SPARQL tab. Press Run query to run the query.
   • data: the RDF or Property graph tab of the Data section. Press Convert to convert the data.
   • schema: the Schema tab, with the language and the format of the schema. Choose what to convert it to, and press Convert.

   Below the list, the demo shows what the example expects and its comment.

4. You can change the inputs and run them again. The verdict compares the result with the status only while the inputs are those of the example.

When you choose an example, the URL of the page gets &example=<n> (the n-th example, from 1) and the inputs of the tab, so it is a permalink of the example as it is now. To start again from the list, use Reload the examples, at the right of the list: it opens the page with only ?manifestURL=…. A URL with ?manifestURL=…&example=3 and no inputs loads the third example when the page opens.

The browser reads the manifest and the files of its examples, so their server must allow other sites to read them (CORS). GitHub Pages and raw.githubusercontent.com do. If a manifest can't be read, the demo says why below the list.

The format of a manifest

A manifest is a YAML list. Each item of the list is an example: a map of keys and values. Each input of an example (its data, schema, shape map, type map or query) is given either as text, with the name of the input, or as the URL of a file, with the name and URL:

- data: |                  # the data, as text…
    PREFIX : <http://example.org/>
    :alice :name "Alice" .
- dataURL: data/alice.ttl  # …or the URL of a file with the data

URLs are relative to the URL of the manifest. Use | for text of several lines, and quotes for text with a : followed by a space, or that starts with @, [ or { (for example queryMap: ":alice@:Person").

Every key is optional. Without action, an example is a validation, as in the manifests of shex.js, and without validationEngine the demo chooses the engine from the inputs (see below).

Sections

A manifest can put its examples in sections, which can have sections too. A section is an item with section (its title), an optional comment (more about it) and examples: a list of examples and sections. A manifest can have examples out of sections too, and a manifest without sections is a list of examples, as before.

- section: Knowledge Graphs
  comment: Examples about Knowledge Graphs
  examples:
  - comment: Tim Berners-Lee in RDF (Turtle)
    dataURL: ex01.ttl
    action: data
  - section: Wikidata
    examples:
    - comment: Wikidata SPARQL query
      endpoint: https://query.wikidata.org/sparql
      queryURL: ex04_wikidata.sparql
      action: query
- comment: An example out of the sections
  dataURL: ex02.ttl
  action: data

The demo shows the titles of the sections, with the number of their examples, closed. A click on a title opens the section (its comment, then its examples and its sections), and another click closes it. Open all the sections and Close all the sections do it for all of them. The examples are numbered in the order of the manifest, in their sections too: &example=4 is the fourth example of the manifest, and the demo opens its sections.

Examples of entries

Validate with ShEx

ShEx needs a schema, data, and a shape map (queryMap) that says which nodes to validate with which shapes.

- schemaLabel: Person
  schema: |
    PREFIX : <http://example.org/>
    PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
    :Person { :name xsd:string }
  dataLabel: Alice has a name
  data: |
    PREFIX : <http://example.org/>
    :alice :name "Alice" .
  queryMap: ":alice@:Person"
  status: conformant
  comment: Alice has a name, so she is a Person

A ShEx schema can import other schemas (IMPORT <iri>). The demo gets them in Chrome and Edge 137 or later; their servers must allow other sites to read them (CORS). Relative imports (IMPORT <book.shex>) are relative to the file of the schema (schemaURL).

Validate with SHACL

Set validationEngine: shacl. The schema is the shapes graph, in an RDF format (schemaFormat, Turtle by default). Without a schema, the shapes are taken from the data. SHACL has no shape map: the shapes say which nodes they apply to (sh:targetClass, sh:targetNode…).

- schemaLabel: Person (SHACL)
  validationEngine: shacl
  schema: |
    PREFIX : <http://example.org/>
    PREFIX sh: <http://www.w3.org/ns/shacl#>
    :PersonShape a sh:NodeShape ;
      sh:targetClass :Person ;
      sh:property [ sh:path :name ; sh:minCount 1 ] .
  dataLabel: Bob has no name
  data: |
    PREFIX : <http://example.org/>
    :bob a :Person .
  status: nonconformant
  comment: A Person needs a name

The targets can also be given apart from the shapes, with targets (or targetsURL, a file) and targetsFormat (Turtle by default). They are RDF triples, merged with the shapes graph before the validation, as the Target declarations of the SHACL tab:

- schemaLabel: Person (SHACL), with the targets apart
  validationEngine: shacl
  schemaURL: person-shapes.ttl
  targets: |
    PREFIX : <http://example.org/>
    PREFIX sh: <http://www.w3.org/ns/shacl#>
    :PersonShape sh:targetNode :bob .
  targetsFormat: turtle
  dataURL: people.ttl
  comment: Bob, validated with the shapes of person-shapes.ttl

Without validationEngine, an example is also validated with SHACL when its schema is in an RDF format (a schemaFormat such as turtle, or a file such as shapes.ttl) and it has no queryMap, or when it gives its schema as shapes or shapesURL. Writing validationEngine: shacl makes it clear.

Validate a property graph with PGSchema

The data is a property graph in YARS-PG (dataFormat: yars-pg), the schema is in PGSchemaC, and the type map (typeMap) says which type each node or edge should have.

- schemaLabel: Person (PGSchema)
  validationEngine: pgschema
  schema: |
    CREATE NODE TYPE ( PersonType : Person { name: STRING } )
  dataLabel: Alice in a property graph
  dataFormat: yars-pg
  data: |
    (n1 {Person} [ name: "Alice" ])
  typeMap: "n1: PersonType"
  status: conformant
  comment: A person in a property graph

Validate with a DCTAP profile

A DCTAP profile is a table in CSV. Its language is schemaLanguage: dctap, which a CSV schema (schemaFormat: csv, or a .csv file) has without saying it. The DCTAP tab converts the profile to ShEx and validates the data with it, for the shape map (queryMap): validationEngine is shex, the only one for DCTAP until rudof can convert DCTAP to SHACL.

The names of the profile are prefixed names (foaf:name) or names without prefix (Person), so the example gives the prefixes of the profile in prefixes (or prefixesURL), as Turtle declarations: PREFIX, and BASE for the names without prefix. The values of picklists are separated by spaces, unless picklistSeparator: "|".

- schemaLabel: Person (DCTAP)
  schemaLanguage: dctap
  validationEngine: shex
  schemaFormat: csv
  schema: |
    shapeID,shapeLabel,propertyID,propertyLabel,mandatory,repeatable,valueNodeType,valueDataType,valueShape
    Person,Person,:name,Name,true,false,literal,xsd:string,
    Person,,:knows,Knows,false,true,iri,,Person
  prefixes: |
    BASE <http://example.org/>
    PREFIX : <http://example.org/>
    PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
  dataLabel: Alice knows Bob
  data: |
    PREFIX : <http://example.org/>
    :alice :name "Alice" ; :knows :bob .
    :bob :name "Bob" .
  queryMap: ":alice@:Person"
  status: conformant
  comment: Alice, validated with a DCTAP profile
- schemaLabel: Person (DCTAP)
  schemaURL: person.csv
  prefixesURL: person-prefixes.ttl
  dataURL: people.ttl
  queryMap: ":bob@:Person"
  comment: The same, with files (the .csv file makes it DCTAP)

Load data

action: data puts the data in the Data section, to convert it to other formats: RDF data in the RDF tab, property graphs (dataFormat: yars-pg) in the Property graph tab.

- action: data
  dataFormat: turtle
  data: |
    PREFIX : <http://example.org/>
    :alice :knows :bob .
  comment: Alice knows Bob, in RDF
- action: data
  dataFormat: yars-pg
  data: |
    (n1 {Person} [ name: "Alice" ])
    (n2 {Person} [ name: "Bob" ])
    (n1) - ({knows}) -> (n2)
  comment: Alice knows Bob, as a property graph

Run a SPARQL query

action: query puts the query in the SPARQL tab, with the data it runs on, or with an endpoint: then the query runs on the endpoint (which must allow other sites to query it, as Wikidata does), and the example needs no data.

- action: query
  data: |
    PREFIX foaf: <http://xmlns.com/foaf/0.1/>
    PREFIX : <http://example.org/>
    :alice foaf:name "Alice" ; foaf:knows :bob .
    :bob foaf:name "Bob" .
  query: |
    PREFIX foaf: <http://xmlns.com/foaf/0.1/>
    SELECT ?name WHERE { ?person foaf:name ?name }
  comment: The names in the data
- action: query
  endpoint: https://query.wikidata.org/sparql
  query: |
    PREFIX wd: <http://www.wikidata.org/entity/>
    PREFIX wdt: <http://www.wikidata.org/prop/direct/>
    SELECT ?occupation WHERE { wd:Q80 wdt:P106 ?occupation }
  comment: The occupations of Tim Berners-Lee, in Wikidata

Validate the data of an endpoint

A validation with ShEx, SHACL or DCTAP can run on the data of a SPARQL endpoint, given by endpoint, instead of data: rudof asks the endpoint for the data of each node it validates. The shape map can use the prefixes of the schema (for DCTAP, its prefixes).

- endpoint: https://query.wikidata.org/sparql
  schema: |
    PREFIX wd: <http://www.wikidata.org/entity/>
    PREFIX wdt: <http://www.wikidata.org/prop/direct/>
    PREFIX : <http://example.org/>
    :Human { wdt:P31 [ wd:Q5 ] }
  queryMap: "wd:Q80@:Human"
  status: conformant
  comment: Tim Berners-Lee is a human, in Wikidata

For this, the demo loads rudof built with endpoints, which needs a browser with JSPI (JavaScript Promise Integration): Chrome or Edge 137 or later. In other browsers, these examples can't be run; queries on endpoints can, as the demo sends them itself. As for queries, the endpoint must allow other sites to query it (CORS).

Show a schema

action: schema puts the schema in the Schema tab, to convert it to other formats, to other languages, to a UML diagram or to a SPARQL query. The language of the schema is its schemaLanguage; without it, the demo chooses it as for validations (see below). A DCTAP profile can have its prefixes and its picklistSeparator.

- action: schema
  schemaLanguage: shex
  schemaFormat: shexc
  schema: |
    PREFIX : <http://example.org/>
    PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
    :Person { :name xsd:string ; :knows @:Person * }
  comment: A schema of people, in ShEx
- action: schema
  schemaFormat: csv
  schema: |
    shapeID,propertyID,valueDatatype
    Person,:name,xsd:string
  prefixes: |
    PREFIX : <http://example.org/>
  comment: The same people, in a DCTAP profile

All the keys

The names of the keys are case-sensitive; their values (actions, engines and formats) are not.

What the example is

Its inputs

Each input is text, or the URL of a file with the input (the key with URL).

The formats of the inputs

The file extensions the demo knows: .ttl, .nt, .rdf, .xml, .owl, .jsonld, .trig, .n3, .nq (RDF); .shex, .shexc, .shexj, .json (ShEx); .pg, .ypg, .yarspg (YARS-PG); .pgs, .pgschema (PGSchemaC); .csv (DCTAP).

How it is shown

How the tab and the formats are chosen

• action: data goes to the Property graph tab when the data is a property graph (dataFormat: yars-pg, or a .pg file), and to the RDF tab otherwise.
• action: query goes to the SPARQL tab.
• action: schema goes to the Schema tab, in the schemaLanguage of the schema. Without it, the language is dctap for a DCTAP profile, else the language of the engine that would validate the schema (below).
• action: validate (or no action) with a DCTAP profile (schemaLanguage: dctap, schemaFormat: csv or a .csv file) goes to the DCTAP tab.
• Other validations go to the tab of their schemaLanguage or validationEngine. Without them, the engine is:
  1. pgschema when the data is a property graph or the schema is PGSchemaC (schemaFormat: pgschema, or a .pgs file);
  2. shacl when the schema is given as shapes or shapesURL, or is in an RDF format and there is no queryMap (ShEx needs one);
  3. shex otherwise.
• The format of each input is its key (dataFormat, schemaFormat…), else the format of the extension of its file, else the default of its tab.

Examples that can't be run

They are in the list, marked “(not supported)”, and can't be chosen. Below the list, Why … examples can't be run opens the list of these examples: for each one, the reason, a hint on how to change its entry, a link to this page, and the entry as the demo read it from the manifest. They are:

• examples without an input that their tab needs (for example a ShEx validation without queryMap, or a query without data or endpoint);
• formats that their tab can't read (for example TriX, or a shex schema for SHACL);
• unknown actions, validation engines or query engines;
• queries on property graphs;
• validations on an endpoint, in browsers without JSPI, such as Firefox and Safari (see above), and validations that read their data as they go (neighborhood in the manifests of shex.js) without an endpoint.

Manifests of shex.js

The demo reads the manifests of shex.js, such as its own examples: they have no action, so they are ShEx validations, with schemaLabel, schemaURL, dataLabel, dataURL, queryMap and status. Examples written for the plugins of shex.js (plugins) can be loaded, with a note: rudof may not run their semantic actions.