- From: Holger Knublauch <holger@topquadrant.com>
- Date: Fri, 12 Aug 2016 10:14:41 +1000
- To: public-data-shapes-wg@w3.org
On 12/08/2016 10:07, Eric Prud'hommeaux wrote: > * Holger Knublauch <holger@topquadrant.com> [2016-08-11 17:32+1000] >> FWIW sh:filterShape is very useful when it comes to deactivating shapes >> defined by someone else. We are already using this a lot: we have defined a >> sh:Shape (dash:None) that always returns false (using sh:in rdf:nil). Then, >> the constraints in the ontologies that we publish have URIs. Anyone who >> wants to override our "default" constraints, just needs to add <constraint> >> sh:filterShape dash:None. Such scenarios would be impossible if people had >> to fiddle with existing constraints, to rearrange their shapes into a >> template such as the "[ sh:or ( [ sh:not [ FILTER ] ] SHAPE ) ]" that you >> mention. > Not impossible, just several more triple manipulations than you are > currently performing, so I understand your point. > > Why do you have to disable shapes? That seems a bit like being locked > into validating against a particular XML schema so you change to to > accept ANY. We use shapes for form generation. In some application contexts, certain properties should not show up. In other cases it's about disabling certain constraints in order to enable others. I cannot yet say how common this design pattern will be in practice, but I guess we are all speculating here. Holger > > >> Holger >> >> >> On 11/08/2016 17:25, Eric Prud'hommeaux wrote: >>> * Karen Coyle <kcoyle@kcoyle.net> [2016-08-10 17:09-0700] >>>> On 8/10/16 3:47 PM, Holger Knublauch wrote: >>>>> Hi Karen, >>>>> >>>>> in terms of a data model, targets, shapes and constraints are classes. >>>>> They actually have corresponding rdfs:Classes in the Turtle file. So one >>>>> way of explaining them, in addition to an abstract syntax, is to >>>>> introduce the data model. I had a UML-like diagram in earlier versions, >>>>> a variant of which I believe would still be a good thing to have. It >>>>> would show how the concepts are connected and possibly appeal to a >>>>> certain technical audience. >>>>> >>>>> Having gone through the spec recently I also cannot help but think that >>>>> most people will understand SHACL simply by following and copying the >>>>> design patterns from the examples. So I believe it's good to have as >>>>> many examples as possible. >>>> Examples are important, but that does not mean that the text should be >>>> unclear. >>>> >>>>> Other than that I am left wondering what conclusions I should draw from >>>>> your observations. For example, I don't see why targets or constraints >>>>> would need to be defined as shapes, because Filters are. Do you have >>>>> suggestions on how to improve the flow? >>>> I did not suggest that constraints and targets should be defined as shapes. >>>> I asked about an inconsistency in the definitions. To my mind, the outlier >>>> is filters. >>>> >>>> Shape := label:IRI|BNode, targets:Set[Target], filters:Set[Shape], >>>> constraints:Set[Constraint] >>> Given that filters appear to be a slight syntactic shorthand for NOT >>> OR, maybe their convenience doesn't justify the cognitive burden they >>> introduce. >>> >>> With filter: >>> >>> ex:ExampleFilteredShape >>> # Everyone who's a member of W3c >>> sh:filterShape [ >>> sh:property [ sh:predicate ex:member ; sh:hasValue ex:W3c ] >>> ] ; >>> # must have 1+ email addrs. >>> sh:property [ sh:predicate ex:email ; sh:minCount 1 ; ] . >>> >>> Without filter we need more ceremony: >>> >>> ex:ExampleFilteredShape >>> sh:constraint [ sh:or ( >>> # Either not a member of W3c >>> [ sh:not [ >>> sh:filterShape [ >>> sh:property [ sh:predicate ex:member ; sh:hasValue ex:W3c ] >>> ] ] ]; >>> # or must have 1+ email addrs. >>> [ sh:property [ sh:predicate ex:email ; sh:minCount 1 ; ] ] >>> ) ] . >>> >>> The template is "[ sh:or ( [ sh:not [ FILTER ] ] SHAPE ) ]". >>> >>> Given that we already have to look for recursion in these expressions >>> (both visually and programatically), eliminating filters would mean >>> one less form to inspect. >>> >>> ex:ExampleFilteredShape >>> sh:filterShape ex:ExampleFilteredShape ; # <-- trouble >>> sh:property [ sh:predicate ex:email ; sh:minCount 1 ; ] . >>> >>> We could also avoid having to define behaviors like filters with >>> filters. >>> >>> >>>> kc >>>> >>>>> Thanks, >>>>> Holger >>>>> >>>>> >>>>> On 10/08/2016 2:07, Karen Coyle wrote: >>>>>> Holger, the way section 2 now reads there are targets, filter shapes, >>>>>> and constraints. Filters are defined as shapes, but neither targets >>>>>> nor constraints are defined in that way. This seems inconsistent and >>>>>> the actual meaning of shape seems less clear. Sometimes it seems to >>>>>> refer to the set of targets, filters and constraints, sometimes it >>>>>> seems to refer to an individual filter segment. >>>>>> >>>>>> In the abstract syntax we have: >>>>>> >>>>>> Shape := label:IRI|BNode, scopes:Set[Scope], filters:Set[Shape], >>>>>> constraints:Set[Constraint] >>>>>> >>>>>> Using target that will become: >>>>>> >>>>>> Shape := label:IRI|BNode, targets:Set[Target], filters:Set[Shape], >>>>>> constraints:Set[Constraint] >>>>>> >>>>>> kc >>>>>> >>>>>> >>>>>> >>>>>> On 8/8/16 5:20 PM, Arnaud Le Hors wrote: >>>>>>> Thanks Holger for the update. Let's talk on Thursday about the >>>>>>> requirements to move the spec to Candidate Recommendation (CR). >>>>>>> Unfortunately I don't think we're quite there yet. Here is quick run >>>>>>> through the main requirements: >>>>>>> >>>>>>> * all known issues impacting conformance of an implementation have been >>>>>>> closed. >>>>>>> * proof of wide review - we need to publish a draft and broadly announce >>>>>>> it calling for public comments prior to moving to CR >>>>>>> * test suite - we at least need to have the framework in place that the >>>>>>> specification can point to >>>>>>> * exit criteria - how do we define what it will take to exit CR - >>>>>>> typically a minimum of two implementations of every feature >>>>>>> >>>>>>> So, for now, please, everyone, review the spec and let's see on Thursday >>>>>>> whether we can agree to publish the updated spec. >>>>>>> >>>>>>> Eric and Karen, if you have a chance to update the abstract syntax draft >>>>>>> that'd be great. Please, let the WG know when you're done. >>>>>>> >>>>>>> Thanks. >>>>>>> -- >>>>>>> Arnaud Le Hors - Senior Technical Staff Member, Open Web Technologies - >>>>>>> IBM Cloud >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> From: Holger Knublauch <holger@topquadrant.com> >>>>>>> To: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org> >>>>>>> Date: 08/08/2016 04:17 PM >>>>>>> Subject: Editing progress >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> >>>>>>> >>>>>>> FYI I did a complete pass through the spec over the last couple of days >>>>>>> and fixed a number of inconsistencies and buglets. Dimitris also did >>>>>>> some updates. In the upcoming meeting we may want to decide to press the >>>>>>> publish button again? I would be interested to hear what is missing with >>>>>>> respect to reaching the next phase of the W3C process. >>>>>>> >>>>>>> Holger >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>> -- >>>> Karen Coyle >>>> kcoyle@kcoyle.net http://kcoyle.net >>>> m: 1-510-435-8234 >>>> skype: kcoylenet/+1-510-984-3600 >>>> >>
Received on Friday, 12 August 2016 00:15:15 UTC