W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > September 2016

Re: Labels for literals in sh:in enumeration

From: Holger Knublauch <holger@topquadrant.com>
Date: Fri, 23 Sep 2016 09:23:38 +1000
To: public-rdf-shapes@w3.org
Message-ID: <cd1edfbf-19ac-4fba-e37f-79e8b9de06e4@topquadrant.com>
I have raised a formal issue for the WG to evaluate this topic:

     https://www.w3.org/2014/data-shapes/track/issues/179

While this doesn't mean that SHACL will include such a feature, it's at 
least on the agenda.

Thanks for your input,
Holger


On 22/09/2016 16:14, Miika Alonen wrote:
> 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
>
>
>
>     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 23:24:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:44 UTC