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

What Irene says. - kc

On 10/17/16 12:06 PM, Irene Polikoff wrote:
> 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 <
> <>>
> Date: Monday, October 17, 2016 at 1:44 AM
> To: < <>>
> Subject: Re: shapes-ISSUE-188 (define validation): "Validation" needs to
> be defined
> Resent-From: <
> <>>
> 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:
>   * 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
>> 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:

Karen Coyle
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Monday, 17 October 2016 15:18:44 UTC