Re: Comments and questions on SHACL

Thanks Irene for the detailled answer

2017-01-03 20:24 GMT+01:00 Irene Polikoff <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) ?

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.



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

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