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

Re: Comments and questions on SHACL

From: Thomas Francart <thomas.francart@sparna.fr>
Date: Wed, 4 Jan 2017 09:31:24 +0100
Message-ID: <CAPugn7UNr+Py_O1uLw5uYKP3JPYXFGYQqQKvm9tKu2+CH-tRjw@mail.gmail.com>
To: Holger Knublauch <holger@topquadrant.com>
Cc: public-rdf-shapes@w3.org
Hello

2017-01-04 6:23 GMT+01:00 Holger Knublauch <holger@topquadrant.com>:

> Hi Thomas,
>
> thanks for your feedback.
>
> On 4/01/2017 0:19, Thomas Francart 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 ;"
>
>
> Good catch, fixed (on the "restructuring" branch)
>
>
>    - 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;
>
>
> sh:order is open for such use cases and has no rdfs:domain. Among others,
> it is used for property constraints and property groups, yet there is no
> reason to not also use it for shapes. Being one of the informal properties
> of SHACL, there is no formal meaning attached to it anyway.
>

https://w3c.github.io/data-shapes/shacl/#nonValidation says :

"Property constraints may have one value
<https://w3c.github.io/data-shapes/shacl/#dfn-value> for the property sh:order
... If present, the recommended use of sh:order is to sort the property
constraints in an ascending order, for example so that properties with
smaller order are placed above (or to the left) of properties with larger
order. ... Groups may also have an sh:order property to indicate the
relative ordering of groups within the same form."

Nowhere can I read that sh:order has no rdfs:domain; the above formulation
leads to think that only property constraints and property groups can have
sh:order. And I don't think a lot of people will go and read the rdfs/owl
file. I think this would be clearer if this is written explicitely. SKOS
for example has such formulations :
https://www.w3.org/TR/2009/REC-skos-reference-20090818/#L1541


>
> Out of interest: in what context do you need an order among shapes (e.g.
> couldn't they be arranged in an rdf:List)?
>

Yes, theoretically an rdf:List could do the job. But rdf:List are just...
you know. Having a simple property to order the shapes would be much more
convenint to rearrange them.
I am currently designing a prototype application that can :

   - Display the content of a shapes definition file (= print a list of
   shapes, that I would like to be ordered);
   - Display the content of a shapes definition file along with the
   corresponding shape validation results for each shape or property
   definition (so, a shape-oriented display of validation results);


>
>    - 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 ?
>
>
> This can be expressed with a variation of Irene's suggestion from her
> parallel email:
>
> ex:LimitPToInstancesOfC
>     a sh:Shape ;
>     sh:targetSubjectsOf ex:p ;
>     sh:class ex:C .
>
> Explanation: The shape applies to all subjects of triples that have ex:p
> as predicate. These become the focus nodes of the shape. The sh:class
> constraint states that all focus nodes must be instances of ex:C.
>
>
OK thanks. See my previous answer.

Cheers
Thomas



> HTH
> Holger
>



-- 

*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 08:32:17 UTC

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