ISSUE-179: Should SHACL include a mechanism to specify display labels?

label annotations

Should SHACL include a mechanism to specify display labels?

State:

CLOSED

Product:

SHACL Spec

Raised by:

Holger Knublauch

Opened on:

2016-09-22

Description:

See the email thread started by Miika Alonen:

https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Sep/0004.html

Form generation is an official use case of SHACL. There is currently no way to state how a specific node should be rendered. This probably sits on the borderline of what SHACL is about, yet I believe we should take his feedback serious.

Miika suggested a specific vocabulary to link enumerated values to labels. I believe we should first solve the more general problem. I suggest to add an "annotation" property (that has no formal semantics and is not used by constraint checking) called sh:labelFunction. Its role is to point at a sh:Function (e.g. sh:SPARQLFunction) that takes a node as an argument and produces a string rendering of it. Example:

ex:PersonShape
a sh:Shape ;
sh:targetClass ex:Person ;
sh:labelFunction ex:getFullName .

ex:getFullName
a sh:SPARQLFunction ;
sh:parameter [
sh:predicate ex:person ;
sh:class ex:Person ;
] ;
sh:returnType xsd:string ;
sh:select """
SELECT ?result
WHERE {
?person ex:firstName ?firstName .
?person ex:lastName ?lastName .
BIND (CONCAT(?firstName, " ", ?lastName) AS ?result) .
}
""" .

In this example, all instances of Person would be rendered by their full name, derived from first name and last name. Other examples include functions that look up alternative strings for literals or use skos:prefLabel etc.

The functions behind sh:labelFunction could take an optional second argument for the target language, e.g. "de". The property sh:labelFunction could also be used in property constraints, to specify labels for all property values.

I believe this annotation property would go a long way to providing a standard label rendering mechanism without costing us anything. The community can then continue without us, defining their own label functions for various use cases. Some URIs for these functions will be established as de-facto standards using linked data principles.

Related Actions Items:

No related actions

Related emails:

1. Re: Process Question: How to clean up meeting minutes (from eric@w3.org on 2017-01-06)
2. Re: Process Question: How to clean up meeting minutes (from holger@topquadrant.com on 2017-01-06)
3. Re: Remaining issues with impact on the syntax (from holger@topquadrant.com on 2016-11-16)
4. Re: Remaining issues with impact on the syntax (from kcoyle@kcoyle.net on 2016-11-15)
5. Re: Remaining issues with impact on the syntax (from holger@topquadrant.com on 2016-11-15)
6. Re: Remaining issues with impact on the syntax (from kcoyle@kcoyle.net on 2016-11-14)
7. Re: Remaining issues with impact on the syntax (from holger@topquadrant.com on 2016-11-14)
8. Re: Remaining issues with impact on the syntax (from eric@w3.org on 2016-11-13)
9. Re: Remaining issues with impact on the syntax (from kcoyle@kcoyle.net on 2016-11-13)
10. Remaining issues with impact on the syntax (from holger@topquadrant.com on 2016-11-11)
11. shapes-ISSUE-179 (label annotations): Should SHACL include a mechanism to specify display labels? [SHACL Spec] (from sysbot+tracker@w3.org on 2016-09-22)

Related notes:

Display change log