Re: Comments and questions on SHACL

A quick followup :


> 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.
>

Using sh:in for multiple classes is not possible as the semantic of sh:in
is to check that the value of the property belongs to the list, not that
the value is an instance of one of the members in the list. I think if the
property can be expressed on multiple classes I need to use sh:or :

ex:TargetSubjectsOfProperty_p

            a sh:Shape ;

            sh:targetSubjectsOf ex:p ;

            sh:or [

               [

               sh:property [

                        sh:predicate rdf:type ;

                        sh:class ex:C1 ;
               ]
               ]

               [

               sh:property [

                        sh:predicate rdf:type ;

                        sh:class ex:C2 ;
               ]
               ]

            ]
 .

Which is a little complex to write. Can any simplification be introduced in
SHACL here ? (such as a "sh:classes" component that could take a list as a
value, or having the ability to pass a list as the value of a "sh:class").

Cheers
Thomas




> 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, 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, site : sparna.fr, linkedin : fr.linkedin.com/in/
> thomasfrancart
> tel :  +33 (0)6.71.11.25.97 <+33%206%2071%2011%2025%2097>, skype :
> francartthomas
>
>
>


-- 

*Thomas Francart* -* SPARNA*
Web de *données* | Architecture de l'*information* | Accès aux
*connaissances*
blog : blog.sparna.fr, site : sparna.fr, linkedin :
fr.linkedin.com/in/thomasfrancart
tel :  +33 (0)6.71.11.25.97, skype : francartthomas

Received on Wednesday, 4 January 2017 11:12:56 UTC