Re: my proposed introduction to the SHACL document

Could you clarify which section this is supposed to replace? It looks 
similar to 1.2 but covers much less material and fewer details.

Thanks
Holger


On 9/4/15 10:43 AM, Peter F. Patel-Schneider 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:38:37 UTC