Re: more sloppiness in the SHACL document

This issue does not address the problems I am pointing out nor does it
correctly describe the solution to them that I am advocating.

I am not pointing out an editorial problem.  I am instead pointing out
problems in how SHACL is defined in the SHACL document.  I am not advocating a
change to a different style of definitions.  I am instead advocating that the
SHACL document not use unclear or ill-founded definitions.

My suggestion is long not because I want to use a different style of writing.
It is long because it needs to address problems in several aspects of
validation reports.

Peter F. Patel-Schneider
Nuance Communications

On 12/05/2016 11:07 PM, Holger Knublauch wrote:
> Thanks for your input. I have raised
> 
>     https://www.w3.org/2014/data-shapes/track/issues/216
> 
> to hear what the WG thinks about this style of writing. I have no strong
> opinion either way right now.
> 
> Holger
> 
> 
> On 6/12/2016 16:56, Peter F. Patel-Schneider wrote:
>> Oops, did too much replacement in combinations and not enough checking.  Here
>> is a revised set of definitions that handles the infrequent cases where a node
>> is a top-level validation in one of the results graphs but something else in
>> another and where a node is two different property paths in different graphs.
>>
>>
>> A SHACL path is a node and an RDF graph where the node is a SHACL property
>> path in the graph
>>
>> The SHACL path of a SHACL shape in a shapes graph S is its value for sh:path
>> in S, if any, and all the triples in S needed to form the SHACL property
>> path starting at this value; otherwise the shape has no SHACL path.
>>
>> The SHACL severity of a SHACL shape in a shapes graph S is its value for
>> sh:severity, if present, otherwise sh:violation
>>
>>
>> A SHACL validation report is an RDF graph meeting the following conditions:
>> - Exactly one node in the graph has SHACL type sh:ValidationReport
>> - Every node in the graph that has SHACL type sh:ValidationReport meets the
>>    following conditions:
>>    - It has sh:ValidationReport as a value for rdf:type
>>    - It has exactly one value for sh:conforms, and that value is an RDF
>>      literal with datatype xsd:boolean whose lexical form is in the lexical
>>      space of the xsd:boolean datatype
>>    - The literal value of its value for sh:conforms is true if and only it
>>      has no values for sh:result
>>    - All its values for sh:result have SHACL type sh:ValidationResult
>> - The graph is a SHACL results graph
>>
>> A SHACL results graph is an RDF graph meeting the following conditions:
>> - Every node in the graph that has SHACL type sh:ValidationResult meets the
>>    following conditions
>>    - It has sh:ValidationResult as a value for rdf:type.
>>    - It has exactly one value for sh:focusNode
>>    - It has at most one value for sh:resultPath and this value if present is
>>      a SHACL property path in the graph
>>    - It has at most one value for sh:valueNode
>>    - It has exactly one value for sh:sourceShape
>>    - It has exactly one value for sh:sourceConstraintComponent
>>    - It has exactly one value for sh:resultSeverity
>>    - Each of its values for sh:resultMessage, if any, are language-tagged
>>      literals and each has a different language tag.
>>
>> A top-level validation result in an RDF graph is a node in the graph with
>> SHACL type sh:ValidationResult that is not the object of any triple in the
>> graph.
>>
>> A SHACL validation report for a SHACL results graph S is any RDF graph
>> containing at least the triples of S plus
>> < n, rdf:type, sh:ValidationReport >
>> < n, sh:conforms, c >
>> < n, sh:result, r >  for each top-level validation result r in S
>> where n is a blank node not present in S
>> and c is "false"^^xsd:boolean if S contains any top-level validation results
>> in S, "true"^^xsd:boolean otherwise
>> and for any triple in the report grpah of the form <n,sh:result,q> q is a
>> top-level validation result in S.
>>
>> Given a focus node f, an optional value node v, a shape s, an optional path
>> <p,P>, an optional severity e, and a constraint component C is a SHACL results
>> graph
>> - containing all the triples in P
>> - where p is a SHACL property path in the graph
>> - and which has exactly one top-level validation result n
>>    - whose value for sh:focusNode in the graph is f
>>    - whose value for sh:resultPath in the graph is p, if p is present,
>>      otherwise there is no value for sh:resultPath in the graph
>>    - whose value for sh:value in the graph is v, if v is present,
>>      otherwise there is no value for sh:value in the graph
>>    - whose value for sh:sourceShape in the graph is s
>>    - whose value for sh:sourceConstraintComponent in the graph is c
>>    - whose value for sh:resultSeverity in the graph is e, if e is present,
>>      otherwise sh:violation
>>
>> The combination of a multiset of SHACL results graphs is the union of the
>> graphs if the graphs do not share nodes that are top-level validation
>> results in any of the graphs, provided that the union is also a SHACL
>> results graph.  If the graphs do share such nodes then each graph in the
>> multiset is first replaced by a graph whose only difference is that each of
>> these shared nodes that are top-level validation results in the graph is
>> replaced by a fresh blank node.  In this case there may be many
>> combinations.
>>
>> Note:  Combination does not use merging so that, for example, the triples for
>> a SHACL property path do not have to be replicated for each validation
>> result that contributes to a validation report.  It is always possible to
>> use different blank nodes in each property path in a multiset of SHACL
>> results graphs and in other places such as lists.  This will ensure that no
>> problems ensue but can be very inefficient.
>>
>>
>> Let G be a data graph.  Let S = { s1, ..., sn } be the set of shapes in a
>> shapes graph S.  A results graph for the validation of G against S is an RDF
>> graph that is a combination of some multiset {{ R1, ..., Rn }} where Ri is a
>> results graph for the validation of G against s in S.
>>
>> Let T = { t1, ..., tn } be the complete targets from a data graph
>> G for a shape s in a shapes graph S.  A results graph for the validation of
>> G against s in S is an RDF graph that is a combination of some multiset {{
>> R1, ..., Rn }} where Ri is a results graph for the validation of ti using G
>> against s in S.
>>
>> Let f be a node and G a data graph.
>> Let C = { c1, ..., cn } be the constraints of a shape s in a shapes graph S.
>> A results graph for the validation of f using G of s in S is an RDF graph
>> that is a combination of some multiset {{ R1, ..., Rn }} where Ri is a
>> results graph for ci
>> given f as focus node,
>> the value nodes for s in S of f with D as the value nodes,
>> D as the data graph,
>> s as the shape, and
>> S as the shapes graph.
>>
>> Given f a focus node, {v1,...,vn} a set of value nodes, D a data graph, s a
>> shape, and
>> S a shapes graph
>> any results graph for a sh:ClassConstraintComponent constraint
>> with mandatory parameter values <sh:class,c>
>> is a combination of some multiset {{ r1, ..., rn }}
>> where ri is the empty RDF graph if vi is a SHACL instance of c
>> and ri is a validation result for f, vi, s, the path of s in S if present,
>> the severity of s, and sh:ClassConstraintComponent
>>
>> Similarly for the other constraint components.
>>
>>
>> A Core SHACL processor MUST provide an interface that takes a data graph and
>> a shapes graph and produces a graph that is validation report for a results
>> graph for the validation of the data graph against the shapes graph or
>> signals an error.
>>
>

Received on Tuesday, 13 December 2016 16:48:08 UTC