Consider allowing sh:name and sh:description on NodeShapes

[danielbeeke]

Currently the SHACL spec states that sh:name and sh:description may be used on Property shapes. It does not state this for NodeShapes.

This is the quote:

If present, tools SHOULD prefer those locally specified labels over globally specified labels at the rdf:Property itself.

(link)

Could it be considered adding to the spec that sh:name and sh:description can also be used on NodeShapes?

The use case is that a system containing NodeShapes might want to display the shapes with a local name and description.

[HolgerKnublauch]

The role of node shapes is similar to classes, and the implicit target pattern aligns node shapes with classes. We have several customers that wanted to use skos:prefLabel and skos:definition instead of rdfs:label and rdfs:comment for their classes. If present, those should be preferred over the rdfs defaults. Given that these (skos:) are already established properties, there is the argument that it's not the business of SHACL to generate yet another pair of properties for that purpose.

With property shapes the situation was different because the intent was to use these names/descriptions for the use of the property (not the property shape).

[HolgerKnublauch]

@danielbeeke as the WG has now started and we are trying to address raised tickets, does my response sound OK to you and can the issue be closed?

[danielbeeke]

Thanks for the response, it sounds okay. However I do still have a question about it.

How about patterns other than the implicit target pattern? Maybe direct sh:class usage.

Someone could have multiple shapes for one class, maybe one to fill the form, another one to validate and others to view a subset of the resource. I think having a label on the shape itself is helpful in that particular use case.

In that regard I think the use case is similar to the usage of sh:name on the property shape. What do you think?

[HolgerKnublauch]

Yes, absolutely having a label and comment on a node shape is very useful. We just use rdfs:label and rdfs:comment for that, and I see no need for sh:name or sh:description instead.

[TallTed]

We just use rdfs:label and rdfs:comment for that, and I see no need for sh:name or sh:description instead.

Flexibility is a good thing. We should permit use of such properties anywhere a user wants to use them. I can imagine scenarios where all of rdf:label, rdfs:comment, skos:prefLabel, sh:name, sh:description, skos:altLabel, skos:hiddenLabel, and more might be used for different local reasons and purposes.

Given that we have defined the sh:name and sh:description properties, they should be usable throughout SHACL, for any identifiable resource, including node shapes.

[HolgerKnublauch]

@TallTed why? Flexibility means a lot of overhead for tooling. How to distinguish/support all these cases. What to pick if multiple such values are present. It's already a pain to have rdfs:label and skos:prefLabel, for example. I wouldn't want to make it worse unless there is a strong reason.

[TallTed]

Priority of constituencies.

User over all.

I don't know why it's "a pain to have rdfs:label and skos:prefLabel", nor how or why you would prevent use of any existing similar properties, never mind why your tools would apparently choke on encountering any new similar properties.

RDF lets anyone say anything about anything. SHACL should let anyone say anything about any shape constraints that they feel is relevant to their definitions, using whatever properties they are familiar with for doing so. That includes all the various and sundry labeling and describing properties available to them, now and ever.

The tooling doesn't necessarily have to offer all those predicates, via menu or otherwise, but it should not prevent manual entry by the user, nor choke once they do so.

[HolgerKnublauch]

Hi Ted, as you say anyone can add any triple to any subject unless that is forbidden or discouraged somewhere. There is nothing in the SHACL spec that forbids or discourages the use of sh:name and sh:description outside of property shapes except that their rdfs:domain is sh:PropertyShape. We could remove these domain statements and be done here. I don't mind. But that's the most I would want to support. The spec should not actively encourage that use nor contain examples that do this.

Here is some background why having too many property options is a pain. This is the dialog for creating node shapes in TopBraid:

You can see the user is prompted to enter a label and a description, which currently map to rdfs:label and rdfs:comment. If we would allow sh:name, optionally, how would users decide which property to use?

Then, for existing node shapes, the form also needs to arrange input widgets in a user-friendly way:

Again, a layout that would have to support multiple properties here is a pain.

Now, labels also need to be queried frequently, for example to display list or tree widgets such as this

That algorithm just gets slower if we have to query more properties. Currently we do skos:prefLabel then rdfs:label, but I guess here we would also need to check for sh:name.

Finally, when ontologies use implicit class targets, the class and node shape are the same resource. Traditionally, classes use rdfs:label (or sometimes skos:prefLabel), so we would end up with a situation where some node shapes (that are also classes) already have rdfs:labels, but other pure node shapes would use sh:name. That doesn't sound sensible to me.

TopBraid offers some control over which property to use, because all forms are soft-coded based on node shapes. So, if users want to use skos:prefLabel instead of rdfs:label, they can sh:deactivate the default property shape for rdfs:label and then add their own property shape for prefLabel to the shape that provides the layout for node shapes. However, as those form definitions are global, it means that the form will no longer display rdfs:labels for any (existing) node shape that uses rdfs:label.

In short, it's just complete chaos and there need to be really strong reasons to allow or encourage these scenarios.

I hope this gave you some more background.

[tpluscode]

Hi Ted, as you say anyone can add any triple to any subject unless that is forbidden or discouraged somewhere

The rdfs:domain of sh:name and sh:description is sh:PropertyShape. To me that counts as discouraging ;)

[TallTed]

It might be better to change from using rdfs:domain and/or rdfs:range, which are explicit and complete limiters, to schema:domainIncludes and/or schema:rangeIncludes, which are guides and allow for values other than those provided in our output documents, for at least some predicate definitions.

Possibly the way to provide for such is to tell people that they can change rdfs:domain and/or rdfs:range values to suit their deployment/use-case for specific use, and that such changes SHOULD NOT propagate beyond their environments UNLESS they include blatant flags about their difference from the "out of the box" definitions.

[HolgerKnublauch]

I think the original question here has been addressed and the ticket should be closed so that we can make some progress.

Please reopen if you disagree.