Re: On various syntax issues

On 19/05/2016 2:39, 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.

They should IMHO only allow sh:Shapes (aka node constraints).

> * Can arbitrary constraints have filters?
> :: There does not appear to be any reason to disallow this.

Yes, the domain of sh:filterShape is sh:Constraint, which means it 
applies also to sh:Shape.

> * 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?

rdf:type links can be missing whenever it is safe to derive the type 
from the incoming properties. This applies to nested shapes in sh:or 
lists, sh:shape, sh:property, sh:inverseProperty and 
sh:sparqlConstraint. There are various ways to express the details on 
this, and your next paragraph does this well, assuming it includes 
default value types.

>
> 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.
>
> In SHACL, nodes 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.
>
> 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.@

Correction: *Constraints* can also have filters.

>
> 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:
>
> * 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.
>
> 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.
>
>

Yes this looks about right (beside minor typos). I do believe we should 
get rid of sh:datatypeIn and sh:classIn. I also believe we should delete 
sh:and. In your other email you stated sh:and would still be needed. Can 
you come up with an example of something that could not be expressed 
otherwise?

I am also not sure whether sh:property and sh:inverseProperty should be 
constraint components and allowed in other predicate-based contexts. 
This idea would need to be discussed first.

Thanks
Holger

Received on Wednesday, 18 May 2016 22:49:54 UTC