Re: ISSUE-194: sh:stem implementation

On Fri, Nov 18, 2016 at 7:48 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

> 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
> email https://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/0e6ed4d3692e30bd02cfc3f321fe5c
> 118b6b5d3e
>
> 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?
>

Although I was missing from the discussion about sh:stem yesterday I recall
voting for sh:stem as a simple shortcut for sh:pattern and sh:nodekind
sh:IRI.
I also confirm that I understood the addition of sh:stem as a simple
one-argument constraint and not with nested values
I also recall talking that Eric's example was based on Peter's syntax

Best,
Dimitris


>
> Thanks,
> Holger
>
>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects: http://dbpedia.org, http://rdfunit.aksw.org,
http://aligned-project.eu
Homepage: http://aksw.org/DimitrisKontokostas
Research Group: AKSW/KILT http://aksw.org/Groups/KILT