- From: Holger Knublauch <holger@topquadrant.com>
- Date: Thu, 15 Sep 2016 08:47:27 +1000
- To: public-rdf-shapes@w3.org
- Message-ID: <6eba46f6-3824-cfa7-f4b7-6d621033e801@topquadrant.com>
To me this doesn't look like a SHACL-specific issue. Having display
aliases for nodes can be solved generically. Even if the drop down menu
would be coded against SHACL, you would want the same labels to be
displayed in all other places of your application, too. A generic
"display label" data structure as you outline with rdf:value below looks
OK to me, but why would you expect this to be part of SHACL only?
Holger
On 14/09/2016 21:59, Miika Alonen wrote:
> There's still some confusion about the use case. Let me clarify a bit.
>
> In our use we have a form where we want to select a color for the
> Rainbow Pony. Instead of showing a drop down menu with HTML color
> codes we want to show the label of the available colors.
>
> For some reason we want the data to be simple, for example:
> ex:MyRainbowPony a ex:RainbowPony .
> ex:MyRainbowPony ex:htmlColor '#FDD7E4' .
> In order to generate the form and validate the data we have defined
> SHACL shape:
> ex:InExampleShape
> a sh:Shape ;
> sh:targetNode ex:RainbowPony ;
> sh:property [
> sh:predicate ex:htmlColor ;
> sh:in ('#FDD7E4 <http://www.computerhope.com/cgi-bin/htmlcolor.pl?c=FDD7E4>''#800080 <http://www.computerhope.com/cgi-bin/htmlcolor.pl?c=800080>') ;
> ] .
> But this shape doesnt define the labels for the colours - so we cannot
> generate the dropdown menu from this shape. Only way to do this
> currently is to add some additional metadata to SHACL graph, for example:
>
> _:x1 rdf:value '#FDD7E4' .
> _:x1 rdfs:label 'Pig Pink'@en .
> _:x1 rdfs:label 'Vaaleanpunainen'@fi .
>
> This additional metadata would be used by the form generator to show
> the color labels in the dropdown menu. Alternatively we could extend
> the SHACL property constraint:
>
> ex:InExampleShape
> a sh:Shape ;
> sh:targetNode ex:RainbowPony ;
> sh:property [
> sh:predicate ex:htmlColor ;
> sh:in ('#FDD7E4 <http://www.computerhope.com/cgi-bin/htmlcolor.pl?c=FDD7E4>''#800080 <http://www.computerhope.com/cgi-bin/htmlcolor.pl?c=800080>') ;
> custom:enumLabel('Pink' 'Purple') ;
> ] .
>
> - 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, 14 September, 2016 12:38:36
> *Subject: *Re: Labels for literals in sh:in enumeration
>
> I am sorry, I got confused with the term label
> sh:in checks the validating value, not values one hop away with e.g.
> rdfs:label
>
> assuming your example
>
> _:x1 rdf:value '#FDD7E4' .
> _:x1 rdfs:label 'Pig Pink'@en .
> _:x1 rdfs:label 'Vaaleanpunainen'@fi .
>
> a shape that would work for you would be something like
>
> [] a sh:Shape ;
> sh:nodeKind sh:BlankNode ;
> sh:property [
> sh:predicate rdfs:label ;
> sh:in ( 'Pig Pink'@en 'Vaaleanpunainen'@fi)
> ]
>
> if you want to constrain the values of a deeper level you can use a
> property path (sh:path) or nest a subshape with sh:shape
>
> On Wed, Sep 14, 2016 at 11:06 AM, Miika Alonen <miika.alonen@csc.fi
> <mailto:miika.alonen@csc.fi>> wrote:
>
> Hi,
>
> Listing the values and labels to the same list, for example:
>
> sh:in ('#FDD7E4
> <http://www.computerhope.com/cgi-bin/htmlcolor.pl?c=FDD7E4>' 'Pig
> Pink' '#800080
> <http://www.computerhope.com/cgi-bin/htmlcolor.pl?c=800080>'
> 'Purple');
>
> would mean that 'Pig Pink' and 'Purple' are also a valid values
> for the predicate. This would be very odd and not very explicit if
> you dont know what to expect from the enumerations.
>
> All i can think of (without adding something to the SHACL syntax)
> would be to include labels to separate resources describing the
> literals:
>
> _:x1 rdf:value '#FDD7E4' .
> _:x1 rdfs:label 'Pig Pink'@en .
> _:x1 rdfs:label 'Vaaleanpunainen'@fi .
>
> ... but then the labels would be kind of off the specification
> that wouldnt support generic form generation.
>
> - Miika
>
> ------------------------------------------------------------------------
> *From: *"Dimitris Kontokostas"
> <kontokostas@informatik.uni-leipzig.de
> <mailto:kontokostas@informatik.uni-leipzig.de>>
> *To: *"Miika Alonen" <miika.alonen@csc.fi
> <mailto:miika.alonen@csc.fi>>
> *Cc: *"public-rdf-sha." <public-rdf-shapes@w3.org
> <mailto:public-rdf-shapes@w3.org>>
> *Sent: *Wednesday, 14 September, 2016 10:40:56
> *Subject: *Re: Labels for literals in sh:in enumeration
>
> Hello Miika,
> you can have it like
> sh:in ( 1 333 true "string" "lang string"@en
> "2"^^xsd:unsignedInteger ex:A )
> and SHACL will check if your value is in this list
>
> if your rdf nodes in the sh:in list are valid, i.e. there is no
> "a"^^xsd:int SHACL engnes (the ones based on SPARQL at least) will
> work correctly
>
> On Wed, Sep 14, 2016 at 9:01 AM, Miika Alonen <miika.alonen@csc.fi
> <mailto:miika.alonen@csc.fi>> wrote:
>
> Hi all,
>
> What would be the best way to include labels to sh:in for
> literals? Using literals instead of resources is reasonable in
> some use cases.
>
> For example you might want to use literals for HTML colors and
> labels for the drop down menu:
>
> ex:InExampleShape
> a sh:Shape ;
> sh:targetNode ex:RainbowPony ;
> sh:property [
> sh:predicate ex:htmlColor ;
> sh:in ('#FDD7E4
> <http://www.computerhope.com/cgi-bin/htmlcolor.pl?c=FDD7E4>''#800080
> <http://www.computerhope.com/cgi-bin/htmlcolor.pl?c=800080>') ;
> ] .
>
> instead of:
>
> sh:in ( ex:Pink ex:Purple ) ...
> ... and something like ... ex:Pink rdf:value '#FDD7E4
> <http://www.computerhope.com/cgi-bin/htmlcolor.pl?c=FDD7E4>' .
>
> There is of course many ways to model this but in case you
> need to use literals for simplicity the could be something
> like enumNames that is proposed to JSON Schema v5:
> https://github.com/json-schema/json-schema/wiki/enumNames-(v5-proposal)
> <https://github.com/json-schema/json-schema/wiki/enumNames-%28v5-proposal%29>
>
> Best Regards,
> Miika Alonen
>
> CSC - IT Center for Science
> miika.alonen@csc.fi <mailto:miika.alonen@csc.fi>
>
>
>
>
> --
> 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
>
>
>
>
>
> --
> 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 Wednesday, 14 September 2016 22:47:59 UTC