<TallTed> scribenick: ipolikof

<TallTed> PROPOSED: Approve minutes of the 22 Feb 2017 Telecon: https://www.w3.org/2017/02/22-shapes-minutes.html

+1

<sandro> +1 minutes

<hknublau> +1

RESOLUTION: Approve minutes of the 22 Feb 2017 Telecon: https://www.w3.org/2017/02/22-shapes-minutes.html

<TallTed> PROPOSED: OPEN https://www.w3.org/2014/data-shapes/track/issues/234 ISSUE-234

<hknublau> +1

+1

<pano> +1

<Dimitris> +1

RESOLUTION: OPEN https://www.w3.org/2014/data-shapes/track/issues/234 ISSUE-234

ISSUE-222

<TallTed> issue-222?

<trackbot> issue-222 -- Response to "On pre-binding" -- open

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

AndyS: 3 parts to the issue, two of them were subjects of discussion on SPARQL CG mailing list. Peter has no examples of a problem, but he is asking for a proof
... Asked Peter to help with a proof. He refused. There is some editorial work to do, but it doesn't change the solution
... The third part of comment is editorial comment for the SHACL document which has already been addressed by Holger

<sandro> +1 fine with not having a proof, but curious if Peter is trying to get at something else

AndyS: I don't know what details the proof could be based on, which is why I think Peter is building on sand

sandro: there is a way to refer to the CG report, but it is a concern because if CG changes a report, then SHACL implementations have to change

AndyS: It is better to copy the definition into SHACL document

sandro: Agree, the same happened with datasets, the definition first appeared in the SPARQL document, but then came back in the RDF document
... Is Peter asking to divide SHACL-SPARQL into a separate document so that it could be worked on more

TallTed: Spliting is work, we decided not to do it

Dimitris: I did the spliting draft 1.5 months ago, but it was decided not to use it

sandro: you can use "at risk" language, this allows you to make a change without going through another CR. Is it possible to mark whatever pre-binding impacts as being "at risk"?

TallTed: It sounds like it makes sense

<Dimitris> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2017Jan/0009.html

<Dimitris> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2017Jan/0015.html

hknublau: all of SHACL-SPARQL depends on pre-binding, where to draw the line?

sandro: we need to do so for all of SHACL SPARQL
... it is unusual to mark a large portion of the document as at risk. Is splitting really so difficult?

hknublau: yes, we have a generic extension mechanism, we could possibly split, but I am worried about the references and having it damage the overall flow of the document

<TallTed> PROPOSED: CLOSE ISSUE-222 by explicitly including the relevant definitions from EXISTS CG; marking SHACL-SPARQL at risk (laying groundwork for rec-track doc split if necessary after first CR)

AndyS: the definition of pre-binding is not going to change, but the details of description may change, what is in the SHACL document now should be already up to date

<hknublau> +1

<sandro> issue-222?

<trackbot> issue-222 -- Response to "On pre-binding" -- open

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

+.05

<AndyS> +1

<pano> +1

<Dimitris> +1

<sandro> +1 sounds like the best path, from what I'm hearing

<TallTed> +1

RESOLUTION: CLOSE ISSUE-222 by explicitly including the relevant definitions from EXISTS CG; marking SHACL-SPARQL at risk (laying groundwork for rec-track doc split if necessary after first CR)

<dallemang> +1

I will write a response to Peter

ISSUE-232

<TallTed> issue-232?

<trackbot> issue-232 -- Respec suggests a section on privacy and security -- open

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

hknublau: I started a wiki page

https://www.w3.org/2014/data-shapes/wiki/Security

hknublau: I have two possible issues, I can put them into a document, does anyone else has other ideas?

TallTed: If we don't hear anything, we could turn it into a section

<TallTed> PROPOSED: CLOSE ISSUE-232 to be satisfied by the content from https://www.w3.org/2014/data-shapes/wiki/Security, modulo editorial tweaks and later input

+1

<hknublau> +1

<pano> +1

<TallTed> +1

<Dimitris> +1

<dallemang> +1

RESOLUTION: CLOSE ISSUE-232 to be satisfied by the content from https://www.w3.org/2014/data-shapes/wiki/Security, modulo editorial tweaks and later input

pano: could not make much progress on JSON-LD context, hope to work on it next week and then we can discuss it

hknublau: it doesn't impact anything, we can close the issue with the action item open, the context will be a separate document on the web

ISSUE-226

<TallTed> PROPOSED: CLOSE ISSUE-226 to be addressed via ACTION-48, producing non-rec-track NOTE

<hknublau> +1

<pano> +1

<dallemang> +1

+1

<TallTed> +1

RESOLUTION: CLOSE ISSUE-226 to be addressed via ACTION-48, producing non-rec-track NOTE

<sandro> +1

<Dimitris> +1

<hknublau> https://www.w3.org/2014/data-shapes/wiki/ISSUE-234

ISSUE-234

nothing fundamentally new in Peter's e-mail: there are comments that are easy to respond to, mainly "editorial" changes, then there are issues he already raised before

https://www.w3.org/2014/data-shapes/wiki/ISSUE-234

<hknublau> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2017Mar/0002.html

hknublau: need help with points 36 and 37 brought up by Peter - validation results
... describes changes made to define conformance checking, issues with recursive results

<sandro> +1 sounds about right

<hknublau> https://github.com/w3c/data-shapes/commit/af5aedc5d3d0b669b916757423ee5f330a2c8800

does the edit address the main point of Peter's comments: if the result doesn't show in the report and a spec says it must happen, how do you test if it happened

hknublau: yes, I think I covered it

TallTed: there could be a comment that "nested validation results" are not defined

hknublau: I could take that out

<TallTed> "rely on conformance checking, effectively a sort of <dfn>nested</dfn> <a>validation result</a>."

<sandro> (Ping)

<ipolikof_> hknublau: give everyone a couple of days to look at the definition before I respond

<ipolikof_> TallTed: yes, this would be the best way to go

<TallTed> WG is asked to review and address draft response by March 3 - https://www.w3.org/2014/data-shapes/wiki/ISSUE-234

hknublau: Peter's comments about disjoint flag on QCRs, I wrote an e-mail about

TallTed: putting it into each QCR branch creates more clarity

QCR disjointness, https://lists.w3.org/Archives/Public/public-data-shapes-wg/2017Mar/0000.html

hknublau: It is more verbose, but gives us more flexibility and addresses Peter's objection on having to look elsewhere

TallTed: seems like a good idea

Dimitris: if you want this requirement in, it is OK with me, but it is a late change, I am not sure how to implement it
... it is a nice to have, but it is late to make such change, I will not object it
... It changes the way the implementation must work, you have to look into other shapes, I think it is useful, but have some concerns

hknublau: We have a similar situation with closed shapes

CR Process

TallTed: announcement to the public review list makes sense

<TallTed> draft Transition Request now in process at https://www.w3.org/2014/data-shapes/wiki/CR-Transition-Request

<TallTed> https://www.w3.org/2015/Process-20150901/#wide-review

should be re-publish the draft

sandro: yes, you probably should

TallTed: 4 weeks is not a hard requirements, so lets take 2 days to review the wiki, commit the change, publish the working draft and then make the announcement, falls mostly into Holger's hans, the rest of us should be reviewing the wiki

sandro: the transition request is looking pretty good, the biggest thing I am not quite sure about is in issues addressed. Ideally, one wants to see a table with the disposition of comments: we received these comments, here is how it was resolved, link to the issue if raised
... this is an enormous amount of work which is why other groups are moving to github
... how far back we have to go, used to be only for comments after the last call, I am not sure what the expectations are, may be we can start now after the new announcement
... I will get guidance on what would be enough
... let's not do anything until I get guidance
... do we think Peter may retract any formal objections

hknublau: he may retract the one about QCRs

if we bring back disjoint and equal for node shapes, there is no expressivity loss, so he may remove that objection as well

Dimitris: with this change we are acting pro-actively for SHACL users, we had a long discussion about it

sandro: is his objection about the loss of expressivity or because of the elegance?

loss of expressivity in case of disjoint and equal, this is the main objection, the other part is probably on principle

sandro: treatment of formal objection, needs to show that the working group considered the objection
... a wiki page for each formal objection so it is easy to understand each and what consideration it was given

hknublau: we should ask Peter if the changes for QCRs and allowing disjoint and equal for node shapes would remove his objections

<TallTed> PROPOSED: move sh:qualifiedValueShapesDisjoint statements from nodeShape or propertyShape, into each QCR branch

+1

<hknublau> +1

<TallTed> +1

<sandro> +1

+1

<pano> +1

RESOLUTION: move sh:qualifiedValueShapesDisjoint statements from nodeShape or propertyShape, into each QCR branch

<hknublau> PROPOSED: Remove the syntax rules that disallow sh:equals and sh:disjoint from node shapes.

<hknublau> 0

+.05

<TallTed> +1

<pano> +1

<sandro> +1 if it satisfies peter's FO

<dallemang> +1

<Dimitris> +1 (I would still prefer all)

<sandro> +0 if it doesn't

RESOLUTION: Remove the syntax rules that disallow sh:equals and sh:disjoint from node shapes

<TallTed> PROPOSED: publish we-hope-the-last Working Draft Friday, incorporating changes for ISSUE-234, etc., immediately followed by wide-review request

+1

<pano> +1

<hknublau> +1

<TallTed> +1

<sandro> +1

<Dimitris> +1

RESOLUTION: publish we-hope-the-last Working Draft Friday, incorporating changes for ISSUE-234, etc., immediately followed by wide-review request

sandro: did we do anything on internalization

hknublau: I looked at it and I don't think there is any impact

sandro: this is great, but we need to notify them

hknublau: I will do the notification

Dimitris: I have been traveling a lot and my workload have exploded, my contribution going forward will be limited

<TallTed> ADJOURNED

<TallTed> trackbot, end meeting

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/WG asked/WG is asked/
Succeeded: s/objects/formal objections/
Default Present: hknublau, TallTed, Dimitris, ipolikof, AndyS, sandro, pano, .05
Present: hknublau TallTed Dimitris ipolikof AndyS sandro pano
Found ScribeNick: ipolikof
Inferring Scribes: ipolikof
Found Date: 01 Mar 2017
Guessing minutes URL: http://www.w3.org/2017/03/01-shapes-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.