See also: IRC log
<Arnaud> I'm fighting with webex myself...
<scribe> scribenick: dimitris
<Arnaud> PROPOSED: Approve minutes of the 21 July 2016 Telecon: http://www.w3.org/2016/07/21-shapes-minutes.html
RESOLUTION: Approve minutes of the 21 July 2016 Telecon: http://www.w3.org/2016/07/21-shapes-minutes.html
Arnaud: we meet again next week
<Arnaud> PROPOSED: Open ISSUE-175
<hknublau> +1
Arnaud: Dimitris raised an issue and put together some proposals for renaming the term scope
+1
<kcoyle> +1
RESOLUTION: Open ISSUE-175
scribe: let's open it but should try and close it next week
<Arnaud> PROPOSED: Close ISSUE-134 as no longer relevant
Arnaud: Looks like this has become irrelevant with the choices we made
<TallTed> +1
<pano> +1
+1
<kcoyle> +1
kcoyle: have we accepted the proposal for the property path generalization and can anyone point to that?
Dimitris: yes
Kcoyle: I can look up the resolution
<kcoyle> https://www.w3.org/2016/06/30-shapes-minutes.html#resolution04
<kcoyle> we can hear you
<kcoyle> maybe time to retire?
RESOLUTION: Close ISSUE-134 as no longer relevant
<hknublau_> +1
Arnaud: When can we publish a new SHACL draft?
... how much time do the editors need?
hknublau: I think issue 133 will have a big impact and then the renaming of scope
... after these are resolved mostly readability and editorial issues will remain
Arnaud: we can decide if we delay 133 and 175
dimitris: I think we should delay a couple of weeks to make the syntax stable
Arnaud: The abstract syntax was improved to tackle the issues we discussed last week but people should check the new document
kcoyle: I would like to hear from people what they think about it
Arnaud: I'd like us to agree on a plan
ericp: there are many buttons that can hide different things in the document
<Zakim> ericP, you wanted to say i'd love to rescue the word "parameters"
Dimitris: I noticed some duplication in the examples, would be nice to align them
<hknublau_> Thanks @ericP to the collapse button for the BNF
ericP: Scoping was a reason for duplication
... would be nice to make the validation work without explicit scopes
Dimitris: There was already an issue about this by Holger
hknublau: It is useful but since we are keep changing at the moment and syncing is not easy
Arnaud: can we somehow automate the syncing
ericP: Scala would be an option
<TallTed> "Nary" should become "N-ary" ... https://en.wikipedia.org/wiki/Arity "Nary" has meanings other than intended.
<kcoyle> thx ted
Arnaud: Holger and Dimitris should signal when you are done so that Eric and Karen can start
Ericp: I will do another pass at naming things
... like parameters / arguments
tallted: if you want to change terminology you should make a complete proposal
Arnaud: I agree with Ted, if you want to rename something make a concrete proposal, at this point we should be very precise
<ericP> TallTed, s/nary/n-ary/g done
Arnaud: last week we had a strawpoll and the WG was divided with a slight preference for merging Shapes and NodeConstraints
kcoyle: with Shape becoming a subclass of Constraint it doesn't work for me because we have shapes at different levels
... I need someone to explain to me how this works when constraints contain constraints
... at this point shapes look shapeless
hknublau: we already have this situation anyway, shapes can point to NodeConstraints and NodeConstraints can point to Shapes
... it depends on if we agree if a Shape is actually a big constraints
... it is like an AND construct
... from this point of view merging makes sense
kcoyle: then why do we still have constraint?
... so Shape is a Constraint
hknublau: before we had sh:constraint to link to a NodeConstraint but now we attach directly to the shape
EricP: the problem was with filters I think that was not clear if filters had filters what is happening
<Arnaud> https://www.w3.org/2016/07/21-shapes-minutes.html#item04
<kcoyle> I think that's what I see, too
<Arnaud> STRAWPOLL: a) merge Shape and NodeConstraint, b) don't merge Shape and NodeConstraint
Arnaud: this merge collapses concepts
Dimitris: I also like to keep things separate
<hknublau_> a) +1 b) -0.7
<kcoyle> a) -.9 b) +1
a) -0 b) +1
<TallTed> a +1 b -1
<pano> a:+1 b:0
<ericP> a) -.9
<ericP> a) -.9 b) +1
Arnaud: what do we do with the strawpoll now? Either one would pass because noone has objected firmly
... Eric, how is this related to ShEx?
EricP: this will not change the abstract syntax, this is less about the alignment with ShEx
<Arnaud> PROPOSED: merge Shape and NodeConstraint
<hknublau_> +1
<pano> +1
<TallTed> +1
-0
<kcoyle> -.9
<ericP> -.9
RESOLUTION: Merge Shape and NodeConstraint
Arnaud: with that done we can close issue 133, right?
<Arnaud> PROPOSED: Close ISSUE-133, based on the series of related resolutions
<hknublau_> +1
hknublau: there are a couple of follow-up issues mentioned in my email but can be treated separate
+1
<pano> +1
<kcoyle> +1
RESOLUTION: Close ISSUE-133, based on the series of related resolutions
hknublau: with the merging sh:or is simpler and we can drop sh:datatypeIn and sh:classIn
<Arnaud> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jul/0076.html
<trackbot> issue-135 -- Should sh:and/sh:or/sh:not/sh:valueShape support constraints too? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/135
hknublau: and another issue is if sh:and/or point to constraints which is indirectly resolved
<Arnaud> PROPOSED: Close ISSUE-135, no longer relevant
+1
<pano> +1
<hknublau_> +1
<TallTed> +1
<kcoyle> +1
RESOLUTION: Close ISSUE-135, no longer relevant
<trackbot> issue-141 -- How to represent mixed datatype-or-class ranges -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/141
PROPOSED: remove sh:datatypeIn and sh:classIn components as they can be expressed with sh:or
<hknublau_> +1
+1
<ericP> +1
ericP: should we remove sh:in as well
<TallTed> +1
<pano> 0
hknublau: sh:in is useful and I would keep it
<kcoyle> 0
RESOLUTION: Remove sh:datatypeIn and sh:classIn components as they can be expressed with sh:or
<Arnaud> PROPOSED: Close ISSUE-141, mixed ranges can now be uniformly handled
PROPOSED: close issue 141, mixed ranges can be expressed with sh:or
<hknublau_> +1
+1
<TallTed> +1
<ericP> +1
<pano> 0
<kcoyle> +1
RESOLUTION: Close issue 141, mixed ranges can be expressed with sh:or
<hknublau_> Wow, we are on a run. Should we handle the scope naming issue next?
Arnaud: let's talk about nested severities
https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jul/0079.html
EricP, I had an action item to see how ShEx people would do it and they said they avoid it
<Arnaud> action-37
<trackbot> action-37 -- Eric Prud'hommeaux to Check what happens in the shex extension that has severities -- due 2016-05-26 -- OPEN
<trackbot> http://www.w3.org/2014/data-shapes/track/actions/37
<Arnaud> issue-150
<trackbot> issue-150 -- Treatment of nested severities -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/150
Arnaud: Dimitris sent an email with his preferences
<Arnaud> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jul/0079.html
<kcoyle> lowest = least severe?
b) Use the outer, unless the inner was lower e.g.
outer: Warning, inner: Info -> use Info
... Warning, inner: Violation -> use Warning
kcoyle: I would want the opposite of what Dimitris prefers, the most severe
... if it is inner or outer, the most severe should win
Arnaud: there are different dimensions
kcoyle: but we need to make it very clear
hknublau: I think the current spec is OK for me, if an nested object returns a violation there are many cases where we want to override
... I need some time to look into this in more detail
TallTed: I think the conceptualization of this is key
... I have data about people and require an address
... within the address I can allow a city or state, or more details, if the inner shape is the address
... my address shape must have a street address
<hknublau_> sh:shape may even take a companion parameter to specify the minimum severity.
TallTed: the violation of the inner shape should not mean that the outer shape is broken
<Arnaud> trackbot, end meeting