my proposed introduction to the SHACL document

I put together an introduction to the SHACL document that I think is much
better than the current one.  It presents a short description of the major
aspects of SHACL and then goes into a non-controversial example,.taken from
the SHACL primer and slightly modified.

There are other parts of the SHACL document that also have bad introductory
material.  This new introduction does not, for example. alleviate the need for
some good introductory material about scopes and filters or about the
relationship between SHACL and SPARQL.


SHACL (Shapes Constraint Language) is a language for determining whether an
RDF graph (possibly in an RDF dataset) validates against certain shapes.
For example, SHACL can be used to check whether all the nodes in an RDF
graph that have a type link to foaf:Person have a single value for foaf:mbox
and that that value is an IRI.  SHACL can also be used to check whether a
particular node in an RDF graph, say the node ex:bug1, has at least one
value for ex:reportedBy and all such values have an rdf:type link to
foaf:Person.  In doing this checking, SHACL only looks at the triples that
are in the graph.

The most general interface to SHACL has two arguments.  The first argument
is an RDF graph (in an RDF dataset) that contains the data that is to be
validated, which is called the data graph.  The second argument consists of
the shapes and other information that control what validation is to be done.
This control information can be itself encoded as an RDF graph, which is
called the control graph.

So in SHACL one might want to determine whether RDF graphs contain
information about issues and users, such as each issue is in either an
unasssigned or an assigned state, and each issue has a reporter and each
such reporter has a precisely one string name and one or more IRI mailboxes.

A control graph that does this validation has two shapes.  The first,
my:IssueShape contains the two constraints on issues.  The second,
my:UserShape, contains the two constraints on reporters.  The first shape
also contains scope information that here says that its constraints are to
be validated against all nodes that have an rdf:type link to ex:Issue.

my:IssueShape a sh:Shape ;
    sh:classScope ex:Issue;
    sh:property [
        sh:predicate    ex:state ;
        sh:allowedValue (ex:unassigned ex:assigned) ;
        sh:minCount 1 ; sh:maxCount 1
    ] ;
    sh:property [
        sh:predicate    ex:reportedBy ;
        sh:valueShape   my:UserShape ;
        sh:minCount 1 ; sh:maxCount 1
    ] .

my:UserShape a sh:Shape ;
    sh:property [
        sh:predicate    foaf:name ;
        sh:valueType    xsd:string ;
        sh:minCount 1 ; sh:maxCount 1
    ] ;
    sh:property [
        sh:predicate    foaf:mbox ;
        sh:nodeKind     sh:IRI ;
        sh:minCount 1
    ] .

The following data graph might be validated against this control graph

inst:Issue1 a ex:Issue ;
    ex:state        ex:unassigned ;
    ex:reportedBy   inst:User2 .

inst:User2 a foaf:Person ;
    foaf:name       "Bob Smith" ;
    foaf:mbox       <> ;
    foaf:mbox       <> .

inst:Issue3 a ex:Issue ;
    ex:state        ex:unsinged ;
    ex:reportedBy   inst:User4 .

inst:User4 a foaf:Person ;
    foaf:name       "Bob Smith", "Robert Smith" ;
    foaf:mbox       <> ;
    foaf:mbox       <> .

The SHACL validation would validate my:IssueShape against inst:Issue1 and
inst:Issue3.  Validating the first node would determine that inst:Issue1
satisfies the constraints in my:IssueShape, along the way determining that
inst:User2 satisfies the constraints in my:UserShape.  Validating the second
node would determine that inst:Issue3 violates the constraint on values for
ex:state, because ex:unsigned is not in the list of allowed values, and also
violates the constraint on values for ex:reportedBy, because inst:User4
violates the my:UserShape constraint on the maximum number of values for

Received on Friday, 4 September 2015 00:44:34 UTC