See also: IRC log
scripenick: pfps
<scribe> scribenick: pfps
<Arnaud> PROPOSED: Approve minutes of the 12 May 2016 Telecon: http://www.w3.org/2016/05/12-shapes-minutes.html
minutes looked acceptable
+1
RESOLUTION: Approve minutes of the 12 May 2016 Telecon: http://www.w3.org/2016/05/12-shapes-minutes.html
arnaud: mailing list
... non-WG members are able to post to the mailing list
eric: new W3C policy is do what you want
... the working group is now member-only
... hopefully no one is being bounced by using an address different from their W3C address
<Labra> +present: labra
arnaud: one reason to limit the list is to easily see what can be included in the working group output
arnaud: tom baker sent in a long comment and the WG discussed it a couple of weeks ago
... I responded thanking him and saying that the WG is working on his comments
... peter sent in a potential response
... a response to tom would help the WG look at some of our issues
... maybe it is just more important for the wg to think about tom's comments
... what should the wg do here? just take tom's comments under advisement or try to respond directly?
pfps: tom is the only really substantive after the FPWD so we ignore his concerns at our peril, I think
eric: if there is no formal response then there is the possibility of doing nothing substantive
arnaud: the wg could raise issues where appropriate
pfps: that would work for me and I am willing to raise these issues
karen: I haven't looked at tom's comments as issues
arnaud: peter has some responses and some "needs work" bits
... what should the process be for tom's comments
... I suggest raising issues for parts that need to be done
marqh: I like providing a response linking to issues
arnaud: let's proceed that way
<marqh> +present: marqh
pfps: much of tom's comments have to do with the presentation of SHACL at the beginning of the spec and this reiterates comments from the working group
... at some point very soon the spec has to be readable by non-WG members and it's not now
arnaud: isn't the working group discussion
pfps: there is discussion about wording - "constraint" vs "validate" etc
... the spec needs a good introduction
markh: there should be an issue on this point
pfps: I'll create an issue on this
karen: needing a good introduction is one thing
... tom is concerned about some technical points - variation from RDF
arnaud: we are not done with the spec so there is still work to be done related to all this
... some of these are editorial issues, some may not be
... please look over tom's comments and see if there are issues to be raised there
ISSUE-141
<trackbot> ISSUE-141 -- How to represent mixed datatype-or-class ranges -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/141
arnaud: we discussed this last week
... the major seems to favor option 3a
https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-141:_Mixed_ranges
holger: I suggest that we postpone this as it depends on the other syntax changes
... if there is a convenient syntax for "string or postal address" then the need for this is very reduced
+1
<kcoyle_> +1
<TallTed> +1
ISSUE-133
<trackbot> ISSUE-133 -- syntax simplification and regularization -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/133
arnaud: there has been discussion on different aspects of syntax simplification
... this needs to be resolved so that progress can be made elsewhere
holger: there seem to be at least there syntax issues that are uncontroversial
... sparql constraints, property scope, and value shape
pfps: I don't have issues with these, I think, but they are infinitesimals compared to significant progress
holger: I think that there is substantial progress here
arnaud: is there more than what holger listed that is non-controversial
<hknublau> PROPOSAL: Close ISSUE-160, generalizing sh:valueShape into sh:shape, also allowing it for node constraints
<hknublau> +1
<Arnaud> issue-160
<trackbot> issue-160 -- Shall we generalize sh:valueShape to sh:shape -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/160
pfps: this is "implementation" to clear the way for synatx changes - if this is supposed to be done to help fix then syntax, then it lives or dies on whether the syntax change is a good idea, so that should be discussed first
karen: I'm not clear why sh:valueShape is actually needed, what does it do that has to be done and are there any other options
holger: I believe that this is the easiest way to check a value for embedded shapes
pfps: my apologies, please ignore my last comment
karen: this is a way to have a shape within a shape
https://w3c.github.io/data-shapes/shacl/#ValueShapeConstraintComponent
pfps: what would sh:value provide?
holger: the proposal is to generalize to allow other kinds of constraints
pfps: this is a slogan not a proposal - to make this change requires some notion of how this new thing works
holger: isn't it obvious
pfps: not at all - I often cannot come up with intuitions behind changes and thus I don't know what is being proposed unless the details are provided
arnaud: a one-line explanation is often not adequate
... what can we do now?
pfps: I feel that there is problem with the intuitions underlying SHACL
... fixing them requires a revolution not an evolution
karen: the way that I came up with a lot of the questions was that I was trying to figure out what SHACL was and I was unable to do so
TallTed: let's move on
arnaud: but how to move on?
marqh: I'm quite taken with Karen's suggestion - a primer would have to provide the notions underlying SHACL
... and problems generating it would provide issues with the spec
arnaud: so do you have a start for the primer, karen
karen: probably - I can put what I have on github, after some sanity checking
arnaud: I encourage you to share early
karen: I'll send a message to the list when I've done this
marqh: perhaps a primer issue would help
karen: I can do that as well
arnaud: that can't hurt
pfps: issue-150 is on the agenda but I don't know if we have enough people to talk about that
arnaud: this needs to be addressed, but it is not a central issue
<trackbot> issue-150 -- Treatment of nested severities -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/150
<Arnaud> pfps: we've talked about severities a lot a while ago and I think Dimitris's question is actually answered in the spec
<Arnaud> pfps: but there is an issue: if you want to do a lint type of checker
<Arnaud> ... have some warnings
<Arnaud> ... there is trouble with nested shapes
<Arnaud> ... especially with negation
<Arnaud> ... the negation of a shape that is warning is everything is wrong
<Arnaud> ericP: you have a solution?
<Arnaud> pfps: what does ShEx do?
<Arnaud> ericP: we don't have severities
<Arnaud> pfps: I have an idea but haven't figured out whether it works all the time
<Arnaud> ... or if there are gotchas somewhere
<Arnaud> ericP: is there a body of work we can draw from?
<Arnaud> pfps: no
<Arnaud> ... the best place to look at is exceptions in programing languages
pfps: one way forward is that instead of looking for violations, instead look for a severity at least as strong as the current severity
<ericP> <IssueShape> { "error" is:submitter @<UserShape> } <UserShape> { "informational" foaf:name LITERAL } \ { <issue> is:submitter [ foaf:notName "Bob" ] }
pfps: I would have to look at this off line
marqh: how important are severities - there are only three
... if there are lots of warnings then no one looks at them
... when would non-violations be needed?
<Zakim> ericP, you wanted to say this is a longshot but what can you manage this by rewrites instead of dynamic paramaters to sh:hasShape?
arnaud: there have been discussions about how many different levels to have
eric: rewrite as nested shapes
pfps: maybe but there still needs to be a spec on how it all works
... I think that the spec says what happens - the question is whether this is the right thing
<scribe> ACTION: eric to check what happens in the ShEx extension that has severities [recorded in http://www.w3.org/2016/05/19-shapes-minutes.html#action01]
<trackbot> Created ACTION-37 - Check what happens in the shex extension that has severities [on Eric Prud'hommeaux - due 2016-05-26].
arnaud: maybe we can learn from the way that ShEx does this
... we'll talk next week about publishing the draft
<Arnaud> trackbot, end meeting
<Labra> exit