- 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