Re: Labels for literals in sh:in enumeration

Im not sure if i understood. Do you mean "magic properties" with some sort of standard serializations for the list members like '#FDD7E4":Pink,#800080:Purple'? 

br, 
Miika 


From: "Holger Knublauch" <holger@topquadrant.com> 
To: public-rdf-shapes@w3.org 
Sent: Wednesday, 21 September, 2016 15:48:51 
Subject: Re: Labels for literals in sh:in enumeration 

In order to link nodes with how they should be rendered, any number of approaches is possible. For example, we could add a property sh:labelFunction that points at a SPARQL function that takes a node as argument and produces a string from it. This would offer the ultimate flexibility, because in that function you could walk any connected triples, do concatenation etc. E.g. 

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

where ex:getFullName would do CONCAT(?firstName, " ", ?givenName). In general, sh:labelFunction could apply to any focus node, i.e. the defined target nodes of a shape. 

While sh:labelFunction would be generic, the SHACL namespace could potentially include a couple of standard label functions with stable URIs, e.g. for the annotation design pattern that you describe. These design patterns could then be hard-coded by engines that don't speak SPARQL. 

(This isn't particularly thought-through yet, but would this be of interest)? 

Holger 


On 21/09/2016 17:03, Miika Alonen wrote: 





Hi Holger. Thanks for the response! 

> I think the broader topic that you are touching on is "literals as > subjects". If RDF would allow literals in the subject position of a > triple then people could write > "#FF0000" rdfs:label "red" . 

I dont think that this issue is related to the "literals as subject"-topic. Desired RDF output here was: "ex:MyColor ex:htmlColor '#FF0000'.". Documenting the use of literals should be seen as separate issue. There are multiple ways of doing this with RDF - but none is documented within the SHACL scope. 

> I believe the RDF 1.1 WG had discussed this topic at length and decided > against literals as subjects. The alternative with the current RDF would > be to "reify" these colors into objects, e.g. > ex:Red > a ex:Color ; > rdfs:label "red" ; > ex:htmlColor "#FF0000" . > That would follow the standard practices in RDF. 

I agree with this "things vs. strings"-argument - but changing the existing data is not always an option. There can also be numerous variations of how the "reified" literal is documented, for example label can be expressed with rdfs:label, dcterms:title, dc:title, skos:prefLabel or whatever. Usually this means that there are too many options to create something generic - for example dynamic form. 

In RDF there are multiple ways for documenting literals, for example reification or using "things instead of strings" or creating SKOS scheme for the values. Thats just it ... too many options. 

> Even in your own solution below there is no real > connection between the Shape and the ex:MyAnnotation node, so what is > SHACL-specific here that couldn't be solved elsewhere? 
Annotation could be linked to any shape or property with an id, for example: "ex:MyAnnotation sh:shape ex:InExample ." or other way around "ex:InExample sh:annotation ex:MyAnnotation ." 

... and then queried with sparql, for example: 

SELECT ?value ?name WHERE { ex:InExample sh:property ?prop . ?prop sh:in*/rdf:rest/rdf:first ?value . ex:MyAnnotation sh:shape ex:InExample . ex:MyAnnotation sh:value ?value . ex:MyAnnotation sh:name ?name . } 

Reason why i am suggesting something like this is that it would only mean changes to the "Non-Validating Constraint Characteristics"-chapter ... meaning not too much work on tight schedule. 

Actually I would prefer solution supporting "reified" values documented in the SHACL graph for example: 

SHAPE GRAPH: 

ex:InExampleShape 
a sh:Shape ; 
sh:targetNode ex:RainbowPony ; 
sh:property [ 
sh:predicate ex:htmlColor ; 
sh:in (ex:Pink ex:Purple) ; 
] . 

ex:Pink sh:value "#FDD7E4" . 
ex:Pink sh:name "Pink" . 

... (END OF SHAPE GRAPH) 

Faulty RDF example: 

ex:MyColor ex:htmlColor '#00000' . 

Correct RDF: 

ex:MyColor ex:htmlColor '#FDD7E4' . 

I think that this would not contradict with RDF practices since it would be Literals "reified" in the shape graph... RDF data would still be simple literals. However, i understand if this is too much work at this point :) 

br, 
Miika 
--------------------------------------------------------------------------
> On 15/09/2016 17:48, Miika Alonen wrote:
> This is turning into a monolog but here's one suggestion for 
> documenting the semantics of the enumerations (sh:in values) in the 
> SHAPE graph:
>
> ex:InExampleShape
>     a sh:Shape ;
>     sh:targetNode ex:RainbowPony ;
>     sh:property [
>         sh:predicate ex:htmlColor ;
>         sh:in ('#FDD7E4' '#800080' ex:Whatever) ;
>     ] .
>
> ex:MyAnnotation a sh:Annotation .
> ex:MyAnnotation sh:value "#FDD7E4" .
> ex:MyAnnotation sh:name "Pig Pink" .
> ex:MyAnnotation sh:description "Typical color of a pig" .
>
> ex:MyAnnotation2 a sh:Annotation .
> ex:MyAnnotation2 sh:value ex:Whatever .
> ex:MyAnnotation2 dcterms:description "For some reason this annotation 
> includes additional metadata" .
> ...
>
> I really think that there should be a standard way to do this. If 
> there is no way to document literal values in sh:in-list, those values 
> will not be documented (or documented in various ways - which still is 
> a serious pitfall). Including something like this to the specification 
> should not be an issue because sh:Annotation (or whatever class name) 
> would not be processed by the validators. Annotations would be used in 
> other use cases - like general documentation or in form generation.
>
> - Miika