Re: comments on SHACL 3 March editors draft

This is getting closer to a definition of how shapes work.

However, this reads as if scopes are applied all the time.  My understanding
is that instead they are only used at top level.

I think that the following wording is close to what is needed:

A node validates against a shape iff either it does not validate against some
filter of the shape or none of the constraints in the shape produce a
validation result with severity sh:Violation for the node.

A graph validates against a shape iff each node that is in any of the scopes
of the shape validates against the shape.

The wording of several other parts of the document will need to be adjusted,
but there are places that need to be adjusted anyway, including the beginning
of 2.2.

peter

PS:  It might be a good idea to liberalize the treatment of severity so that
shapes with low severity levels consider validation reports of the same
severity or worse as failures.  This means that a shape with severity level
sh:Info could use other shapes with the same severity level as sub-shapes.


On 03/15/2016 02:52 PM, Dimitris Kontokostas wrote:
> Regarding filter shapes.
> Another attempt is to provide the following definition in section 2:
> 
> A node can either conform or not conform to a shape. A node conforms to a
> shape when for every scope, filter and constraint in a shape
>  - the node is in scope, conforms to the filter shapes and satisfy the constraint
>  - the node is in scope but does not satisfy the filter shapes or
>  - the node is not in scope.
> 
> this does not impose any order even for scopes but maybe I miss something or
> needs some refinement (help welcome).
> 
> Regarding the remaining "first..then" in the spec.
> I didn't put any effort in section 2.2 yet but if they are spread even outside
> of 2.2 we should better create an issue to keep track of this (for filter shapes)
> 
> Regarding the  "IF ... THEN" for filter shapes again, iirc they were suggested
> by Arthur and we had a resolution on them for issue-49.
> 
> if there are other unnecessary ordering constructs we'd better create separate
> issues, this thread is getting too big
> 
> 
> On Tue, Mar 15, 2016 at 8:11 PM, Peter F. Patel-Schneider
> <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
> 
>     I don't think that this solves the problem.
> 
>     Spread around the document is wording like "first... then" or other ordering
>     constructs.  It may be that these ordering constructs change the result or it
>     may be that all they do is specify a particular sequence of execution.  The
>     problem with leaving them in without closely examining them is that it is very
>     hard to know which is which.  Instead of a statement saying that order only
>     matters when some little bit of the document has something where it does
>     matter, the document should be written in a way that order doesn't matter
>     unless it the ordering is necessary.
> 
>     If the specification for SHACL was pure SPARQL then this would not matter so
>     much, but the specification for SHACL includes non-SPARQL stuff and some of
>     this non-SPARQL stuff looks very procedural.  Thus a lot of care needs to be
>     taken to ensure that no little thing deep down in the specification is some
>     place where order changes the results.
> 
>     peter
> 
>     PS:  I'm not sure which figure is in play here.  If it is the UML-like figure
>     then I don't see that it has any utility and it should go.
> 
> 
>     On 03/15/2016 10:36 AM, Dimitris Kontokostas wrote:
>     > Peter, can you check if this commit overcomes the ordering issue?
>     > https://github.com/w3c/data-shapes/commit/9edef4c82a7f6480d0c45e3e34656c7f93f1dfa5
>     >
>     > Would you prefer to delete the figure completely? It that case I would delete
>     > that last two lines of the commit too
>     >
>     >
>     > On Mon, Mar 7, 2016 at 6:32 PM, Peter F. Patel-Schneider
>     > <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>
>     <mailto:pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>>> wrote:
>     >
>     >     On 03/06/2016 08:46 PM, Holger Knublauch wrote:
>     >     [...]
>     >
>     >     > On 7/03/2016 6:59, Peter F. Patel-Schneider wrote:
>     >
>     >     [...]
>     >
>     >     .2 Filters
>     >
>     >     >> A SHACL processor might not begin by validating filters.  It might instead
>     >     >> look at all in-scope nodes and only later remove those that don't pass the
>     >     >> filters.  The document makes this illegal but it might be useful if the
>     >     >> filter shape is expensive to compute and few violations are expected.
>     >     >
>     >     > I believe this is already covered by stating that SHACL engines can produce
>     >     > additional validation results, see discussion above.
>     >
>     >     This is not about validation results.  It is about order of execution.  The
>     >     document states:
>     >
>     >     When a SHACL processor validates a focus node against a shape, it begins by
>     >     validating any filters associated with the shape via sh:filterShape.
>     >
>     >     This is too procedural.
>     >
>     >     peter
>     >
>     >
>     >
>     >
>     >
>     > --
>     > Dimitris Kontokostas
>     > Department of Computer Science, University of Leipzig & DBpedia Association
>     > Projects: http://dbpedia.org, http://rdfunit.aksw.org,
>     > http://http://aligned-project.eu <http://aligned-project.eu/>
>     > Homepage:http://aksw.org/DimitrisKontokostas
>     > Research Group: AKSW/KILT http://aksw.org/Groups/KILT
>     >
> 
> 
> 
> 
> -- 
> Dimitris Kontokostas
> Department of Computer Science, University of Leipzig & DBpedia Association
> Projects: http://dbpedia.org, http://rdfunit.aksw.org,
> http://http://aligned-project.eu <http://aligned-project.eu/>
> Homepage:http://aksw.org/DimitrisKontokostas
> Research Group: AKSW/KILT http://aksw.org/Groups/KILT
>

Received on Thursday, 17 March 2016 16:04:59 UTC