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