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

Hi!

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

I certainly agree with you that just keep adding features to SHACL 
without resolving some of the (more important?) fundamental issues first 
might not be the best idea. However, information on how to deal with 
rdf:Lists or even rdfs:Containers (admittedly, I doubt the latter is 
actually being used very often) as property values needs to be provided 
since some property constraints seem to not work as intended when used 
together with, e.g., rdf:Lists.

For example using your API, validation for ex:InvalidExample fails since 
both ex:list definitions are counted separately (i.e., 2 instead of 1) 
hence, sh:maxCount 1 is validated. Other property constraints like 
sh:equals for comparing two lists will also fail in any case.

ex:InvalidExample
   a ex:Example ;
   ex:list (1 2 3) ;
   ex:list (1 2 3) ;
   ex:object ex:AnotherExample ;
   ex:object ex:AnotherExample ;
   ex:literal 1 ;
   ex:literal 1 ;
.

ex:ExampleShape
   a sh:Shape ;
   sh:nodeClass ex:Example ;
     sh:property [
       sh:maxCount 1 ;
       sh:minCount 1 ;
       sh:predicate ex:list ;
     ] ;
     sh:property [
       sh:maxCount 1 ;
       sh:minCount 1 ;
       sh:predicate ex:literal ;
     ] ;
     sh:property [
       sh:maxCount 1 ;
       sh:minCount 1 ;
       sh:predicate ex:object ;
     ] .

Users could also be inclined to use, e.g., sh:in for defining the super 
"set" of values an rdf:List/rdfs:Container should be allowed to contain 
(which will obviously not work as of now).

> With this I propose closing this ISSUE, leaving it to extension 
> libraries and future WGs
> that may pick up the most commonly used extensions.

Besides the fact that at least a few people have expressed the need of 
such a feature [1,UC26,UC42], we definitely have to provide a disclaimer 
somewhere in the spec. defining on how rdf:Lists/rdfs:Containers should 
be handled by SHACL implementations.

regards,
simon

[1] 
http://w3c.github.io/data-shapes/data-shapes-ucr/#r6.12-expressivity-checking-for-well-formed-rdf-lists
[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

---
DDipl.-Ing. Simon Steyskal
Institute for Information Business, WU Vienna

www: http://www.steyskal.info/  twitter: @simonsteys

Am 2016-01-27 08:37, schrieb Holger Knublauch:
> 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 Friday, 29 January 2016 06:58:32 UTC