Re: Please review the SHACL draft (was Re: Editing progress)

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.

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 Thursday, 11 August 2016 07:32:48 UTC