- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Fri, 18 Nov 2016 07:53:03 -0800
- To: public-data-shapes-wg@w3.org
On 11/17/16 10:57 PM, Holger Knublauch wrote: > > > On 18/11/2016 16:44, Eric Prud'hommeaux wrote: >> * Holger Knublauch <holger@topquadrant.com> [2016-11-18 15:48+1000] >>> I was tasked to research why the definition of sh:stem in the current >>> draft >>> does not align with Eric's original proposal from >>> >>> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Mar/0311.html >>> >>> >>> and in particular excludes Range Exclusions or Union/or stems. >>> >>> His proposal was >>> >>> PROPOSAL: write stems in shacl like: >>> >>> <http://a.example/S1> a sh:Shape; >>> sh:propValues ( >>> <http://a.example/p1> [ >>> sh:values [ >>> a sh:StemRange; >>> shex:stem <http://a.example/v> >>> ] >>> ] >>> ). >>> >>> which is based on a syntax variation proposed by Peter, using >>> sh:propValues >>> instead of sh:property. It also uses shex:stem as the wrong >>> namespace. So >>> clearly it was impossible to agree on this proposal in this form, and we >>> must have instead voted on some follow-up variation. >>> >>> Updated to the actual syntax of SHACL his example would look like >>> >>> <http://a.example/S1> a sh:Shape; >>> sh:property [ >>> sh:predicate <http://a.example/p1> ; >>> sh:values [ >>> a sh:StemRange; >>> sh:stem <http://a.example/v> >>> ] >>> ] . >>> >>> which differs from the current draft: >>> >>> <http://a.example/S1> a sh:Shape; >>> sh:property [ >>> sh:predicate <http://a.example/p1> ; >>> sh:stem "http://a.example/v" ; >>> ] . >>> >>> His original email also has a second PROPOSAL that was only visible >>> when you >>> scroll down: >>> >>> PROPOSAL: write exclusions in shacl like: >>> >>> <http://a.example/S1> a sh:Shape; >>> sh:propValues ( >>> <http://a.example/p1> [ >>> sh:values [ >>> a sh:StemRange; >>> shex:stem <http://a.example/v> >>> sh:exclusions: ( >>> [ "type": "Stem", "stem": <http://a.example/v1> ], >>> [ "type": "Stem", "stem": <http://a.example/v2> ], >>> [ "type": "Stem", "stem": <http://a.example/v3> ] >>> ) >>> ] >>> ] >>> ). >>> >>> >>> The vote at https://www.w3.org/2016/04/07-shapes-minutes.html was about >>> >>> PROPOSED: Close ISSUE-80, adding sh:stem to the spec outlined in >>> Eric's >>> emailhttps://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Mar/0311.html >>> >>> >>> There was no prior discussion in the minutes above, but we have >>> talked about >>> it in the meeting beforehand: >>> >>> https://www.w3.org/2016/03/31-shapes-minutes.html#item05 >>> >>> The discussion there is focused on sh:stem as syntactic sugar for >>> sh:pattern, e.g. Peter stated "as sugar its not very sweet", Karen >>> "worth it >>> to her. doing it with patterns could be helpful. sh:stem makes it more >>> specific, easier for more casual users.". Then there must have been an >>> unscribed section which Peter summarized as "the point was whether to >>> have >>> this construct have an implicit disjunction somehow, either along >>> with the >>> current top-level disjunction (which would be new) or like in >>> sh:classIn'", >>> but no conclusion is recorded. >>> >>> The actual edit to fold this in was done by Dimitris, see >>> >>> https://github.com/w3c/data-shapes/commit/0e6ed4d3692e30bd02cfc3f321fe5c118b6b5d3e >>> >>> >>> And this definition has been read by many people over the last 7 months, >>> nobody objected. >>> >>> I am also 100% sure that I would not have voted for the complete >>> proposal >>> with the intermediate objects, exclusions, disjunction etc. This >>> would have >>> been a huge implementation overhead. >>> >>> My only explanation is that: >>> >>> 1) The discussion that is not recorded must have concluded that the >>> WG is >>> only supporting sh:stem as the light-weight syntactic sugar for >>> sh:pattern + >>> sh:nodeKind sh:IRI. >> >> Why would we add >> <S> sh:property [ sh:predicate X ; sh:stem "http://a.example/" ] >> when we already had >> <S> sh:property [ sh:predicate X ; sh:pattern "http://a.example/.*" ] >> Was the goal to save five characters? The whole point of stems is that >> they go in value sets (which are, in turn, syntactic sugar for pairs of >> sh:nodeKind and sh:pattern). > > As Karen said "to make it more explicit", and as Peter said "as not very > sweet sugar". And to include the implicit sh:nodeKind constraint. So > there was a bit of value in it, and if you look at the votes, support > for this was rather lukewarm. (BTW your sh:pattern would require a ^ too). Given that we didn't have an example of how it would be with multiple "or'd" stems, and the example in the spec only shows one, I think you cannot conclude that everyone understood the implication of multiples. I do think that the examples in the spec are often the simplest case, which doesn't convey the complexity of the solutions. Although using "or" for multiple stems is not impossible, this type of situation does make the compact syntax much more appealing. I also find that the usage of "and" "or" "not" in SHACL feels quite unintuitive, placing them before a series of statements, not between. Meanwhile, could someone please produce an example that shows how one would write, in SHACL and in the compact syntax: dct:subject must have a value that is the stem of any one of the following: http://id.loc.gov/subject/ http://en.wikipedia.org/ http://dbpedia.org/ kc > > I think there was a misunderstanding here. We could vote again, but > it'll be a -1 from me on your proposal anyway. Sorry. > > Holger > > >> >> >>> 2) In the PROPOSAL, Arnaud simply linked to Eric's specific email as a >>> placeholder for the discussion that happened. We have similar cases >>> and many >>> other rather informal PROPOSALs elsewhere. >>> >>> 3) People glancing over the email link only saw the first proposal, >>> not the >>> second one further down. And even the first proposal was misleading >>> due to >>> the syntax variations. >>> >>> Although I cannot formally prove how we got there, my verdict is >>> quite clear >>> that the current draft does reflect what we really voted on at the time. >>> Since exclusions and disjunctions are easily covered by sh:or and >>> sh:not I >>> do not think we need to change the current draft, and we could even >>> delete >>> sh:stem if it doesn't provide enough value over sh:pattern. >>> >>> Dimitris, you did the actual edits. Do you remember anything about the >>> history? >>> >>> Thanks, >>> Holger >>> > > > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
Received on Friday, 18 November 2016 15:53:38 UTC