Re: shapes-ISSUE-188 (define validation): "Validation" needs to be defined

I think the current definition doesn¹t define ³validation². It defines what
it means for a data graph to be valid or to validate.

The definition of the validation would need to start with  something like
what Karen proposes e.g., validation is a process that determines if a data
graph validates against a shape graph.

As for the the definition of what it means to be valid, it seems that there
are some possible holes:

Are these conditions cumulative ­ meaning all need to be true or does any
single one is enough?
What does it mean for a node to validate against a shape? The first bullets
says what it means for a focus node to validate. The second one says that
each node must validate without mentioning the word focus. May be it is a
bit picky, but I felt there was some discontinuity.


Irene 
From:  Holger Knublauch <holger@topquadrant.com>
Date:  Monday, October 17, 2016 at 1:44 AM
To:  <public-data-shapes-wg@w3.org>
Subject:  Re: shapes-ISSUE-188 (define validation): "Validation" needs to be
defined
Resent-From:  <public-data-shapes-wg@w3.org>
Resent-Date:  Mon, 17 Oct 2016 05:45:02 +0000

    
 Hi Karen,
 
 the current snapshot defines the term "validation" in the beginning of
section 3:
 

The definition for validating a data graph <#dfn-data-graph>  against a
shapes graph <#dfn-shapes-graph>  as well as a node <#dfn-node>  from the
data graph against a shape <#dfn-shape>  from the shapes graph is provided
below:
 
 
VALIDATION DEFINITION
 
 
* A focus node <#dfn-focus-node>  validates against a shape <#dfn-shape>  if
and only if either it does not validate against some filter <#dfn-filter>
of the shape or none of the constraints <#dfn-constraint>  in the shape
produce a validation result <#dfn-validation-results>  or a failure
<#dfn-failure>  for the focus node.
* A data graph <#dfn-data-graph>  validates against a shape <#dfn-shape>  if
and only if each node that is in any of the targets <#dfn-target>  of the
shape validates against the shape.
* A data graph <#dfn-data-graph>  validates against a shapes graph
<#dfn-shapes-graph>  if and only if the data graph validates against
eachshape <#dfn-shape>  in the shapes graph.
 
 
 I believe this covers the terminology, esp with the different nuances of
validation, e.g. of a focus node. It also correctly identifies failures as
another possible outcome.
 
 Your proposal merely bases validation on another undefined term "obeys the
constraints", which IMHO just shifts the problem. The ultimate definition
may require an elaborated link to the evaluation mechanisms including SPARQL
queries, but Dimitris' prose above clarifies that eventually it's about not
producing any validation results and failures.
 
 What is missing for this ISSUE?
 
 Holger
 
 
 
On 9/10/2016 12:51, RDF Data Shapes Working Group Issue Tracker wrote:
 
 
>  
> shapes-ISSUE-188 (define validation): "Validation" needs to be defined
> 
> http://www.w3.org/2014/data-shapes/track/issues/188
> 
> Raised by: Karen Coyle
> On product: 
> 
> The term validation as used in SHACL needs to be defined. (The English
> language term is ambiguous.) The XML schema has a clear defiinition [1]. Based
> on that, I suggest the following as a definition of validation in SHACL:
> 
> [Definition:]   Validation is the process of determining whether a node in the
> data graph obeys the constraints expressed in a shapes graph. The validation
> result is true when the node in the data graph obeys the constraints, and
> false when it does not.
> 
> Note that XML allows for 3 validation results: true, false, and undetermined.
> I do not know if SHACL also follows this pattern, so my true/false declaration
> above may need adjustment if that is the case. Here is what XML schema says:
> 
> Note: As just defined, validation produces not a binary result, but a ternary
> one: if the information item is ·strictly assessed·, it will be either valid
> or invalid, but if no applicable declaration is found, its validity will be
> unknown (and its [validity] property will have the value notKnown). Whether in
> a particular application notKnown should be treated in the same way as invalid
> or differently is outside the scope of this specification; sometimes one
> choice is appropriate, sometimes the other.
> 
> 
> [1] See: https://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/#key-vn
>