SHACL shapes allow validation of RDF content against syntax and business rules. This service, available also via SOAP APIREST API and command-line tool, focuses on the implementation of these rules as SHACL shapes and allows you to validate them against the SHACL specification.
Shapes can be validated against the specification's core rules, its advanced features, or optional best practices (click here for further details). For questions and feedback on this service please contact DIGIT-ITB@ec.europa.eu.
SHACL shape validation options
Three validation options are provided for the validation of your SHACL shapes:
Extended W3C syntax rules and best practices: This option includes all syntax rules (see previous options), extending them with additional shapes that provide suggestions based on compiled best practices (to view these click 'View additional details' below).
Disclaimer: The SHACL shapes implementing the SHACL advanced features and remaining core rules (see second option) as well as the list and implementation of best practices (see third option) result from the experience and work of the European Commission's DIGIT and specifically the Interoperability Test Bed team and the Semantic Interoperability Community (SEMIC). These are provided for the benefit of SHACL shape developers but should not be considered as endorsed by W3C nor be used for formal conformance testing.
Best practice rules
sh:name / sh:description
Both sh:name and sh:description may have multiple values, but should only have one value per language tag.
A shape should have at least one value for sh:message in the shapes graph, then all validation results produced as a result of the shape will have exactly these messages (as natural language) as their value of sh:resultMessage.
A shape should not have more than one value for sh:message with the same language tag.
The value type of the sh:defaultValue should align with the specified sh:datatype or sh:class of the same shape.
Avoid large rdf:list due to their inefficiency.
Every NodeShape SHOULD contain rdfs:label and rdfs:comment, and they SHOULD only have one value per language tag.
Each property SHALL have a sh:name (in the context of the target where it appears) to provide human-oriented labels. This is the preferred alternative to overwriting rdfs:labels coming from external foreign vocabularies to fit the context better.
Each property SHOULD have sh:description (in the context of the target where it appears) to provide further human-oriented details. This is the preferred solution over adding additional usage notes to fit the context.
If present at property shapes, the recommended use of sh:order is to sort the property shapes in an ascending order, for example so that properties with smaller order are placed above (or to the left) of properties with larger order.
Rules not implemented
The values of sh:expression at a shape must be well-formed node expressions.
The values of sh:condition at a rule must be well-formed shapes.
A function expression is a blank node that does not fulfill any of the syntax rules of the other node expression types and which is the subject of exactly one triple T where the object is a well-formed SHACL list, and each member of that list is a well-formed node expression.
This service is powered by the Interoperability Test Bed, a conformance testing service offered by the European Commission's DG DIGIT for projects involved in the delivery of cross-border public services. Find out more here.