- From: Holger Knublauch <holger@topquadrant.com>
- Date: Fri, 18 Nov 2016 16:57:32 +1000
- To: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
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). 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 >>
Received on Friday, 18 November 2016 06:58:09 UTC