W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > August 2016

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

From: Eric Prud'hommeaux <eric@w3.org>
Date: Thu, 11 Aug 2016 20:07:38 -0400
To: Holger Knublauch <holger@topquadrant.com>
Cc: public-data-shapes-wg@w3.org
Message-ID: <20160812000737.GC11245@w3.org>
* 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.


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

-- 
-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 Friday, 12 August 2016 00:07:44 UTC

This archive was generated by hypermail 2.3.1 : Friday, 12 August 2016 00:07:44 UTC