Re: Labels for literals in sh:in enumeration from Miika Alonen on 2016-09-22 (public-rdf-shapes@w3.org from September 2016)

From: Miika Alonen <miika.alonen@csc.fi>
Date: Thu, 22 Sep 2016 09:14:53 +0300 (EEST)
To: Holger Knublauch <holger@topquadrant.com>
Cc: public-rdf-shapes@w3.org
Message-ID: <1535356808.4419600.1474524893803.JavaMail.zimbra@csc.fi>
Hi, 

Thanks for the example. sh:SparqlFunctions will be very useful and predefined queries for getting annotations would help in more complex cases. 

Here one more example for the annotation usecase: 

<ex:FormShape> a sh:Shape ; 
sh:property [ sh:description "How can we improve our service?" ; 
sh:name "Feedback" ; 
sh:datatype xsd:string ; 
sh:order 0 ; 
sh:predicate <http://example.com/feedback> ], 
[ sh:description "Rate our service" ; 
sh:annotation ex:Poor, ex:OK, ex:Great ; 
sh:in ( 1 2 3 ) ; 
sh:name "Rating" ; 
sh:order 1 ; 
sh:predicate <http://example.com/grade> ] . 

<ex:Poor> a sh:Annotation ; 
sh:name "Poor" ; 
sh:value 1 . 

<ex:OK> a sh:Annotation ; 
sh:name "OK" ; 
sh:value 2 . 

<ex:Great> a sh:Annotation ; 
sh:name "Great" ; 
sh:value 3 . 


I was also thinking that sh:annotation could be a list (i would allow both), for example "sh:annotation (ex:Poor ex:OK ex:Great). 

If you think it as JSON-LD - which is likely format to use if you want to generate HTML forms - there is not a big difference, except annotations objects are not in order: 

{ 
"@context": { 
"ex": "http://example.org/ns#", 
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#", 
"rdfs": "http://www.w3.org/2000/01/rdf-schema#", 
"sh": "http://www.w3.org/ns/shacl#", 
"xsd": "http://www.w3.org/2001/XMLSchema#", 
"sh:in": { 
"@id": "http://www.w3.org/ns/shacl#in", 
"@container": "@list" 
} 
}, 
"@graph": [ 
{ 
"@id": "ex:FormShape", 
"@type": "sh:Shape", 
"sh:property": [ 
{ 
"@id": "_:b0", 
"sh:description": "How can we improve our service?", 
"sh:name": "Feedback", 
"sh:order": 0, 
"sh:predicate": { 
"@id": "http://example.com/feedback" 
} 
}, 
{ 
"@id": "_:b1", 
"sh:annotation": [ 
{ 
"@id": "ex:Great", 
"@type": "sh:Annotation", 
"sh:name": "Great", 
"sh:value": 3 
}, 
{ 
"@id": "ex:Poor", 
"@type": "sh:Annotation", 
"sh:name": "Poor", 
"sh:value": 1 
}, 
{ 
"@id": "ex:OK", 
"@type": "sh:Annotation", 
"sh:name": "OK", 
"sh:value": 2 
} 
], 
"sh:description": "Rate our service", 
"sh:in": [ 
1, 
2, 
3 
], 
"sh:name": "Rating", 
"sh:order": 1, 
"sh:predicate": { 
"@id": "http://example.com/grade" 
} 
} 
] 
} 
] 
} 


br, 
Miika 


From: "Holger Knublauch" <holger@topquadrant.com> 
To: public-rdf-shapes@w3.org 
Sent: Thursday, 22 September, 2016 03:35:04 
Subject: Re: Labels for literals in sh:in enumeration 



On 22/09/2016 0:35, Miika Alonen wrote: 



Hi, 

Issue was about documenting the literals defined in the SHACL graph. Here is the refined ISSUE once again: 

Desired data format: 
_:n1 ex:htmlColor '#FDD7E4' . 

ISSUE: No way to generate this from the SHACL graph. 
<select> 
<option value="#FDD7E4">Pink</option> 
<option value="#800080">Purple</option> 
</select> 

I came up with two solutions. First one is non-validating and second would require additional changes to the validation logic. I added the second option because in the first option you have to do some extra work (match literals in the list to the literals in the annotations) to find the correct annotations. 

1) Non-validating: Add sh:Annotation (or similar). 

(SHAPE GRAPH) 
a sh:Shape ; 
sh:targetNode ex:RainbowPony ; 
sh:property [ 
sh:annotation ex:MyAnnotation1, ex:MyAnnotation2 ; 
sh:predicate ex:htmlColor ; 
sh:in ('#FDD7E4' '#800080') ; 
] . 



Here is how this could look like with the sh:labelFunction proposal: 

... 
sh:property [ 
sh:labelFunction ex:getAnnotationName ; 
sh:predicate ex:htmlColor ; 
sh:in ('#FDD7E4' '#800080') ; 
] . 

ex:getAnnotationName 
a sh:SPARQLFunction ; 
sh:parameter [ 
sh:predicate ex:value ; 
] ; 
sh:select """ 
SELECT ?name 
WHERE { 
?ann sh:value ?value . 
?ann sh:name ?name . 
} """ . 

Above, sh:labelFunction applies to all value nodes, i.e. all values of the given property in the context of the shape. 

Note that having this as a function would also allow other implementations to attach their own label logic, e.g. written in JavaScript. 

Does this make sense? 

Holger 



BQ_BEGIN


ex:MyAnnotation a sh:Annotation . # could be omitted 
ex:MyAnnotation sh:value "#FDD7E4" . 
ex:MyAnnotation sh:name "Pig Pink" . 
ex:MyAnnotation sh:description "Typical color of a pig" . 

ex:MyAnnotation2 sh:value "#FDD7E4" . 
ex:MyAnnotation2 sh:name "Purple" . 
(END OF SHAPE GRAPH) 

Annotations could also be linked to resources (eg. values of sh:targetNode) using sh:value when it is practical to describe some external resources in the shape graph. 

2) Validating: Add support for "reified" literals. This would require additions to the validation logic - but this would be easier to traverse. 

(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' . 

br, 
- Miika 


From: "Dimitris Kontokostas" <kontokostas@informatik.uni-leipzig.de> 
To: "Miika Alonen" <miika.alonen@csc.fi> 
Cc: "public-rdf-sha." <public-rdf-shapes@w3.org> 
Sent: Wednesday, 21 September, 2016 15:28:34 
Subject: Re: Labels for literals in sh:in enumeration 

Hi Miika, 
we will need to make sure we are talking about validating or non-validating behavior here. 
in the example you specify it is clear that what you suggest changes the way SHACL performs validation 


BQ_BEGIN
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' . 
BQ_END


meaning that with this suggestion sh:in would behave differently when there exists an sh:value/name in the shapes graph. 
Personally I would be against such a direction but not sure what others have to say. 

If this proposal was only about labeling checkboxes / drop-down menus it would be easier to get integrated imho 
However, I am not a UI guy and cannot evaluate this proposal in depth, e.g. is only this sufficient, with which shacl constructs could these annotations be combined with (besides sh:in), etc 

Best, 
Dimitris 



On Wed, Sep 21, 2016 at 10:03 AM, Miika Alonen < miika.alonen@csc.fi > wrote: 

BQ_BEGIN



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 

BQ_END




-- 
Dimitris Kontokostas 
Department of Computer Science, University of Leipzig & DBpedia Association 
Projects: http://dbpedia.org , http://rdfunit.aksw.org , http://aligned-project.eu 
Homepage: http://aksw.org/DimitrisKontokostas 
Research Group: AKSW/KILT http://aksw.org/Groups/KILT 



BQ_END
Received on Thursday, 22 September 2016 06:15:27 UTC