Re: shapes-ISSUE-172 (sh:nodeKind SPARQL definition): the sh:nodeKind SPARQL definition is unnecessarily complex [SHACL Spec]

On 06/30/2016 10:47 AM, Karen Coyle wrote:
> Thank you, Peter. I think this is the best explanation/documentation I've seen
> on this, and will hang on to it. I still think the spec could be made clearer
> (you seem to be the only one who has understood it thus far), but it appears
> that we aren't yet at "how it works" but still at "does it work?"
[...]
> kc

You may also like the following excerpts from
https://www.w3.org/2014/data-shapes/wiki/Refactor.   These are for my
refactoring of the SHACL syntax to collapse constraints and shapes, but most
of it works for standard SHACL.

peter


SHACL is designed to determine whether some information satisfies a set of
conditions. This process is called validation in SHACL. The main
functionality provided by a SHACL engine is to determine whether one RDF
graph, called the data graph and containing the information to be validated,
validates against another RDF graph, containing the conditions and called
the shapes graph because the main syntactic construct in SHACL is the
shape. Data graphs and nodes in the data graph are said to validate against
shapes and shapes graphs.

...

Core SHACL Syntax

Shapes in core SHACL have

1. zero or more scopes (triples with the shape as subject and sh:scopeNode,
   sh:scopeClass, sh:scopePropertyObject, sh:scopePropertySubject,
   sh:scopeAllObjects, or sh:scopeAllSubjects as the predicate),
2. zero or more filters (triples with sh:filter as the predicate), whose
   objects are themselves shapes, and
3. zero or more components (triples with the shape as subject and one of the
   component properties below as property).

The scopes of a shape select nodes for validation. Filters further cut down
on the nodes for validation. Components state conditions that nodes need to
satisfy to validate against the shape.

...

Semantics for Core SHACL

A data graph validates against a shapes graph if the data graph validates
against every node in the shapes graph that is the subject of at least one
triple whose predicate is one of the scope properties. These nodes are
called the scoped shapes of the shapes graph. Any node in the shapes graph
that is used as a shape during validation is then a shape whether it has
SHACL type sh:shape or not. (This is a different definition of shapes but it
does not require any use of typing to determine what is a shape.)

A data graph validates against a scoped shape if the set of nodes of the
graph selected by any scope of the scoped shape validates against the scoped
shape.

Scopes select certain RDF terms (or nodes, but RDF only uses node with
respect to the nodes of an RDF graph). A sh:scopeNode value selects that
term. A sh:scopeClass value selects each term that is a SHACL instance of
the class in the data graph. A sh:scopePropertyObject value selects each
term that is the object of some triple in the data graph with that property
as predicate. A sh:scopePropertySubject value selects each term that is the
subject of a triple in the data graph with that property as predicate. A
sh:scopeAllObjects selects all terms that are the object of some triple in
the data graph. A sh:scopeAllSubjects selects all terms that are the subject
of some triple in the data graph.

A set of RDF terms (the focus nodes) validates against a shape as
follows. The in-filter nodes are those focus nodes which validate against
each of the filters of the shape. Focus nodes that are not in-filter nodes
are called out-of-filter nodes.

To uniformly handle all components the semantics for components is defined
in terms of a set of of nodes (the in-filter nodes) and not in terms of a
single node. Some components (sh:shape, sh:and, sh:or, sh:not, sh:hasValue,
sh:minCount, sh:maxCount, sh:uniqueLang, and sh:partition) work on this set
as a whole. There is one or more elements in the validation result precisely
when one or more in-filter node fails to validate against the component. The
component separately determines which in-filter nodes validate or fail to
validate against the component. The other components (sh:in, ...,
sh:pattern, sh:propValues) work on each in-filter node independently. The
validation results for the component contains an element for each in-filter
node that failed to validate against that component. in-filter nodes for
which there is no validation result are considered to validate against the
component.

A set of focus nodes validates against a shape if the set of in-filter nodes
from this set of focus nodes validates against each of the shape's
components.

...

Received on Friday, 1 July 2016 00:37:32 UTC