Re: New Terminology Section

On 8/05/2016 2:22, Karen Coyle wrote:
> On 5/6/16 10:07 PM, Holger Knublauch wrote:
>>> The big question, though, in my mind, is whether the use of classes in
>>> SHACL follows the definition in RDFS.
>>> In terms of the data graph, the RDFS concept of class is used only in
>>> the sense that nodes can be identified as a triple with a predicate
>>> "rdf:type" and some designated value.
>>> In the shapes graph, I'm not at all clear on how classes are being
>>> used. There are a lot of declared classes that appear to have no
>>> functionality within the standard. I'm going to open up an issue so we
>>> can try to clarify what classes in SHACL are - that may help us with
>>> finding wording.
>> Details are needed. Not clear what problems you are seeing.
> In this example, defined SHACL class sh:Shape is used. So to me that 
> is a class that has a function/use demonstrated in the SHACL spec.
> ex:ExampleFilteredShape
>     a sh:Shape ;
>     sh:scopeClass ex:Person ;
>     sh:filterShape [
>         a sh:Shape ; # Optional triple
>         sh:property [
>             sh:predicate ex:member ;
>             sh:hasValue ex:W3c ;
>         ]
>     ] ;
>     sh:property [
>         sh:predicate ex:email ;
>         sh:minCount 1 ;
>     ] .
> Nowhere do I see any visible use of sh:DatatypeConstraintComponent,[1] 
> sh:DatatypeInConstraintComponent, or any other 
> "sh:XConstraintComponent". Therefore it isn't obvious to me what 
> function these have in the SHACL vocabulary. They are defined in the 
> constraint section but never again referenced in the document. This is 
> especially curious since we have said that no inferencing takes place 
> so class/type relationships must be made explicit with an rdf:type 
> predicate. I would expect to see some usage of them described in the 
> document.
> kc
> [1]

The ConstraintComponents are not classes, and they are not explicitly or 
implicitly referenced via rdf:type. They are basically shapes. Like 
shapes, they serve as a group of constraints (here: the constraints that 
define the parameter properties such as sh:minCount which has datatype 
xsd:integer). Like shapes, they are laid over a graph without the graph 
even knowing about that overlay. However, ConstraintComponents are not 
officially instances of sh:Shape, because this would "pollute" each 
shapes graph with additional shapes that would always be validated. The 
design is such that SHACL engines could very easily use the constraint 
components as shapes, and sh:Parameters as sh:PropertyConstraints, if 
the user requests to validate the shapes graph itself.

Is this clearer?


Received on Sunday, 8 May 2016 23:20:05 UTC