Re: Labels for literals in sh:in enumeration

I mean SHACL SPARQL Functions

https://www.w3.org/TR/shacl/#functions

Imagine a function such as

ex:getFullName
     a sh:SPARQLFunction ;
     sh:parameter [
         sh:predicate ex:person ;
         sh:class ex:Person ;
     ] ;
     sh:returnType xsd:string ;
     sh:select """
         SELECT ?result
         WHERE {
             ?person ex:firstName ?firstName .
             ?person ex:lastName ?lastName .
             BIND (CONCAT(?firstName, " ", ?lastName) AS ?result) .
         }
         """ .

Or likewise a SELECT query that starts at the actual string color value 
and maps this into human-readable labels by following some properties of 
your choice.

Holger



On 22/09/2016 1:09, Miika Alonen wrote:
>
> 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
>
>
>