Re: more sloppiness in the SHACL document

No, this is issue is not about any specific problem. It is about whether the working group thinks the spec should be using this style of writing and to what extent.

> On Dec 13, 2016, at 11:47 AM, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
> 
> 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 17:11:32 UTC