ISSUE-194: sh:stem implementation

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.

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