12:59:29 <RRSAgent> RRSAgent has joined #shapes
12:59:29 <RRSAgent> logging to http://www.w3.org/2017/01/11-shapes-irc
12:59:31 <trackbot> RRSAgent, make logs rdf-data-shapes
12:59:31 <Zakim> Zakim has joined #shapes
12:59:33 <trackbot> Zakim, this will be SHAPES
12:59:33 <Zakim> ok, trackbot
12:59:34 <trackbot> Meeting: RDF Data Shapes Working Group Teleconference
12:59:34 <trackbot> Date: 11 January 2017
13:00:10 <TallTed> TallTed has joined #shapes
13:00:29 <AndyS> present+
13:00:36 <Nicky> present+
13:01:29 <hknublau> present+
13:01:43 <Dimitris> Dimitris has joined #shapes
13:01:54 <TallTed> present+
13:02:22 <pano> pano has joined #shapes
13:03:26 <Dimitris> present+
13:04:54 <hknublau> PROPOSED: Approve minutes of the 04 Jan 2017 Telecon: https://www.w3.org/2017-01/04-shapes-minutes.html
13:05:02 <pano> present+
13:05:12 <TallTed> trackbot: start meeting
13:05:15 <trackbot> RRSAgent, make logs rdf-data-shapes
13:05:18 <trackbot> Zakim, this will be SHAPES
13:05:18 <trackbot> Meeting: RDF Data Shapes Working Group Teleconference
13:05:18 <trackbot> Date: 11 January 2017
13:05:18 <Zakim> ok, trackbot
13:05:48 <hknublau> PROPOSED: Approve minutes of the 04 Jan 2017 Telecon: https://www.w3.org/2017/01/04-shapes-minutes.html
13:06:34 <hknublau> RESOLVED: Approve minutes of the 04 Jan 2017 Telecon: https://www.w3.org/2017/01/04-shapes-minutes.html
13:06:37 <Dimitris> present+
13:07:01 <ipolikoff> ipolikoff has joined #shapes
13:08:06 <hknublau> scribenick: pano
13:08:38 <TallTed> chair: TallTed
13:08:52 <TallTed> TOPIC: WG Outlook
13:09:32 <pano> TallTed: Outlook much improved vs the previous month
13:10:16 <pano> ...: [Summary of call with W3M]
13:12:20 <pano> ...: if we can make progress and make CR and handle the comments properly we have a shot at still making this a success
13:12:46 <pano> ipolikoff: we have till end of march for CR
13:13:48 <pano> ...: W3M understands that we're working on important parts for the RDF community, and that's why they are considering this extension
13:15:06 <pano> ...: Annotate issues as at risk, when changes are made due to comments
13:16:20 <pano> ...: we do have to consider the public comments, and address them, but don't have to tackle it in line with the wishes of the commenter
13:17:12 <simonstey> +q
13:17:19 <pano> TallTed: We have to document the process of handling the comments, so that we can show W3M that we properly handled them.
13:17:33 <hknublau> ack simonstey
13:17:49 <pano> simonstey: Did W3M say anything about the chairmanship?
13:18:48 <pano> TallTed: We are making efforts to try to get Arnaud back as chair. This is still in progress.
13:19:27 <TallTed> TOPIC: Dimitris' Draft
13:20:18 <pano> Dimitris: This was an effort to speed up the process
13:20:32 <simonstey> proposal: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2017Jan/0015.html
13:21:00 <pano> ...: shacl core is in good shape
13:21:33 <pano> ...: and i think the sparql semantics part can be separated into a different document
13:21:55 <ipolikoff> +q
13:22:37 <pano> ...: so there are two specs: the shacl core, and the shacl sparql
13:23:02 <hknublau> ack ipolikoff
13:23:27 <pano> ipolikoff: the document is quite formal and quite different from the current one
13:23:47 <Dimitris> q+
13:24:15 <pano> ...: my preference would be to have one more descriptive document / tutorial, and one more mathematical/theoretic
13:26:09 <simonstey> primer?
13:26:54 <simonstey> q+
13:26:55 <TallTed> q+
13:27:07 <hknublau> ack Dimitris
13:27:43 <pano> ... i would like the spec to be written in a descripte style as it is now, and have a separate doc that specifies the mathematical parts
13:28:32 <ipolikoff> formal precision is a good thing and improval, but I would prefer it to be in one section at the end
13:28:40 <TallTed> ack simonstey
13:29:34 <ipolikoff> have both the natural language text and mathematical precision in the document
13:31:19 <ipolikoff> agree with Simon that it is now less easy to read
13:31:38 <pano> simonstey: would it be beneficial to have the formal definitions to not be in sparql, but in a more abstract language? Because implementers with no knowledge of sparql might have a hard time to implement the spec
13:31:57 <hknublau> ack TallTed
13:32:02 <AndyS> q?
13:32:07 <pano> ... but even with the time extension, this will be hard to achieve
13:32:21 <AndyS> q+
13:33:16 <simonstey> q+
13:33:20 <pano> TallTed: skimming over Dimitri's draft, I agree, the math is a lot. And I can imagine this will scare people off.
13:33:56 <pano> ipolikoff: this is why I would propose to put it in a separate section
13:34:17 <pano> TallTed: The problem is that that section would be the bulk of the document
13:35:19 <TallTed> ack AndyS
13:35:28 <pano> ... we could put the friendlier prose in the start of each section, and the formalisms at the end of each section
13:39:05 <TallTed> q?
13:39:20 <TallTed> ack simonstey
13:39:32 <AndyS> AndyS: SPARQL 1.0 was pushed into the users-then-formal style after the first Last Call.
13:40:13 <AndyS> ... it speaks to the implementers who want an exact, concise definition (e.g. why such and such a test does exacty what it does)
13:40:35 <AndyS> ... this is not what a general users wants or prefers.
13:40:48 <ipolikoff> +q
13:41:12 <AndyS> ... there are other styles but the tutorial-formal split was (for SPARQL) less work.
13:42:51 <Dimitris> q+
13:43:57 <ipolikoff> <TallTed> make sure that in moving too using the formal definition we have not changed what we had before
13:44:00 <TallTed> ack
13:44:09 <TallTed> q?
13:44:12 <TallTed> ack ipolikoff
13:45:06 <pano> ipolikoff: in removing the sparql definitions, are we impacting the implementers that would use sparql for implementing shacl in a negative way?
13:45:53 <TallTed> ack Dimitris
13:46:14 <pano> AndyS: I think separating explanation and definition is key here, explanations in sparql can still be helpful.
13:46:37 <simonstey> +q
13:47:35 <Dimitris> q+
13:47:44 <hknublau> ack simonstey
13:47:56 <hknublau> ack Dimitris
13:48:04 <hknublau> q+
13:48:17 <pano> simonstey: we had discussions about using sparql for formal definitions in the beginning of the WG, I believe this was an official resolution.
13:48:34 <pano> Dimitris: the current spec isn't fully defined in sparql
13:48:40 <TallTed> STRAW POLL: 1. shift to very mathematical (and no SPARQL); 2. add this (normative?) mathematical as section following (non-normative?) prose (including SPARQL examples); 3. revert to prose (including SPARQL examples)
13:48:57 <pano> TallTed: that's because we said we would sparql as much as possible
13:49:02 <simonstey> 4. a mix?
13:49:16 <ipolikoff> simonstey: we have decided previously to use sparql as much as possible
13:49:31 <simonstey> +q
13:49:35 <simonstey> ack hknublau
13:50:06 <pano> hknublau: looking at this draft, I believe it invalidates about 50% of our previous resolutions... a lot for sure
13:50:37 <simonstey> ack simonstey
13:51:14 <hknublau> q+
13:52:36 <pano> simonstey: i mean 4. that we use the mathematical style for those parts that are not currently defined in sparql, but i think this would be hard to do
13:53:19 <simonstey> ack hknublau
13:53:19 <TallTed> ack hknublau
13:54:35 <TallTed> 1. -0.9   2. +1   3. -0.5
13:54:54 <AndyS> A/ doc style - two sections; tutorial-formal   B/ (decisions) metamodel : orthogonal  C/ SPARQL in core - pref use as examples, not definition.
13:55:14 <pano> hknublau: I would suggest some kind of a mix by adding more precision to the current draft where necassary. I think starting from section 4 the mathematical style would be cleaner
13:56:04 <pano> ... I much prefer the sparql definition for things like minlength etc.
13:56:05 <ipolikoff> 1. -0.9   2. +.05   3. -0.5  4. +1
13:56:29 <hknublau> scribenick: ipolikoff
13:57:13 <simonstey> 1: 0.5 2: 1 3:-0 4: 0.5
13:57:19 <hknublau> 1. -0.9 2. 0    3. -  4: +1
13:57:36 <Dimitris> 1) +1  (enriching with examples) 2) 0, 3) -0.5
13:58:02 <pano> 1. -0.5   2. 0    3. -0.5
14:00:00 <simonstey> +q
14:00:58 <ipolikoff> simonstey: option 2 is easier to accomplish from the editorial perspective than 4
14:01:59 <ipolikoff> hknublau: not sure that option 2 is easier because we would need to keep the formalisms in sync
14:02:10 <TallTed> ack simonstey
14:03:29 <ipolikoff> TallTed: we are clearly going for a blend, need to decide the best way to achieve it, this is largely the editorial question
14:04:33 <ipolikoff> AndyS: using a blend imposes limitations on the prose
14:05:34 <ipolikoff> AndyS: it is the editors call, but keeping the formalism all over the place will get push back from implementers
14:08:01 <ipolikoff> TallTed: can we use the current spec and add formalism as a section
14:08:27 <ipolikoff> hknublau: yes, this is good
14:09:03 <TallTed> PROPOSED: add Dimitris' formalized math draft as a section to the existing prose in progress; then work to align the sections
14:09:18 <hknublau> 0.5
14:09:22 <ipolikoff> +1
14:09:23 <TallTed> +1
14:09:34 <simonstey> +1
14:10:56 <ipolikoff> TallTed: it will be a lot of work, would have been easier if the formalism used the same notations
14:11:54 <ipolikoff> Dimitris: yes, it will be a lot of work
14:12:05 <Dimitris> -0.5 (too much work to have both like this)
14:12:10 <AndyS> +1
14:12:28 <TallTed> RESOLVED: add Dimitris' formalized math draft as a section to the existing prose in progress; then work to align the sections
14:13:31 <ipolikoff> <AndyS>: we need to have the formalism in the spec, otherwise we will get a lot of push back, whether it is in line with the text or in a separate section
14:13:40 <simonstey> <-
14:15:20 <ipolikoff> Dimitris: should we have another editor? someone who has experience with writing formal math
14:16:02 <ipolikoff> TallTed: make a request to the working group to see who can help
14:16:17 <simonstey> +q
14:16:53 <ipolikoff> AndyS: help can come in reviewing sections for consistency
14:16:58 <Dimitris> q+
14:17:02 <TallTed> q?
14:17:05 <hknublau> ack simonstey
14:17:44 <ipolikoff> simonstey: I will help
14:17:45 <hknublau> ack Dimitris
14:18:49 <TallTed> TOPIC: ISSUE-211: Eliminate property constraints
14:19:26 <hknublau> q+
14:20:42 <TallTed> PROPOSED: close ISSUE-216 with the resolution above -- i.e., we're mixing in the mathematical formalism
14:20:46 <hknublau> +1
14:20:51 <TallTed> +1
14:20:51 <ipolikoff> +1
14:20:56 <simonstey> +1
14:21:20 <AndyS> +1
14:21:36 <TallTed> RESOLVED: close ISSUE-216 with the resolution above -- i.e., we're mixing in the mathematical formalism
14:21:56 <Dimitris> same as above   -0.5 (too much work to have both like this)
14:22:23 <TallTed> ack hknublau
14:22:39 <ipolikoff> ack hknublau
14:22:46 <hknublau> PROPOSAL: Turn sh:property and sh:sparql into constraint components as described in https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Dec/0062.html
14:23:20 <hknublau> +1
14:25:04 <ipolikoff> hknublau: proposes  an intermediate step to use the branch to make it easier to tackle 211
14:26:06 <TallTed> +1
14:26:33 <ipolikoff> +1
14:26:35 <Dimitris> +1 (if it does not affect the metamodel issue)
14:26:43 <Nicky> +1
14:27:11 <simonstey> +1
14:27:20 <TallTed> RESOLVED: Turn sh:property and sh:sparql into constraint components as described in https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Dec/0062.html
14:27:22 <hknublau> q+
14:27:29 <TallTed> ack hknublau
14:28:35 <ipolikoff> hknublau: willing to make compromises
14:28:38 <hknublau> PROPOSAL 2: Generalize targets so that they apply to all shapes. Rename sh:PropertyConstraint to sh:PropertyShape. Rename its abstract superclass from sh:Constraint to sh:AbstractShape. Use the term "constraint" to refer to the use of parameters such as sh:minCount.
14:29:26 <TallTed> see https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-211:_Eliminate_property_constraints
14:32:39 <simonstey> +q
14:33:04 <TallTed> ack simonstey
14:33:06 <hknublau> ack simonstey
14:33:13 <simonstey> https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Nov/0053.html
14:34:18 <ipolikoff> simonstey: what problems does the proposal solve?
14:35:42 <ipolikoff> hknublau: we have 2 very distinct concepts: shapes and property shapes (or property constraints), they can have different attributes
14:36:03 <Dimitris> q+
14:37:29 <ipolikoff> simonstey: is this implementation issue? I am still not seeing the major issue
14:37:39 <TallTed> ack Dimitris
14:38:42 <ipolikoff> Dimitris: the main issue is how much freedom we want to give users in writing shapes, do we want to restrict them and not allow them to write silly code
14:38:46 <ipolikoff> +q
14:40:29 <ipolikoff> Dimitris: also makes it easier to implement
14:41:05 <ipolikoff> TallTed: does your proposal eliminates the abstract superclass
14:41:33 <simonstey> http://w3c.github.io/data-shapes/shacl/#shapes
14:41:33 <ipolikoff> Dimitris: my proposal - everything is a shape, there are no constraints
14:42:12 <ipolikoff> TallTed: I have difficulty visualizing it, I would like to see them side by side
14:43:52 <ipolikoff> simonstey: what if there are node shapes and property shapes?
14:44:18 <ipolikoff> hknublau: could work, but breaks the existing syntax
14:45:51 <ipolikoff> simonstey: get rid of the property constraints to changes them into property shapes, but two sibling classes one called shape and another property shape is strange
14:46:29 <ipolikoff> hknublau: I don't have a problem with renaming shape class into node shape
14:46:59 <ipolikoff> TallTed: this will greatly help comprehension
14:47:24 <ipolikoff> hknublau: breaks examples, but I can live with it
14:47:58 <hknublau> PROPOSAL 2: Generalize targets so that they apply to all shapes. Rename sh:PropertyConstraint to sh:PropertyShape. Rename sh:Shape to sh:NodeShape. Rename their abstract superclass from sh:Constraint to sh:Shape. Use the term "constraint" to refer to the use of parameters such as sh:minCount.
14:48:18 <ipolikoff> +.5
14:48:36 <TallTed> +1
14:48:45 <hknublau> +1
14:49:13 <simonstey> +0.5
14:50:31 <Dimitris> +1 as long as the issue remains open
14:50:34 <TallTed> RESOLVED: Generalize targets so that they apply to all shapes. Rename sh:PropertyConstraint to sh:PropertyShape. Rename sh:Shape to sh:NodeShape. Rename their abstract superclass from sh:Constraint to sh:Shape. Use the term "constraint" to refer to the use of parameters such as sh:minCount.
14:52:31 <simonstey> +1 for keeping it open
14:52:34 <ipolikoff> TallTed: need visualization to understand what remains in the issue
14:53:01 <Dimitris> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Dec/att-0040/diagram.png
14:53:06 <ipolikoff> TallTed: present it in the wiki or e-mail in a pictorial way
14:54:51 <ipolikoff> hknublau: the other picture is node shape and property shape as siblings with the parent class shape
14:55:49 <ipolikoff> simonstey: we can make these changes as a result and pull in holger's branch and make the decision next week
14:57:25 <ipolikoff> hknublau: there will already be formal representation in the spec, with this, we do not need abstract syntax
14:58:21 <TallTed> TOPIC: ISSUE-177: Abstract Syntax is disconnected from concrete syntax
14:58:22 <ipolikoff> simonstey: can we utilize anything in the abstract syntax?
14:59:04 <hknublau> PROPOSAL 2: Close ISSUE-177 with no change before CR. Abstract syntax is currently not on the recommendation track. If WG has sufficient time and resources after reaching CR milestone and sees value in it, abstract syntax could be updated to become a more focused document, better sync up with the spec and be published as a WG note.
14:59:08 <hknublau> +1
14:59:16 <ipolikoff> +1
14:59:24 <TallTed> +1
14:59:29 <Dimitris> +1
14:59:35 <simonstey> +1
15:00:10 <TallTed> RESOLVED: Close ISSUE-177 with no change before CR. Abstract syntax is currently not on the recommendation track. If WG has sufficient time and resources after reaching CR milestone and sees value in it, abstract syntax could be updated to become a more focused document, better sync up with the spec and be published as a WG note.
15:00:15 <hknublau> PROPOSAL: Close ISSUE-92 deleting sh:partition. QCRs provide sufficient coverage of the given use cases.
15:00:49 <simonstey> 0
15:01:15 <Dimitris> 0
15:01:18 <ipolikoff> Dimitris: should it be announced?
15:01:19 <hknublau> +1
15:01:24 <ipolikoff> +1
15:03:59 <TallTed> ADJOURNED
15:04:08 <TallTed> trackbot: end meeting
15:04:08 <trackbot> Zakim, list attendees
15:04:08 <Zakim> As of this point the attendees have been AndyS, Nicky, hknublau, TallTed, Dimitris, pano, .5
15:04:16 <trackbot> RRSAgent, please draft minutes
15:04:16 <RRSAgent> I have made the request to generate http://www.w3.org/2017/01/11-shapes-minutes.html trackbot
15:04:17 <trackbot> RRSAgent, bye
15:04:17 <RRSAgent> I see no action items