Re: shapes-ISSUE-119 (rdf:Lists): Defining constraints on (values of) rdf:Lists [SHACL - Core]

I had implemented something similar to your proposed sh:listShape, but 
called it memberShape. I have put this into an extension library (called 
dash) which will be my place for other, similarly general features for 
now. Definition below. Similar additions could include listMinLength, 
listMaxLength.

As much as I acknowledge that people will want to do this, I do wonder 
whether we are overstepping the point of saturation here. We cannot keep 
adding all kinds of features. At some stage we need to say enough is 
enough and leave such things to the extension mechanism (which can 
perfectly handle this already). We will not be able to cover all 
requirements. We need to edit, test and maintain all this, and there is 
already a lack of resources noticeable on what we have:

- metamodel discussion
- recursion
- partitioning / QCRs
- general editing / consistency of terminology
- test cases
- ...

The resolution below was only to accept the requirement, but that 
doesn't mean we have to implement a solution. With this I propose 
closing this ISSUE, leaving it to extension libraries and future WGs 
that may pick up the most commonly used extensions.

Regards,
Holger


dash:MemberShapePropertyConstraint
   rdf:type sh:ConstraintTemplate ;
   rdfs:comment "Can be used to specify constraints on the members of a 
given list, assuming that the given sh:property has rdf:Lists as values. 
A violation is reported for each member of the list that does not comply 
with the constraints specified by the given shape."^^xsd:string ;
   rdfs:label "Member shape property constraint"^^xsd:string ;
   rdfs:subClassOf sh:AbstractPropertyConstraint ;
   sh:argument [
       sh:description "The shape that the list members must 
have."^^xsd:string ;
       sh:name "member shape"^^xsd:string ;
       sh:class sh:Shape ;
       sh:optionalWhenInherited "true"^^xsd:boolean ;
       sh:predicate dash:memberShape ;
     ] ;
   sh:message "List member {?member} does not have the specified member 
shape."^^xsd:string ;
   sh:sparql """
         SELECT $this ($this AS ?subject) $predicate ?object ?failure 
?member
         WHERE {
             $this $predicate ?object .
             ?object rdf:rest*/rdf:first ?member .
             BIND (sh:hasShape(?member, $memberShape, $shapesGraph, 
false) AS ?hasShape) .
             BIND (!bound(?hasShape) AS ?failure) .
             FILTER (?failure || !?hasShape) .
         }
""" ;
.

On 27/01/2016 5:11 PM, RDF Data Shapes Working Group Issue Tracker wrote:
> shapes-ISSUE-119 (rdf:Lists): Defining constraints on (values of) rdf:Lists [SHACL - Core]
>
> http://www.w3.org/2014/data-shapes/track/issues/119
>
> Raised by: Simon Steyskal
> On product: SHACL - Core
>
> While working through the list of possible open use cases/requirements Karen sent us, I noticed that we haven't tackled the (special?) treatment of rdf:Lists yet (as we agreed on to do so in resolution of ISSUE-46 [1] which says: "RESOLUTION: Close ISSUE-46 by adding requirements 2.6.12 and 2.6.13 [2] as proposed by Richard in [3]").
>
> One approach for accomodating [2] could be to specify that whenever certain types of property constraints are defined for a property which has an rdf:List as its value, those constraints are actually applied to all members of that list rather than on the list itself:
>
> -----------------------------------
> Example:
> -----------------------------------
> ex:ExampleShape a sh:Shape ;
>    sh:scopeClass ex:ExampleClass ;
>    sh:property [
>      sh:datatype xsd:integer ;
>      sh:predicate ex:list ;
>    ] .
>
> ex:ValidExample a ex:ExampleClass ;
>    ex:list (1 2 3) .
>
> ex:InvalidExample a ex:ExampleClass ;
>    ex:list (1 "aa" 3) .
> -----------------------------------
>
> However, certain types of property constraints should still only be applied to the actual rdf:List itself:
>
> -----------------------------------
> Example:
> -----------------------------------
> ex:ExampleShape a sh:Shape ;
>    sh:scopeClass ex:ExampleClass ;
>    sh:property [
>      sh:minCount 2 ;
>      sh:maxCount 2 ;
>      sh:predicate ex:list ;
>    ] .
>
> ex:ValidExample a ex:ExampleClass ;
>    ex:list (1 2 3) ;
>    ex:list (1 3 5) .
>
> ex:InvalidExample a ex:ExampleClass ;
>    ex:list (1 2 3) .
> -----------------------------------
>
> To avoid potential conflicts if someone wants to specify that, e.g., the value of a certain property must be an rdf:List AND that all values of that list must be of type ex:Example, we could introduce a concept similar to sh:valueShape called sh:listShape:
>
> -----------------------------------
> Example:
> -----------------------------------
> ex:ExampleShape a sh:Shape ;
>    sh:scopeClass ex:ExampleClass ;
>    sh:property [
>      sh:class rdf:List ;
>      sh:listShape [
>        a sh:Shape ;
>        sh:constraint [
>          sh:class ex:Dog
>        ]
>      ]
>      sh:predicate ex:list ;
>    ] .
>
> ex:ValidExample a ex:ExampleClass ;
>    ex:list (ex:Lassie ex:Beethoven) .
>
> ex:InvalidExample a ex:ExampleClass ;
>    ex:list (ex:Lassie ex:Flipper) .
>    
> ex:Lassie a ex:Dog .
> ex:Beethoven a ex:Dog .
> ex:Flipper a ex:Dolphin .
> -----------------------------------
>   
> However, if we want to allow treating each member of an rdf:List differently, we have to come up with some other ideas such as introducing another constraint type alongside sh:PropertyConstraint, sh:NodeConstraint, ... called, e.g., sh:ListConstraint.
>
> best regards,
> simon
>
>
> [1] https://www.w3.org/2014/data-shapes/track/issues/46
> [2] http://w3c.github.io/data-shapes/data-shapes-ucr/#r6.12-expressivity-checking-for-well-formed-rdf-lists
> [3] https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015May/0017.html
> [UC26] http://w3c.github.io/data-shapes/data-shapes-ucr/#uc26-rdf-lists-and-ordered-data
> [UC42] http://w3c.github.io/data-shapes/data-shapes-ucr/#uc42-constraining-rdf-graphs-to-provide-better-mapping-to-json
>
>
>
>

Received on Wednesday, 27 January 2016 07:37:47 UTC