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

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

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Thursday, 11 August 2016 07:25:37 UTC