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

From: Holger Knublauch <holger@topquadrant.com>
Date: Thu, 22 Sep 2016 10:35:04 +1000
To: public-rdf-shapes@w3.org
Message-ID: <9cd9b762-8474-569b-ffad-a2906f1aea8c@topquadrant.com>
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


>
> 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
>
>     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' .
>
>
> 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 
> <mailto:miika.alonen@csc.fi>> 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
>
>
>
>
> -- 
> 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
>
>
Received on Thursday, 22 September 2016 00:35:41 UTC