<AndyS> scribenick: AndyS

<scribe> scribe: Andy Seaborne

Admin

<Arnaud> PROPOSED: Approve minutes of the 30 Nov 2016 Telecon: http://www.w3.org/2016/11/30-shapes-minutes.html

RESOLUTION: Approve minutes of the 30 Nov 2016 Telecon: http://www.w3.org/2016/11/30-shapes-minutes.html

next meeting : maybe December 21 : Arnaud and EricP can not make it.

Offer of chair?

Arnaud: take this to email

Review of edits.

holger: mostly editorial MUST, SHOULD etc.
... (1) now don't say that TTL file is normative. It is a placeholder for when the namespace is published.
... (2) sh:in can take blank nodes as list members : symmetry with sh:value.

arnaud: test - is an impl changed?

<ericP> an edit would be editorial if there were no credible interpretation in one version and the edit changes that interpretation

arnaud: at the moment, this is about highlighting a change - not full CR republish. (this is advice, not full W3C process)

kcoyle: I have been suggesting editorial changes

<Dimitris> Karen, I will follow up on those suggestions

WG Outlook

arnaud: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Dec/0045.html
... W3C has changed. Less keen on extensions.
... now a AC discussion. Not discretion of team/director.
... harder to launch a WG.
... now prefer to incubator (in a CG)
... if applied to shapes, we'd need more polished input.
... need to deliver REC by June <- PR by April <- CR by February
... in effect one month.
... team has reviewed the spec : core clearer, SPARQL less clear.
... not about whether full is useful. This is a mgt tactic
... user feedback on comment list
... user feedback on comment list
... my suggestion is drop shex/shacl alignment despite all the work that has been done to align shex and shacl.
... shex has a CG and has a published spec https://shexspec.github.io/spec
... if don't get to REC, may change gear to move to CG - open to all - more open on process.
... mature spec, and come back to W3C.

<Labra> +present labra

arnaud: WG publishes as "WG Note"s - exports the IP. License allows a fork of the content.
... re: comments. Now there is no LC stage, comments must be handled during WG lifetime. (This is a burden on any and all WGs now)
... holger - can we split the spec?

<Arnaud> STRAWPOLL: separate Core from SPARQL extension

andys: how much less work would there be if split ?

arnaud: less process , less new issues (there are people waiting to comment)
... we need full test suite
... sets the bar higher.
... team suggestions is driven by making the spec smaller.

kcoyle: is the issue they too intertwined?

dimitris: two docs requires some work but possible.

holger: concerned about the metamodel. Uses same namespace.

arnaud: namespace should not be a problem. Can add to existing namespaces.

<Arnaud> STRAWPOLL: separate Core from SPARQL extension

<hknublau> -1

arnaud: minor aspect - wanted to be clear.

<ericP> +1

arnaud: minor aspect - wanted to be clear.

strawpoll

<Labra> +1

<kcoyle> +.9

<TallTed> +0.5

<Dimitris> 0

<marqh> -0.5

<pano> -1

<TallTed> "separate Core from Extension" is a better phrasing

<ipolikoff> -1

holger: more meeting time? There are proposal made, the limitation is meeting time at the moment.

arnaud: already doing 2h calls - concerned if people would turn up.

andys: do more meeting prep on proposals??

arnaud: have tried this but seems people are time-short.
... wiki proposal page is good.
... it is not happen though (not fast enough anyway).

Disposal of raised issues

<Arnaud> PROPOSED: Open ISSUE-215, ISSUE-216, ISSUE-217

<kcoyle> +1

<Dimitris> +1

andys: takes time to go full cycle to get confirmation from issue raiser

<ericP> +1

arnaud: we need to give reasonable time to confirm - that is enough
... one way is to use github issues
... become listed and threaded with no people-work.
... "close" signals to commenter and they can reopen/comment more.

<hknublau> That would be risky IMHO. We could get flooded.

arnaud: old way - wiki page - karen has done a lot work to keep that up to date.

<hknublau> +1

<pano> +1

<TallTed> +1

<Labra> +1

RESOLUTION: Open ISSUE-215, ISSUE-216, ISSUE-217

ISSUE-211: Eliminate property constraints

https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-211:_Eliminate_property_constraints

arnaud: dimitris has put a proposal togther ; holger is against.
... ask for brief summaries from editors

<ericP> Dimitris: i counted and we had 5 or 7k email with an average of about 12/day.

dimitris: seems people not able to keep up with the email.
... current design is OOP-style.
... but RDF is not OOP
... works for 95% but last 5% is hard -- pfps comments
... we have two defn (section 2) anyway.
... for timeline, we need to compromise. A change is a simpler metamodel.
... precise and better than what we have at the moment.
... more robust for CR

arnaud: questions on proposal?

kcoyle: like idea of moving away from OOP but can't undertand the implications and work load?

<ipolikoff> +q

dimitris: section 2 mostly. Remove sh:property. Can keep for compatibility else use sh:shape.

<Dimitris> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Dec/att-0053/shape-control.text

<Dimitris> here is the re-write of the spec from Peter

ipolikoff: not clear as to benefits

dimitris: simplifies, so less bugs

<ericP> it moves us away from the OOP paradigm which is controversial when applied to RDF

arnaud: benefit is not only about convenience

ipolikoff: if more things allowed, there is more possibilities to shapes and so more testing etc

arnaud: there are different interpretations of the proposal
... the proposal addresses the root cause of many current and future issues
... risks other issues arising

kcoyle: this week is first time OOP has been mentioned

ipolikoff: not an implementation restriction

TallTed: while don't have complete comprehension - does seem to be an improvement
... users will write all possible things a spec allows. Need to handle even "strange" cases.

holger: not an OOP design - but can be understood by people with an OO background.
... 211 looses this way to understand SHACL.
... process issue - stable design for 6months now. Some feedback, some implementation.
... no feedback suggests this change.
... high risk to make this change.
... 5% cases required one sentence to address in current design
... sh:property changes many existing shapes already written
... metamodel - had a long discussion already
... we had an agreement
... There are differences: shapes can be closed, property constraints can't be.
... this is undoing that agreement which was already a compromise.
... implementation impact - performance and complexity

arnaud: on one point - process - valid concern about time - many new issues is grounds for revisiting to see if there is a better way.

<Dimitris> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Dec/att-0053/shape-control.text

holger: another way to explain SHACL ... useful input ... not clear there is simplicity
... no explanatory prose
... no examples

marqh: tend towards evolution rather revolution
... useful input to give a formal description - can we use that material is current spec?
... need more sense of why this is better at this moment

arnaud: better to make a decision at this point

<Arnaud> PROPOSAL: Close ISSUE-211 adopting a variation of Peter's suggestion as described in https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Dec/0021.html . The new metamodel diagram: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Dec/att-0040/diagram.png . A re-write of the spec from Peter for his original proposal is https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Dec/att-0053/shape-control.text , the proposed variat[CUT]

<hknublau> -1

<kcoyle> +1

<Dimitris> +1

<ericP> +1

<Labra> +1

<marqh> -0.5

<ipolikoff> -.9

<TallTed> +0.8

<pano> -1

-0.5

<Arnaud> PROPOSAL: Close ISSUE-211 as already discussed (extensively) and too late for such a fundamental change, see https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0117.html

<hknublau> +1

<kcoyle> -0

<ipolikoff> +1

<ericP> -.5

<marqh> 0

0

<Dimitris> -.5

<TallTed> -0.5

<pano> +1

<Labra> -0.5

RESOLUTION: Close ISSUE-211 as already discussed (extensively) and too late for such a fundamental change, see https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0117.html

ISSUE-197

https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-197:_Defined

<ericP> scribenick: ericP

<scribe> scribe: Eric Prud'hommeaux

hknublau: i agreed with trying to avoid the sense of definition
... but when someone puts a term into an RDF graph, this is at most a declaration

Arnaud: there aren't mamy votes on the associated proposal but hknublau says we can close the issue as is

<kcoyle> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0149.html

kcoyle: i had questions which i don't believe were answered
... i pointed out places where i thought that "define" was being use incorrectly.
... i don't know if those changes got made but there were sentences i didn't understand.

<Arnaud> PROPOSED: Close ISSUE-197 as resolved by https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0130.html

<hknublau> +1

hknublau: i've followed the spirit of karen's advice; not sure if i responded.

<kcoyle> +.5 (I'll check later)

<hknublau> (I will check her email again)

<pano> +1

<ipolikoff> +1

<ipolikoff> have to leave now, sorry

<TallTed> +1

<Dimitris> +1

<Labra> +

<Labra> +0

RESOLUTION: Close ISSUE-197 as resolved by https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0130.html

ISSUE-209

<trackbot> issue-209 -- What is a shape -- open

<trackbot> http://www.w3.org/2014/data-shapes/track/issues/209

Arnaud: we've discussed this in different ways.
... it keeps popping back up when someone says the doc is not clear on this.

hknublau: we're saying that a shape is a node.
... we're doing the same thing for every other term.
... if we say "a shape is a resource", i.e. that it lives in the real world, we'd have to do that everywhere
... pfps proposed the terminology we use
... shapes can have values while resources cannot

Arnaud: we don't have to wait for pfps to bless our resolutions before closing issues.
... but it's better if we hear some closure
... he's demonstrated that he'll scream if we don't address his issues

Dimitris: we have to restructure section 2 anyways
... so we need to redefine a shape anyways

hknublau: but that's issue-212, removing focus constraint

Arnaud, should we try to close issue-212 first?

hknublau: won't change anything

<Arnaud> PROPOSED: Close ISSUE-209 as addressed by https://github.com/w3c/data-shapes/commit/bec7b6852529acc80954dbc38cf4e435861238a2

<hknublau> +1

kcoyle: not sure how to vote on this before issue-212

ISSUE-212

<trackbot> issue-212 -- Property constraints and focus node constraints -- open

<trackbot> http://www.w3.org/2014/data-shapes/track/issues/212

hknublau: we may have made an editorial mistake in introducing "focus node constraint"
... in the old design, we had a sh:constraint property linking a node to a constraint
... we didn't discard focus node constraint
... there's a section on it but it's basically emtpy so it could be merged with shape
... folks just need to be aware that shapes double as constraints

kcoyle: apart from getting rid of focus node constraint, i think that shapes should not be constraints

marqh: trying to sift through the doc and haven't found an answer to "what's a focus node?"

kcoyle: maybe in 2.2?

<Arnaud> http://w3c.github.io/data-shapes/shacl/#focusNodes

hknublau: that's the official definition [reads]
... later on we say how it can be derived using targets, etc.
... there's not much more we can say about it; it's basically a random node that is a parameter to validation

<Arnaud> PROPOSED: Close ISSUE-212 as resolved by https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0129.html and replace the term "focus node constraint" with "shape" throughout the document.

marqh: the definition of focus node constraint doesn't jump out at me as clear.
... i support the proposal

<hknublau> +1

<kcoyle> -.5

<marqh> +1

<Dimitris> -.5

<pano> +1

<TallTed> +1

kcoyle: will there be more text added to Shape to cover this?

hknublau: i think we can restructure this section by describing the commonalities, e.g. every constraint has a severity and a message

marqh: is it worth opening an issue with the scribed two-line summary?

Arnaud: agreed. maybe in the resolution for issue-209, we can capture hknublau's text

RESOLUTION: Close ISSUE-212 as resolved by https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0129.html and replace the term "focus node constraint" with "shape" throughout the document.

ISSUE-209

<trackbot> issue-209 -- What is a shape -- open

<trackbot> http://www.w3.org/2014/data-shapes/track/issues/209

<Arnaud> PROPOSED: Close ISSUE-209 as addressed by https://github.com/w3c/data-shapes/commit/bec7b6852529acc80954dbc38cf4e435861238a2 plus restructure of Focus node section by describing the commonalities, e.g. every constraint has a severity and a message

<Arnaud> PROPOSED: Close ISSUE-209 as addressed by https://github.com/w3c/data-shapes/commit/bec7b6852529acc80954dbc38cf4e435861238a2 plus restructure of Focus node and Shapes sections by describing the commonalities, e.g. every constraint has a severity and a message

<hknublau> +1

<kcoyle> 0

<pano> +1

<TallTed> +0.5

<Dimitris> 0

<Labra> 0

RESOLUTION: Close ISSUE-209 as addressed by https://github.com/w3c/data-shapes/commit/bec7b6852529acc80954dbc38cf4e435861238a2 plus restructure of Focus node and Shapes sections by describing the commonalities, e.g. every constraint has a severity

Arnaud: we can examine the implementation when the editors summarize their edits

<Arnaud> trackbot, end meeting