This service allows you validate Public Service data against the specifications linked to the Single Digital Gateway and specifically its Catalogue of Services. Access to this service is anonymous and no data, nor validation reports, are retained following its use. The service is also offered via SOAP API and REST API (for machine-to-machine integration), Docker image (for on-premise use), and command line tool (for scripting).
The content to validate can be provided as a file, a URI reference, via editor, or via query to a public SPARQL endpoint. A detailed user guide is available here.
Click here for a detailed reference of the core specification rules and their National extensions.
Validation rule reference
The following tables list the data validation rules split per relevant specification. Click on a specific Member State to view its National extensions.
CPSV-AP rules
| Rule ID | Target | Severity | Description |
|---|---|---|---|
| text-language | sh:name / sh:description | Warning | Both sh:name and sh:description may have multiple values, but should only have one value per language tag. |
| message | sh:message | Warning | 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. |
| message-language | sh:message | Warning | A shape should not have more than one value for sh:message with the same language tag. |
| name-property | sh:property | Warning | 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. |
| description-property | sh:property | Warning | 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. |
| order | sh:order | Warning | 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. |
SDG Data Model rules
| Rule ID | Target | Severity | Description |
|---|---|---|---|
| text-language | sh:name / sh:description | Warning | Both sh:name and sh:description may have multiple values, but should only have one value per language tag. |
| message | sh:message | Warning | 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. |
| message-language | sh:message | Warning | A shape should not have more than one value for sh:message with the same language tag. |
| name-property | sh:property | Warning | 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. |
| order | sh:order | Warning | 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. |