Re: my proposed introduction to the SHACL document

I would prefer

SHACL (Shapes Constraint Language) is a language for specifying data
shapes and determining whether an
RDF graph (possibly in an RDF dataset) conforms to certain shapes.



Irene Polikoff, CEO
TopQuadrant, Inc. www.topquadrant.com <http://www.topquadrant.com/>
Technology providers making enterprise information meaningful
Blogs ‹ http://www.topquadrant.com/the-semantic-ecosystems-journal/,
http://www.topquadrant.com/composing-the-semantic-web/
LinkedIn ‹ https://www.linkedin.com/company/topquadrant
Twitter - https://twitter.com/topquadrant






On 9/3/15, 8:43 PM, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
wrote:

>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.
>
>peter
>
>
>
>
>
>
>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       <mailto:bob@example.org> ;
>    foaf:mbox       <mailto:rs@example.org> .
>
>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       <mailto:bob@example.org> ;
>    foaf:mbox       <mailto:rs@example.org> .
>
>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
>foaf:name.
>

Received on Friday, 4 September 2015 01:58:58 UTC