Re: On various syntax issues

Some small-ish points ...

On 5/18/16 9:39 AM, Peter F. Patel-Schneider wrote:
>  New Design for SHACL Syntax
>
> This is a description of what Holger might have meant in his recent message
> on SHACL syntax.  Sections that embody significant changes are @marked like
> this@.  There are several remaining issues:
> * Should sh:and, sh:or, and sh:not allow any kind of constraint that is
> allowed where they are?
> :: This makes the syntax somewhat more difficult to describe.
> * Can arbitrary constraints have filters?
> :: There does not appear to be any reason to disallow this.
> * What is the exact relationship between the linking properties (sh:property,
> ...) and the constraint types (sh:PropertyConstraint, ...)?
> :: When can the rdf:type links for constraints be missing?
>
> Constraints are nodes in the shape graph.  @There are three kinds of
> constraints in the core of SHACL: shapes, property constraints, and inverse
> property constraints, which have SHACL type sh:shape, sh:propertyConstraint,
> and sh:inversePropertyConstraint, respectively.@  No node in a shape graph
> can have more than one of these among its types.

Double use of shape: shapes graph has constraint nodes that have shape 
constraints. This will cause confusion every time that "shape" is used. 
I prefer that "shape" not be a type of constraint, especially a property 
constraint. "shape" (or at least something uniquely named) needs to 
encompass the scope and the constraints, and a propertyConstraint is 
defined within the context of "this thingX" with a defined scope.

>
> In SHACL, nodes are validated against constraints,

data shape nodes.... or nodes in the data shape are validated against 
constraints

resulting in validation
> reports containing validation results.  (The details of validation results
> are not described here.)  The node being validated is called the focus node.
> If the validation of a node against a constraint produces no validation
> results that have a severity level of violation then that node is said to
> validate against the constraint.

Here we've got validate as the action ("validated against") and the 
result ("said to validate against"). The first can result in an error, 
thus not the same as the latter. I'd say we have to stick to "fails 
validation" or "passes validation" but not "validates". Either that or 
we have to speak of "comparison" rather than validation, which does not 
imply a positive outcome. Using "satisfies" rather than validates (3 
paras down) could be an alternative.

>
> Property constraints and inverse property constraints have exactly one value
> for sh:predicate.  Property constraints work on the values of their
> predicate for a focus node; inverse property constraints work on the inverse
> values of their predicate for a focus node; @shapes work on the focus node
> itself@.  The set of nodes that are being worked on are called the value
> nodes.  Constraints also have a severity which can be informational,
> warning, or violation.
>
> @As well as being a kind of constraint, shapes also are used to initiate
> validation, through scopes.@  Each node that is in any scope of a shape is
> validated against that shape.  @Shapes also have filters.  Only nodes that
> validate against all filters of a shape can produce validation results.@
>
> Constraints are made up of components.  When a node is validated against a
> constraint it is validated against each of its components.  The processing
> of each component is described here.  If the condition described is not
> satisfied, then one or more validation results are produced with the
> severity level of the constraint.
>
> Components that @are [should be]@ allowed for all kinds of constraints:

Say somewhere above that "value nodes" are in the data shape, and the 
rest of this reads better.

>
> * sh:in ( n1 ... nm )
> :: Each value node is one of the ni.
> * sh:class c
> :: Each value node has c as one of its SHACL types.
> * sh:classIn ( c1 ... cn )
> :: Each value node has one of the ci as one of its SHACL types.
> * sh:datatype dt
> :: Each value node has a datatype of dt.
> * sh:datatypeIn ( dt1 ... dtn )
> :: Each value node has a datatype that is one of the dti.
> * sh:minLength non-negative integer
> :: The SPARQL STR representation of each value node is at least this long.
> * sh:maxLength non-negative integer
> :: The SPARQL STR representation of each value node is at most this long.
> * sh:minExclusive l
> :: Each value node is greater than l, using SPARQL > test.
> * sh:minInclusive l
> :: Each value node is greater than or equal to l, using SPARQL >= test.
> * sh:maxExclusive l
> :: Each value node is less than l, using SPARQL < test.
> * sh:maxInclusive l
> :: Each value node is less than or equal to l, using SPARQL <= test.
> * sh:nodeKind sh:BlankNode or sh:IRI or sh:Literal or BlankNodeOrIRI or
> BlankNodeOrLiteral or IRIOrLiteral
> :: Each value node is a blank node, an IRI, a literal, a blank node or IRI, a
> blank node or literal, or an IRI or literal, respectively
> * sh:pattern regex  or  sh:pattern regex ; sh:flags
> :: The SPARQL STR representation each value node matches regex using SPARQL
> REGEX, with flags if present.
> * sh:property pc
> :: Each value node validates against pc, a property constraint.
> * sh:inverseProperty ipc
> :: Each value node validates against ipc, an inverse property constraint.
> * sh:and ( shape ... shape )
> :: Each value node validates against each shape.
> * sh:or ( shape ... shape )
> :: Each value node validates against some shape.
> * sh:not shape
> :: Each value node does not validate against the shape.

I still perceive a difference between the "selection" of a property 
(sh:property) and the application of constraints (sh:minInclusive). 
Perhaps that is mainly a matter of documentation, but the workflow steps 
in developing a SHACL document have these at different points in my mind.

>
> Components that are only allowed for property and inverse property constraints:
>
> * sh:hasValue n
> :: Some value node is the same as n.
> * sh:uniqueLang true
> :: There are no repeated language tags among the value nodes.
> * sh:minCount int
> :: There are at least int value nodes.
> * sh:maxCount int
> :: There are at most int value nodes.
> * sh:equals p
> :: The set of value nodes is the same as the set of values of p for the focus
> node.
> * sh:disjoint p
> :: The set of value nodes is the disjoint from set of values of p for the
> focus node.
> * sh:lessThan p
> :: ...
> * sh:lessThanOrEqual p
> :: ...
>
> Components that are allowed only for shapes:
>
> * @sh:closed true ; sh:ignoredProperties ( p1 ... pn )@
> :: Each value node has no values for any property not in the list or that is
> not the property of a sh:property component of the shape.
>
>

Basically makes sense to me. - kc

>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Wednesday, 18 May 2016 18:26:21 UTC