W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > January 2017

Re: Comments and questions on SHACL

From: Holger Knublauch <holger@topquadrant.com>
Date: Thu, 5 Jan 2017 09:40:27 +1000
To: public-rdf-shapes@w3.org
Message-ID: <e3d46530-c386-ef94-e9ad-8599988b4cac@topquadrant.com>


On 4/01/2017 18:18, Thomas Francart wrote:
> Thanks Irene for the detailled answer
>
> 2017-01-03 20:24 GMT+01:00 Irene Polikoff <irene@topquadrant.com 
> <mailto:irene@topquadrant.com>>:
>
>     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}.
>
>
> Correct.
>
>
>     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.
>
>
> I don't think I can use sh:closed. I need to check the validity of 
> data published my different institutions that should conform to a core 
> model, but these institutions also have the possibility to extend the 
> core model with other vocabularies (e.g. DCTerms) or their own ontology.
>
>
>     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 ;
>
>                 ] .
>
>
> OK, couls it be written simply like this :
>
> ex:TargetSubjectsOfProperty_p
>
>             a sh:Shape ;
>
>             sh:targetSubjectsOf ex:p ;
>
>             sh:class ex:C .
>
>
> ? are these 2 ways of writing the shapes equivalent (using sh:class 
> ex:C or using sh:property with sh:predicate rdf:type) ?

The solution with sh:property on rdf:type would test the rdf:type of the 
rdf:type, which is something else.

>
> I actually though about this approach but I wanted to limit the number 
> of shapes in my shapes definitions, but I think this is probably the 
> way to go.
> If I need to express both a "domain" and "range" constraint on a 
> property ex:p can I write something like :
>
> ex:TargetSubjectsOfProperty_p
>
>             a sh:Shape ;
>
>             sh:targetSubjectsOf ex:p ;
>
>             sh:class ex:C .
>             sh:property [
>                sh:predicate ex:p ;
>                sh:class ex:RangeClass ;
>             ]
>
> Then maybe having a "one Shape per property" approach would be more 
> appropriate than having a "one Shape per class" approach. I will need 
> to think about it.

Yes, you have a global property constraint and thus it should also be 
expressed outside of classes.

>
>     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.
>
>
> Your explanation triggers an additionnal question : are the property 
> constraints inherited by subclasses through rdfs:subClassOf ? where is 
> this written in the spec ?
>
> ex:Party a rdfs:Class, sh:Shape ;
>   ex:property [
>     ex:homePage ;
>     sh:nodeKind sh:IRI ;
>   ]
>
> ex:Person a rdfs:Class, sh:Shape ;
>   rdfs:subClassOf ex:Party .
>
> In the above example, does it means that ex:Person "inherits" the   
> property constraints on ex:homePage ?

Yes, it inherits them, because ex:Party a rdfs:Class, sh:Shape is 
equivalent to a sh:targetClass target statement. sh:targetClass applies 
to all direct instances plus the indirect instances (of known 
subclasses). See section on sh:targetClass, use of the term SHACL instances.

HTH
Holger



>
> Thanks again
> Thomas
>
>
>     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 <mailto: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 <tel:+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 <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
Received on Wednesday, 4 January 2017 23:41:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:48 UTC