Re: limiting ill-formed nodes in SHACL

Yes, the working group is chartered for a finite period of time. Unlike in the past when significant extensions were granted  as long as the WG was making progress, the extension process now is much more onerous and, in general, discouraged in favor of getting the first release of the recommendation out and in use quickly. This is what W3C members want and it makes sense. 

A WG, no matter how much it tries, can’t address or even envision all potential issues. The importance of many issues can’t be judged correctly until the standard is in wide real life use.   And the “best way” to address them can’t necessarily be judged either, until there is enough real life experience. So, there is a move towards a more pragmatic approach that relies on future iterations driven by the input that will come from organizations as they actually use the standard to solve problems important to them.

With this, I think “nice to have” and even some “must have” (unless they come from multiple parties and are strongly supported by real life use cases) should be documented as potential future work items.

Irene


> On Feb 27, 2017, at 1:53 AM, Holger Knublauch <holger@topquadrant.com> wrote:
> 
> 
> 
> On 27/02/2017 6:17, Peter F. Patel-Schneider wrote:
>> It appears that SHACL defines ill-formed nodes too broadly.
>> 
>> Currently the graph
>> 
>> ex:s1 rdf:type sh:NodeShape ;
>>  sh:targetClass ex:C1 ;
>>  sh:class ex:C2 .
>> 
>> ex:s2 sh:class 5 .
>> 
>> appears to contain an ill-formed node because an object of a triple with
>> property sh:class is not an IRI.  Validation results when using this graph
>> thus appear to be undefined.
>> 
>> It would be better to limit these requirements to situations where the
>> subject of the triple is a shape.
> 
> This comment appears to be very similar to your comment 18), see
> 
>    https://www.w3.org/2014/data-shapes/wiki/ISSUE-234 <https://www.w3.org/2014/data-shapes/wiki/ISSUE-234>
> 
>> 
>> Currently the graph
>> 
>> ex:s1 rdf:type sh:NodeShape ;
>>  sh:targetClass ex:C1 ;
>>  sh:pattern "(" .
>> 
>> contains an ill-formed node because the value of ex:s1 for sh:pattern is not
>> a valid pattern argument for the SPARQL REGEX function.  Validation results
>> when using this graph are thus undefined.
>> 
>> It would be better to just require that the values of shapes for sh:pattern
>> be strings and handle the possible errors produced like SPARQL errors are
>> handled elsewhere in SHACL.
> 
> This comment appears to be very similar to your comment 45), see
> 
>    https://www.w3.org/2014/data-shapes/wiki/ISSUE-234 <https://www.w3.org/2014/data-shapes/wiki/ISSUE-234>
> 
>> 
>> 
>> Currently the graph
>> 
>> ex:s1 rdf:type sh:NodeShape ;
>>  sh:targetClass ex:C1 ;
>>  sh:class ex:C2 .
>> 
>> ex:s2 sh:node ex:s3 .
>> 
>> ex:s3 sh:path ex:p1 .
>> 
>> contains an ill-formed node because ex:s3 is a node shape and it has a value
>> for sh:path.  Validation results when using this graph are thus undefined.
>> 
>> It would be better if objects of triples with properties like sh:node only
>> made their objects shapes if the subject of the triple was already a shape.
>> A suitable inductive definition of shapes that does the right thing is easy
>> to produce.
> 
> Can you suggest the exact incremental wording to the current definition of "shapes" that would cover this scenario? We can then discuss this in the WG.
> 
> In my personal opinion, at the current state of the process (with only 4 weeks before CR) I am very hesitant towards changes in the "nice to have" category, esp if they may cause follow-up issues or longish email discussions. With your own W3C experience I assume you are aware of these process limitations, regardless of how much longer we could in theory continue with these design questions.
> 
> Thanks,
> Holger
> 
> 
>> 
>> 
>> Limiting ill-formed nodes expands the number of graphs that have defined
>> behaviour in SHACL without appreciably increasing the complexity of the
>> language.
>> 
>> 
>> Peter F. Patel-Schneider
>> Nuance Communications