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

Re: ISSUE-194: sh:stem implementation

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>
Message-ID: <699bc6f2-2be9-04f2-4fd9-2228060c066b@topquadrant.com>


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:38 UTC