17:59:51 RRSAgent has joined #shapes 17:59:51 logging to http://www.w3.org/2016/08/04-shapes-irc 17:59:53 RRSAgent, make logs rdf-data-shapes 17:59:53 Zakim has joined #shapes 17:59:55 Zakim, this will be SHAPES 17:59:55 ok, trackbot 17:59:56 Meeting: RDF Data Shapes Working Group Teleconference 17:59:56 Date: 04 August 2016 chair: Arnaud regrets: ericP, jamsden agenda: https://www.w3.org/2014/data-shapes/wiki/Meetings:Telecon2016.08.04 18:00:59 kcoyle has joined #shapes 18:02:04 present+ 18:02:17 present+ 18:02:22 present+ 18:02:26 present+ 18:05:08 present+ 18:09:58 +q 18:10:08 ack simonstey 18:11:58 scribe: simonstey 18:12:22 TOPIC: Admin 18:12:24 PROPOSED: Approve minutes of the 28 July 2016 Telecon: http://www.w3.org/2016/07/28-shapes-minutes.html 18:13:06 RESOLVED: Approve minutes of the 28 July 2016 Telecon: http://www.w3.org/2016/07/28-shapes-minutes.html 18:13:26 hknublau has joined #shapes 18:13:38 TOPIC: Drafts Publication 18:14:21 present+ 18:14:27 Arnaud: we agreed to wait with the abstract syntax & SHACL drafts 18:14:38 ... any updates on where we stand? 18:15:08 Dimitris: hknublau did some work on the draft and I plan to continue tomorrow 18:15:43 ... I think in two weeks from now we could have another version of the draft published 18:16:17 hknublau: in my opinion it's still not 100% perfectly readable 18:16:40 ... I guess it needs another pass from someone 18:17:10 ... was also waiting on some resolutions 18:17:25 TOPIC: ISSUE-92 18:17:27 issue-92 18:17:27 issue-92 -- Should repeated properties be interpreted as additive or conjunctive? -- open 18:17:27 http://www.w3.org/2014/data-shapes/track/issues/92 18:18:56 Arnaud: regarding sh:partition, I think we should wait for ericP to decide whether we want to keep/remove it 18:19:09 ... I'm in favour of dropping it though 18:22:14 topic: ISSUE-175 18:20:36 Arnaud: unfortunately, none of the proposals clearly sticks out 18:21:11 q+ 18:21:19 ack kcoyle 18:21:35 https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-175:_rename_scope 18:21:51 issue-175 18:21:51 issue-175 -- Alternate naming for term for scope / in-scope -- open 18:21:51 http://www.w3.org/2014/data-shapes/track/issues/175 18:22:16 issue-175 18:22:16 issue-175 -- Alternate naming for term for scope / in-scope -- open 18:22:16 http://www.w3.org/2014/data-shapes/track/issues/175 18:22:42 kcoyle: we have to be clear about used terminology 18:22:57 q+ 18:23:10 ack hknublau 18:23:12 ... i.e., "they are in scope" vs. "they are selected" 18:24:05 hknublau: what kcoyle says is correct; the problem was that someone from outside the group was mentioning that "scope" already has another meaning in cs 18:24:23 ... my personal fav. for now is "target" instead of "scope" 18:24:46 ... i.e., a shape is "targeting" a set of nodes 18:25:11 +1 for target 18:25:23 q+ 18:25:53 ack kcoyle 18:26:25 target works for me as well 18:26:32 hknublau: targetnode, targetclass, etc. 18:26:42 but I would rather targetInstancesOf instead of targetClass 18:27:12 q+ 18:27:48 ack Dimitris 18:28:28 [talking about a variation of "Proposal 5: Use target instead of scope / in-scope (suggested by James Anderson). The existing properties would be renamed to sh:targetNode, sh:targetInstancesOf, sh:targetObjectsOf, sh:targetSubjectsOf"] 18:28:57 Dimitris: I would prefer targetInstancesOf instead of targetClass 18:29:24 q+ 18:30:10 q- 18:30:19 ack simonstey 18:33:06 simonstey: we have to be very clear on explaining what sh:targetClass means 18:33:35 PROPOSED: Close ISSUE-175, changing "scope" to "target" 18:33:58 +1 18:34:03 +1 18:34:08 +1 18:34:18 +1 18:34:39 +1 18:34:50 RESOLVED: Close ISSUE-175, changing "scope" to "target" 18:36:39 TOPIC: ISSUE-169 18:34:45 issue-169 18:34:45 issue-169 -- Should we rename sh:scopeProperty/InverseProperty -- open 18:34:45 http://www.w3.org/2014/data-shapes/track/issues/169 18:36:48 PROPOSED: Close ISSUE-169, rename sh:targetProperty to sh:targetSubjectsOf and sh:targetInverseProperty to sh:targetObjectsOf. 18:36:49 hknublau: I raised that issue directly after we decided to kick out inverseproperty 18:37:50 q+ 18:38:00 ack kcoyle 18:38:11 PROPOSED: Close ISSUE-169, rename sh:targetProperty to sh:targetObjects and sh:targetInverseProperty to sh:targetSubjects. 18:40:25 PROPOSED: Close ISSUE-169, rename sh:targetProperty to sh:targetObjectsOf and sh:targetInverseProperty to sh:targetSubjectsOf. 18:40:44 +1 18:40:51 +1 18:41:32 +1 18:41:37 +q 18:41:40 +1 18:41:50 ack simonstey 18:43:18 sh:scope 18:46:08 0 18:46:24 kcoyle: the problem I have is that if you start to concatenate a bunch of subjects together, well it doesn't really work well in english 18:47:24 RESOLVED: Close ISSUE-169, rename sh:targetProperty to sh:targetObjectsOf and sh:targetInverseProperty to sh:targetSubjectsOf 18:47:59 ... grammatically correct would be sh:targetedSubjectsOf which makes it even longer 18:48:11 TOPIC: ISSUE-150 18:48:22 Arnaud: we started talking about that last week 18:48:53 ... there are two different dimensions to the problem 18:49:06 ... 1.) higher sev. wins over lower sev. 18:49:44 ... 2.) what happens with nested sev.? 18:50:22 Dimitris: if a shape has a warning, info, and violation 18:50:40 ... only if viol. fails the shape doesn't validate 18:51:09 q+ 18:51:54 q- 18:52:31 ... if a shape doesn't validate but has a nested shape that would throw a warning that warning isn't actually thrown 18:53:12 q+ 18:53:31 https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jul/0079.html 18:54:04 ack hknublau 18:54:25 hknublau: I would change anything in the spec 18:54:46 ... I also don't agree with treating all sev. the same 18:54:59 ... an info isn't a violation 18:56:52 Arnaud: it all boils down to what the application actually does with the validation results 18:57:03 +q 18:57:16 ack simonstey 18:58:16 q+ 18:58:36 present+ 18:58:42 ack Dimitris 18:58:51 simonstey: agree with hknublau 19:00:14 q+ 19:00:52 ack TallTed 19:02:09 TallTed: there is a difference between "data is not available/wrongly formatted" vs. "data is wrong" hence should have dif. levels of severity 19:03:09 hknublau: we leave it to the engine to signal e.g. a failure to the outside 19:03:52 TallTed: ex, "123456789"^^xsd:int vs "1-234-56-789"^^xsd:string vs (missing) for a phone number 19:04:43 q+ 19:05:30 q- 19:05:50 http://w3c.github.io/data-shapes/shacl/#terminology 19:06:30 Arnaud: I guess we are missing on a sentence explaining the term "failure" 19:06:46 hknublau: I'll fix that 19:08:53 q+ 19:09:09 ack kcoyle 19:09:24 http://w3c.github.io/data-shapes/shacl/#results-severity 19:10:17 kcoyle: either shacl provides the levels you need or it allows you to define those levels yourself 19:10:51 ... I'm not sure how much burden that puts on implementers 19:10:52 q+ 19:10:58 ack Dimitris 19:11:37 q+ 19:12:43 yes, what Simon is saying - can't have it both ways 19:13:07 Dimitris: with my proposed approach it should be easy to add additional sev. levels 19:14:12 ack hknublau 19:14:52 hknublau: we used to have a design with an hierarchy 19:15:25 ... where you could e.g. subclass a warning and make it an error or alike 19:16:09 ... which was rejected by the group and I agrree it isn't optimal 19:17:01 Arnaud: hknublau is saying there isn't any problem vs. Dimitris saying that there is 19:17:18 hknublau: I see no warning with nesting either 19:17:25 q+ 19:17:34 ack Dimitris 19:18:42 Dimitris: it's also about reporting where it can easily become confusing for users 19:18:46 q+ 19:19:44 ack TallTed 19:21:02 TallTed: it's use case dependend whether you care about nested sev. or not 19:22:25 I agree for OR as well 19:22:55 but not for all other nested cases 19:23:21 [ TallTed and hknublau discussing different use cases of nested shapes/severities and respective impact of sev. reporting ] 19:25:13 this gets problematic even in sh:or because sh:Warning and shInfo does not case a violation 19:25:31 q+ 19:26:14 Arnaud: I somehow agree with TallTed here in the sense that we have to allow users to configure those things by themselves 19:26:41 ack Dimitris 19:28:17 +q 19:29:13 -q 19:29:41 hknublau: the important part is the most outer shape 19:30:05 +q 19:30:20 ack simonstey 19:32:36 I agree with Simon 19:32:47 this is inline with what I was proposing 19:33:14 trackbot, end meeting 19:33:14 Zakim, list attendees 19:33:14 As of this point the attendees have been Arnaud, simonstey, pano, Dimitris, kcoyle, hknublau, TallTed 19:33:22 RRSAgent, please draft minutes 19:33:22 I have made the request to generate http://www.w3.org/2016/08/04-shapes-minutes.html trackbot 19:33:23 RRSAgent, bye 19:33:23 I see no action items