Re: Comments and questions on SHACL

Thomas,

Thanks for reporting the editorial issue with the example and look for a separate e-mail regarding the shapes order requirement.

For the equivalent of the domain constraint, I am assuming that you want to see a violation if {ex:x ex:p ex:value} and {ex:x rdf:type ex:C2}. 

If so, you may want to consider defining “closed shapes” using sh:closed true . This will work as long as you want closed shapes for all classes and associated properties. In your example, it means that you will have a closed shape for members of ex:C2 and any other classes that may be in your data.

However, if there is no rdf:type statement for ex:x or there is {ex:x rdf:type ex:C3} and there is no closed shape defined for members of ex:C3, you would not get a violation. If you need to cater for these cases while keeping down the number of shapes, you could define one additional shape to ensure that any node that is a subject of any triple always has a type (I think this would require a SPARQL-based target) and the type is in the list of classes you enumerate - that is classes for which you have shapes.

If this approach doesn’t work with your data and use cases, I think you may have to create a shape for each property you need to implement such constraint for. This could be done using something like:

ex:TargetSubjectsOfProperty_p

            a sh:Shape ;

            sh:targetSubjectsOf ex:p ;

              sh:property [

                        sh:predicate rdf:type ;

                        sh:class ex:C ;

            ] .

Or use sh:in instead of sh:class if members of multiple classes may have values for this property. Note that unlike the closed shapes approach above, this will not use the subclass hierarchy. So, if for example, you have a class ex:Party with subclasses ex:Organization and ex:Person and you want any party to have ex:homePage property, with closed shapes you could define the constraint at the ex:Party level. And it will allow people and organizations (but not members of a class that is not a sub of party) to have ex:homePage property. If you use the target subjects approach, you would need to say:


ex:TargetSubjectsOfProperty_homePage

            a sh:Shape ;

            sh:targetSubjectsOf ex:homePage ;

              sh:property [

                        sh:predicate rdf:type ;

                        sh:in (ex:Party, ex:Person, ex:Organization) ;

            ] .



I wonder if others can come up with some additional alternatives.


Regards,

Irene Polikoff

> On Jan 3, 2017, at 9:19 AM, Thomas Francart <thomas.francart@sparna.fr> wrote:
> 
> Hello
> In the example shapes graph at https://w3c.github.io/data-shapes/shacl/#NodeKindConstraintComponent <https://w3c.github.io/data-shapes/shacl/#NodeKindConstraintComponent>, "sh:nodeKind ex:IRI ;" should be "sh:nodeKind sh:IRI ;"
> In https://w3c.github.io/data-shapes/shacl/#nonValidation <https://w3c.github.io/data-shapes/shacl/#nonValidation>, I would find it useful to be able to express sh:order also on Shapes and not only PropertyConstraints, in order to display an ordered list of Shapes;
> I have a doubt about the best way to express the equivalent of a "domain" contraint in SHACL, that is : "given a property :p, I want to make sure that all X that are subjects of :p have class C". Given that I have defined one Shape per Class in my ontology, can I express this without redefining an extra shape and keeping only one Shape per class ?
> Cheers
> Thomas
> 
> -- 
> 
> Thomas Francart - SPARNA
> Web de données | Architecture de l'information | Accès aux connaissances
> blog : blog.sparna.fr <http://blog.sparna.fr/>, site : sparna.fr <http://sparna.fr/>, linkedin : fr.linkedin.com/in/thomasfrancart <https://fr.linkedin.com/in/thomasfrancart>
> tel :  +33 (0)6.71.11.25.97, skype : francartthomas