The SKOS Shape should comply with all constraints from the SKOS-Reference

[sroertgen]

The constraints defined in the SKOS-Reference, should all be checked with the SKOS shape.

[tombaker]

@sroertgen By "constraints", do you specifically mean the integrity conditions defined in the spec, or do you want to check SKOS graphs for conformance with other quality criteria, as per Skosify or qSKOS?

[sroertgen]

Hello @tombaker ,

Yes, I thought about checking the integrity conditions in the shape and throwing an error if the data does not conform to the shape.

Quality checks are also interesting. Is there a published list of quality criteria we can reuse? I could also think about translating them into a shape. But these would only throw "warning" or "info" messages.

[nichtich]

In any case the documentation should make clear which explicit integrity conditions and which other rules are enforced. A query for regex S[0-9]+ in sh:description sh:message might help to automatically create a list.

I found the rules are only mentioned via some sh:description but they should better be in sh:message of each shape, so the query would be like

prefix sh: <http://www.w3.org/ns/shacl#>

SELECT ?shape ?msg {
  ?shape sh:message ?msg
  filter(regex(?msg,"S[0-9]+")) 
}

P.S: I've created a pull request to implement this (without filter by now)

[nichtich]

Integrity constrains from https://www.w3.org/TR/skos-reference/

• [x] S9 | skos:ConceptScheme is disjoint with skos:Concept.
• [x] S13 | skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties.
• [x] S14 | A resource has no more than one value of skos:prefLabel per language tag.
• [x] S27 | skos:related is disjoint with the property skos:broaderTransitive (by my reading of this constraint differs from the implementation in Shacl!).
• [ ] S37 | skos:Collection is disjoint with each of skos:Concept and skos:ConceptScheme.
• [ ] S46 | skos:exactMatch is disjoint with each of the properties skos:broadMatch and skos:relatedMatch.

[sroertgen]

Hey @nichtich,

thank you for providing feedback!

So for better documenting constraints inside the shape I began working on adding property groups, e.g. https://github.com/skohub-io/shapes/blob/3e93b208993a8c86c94499aab59a17c0023d8d46/skos.shacl.ttl#L27-L50

These groups can then be assigned to sh:property, e.g.

https://github.com/skohub-io/shapes/blob/3e93b208993a8c86c94499aab59a17c0023d8d46/skos.shacl.ttl#L74-L81

What do you think of this approach?

But +1 for extracting this info later with a query.

[sroertgen]

In any case the documentation should make clear which explicit integrity conditions and which other rules are enforced. A query for regex S[0-9]+ in sh:description sh:message might help to automatically create a list.

I found the rules are only mentioned via some sh:description but they should better be in sh:message of each shape, so the query would be like

prefix sh: <http://www.w3.org/ns/shacl#>

SELECT ?shape ?msg {
  ?shape sh:message ?msg
  filter(regex(?msg,"S[0-9]+")) 
}

P.S: I've created a pull request to implement this (without filter by now)

And I fully agree on using sh:message

[nichtich]

I'm not sure about your approach with PropertyGroup. Seems to make sense for other use cases. In particular the group is lost in validation reports (except if sh:sourceShape links to a shape that links to a group but this looks a bit complex).

[sroertgen]

Done with 89a1e9763cc815ae2d9ea3b3ffb4677700de0f8d