shapes-ISSUE-179 (label annotations): Should SHACL include a mechanism to specify display labels? [SHACL Spec]

shapes-ISSUE-179 (label annotations): Should SHACL include a mechanism to specify display labels? [SHACL Spec]

Raised by: Holger Knublauch
On product: SHACL Spec

See the email thread started by Miika Alonen:

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:

    a sh:Shape ;
    sh:targetClass ex:Person ;
    sh:labelFunction 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.

Received on Thursday, 22 September 2016 23:21:31 UTC