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