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

On 29/01/2016 4:58 PM, Simon Steyskal wrote:
> 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. 

That looks OK to me. Your example has two different rdf:Lists, and we 
only compare their root nodes. Even if the lists have the same contents, 
they are different RDF resources. If you wanted these rdf:lists to be 
treated differently, then why not also do this for any other blank node 
that has the same structure? I don't see how this is feasible or even 
desirable.

> Other property constraints like sh:equals for comparing two lists will 
> also fail in any case.

sh:equals also just compares property values, i.e the nodes, not the 
actual contents of the rdf:List.

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

I'd be happy with editorial changes, of course. But the issues you 
mention above (e.g. with sh:in) only tell me that getting into special 
treatment of rdf:Lists is a slippery slope that can cause all kinds of 
new issues. I would suggest to continue treating them as any other RDF 
node. The SPARQL definitions make the current behavior clear to people 
familiar with SPARQL, but maybe you are right and we should add 
additional prose to other readers.

Holger


>
> 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 Saturday, 30 January 2016 02:15:37 UTC