See also: IRC log
<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
<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
<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
<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
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
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
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.[End of scribe.perl diagnostic output]