Skip to main content

Generate schemata from message specification

Wizard step 3

At a certain point, you may conclude the customized message tree is done and you want to move on. The wizard can generate several outputs, like message schemas in different languages and example messages. These outputs are generated dynamically and freely, so you can check the output, alter the message and try again. Note that generation is a relatively newly added feature, and that not all of the possible constructs for all syntaxes may be generated. So we advise you to use the generated document as a starting point rather than as an end result. Also if you find anything you don't expect, or miss anything you do expect, please report it to us, so we can improve our output generators.

XML schema and example

The wizard has two styles of generating XML schemas. These styles are called "Venetian Blinds" and "Russian Doll" style. A toggle switch allows you to toggle between these styles. Note that the Venetian Blinds style is still experimental, due to difficulty in recognizing identical elements down the tree, so Russian Doll is the safest choice for you. More information about these styles are listed in the XML schema design document.

JSON schema and example

For the JSON Schema generation also these two styles apply: Russian Doll style, and Venetian Blinds style. The wizard will generate an example message as well and use your provided example values, or value constraints, or fixed value first, and if these are not present for the element it will create a random value.

RDF mapping language (RML)

End users interested in using ontologies and triples as a unit of information can use the RML generator. Both XML schema and JSON schema offer a RDF Mapping Language specification, next to the schema. This RML specification formalizes a way to translate XML or JSON messages back to triples, which are the basic units of information in an ontology. In this way the xml and json information can be automatically translated into triples that can be fed into a triple store. In order for this functionality to work the generator relies on URI annotations of elements and underlying properties.

For convenience a YARRRML serialization of the RML mapping is available as well. YARRRML is a more human readable representation. The RML is expressed in YAML henced the name YARRRML. There is a YARRRML playground available for testing purposes. Note! there is a limitation for using generated YARRRML output: the library we use to transform RML to YARRRML doesn't pick up the join condition that is needed for multi-level data structures.

SHACL

SHACL is a promising Semantic Web technology. It stands for Shapes Constraint Language and it offers validation features over RDFS data. Lately, it is also used more and more as an alternative to specifying constraints in OWL, as it is considered easier to read, and closer to implementations. See SHACL output for more information.

OpenAPI schema

Using the JSON Schema as a starting point, the wizard can create a basic OpenAPI specification (formerly known as Swagger). For now this generator provides a single resource with GET, PUT and a POST operations for a message. Because some of the OpenAPI specification is very deployment-specific, the goal of the OpenAPI generator is to provide a basic framework that you can extend with your own specific deployment configuration, like API token or specific URL paths. More details, and design decisions for the generated OpenAPI are to be found at the OpenAPI design page. We recommend to pick up the OpenAPI spec generated by the Wizard and continue in a Modern Openapi editor.

Graph Pattern

Graph patterns are part of the SPARQL standard for querying graph data. Typically they form the 'where clause' of a SPARQL query. The Wizard can be used to make a graph pattern from your message model according to the following principles:

  • If there is a fixed value for a certain element, that is considered as a fixed value for filtering the data. You can add a fixed value in Step 2 of the Wizard. In this example, the element of interest countryCode has under 'Constraints', 'Fixed value' the value 'NL'. In the Graph pattern this value is included.
  • If there is no fixed value (or multiple allowed values are specified) then the element is transformed into a variable (?a, ?b, ?c for resources and ?literal-a, literal-b, ?literal-c for literals).
  • Class variables are typed according to their target class in the underlying message model (if present).

Graph patterns can be used as an input in the Knowledge Engine to indicate the informational capabilities of each collaboration partner.