- 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