Re: Understanding Node vs Property Shapes and Property Paths

This looks correct.

With data:

hr:Long a hr:Employee.
hr:Employee a rdfs:Class.

If your focus node is hr:Long, zero or more paths will deliver values hr:Long, hr:Employee, rdfs:Class. One or more paths will deliver values  hr:Employee, rdfs:Class.

You could try rdf:type/rdf:type as the path. This will get the type of a resource that is used as a type and ensure that it is rdfs:CLass or rdf:Property.

> On Apr 21, 2020, at 11:39 AM, James Hudson <jameshudson3010@gmail.com> wrote:
> 
> Hello,
> 
> Since people here have been so helpful in the past, I thought I would ask a few more questions.
> 
> Background to this is my SO question at https://stackoverflow.com/questions/61323857/what-is-the-difference-between-these-shape-graphs-which-use-shor <https://stackoverflow.com/questions/61323857/what-is-the-difference-between-these-shape-graphs-which-use-shor>
> 
> The SO question has the data graph under consideration.
> 
> In the book Validating RDF, it says:
> 
> Node shapes declare constraints directly on a node. Property shapes declare constraints on the values associated with a node through a path.
> 
> Based on this, I believe I want to use a Property Shape because I want to define a constraint on the value of the rdf:type path on a focus node. Is this correct?
> 
> If I try the property shape:
> 
> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema# <http://www.w3.org/2000/01/rdf-schema#>> .
> @prefix rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns# <http://www.w3.org/1999/02/22-rdf-syntax-ns#>> .
> @prefix sch:  <http://schema.org/ <http://schema.org/>> .
> @prefix sh:   <http://www.w3.org/ns/shacl# <http://www.w3.org/ns/shacl#>> .
> @prefix ex:   <http://example.org/ <http://example.org/>> .
> 
> ex:ClassOrProperty
>     a sh:PropertyShape ;
>     sh:target [
>         a sh:SPARQLTarget ;
>         sh:select   """
>                     SELECT ?this
>                     WHERE {
>                         ?this ?p ?o .
>                     }
>                     """ ;
>     ] ;
> 
> 
>     sh:path [sh:zeroOrMorePath rdf:type] ;
>     sh:in ( rdfs:Class rdf:Property ) ;
> .
> 
> I get the unexpected validation error:
> (J)
> Constraint Violation in InConstraintComponent (http://www.w3.org/ns/shacl#InConstraintComponent <http://www.w3.org/ns/shacl#InConstraintComponent>):
> 	Severity: sh:Violation
> 	Source Shape: ex:ClassOrProperty
> 	Focus Node: hr:Longer
> 	Value Node: hr:Employee
> 	Result Path: [ sh:zeroOrMorePath rdf:type ]
> 
> The way I thought [sh:zeroOrMorePath rdf:type] ; would work is that it would consider the node hr:Longer and follow the rdf:type path through hr:Employee to where it terminates at rdfs:Class and then validate. However, it seems to stop one step away, sees that hr:Employee is not a rdfs:Class or rdf:Property and then generates a validation error.
> 
> I get another unexpected validation error:
> (K)
> Constraint Violation in InConstraintComponent (http://www.w3.org/ns/shacl#InConstraintComponent <http://www.w3.org/ns/shacl#InConstraintComponent>):
> 	Severity: sh:Violation
> 	Source Shape: ex:ClassOrProperty
> 	Focus Node: hr:Employee
> 	Value Node: hr:Employee
> 	Result Path: [ sh:zeroOrMorePath rdf:type ]
> 
> I was thinking that the zero in sh:zeroOrMorePath would see hr:Employee a rdfs:Class ; and validate. Is it the case that the zero in sh:zeroOrMorePath causes a validation engine to compare a node against itself without following or looking for the path?
> 
> I did try using sh:oneOrMorePath, but I received the validation error (J) again, but (K) did not show up. Is the reason why (K) did not show up because it was forced to see hr:Employee a rdfs:Class ; because of the one in sh:oneOrMorePath and could validate it?
> 
> Perhaps a validation engine validates every node along the path and not just where the path terminates? If this is the case, is it possible to validate where the path terminates only?
> 
> Needless to say, I am rather confused.
> 
> Can anyone clear this up?
> 
> Thank you,
> James
> 
> 
> 

Received on Tuesday, 21 April 2020 16:12:18 UTC