Re: my proposed introduction to the SHACL document

Although considerably shorter than the current section 1, I feel that 
the "Motivation" information would belong elsewhere - not in the 
specification itself. Perhaps the primer? But in much less detail, IMO. 
So I'm a +1 for Peter's text. Also, I prefer his "validates against 
shapes" to the "conforms" language suggested by Irene. Validates is 
clearer and more specific than "conforms."

kc

On 9/3/15 6:40 PM, Peter F. Patel-Schneider wrote:
> This would replace the entirety of the abstract and Section 1.
>
> peter
>
>
> On 09/03/2015 06:38 PM, Holger Knublauch wrote:
>> 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.
>>>
>>
>>
>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Friday, 4 September 2015 18:18:38 UTC