Re: ISSUE-194: sh:stem implementation

* 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).


> 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
> 

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Friday, 18 November 2016 06:44:35 UTC