17:55:07 RRSAgent has joined #shapes 17:55:07 logging to http://www.w3.org/2015/09/03-shapes-irc 17:55:09 RRSAgent, make logs rdf-data-shapes 17:55:09 Zakim has joined #shapes 17:55:11 Zakim, this will be SHAPES 17:55:11 I do not see a conference matching that name scheduled within the next hour, trackbot 17:55:12 Meeting: RDF Data Shapes Working Group Teleconference 17:55:12 Date: 03 September 2015 17:56:12 kcoyle has joined #shapes 18:00:08 present+ Arnaud 18:00:23 present+ kcoyle, pfps 18:01:40 present+ hknublau 18:02:29 Dimitris has joined #shapes 18:03:08 present+ ericp, TallTed, Dimitris 18:05:26 pfps has joined #shapes 18:05:30 scribenick pfps 18:06:15 Dimitris, are you calling back? 18:06:30 yes, I cannot hear anything 18:06:38 Topic: Admin 18:07:33 PROPOSED: Approve minutes of the 27 August Telecon: http://www.w3.org/2015/08/27-shapes-minutes.html 18:07:56 the minutes are a fair record of what happened 18:09:32 I find that the working group has been making resolutions during meeting without any advance notice. arnaud: we cannot stopped working every time someone is absent ... the best we can do is try to make progress ... people who were absent can object to the resolutions 18:12:43 I object to the closing of ISSUE-74 last week even though I had expressed regrets before the agenda was sent out 18:14:26 RESOLVED: Approve minutes of the 27 August Telecon: http://www.w3.org/2015/08/27-shapes-minutes.html, noting objection from Peter on reolution of ISSUE-74 18:14:36 s/reolution/resolution/ 18:14:55 arnaud: next meeting 18:15:22 arnaud: F2F in France, agenda has had minor changes 18:16:22 arnaud: remote participation will be via WebEx and IRC, as usual 18:16:33 there might be different codes 18:16:46 eric: I'll check out the situation 18:17:08 Topic: Disposal of Raised Issues 18:17:16 arnaud: ISSUE-84 18:17:27 issue-84 18:17:27 issue-84 -- Constraint to limit IRIs of focus nodes to a given enumeration (similar to owl:oneOf) -- raised 18:17:27 http://www.w3.org/2014/data-shapes/track/issues/84 18:17:47 holger: no current notion of enumerated values 18:17:58 q+ 18:18:05 ack kcoyle 18:18:08 holger: only related feature is allowed values 18:18:47 kcoyle: can the enumerations be anything, e.g., literals 18:19:05 holger: as these are for focus nodes, only IRIs make sense 18:19:33 kcoyle: but don't literals make sense as well 18:19:57 holger: no, the only thing that makes sense are IRIs, not blank nodes or literals 18:20:15 PROPOSED: Open ISSUE-84: Allowed IRIs 18:20:19 +1 18:20:24 I'm find with opening the issue 18:20:25 +1 18:20:29 +1 18:20:40 s/find/fine/ 18:21:07 eric: the short name should be changed 18:21:26 holger: if anyone has a better name, go ahead and change it 18:21:34 arnaud: maybe we should try to find a better name 18:21:59 arnaud: eric do you have a suggestion? 18:22:10 eric: ... 18:22:17 RESOLVED: Open ISSUE-84: Constraint to limit IRIs of focus nodes to a given enumeration (similar to owl:oneOf) 18:22:56 eric: "an enumerated set of legal focus nodes" 18:24:05 Topic: SHACL Spec Review 18:24:23 arnaud: the idea was to look at the spec and see whether they think it can be publised as a FPWD 18:25:23 arnaud: what should be done with the feedback sent to the mailing list? 18:25:58 arnaud: peter is objecting to publication so putting forward a resolution now is not useful 18:26:25 arnaud: there have been changes to the spec since the reviews 18:26:30 q+ 18:26:37 ack pfps 18:27:43 pfps: both Arthur's and my review are for an out-of-date version of the document 18:28:03 pfps: so how can the current version of the document be published? 18:28:46 holger: there is a frozen version that has been saved 18:29:10 q+ 18:29:28 holger: I am editing the current version 18:32:26 ack pfps 18:32:42 pfps: I'm confused as to what my review is for? 18:33:01 arnaud: the goal was to try to get agreement to publish a FPWD 18:34:00 pfps: at some point we should be publishing something and I thought that I was reviewing something that was going to be published 18:34:18 Arnaud has joined #shapes 18:35:03 arnaud: do you agree with publishing what you reviewed as a FPWD 18:35:07 pfps: hell no 18:35:35 arnaud: so the process would be to determine what it would take for you to be OK with publishing the document 18:35:59 q+ 18:36:50 pfps: in my opinion there needs to be a complete rewrite of the document and a complete review 18:36:56 ack q+ 18:37:12 arnaud: who is going to do the rewrite? 18:38:03 ted: we are losing the point of what this is - this is a FPWD not a candidate recommendation 18:38:28 ted: there could be a complete rewrite after first publication 18:39:07 ted: this is only a heartbeat 18:39:18 q+ 18:40:18 arnaud: it appears that peter thinks that the document is not publishable as it would turn people off for ever 18:40:50 pfps: my most serious comment is that I feel that the document does not reflect the state of the document 18:42:54 pfps: the main example in the document uses shapes as classes, which is controversial, in my opinion 18:43:48 arnaud: a complete rewrite is ... 18:44:16 not practical 18:49:46 pfps: I spent a lot of time looking at the document and found lots of problems - I don't think that the document reflects the thinking of the working group, the document has lots of technical flaws, and it does not present an understandable view of SHACL 18:49:59 holger: ... 18:50:45 arnaud: anyone is welcome to create a branch and make changes 18:50:49 q+ 18:51:01 ack TallTed 18:51:16 ack pfps 18:51:48 pfps: yes, having more people contribute to the document would be useful 18:52:23 arnaud: who is going to do the rewrite? 18:53:05 pfps: I'm not going to do it. 18:53:45 pfps: I've done a review of the document and put forward a number of changes that I think are needed and a number of flaws that I see in it 18:54:08 arnaud: at the F2F meeting there will be a proposal to publish a FPWD 18:54:31 arnaud: we have to move forward 18:54:55 holger: what is the working group being asked to do? 18:55:32 scribe comment - I think that arnaud was asking for the working group to look at the reviews but I didn't get a chance to scribe that 18:56:18 holger: I have made a number of changes to address comments 18:56:39 holger: right now I am using pseudo code but Arthur had a comment on that 18:56:52 holger: is there another way of doing things 18:57:00 arnaud: any suggestions? 18:57:08 q+ 18:57:13 ack pfps 18:57:47 pfps: in many papers I have seen the English description is better than the pseudo code 18:58:16 holger: how about Java script? 18:59:02 pfps: the problem is having the right level of specificity 18:59:17 arnaud: that is why pseudo code is often used 18:59:55 arnaud: there is no good answer - the only way forward is to choose the least worse 19:00:28 arnaud: you could change a small part and pass it by Arthus 19:00:53 holger: I'll experiment, but that is not going to happen by next week 19:01:11 s/Arthus/Arthur/ 19:01:46 arnaud: we will come back to this at the F2F 19:01:55 Topic: ISSUE-70: blank node default type 19:02:24 issue-70? 19:02:24 issue-70 -- special treatment of blank node types -- open 19:02:24 http://www.w3.org/2014/data-shapes/track/issues/70 19:04:42 pfps: I would like any language that the working group proposes to be as simple as possible so special treatment of certain kinds of nodes needs strong justification 19:06:19 holger: from my perspective the most important aspect is usability - the language needs to look attractive - I would be OK with not requiring type triples at all 19:06:22 https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Aug/0155.html 19:07:00 holger: I find the JSON-LD syntax to be quite reasonable 19:07:41 arnaud: [summarize the two points of view] 19:07:53 arnaud: any other comments? 19:08:03 ... from others 19:08:42 arnaud: if you really want something simple to write you can use the user-friendly syntax 19:09:05 holger: if we had that syntax ... 19:09:35 arnaud: the fact that we don't have the user-friendly syntax makes this call harder 19:10:23 don;t understand 19:10:36 holger: what about making the type triple optional 19:10:50 pfps: I'm not against that, but are there other problems? 19:11:31 holger: if people share IRIs then it would be helpful to have the type triple 19:11:47 pfps: I would go along with that 19:12:55 arnaud: maybe a warning that omitting the type arc might sometimes cause problems 19:13:00 Proposal: For the properties marked with a sh:defaultValueType, the rdf:type triple is optional (to the engine). For IRIs, the recommendation will be to have a type triple (a SHOULD). 19:13:54 pfps: I don't know if I understand this proposal 19:14:27 Proposed: type triples are optional whenever they can be deteremined 19:15:31 holger: I think that there needs to be a sh:defaultValueType to make sense of the proposal 19:15:51 pfps: I think that a crisper proposal is needed 19:16:12 arnaud: agree 19:16:13 PROOSAL: rdf:type statements SHOULD be included whenever possible, but they are optional. omitting rdf:type statements may have various negative effects, so their inclusion is strongly recommended. 19:16:58 s/PROOSAL/PROPOSED/ 19:17:06 holger: I don't like SHOULD on blank nodes 19:17:21 holger: I'll try to work out something 19:17:28 PROPOSED: Close ISSUE-70, stating that rdf:type statements SHOULD be included whenever possible, but they are optional. omitting rdf:type statements may have various negative effects, so their inclusion is strongly recommended for IRIs. 19:18:33 PROPOSED: Close ISSUE-70, stating that rdf:type statements are optional but SHOULD be included whenever possible on IRI nodes. omitting rdf:type statements may have various negative effects, so their inclusion is strongly recommended for IRIs. 19:19:05 PROPOSED: Close ISSUE-70, stating that rdf:type statements are optional but SHOULD be included whenever possible on IRI nodes. omitting rdf:type statements may have various negative effects 19:19:31 +1 19:19:34 +1 19:19:34 +1 19:19:34 +1 19:19:42 +1 19:19:51 +0 19:20:11 RESOLVED: Close ISSUE-70, stating that rdf:type statements are optional but SHOULD be included whenever possible on IRI nodes. omitting rdf:type statements may have various negative effects 19:20:39 topic: ISSUE-51 19:20:39 ISSUE-51 -- What types of validation results should be returned -- open 19:20:39 http://www.w3.org/2014/data-shapes/track/issues/51 19:20:59 https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Aug/0157.html 19:21:59 arnaud: holger put together a proposal trying to be between something that it too simple and something that is too complex 19:22:10 q+ 19:22:15 ack pfps 19:22:34 pfps: are there meta-classes involved? 19:22:45 holger: no 19:22:47 q+ 19:22:52 pfps: sorry, I misread 19:23:50 ack kcoyle 19:24:07 kcoyle: my concern is that the validation result was not returning anything for success 19:24:59 holger: there are success results - an API would have a boolean 19:25:32 q+ 19:25:50 ... 19:26:23 arnaud: karen are you simply asking for something that says that no error was found? this would be a boolean result in the API 19:26:35 ack TallTed 19:26:43 holger: the API has such a boolean, which is supported by the data model 19:27:35 ted: i've seen success with information ... 19:27:50 holger: you can determine the result from looking at the data produced 19:28:17 ted: successresult and validationresult are both success results - one has more information than the other 19:29:02 holger: there should be some distinction between errors and non-errors 19:29:32 ted: drop sucessresult and use non-error validationresult 19:30:00 dimitris: there can be multiple success results and multiple failure results 19:30:25 ted: validationresult would be better as constraintresult 19:30:42 arnaud: we are out of time 19:31:39 holger: success results are at the shape level - validation results are at the focus node level 19:32:08 arnaud: we will look at this next week - people can come up with proposals 19:32:47 arnaud: the goal for next week is to close as many issues as possible - we need to make progress 19:33:03 arnaud: people should read the reviews of the draft 19:33:13 arnaud: there are still issues with nomenclature 19:33:31 the different levels of success/failure need different levels of messaging. overall success/failure of a shape validation is comprised of many success/failures of constraints within the shape. each constraint might produce pure-success/success-with-info/error (but need not produce success output). 19:33:42 chair: Arnaud 19:33:48 agenda: https://www.w3.org/2014/data-shapes/wiki/Meetings:Telecon2015.09.03 19:34:12 regrets: aryman, simonstey 19:34:20 trackbot, end meeting 19:34:20 Zakim, list attendees 19:34:20 As of this point the attendees have been Arnaud, kcoyle, pfps, hknublau, ericp, TallTed, Dimitris 19:34:28 RRSAgent, please draft minutes 19:34:28 I have made the request to generate http://www.w3.org/2015/09/03-shapes-minutes.html trackbot 19:34:29 RRSAgent, bye 19:34:29 I see no action items