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> 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