See also: IRC log
<scribe> scribenick: hknublau
<ericP> PROPOSED: Approve minutes of the 26 Oct 2016 Telecon: http://www.w3.org/2016/10/26-shapes-minutes
<kcoyle> +1
+1
RESOLUTION: Approve minutes of the 26 Oct 2016 Telecon: http://www.w3.org/2016/10/26-shapes-minutes
Discussing whether we could move the meeting 30 minutes earlier
<ericP> STRAWPOLL: can folks meet 30 mins earlier?
<ericP> yes
<kcoyle> ok
<simonstey> yes
<pano> yes
yes pls
<TallTed> reasonably likely
<ericP> STRAWPOLL: virtual F2F 16 Nov 08:00-12:00 EST
<ericP> ok
<kcoyle> ok
ok
<simonstey> ok
<pano> ok
<TallTed> should be ok
<ericP> ISSUE-193
<trackbot> ISSUE-193 -- Targets can be refined; focus nodes do not change -- raised
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/193
ericP: (confirming the definition of focus nodes, value nodes)
<ericP> ericP: validation of a node as a shape starts with the node as the "focus node"; node constraints are evaluated with "value" as the focus node; path constraints treat the other end of the path as the "value"; recursive shapes treat the value as the focus node.
<ericP> PROPOSED: open ISSUE-193
+1
<ericP> +1
<pano> +1
<kcoyle> +1
<TallTed> +1
RESOLUTION: open ISSUE-193
<trackbot> issue-140 -- SHACL needs to support validation of individual nodes -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/140
ericP: (Summary of previous discussion on ISSUE-140)
<ericP> hknublau: i believe the problem you see with targets hindering reuse isn't a big issue. just add another targetClass for the class you want
<ericP> ericP: but if the shape has a targetClass of e.g. foaf:Person and i don't want to apply to all of them...
<ericP> hknublau: add a filterClass
kcoyle: We don't have to argue about which one will win
... both have use cases
... spec states there can be zero or more targets, without saying what zero targets looks like
hknublau: people can already do that, with named graphs
kcoyle: interesting idea but very different to what SHACL currently does
<Zakim> ericP, you wanted to propose moving the target* out to a control graph
kcoyle: examples should not show targets
... An explanation should be given
... "some of the following examples show how it looks without targets"
... implicit statement should be made explicit
ericP: Sounds good, I support putting a section into the target section
TallTed: Best compromise would be to show both patterns
kcoyle: what about progressively
TallTed: makes sense if things are additive
<simonstey> http://w3c.github.io/data-shapes/shacl/#targets
simonstey: does it make sense to have constraints without targets
<Zakim> ericP, you wanted to say that when we got the feedback about showing which nodes selections before we had tables with node/shape validation results
ericP: in ShEx we rarely state a relation between a node and a shape
... we now have an API invocation convention
<simonstey> +q
kcoyle: What Simon said is half true. With property constraints you target a specific property.
hknublau: even for property constraints, you'd still need something like sh:targetSubjectOf
<ericP> 1st API-style example
<ericP> 1+
(Totally lost scribing)
No resolution, editor waiting for specific input on what to add
<ericP> ISSUE-188
<trackbot> ISSUE-188 -- "Validation" needs to be defined -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/188
kcoyle: the term validation (in English) is tricky - to make something true
... unfortunately used with different definitions,
... I had made a proposal on how to reformulate things
... only use one meaning of validation
... alternative: call validation -> "comparison"
<Zakim> ericP, you wanted to propose "verification"
ericP: I propose verification
hknublau: what about "checking"? Constraint checking sounds natural to me.
kcoyle: checking is a little informal
hknublau: Sounds like yet another editorial issue that is hard to discuss without looking at details
kcoyle: I'll work on a proposal / branch
<ericP> ACTION: kcoyle to fork an experiment without "validation" [recorded in http://www.w3.org/2016/11/02-shapes-minutes.html#action01]
<trackbot> Created ACTION-44 - Fork an experiment without "validation" [on Karen Coyle - due 2016-11-09].
<ericP> ISSUE-191
<trackbot> ISSUE-191 -- Should the value types of parameters be constraints -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/191
https://github.com/w3c/data-shapes/commit/292f12936181ca2d3fd5c096a7880f2de6054f02
<ericP> hknublau: follow the link in the issue to the commit
<ericP> ... pfps was unhappy with the way we specified the permissible value types for Parameters (e.g. minCount takes an integer)
<ericP> ... this edit <https://github.com/w3c/data-shapes/commit/292f12936181ca2d3fd5c096a7880f2de6054f02> is in the editor's draft
<ericP> ... whenever there's a clear constraint (e.g. "takes an integer"), i've added text in front to say "the value of blah blah is a foo".
<ericP> ... when it's not clear, i've not changed anything
<ericP> ... so this says that a shapes graph with a float minCount is invalid
<ericP> ... all ok with this edit?
kcoyle: what about upper case MUST etc?
<ericP> kcoyle: are we upper-casing 2119 keywords?
<simonstey> The key words MAY, MUST, OPTIONAL, and REQUIRED are to be interpreted as described in [RFC2119].
hknublau: I am never sure about this. It would be a huge edit to do this everywhere.
<simonstey> +q
<simonstey> -q
<simonstey> +1 to teds point
<ericP> hknublau: pfps said 2119 should be about tool conformance
<ericP> TallTed: i think here we don't say MUST; we say "is"
TallTed: MUST would be wrong to use here
ericP: SPARQL uses them minimally, TTL doesn't use it at all
Arnaud: Replace must with "is"
... MUST is for the engine/implementation. Don't use it for the description of the language.
<ericP> PROPOSED: editors replace 2119 keywords with "is" when describing the language
<TallTed> "The values of … must be …" change to "The values of … are …"
<ericP> PROPOSED: close ISSUE-191 accepting <https://github.com/w3c/data-shapes/commit/292f12936181ca2d3fd5c096a7880f2de6054f02> modulo changing 2119 keywords
+1
<ericP> +1
<TallTed> +1
<kcoyle> +1
<pano> +1
RESOLUTION: close ISSUE-191 accepting <https://github.com/w3c/data-shapes/commit/292f12936181ca2d3fd5c096a7880f2de6054f02> modulo changing 2119 keywords
<ericP> ISSUE-192\
<trackbot> ISSUE-192 -- Should filter shapes be of type sh:Shape? if not, then what? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/192
kcoyle: this was a long discussion
<kcoyle> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Oct/0139.html
kcoyle: I still have (editorial) issues, but I am OK with moving on.
simonstey: echoing Arnaud's view on MUST
... not native English speakers have it easier here, because we don't get these fine differences
... goes back to shapes without target - needs to be referenced from another shape (e.g. sh:shape).
... otherwise you'd need a target.
<Arnaud> for what it's worth, I share Karen's confusion about the way this is written
Please suggest better wording.
<ericP> ACTION: kcoyle to propose text for ISSUE-192 [recorded in http://www.w3.org/2016/11/02-shapes-minutes.html#action02]
<trackbot> Created ACTION-45 - Propose text for issue-192 [on Karen Coyle - due 2016-11-09].
<Arnaud> trackbot, end meeting