18:06:07 <hsolbrig> present+ hsolbrig
18:06:52 <ericP> agenda: https://www.w3.org/2014/data-shapes/wiki/Meetings:Telecon2016.08.25
<ericP> chair: ericP
18:07:05 <pano> present+
18:08:18 <TallTed> present+
18:08:43 <kcoyle> scribenick: hsolbrig
18:08:51 <ericP> present+
18:09:35 <ericP> present+ kcoyle hsolbrig Dimitris 
18:09:40 <Dimitris> present+
<hsolbrig> topic: Admin
18:10:02 <ericP> PROPOSED: Approve minutes of the 11 August 2016 Telecon: http://www.w3.org/2016/08/11-shapes-minutes.html
18:11:18 <ericP> RESOLVED: Approve minutes of the 11 August 2016 Telecon: http://www.w3.org/2016/08/11-shapes-minutes.html
18:11:36 <hsolbrig> Next meeting: Sept 1
18:11:52 <ericP> regrets: holger, andy, Arnaud
18:12:03 <ericP> topic: Drafts Publication
18:12:33 <hsolbrig> ericP: SHACL published, Abstract Syntax was not...
18:13:06 <hsolbrig> ... not sure whether it will be normative, editor proposed "SHACL Abstract Syntax" as its name
18:14:05 <hsolbrig> ericP: Iovka brought up 2 issues.  One a correction on "hasValue" vs. "in", the other was to provide additional examples for the comparison against another value.
18:14:54 <hsolbrig> ericP: Both have been fixed.
18:15:03 <ericP> PROPOSED: publish updated Abstract Syntax Draft as shortname shacl-abstact-syntax
18:15:15 <hsolbrig> +1
18:15:19 <Dimitris> +1
18:15:25 <TallTed> +1
18:15:32 <kcoyle> +1
18:15:49 <pano> 0
18:16:07 <ericP> RESOLVED: publish updated Abstract Syntax Draft as shortname shacl-abstact-syntax
18:16:23 <ericP> topic: Public Comments
18:16:47 <hsolbrig> ericP: pfps commented on SHACL on the public mailer
18:16:49 <ericP> -> https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Aug/0005 pfps's comments on last SHACL draft
18:17:24 <ericP> -> https://www.w3.org/2014/data-shapes/wiki/Public_Comments#Peter.27s_Email_2016-08-16 response to pfps's comments
18:18:22 <kcoyle> q+
18:18:44 <ericP> ack next
18:18:46 <hsolbrig> ericP: there has been no review.  Suggest that we write responses in the form: (ii) response...  where ii is your initials
18:18:52 <RRSAgent> RRSAgent has joined #shapes
18:18:52 <RRSAgent> logging to http://www.w3.org/2016/08/25-shapes-irc
18:18:54 <trackbot> RRSAgent, make logs rdf-data-shapes
18:18:54 <Zakim> Zakim has joined #shapes
18:18:56 <trackbot> Zakim, this will be SHAPES
18:18:56 <Zakim> ok, trackbot
18:18:57 <trackbot> Meeting: RDF Data Shapes Working Group Teleconference
18:18:57 <trackbot> Date: 25 August 2016
18:20:14 <hsolbrig> present+ ericP hsolbrig kcoyle Dimitris TallTed pano
18:20:23 <ericP> present+ hsolbrig TallTed Dimitris ericP kcoyle pano
18:20:43 <hsolbrig> kcoyle: someone will have to turn that into a formal response on the mailing list.  Who will do this?
18:20:57 <Dimitris> q+
18:21:10 <hsolbrig> ericP: Holger is the most viable candidate, but he isn't here...
18:22:45 <ericP> Dimitris: can reply saying we've created this page and will create issues for non-editorial comments
18:23:19 <hsolbrig> kcoyle: We got more specific in our earlier responses, but gave answers to some of the questions
18:24:11 <ericP> Dimitris: based on holger's page, we can say "thank you"; we won't be able to reply [substantively] for a few weeks
18:25:23 <ericP> ACTION: Dimitris to send a thank you to pfps, linking https://www.w3.org/2014/data-shapes/wiki/Public_Comments#Peter.27s_Email_2016-08-16
18:25:23 <trackbot> Created ACTION-40 - Send a thank you to pfps, linking https://www.w3.org/2014/data-shapes/wiki/public_comments#peter.27s_email_2016-08-16 [on Dimitris Kontokostas - due 2016-09-01].
18:27:11 <ericP> topic: Raised Issues
18:27:22 <ericP> ISSUE-176
18:27:22 <trackbot> ISSUE-176 -- Should SHACL include a (simple) rules feature -- raised
18:27:22 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/176
18:28:08 <pano> SWRL?
18:28:55 <ericP> -> https://www.w3.org/2014/data-shapes/wiki/Rules SHACL rules wiki
18:32:22 <hsolbrig> harolds:  Would changes to the data graph be permanant or temporary?
18:32:37 <hsolbrig> ericp: would all rules have to run before matching happens?
18:32:52 <kcoyle> q+
18:33:26 <ericP> ack next
18:33:27 <ericP> ack next
18:33:29 <hsolbrig> ericp: if you have one shape that depends on another shape, you don't know everything you are going to validate at the time of selection
18:34:25 <hsolbrig> kcoyle: something similar has come up when we've talked about preprocessing.  We stepped back from that -- isn't this the same sort of thing?  It looks "fairly dangerous", I
18:34:44 <hsolbrig> kcoyle: ... can't feel good about adding to the standard.
18:36:41 <hsolbrig> ericp: should we open this issue or postpone?
18:36:49 <ericP> PROPOSED: open ISSUE-176
18:36:51 <TallTed> tallted: long ago we decided that SHACL engines would be fed a graph which it would validate, and that SHACL engines would not change that graph before validation ... but this reverses that and re-opens many past decisions
18:37:03 <hsolbrig> +1
18:37:04 <Dimitris> +1
18:37:05 <pano> +1
18:37:05 <TallTed> +1
18:37:10 <kcoyle> +1
18:37:11 <ericP> RESOLVED: open ISSUE-176
18:37:29 <hsolbrig> ericP: Will add to next weeks agenda
18:37:48 <ericP> topic: ISSUE-150
18:38:16 <TallTed> issue-150?
18:38:16 <trackbot> issue-150 -- Treatment of nested severities -- open
18:38:16 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/150
18:39:33 <ericP> Dimitris: holger said he'd not object if we treat all severities the same way
18:40:24 <hsolbrig> I can't hear Dimitris -- someone else needs to transcribe
18:41:03 <kcoyle> dimitris: when you have nested shapes, and you have a warning, then the nested severity succeeds
18:41:26 <kcoyle> ... my proposal was to have everything flat and the developer can do as they wish
18:43:35 <hsolbrig> kcoyle: I didn't realize that SHACL document actually determines what you do with a violation.
18:44:05 <hsolbrig> Dimitris: it does...  what we do here is just remove the severity restriction
18:44:06 <Dimitris> http://w3c.github.io/data-shapes/shacl/#validation
18:44:26 <Dimitris> "A node validates against a shape iff either it does not validate against some filter of the shape or none of the constraints in the shape produce a validation result with severity sh:Violation or a failure for the node."
18:45:09 <hsolbrig> ericP: where else do we talk about when something validates?
18:45:35 <hsolbrig> ericP: is it used elsewhere or just advice for a tool (thumbs up or thumbs down)?
18:46:18 <hsolbrig> Dimitris: Section 3 describes it...
18:46:46 <hsolbrig> kcoyle:  Is the issue getting down to one validation type or refining how validation types work?
18:48:25 <hsolbrig> kcoyle: I don't see a rule in the document that says an engine treats a violation in a different way
18:49:30 <hsolbrig> ericp: My hunch is that a broader notion of validation applies when you are doing a subshape -- outer shape is a customer, inner one is something about that customer (e.g. they have to have an address record)...
18:49:57 <hsolbrig> ... where is it useful to say "there is a notion of validation" -- warning mean you do, critical you don't
18:50:30 <hsolbrig> Dimitris: Different requirements -- some people, warnings have impact, others not.
18:51:00 <pano> q+
18:51:08 <hsolbrig> Dimitris: we should have levels of violation, but we shouldn't have any priority. Should be neutral on how severity is integrated
18:51:29 <hsolbrig> ericp: that takes away the notion of "validation" as well?
18:51:55 <hsolbrig> kcoyle: does removing the notion of validation fix this?
18:51:56 <hsolbrig> q+
18:52:25 <hsolbrig> kcoyle: how would you change the first bullet
18:53:18 <ericP> ack next
18:53:42 <hsolbrig> dimitris: ... we let the people who wrote the shape determine the significance of the violation level
18:54:07 <hsolbrig> pano: what is the use of severity in the spec?  Can we just leave it out or should we leave it up to the implementer?
18:54:28 <hsolbrig> dimitris:  we leave the notion, but people can define their own severities.
18:54:42 <hsolbrig> pano: what is use of sh:warning
18:54:52 <ericP> ack next
18:54:53 <hsolbrig> dimitirs: predefined for convenience
18:55:23 <ericP> hsolbrig: the notion of validation vs. conformance used to be a critical topic
18:55:55 <ericP> ... i frequently use shapes to ask if a node in a data graph conforms with a shape
18:56:05 <ericP> ... i want yes/no and not a whole lot more
18:56:15 <hsolbrig> Uh oh - I think I lost audio?
18:57:05 <hsolbrig> ericP: we need to think about testing.  If I give you a schema with foaf:shoeSize as integer, you give me a string, we don't have prescribed errors
18:57:37 <hsolbrig> ericP: harold and arnaud disagreed on whether XML Shema group gave specified errors.
18:57:47 <Dimitris> q+
18:57:48 <hsolbrig> ericP: how do we test warning levels
18:57:49 <hsolbrig> q+
18:57:56 <ericP> ack next
18:58:11 <hsolbrig> Dimitris: right now we keep the severity levels
18:58:18 <ericP> ack next
18:59:48 <ericP> hsolbrig: knowing how something didn't conform is very useful; saying that an integer violation is more/less severe than something else should be left to the application
18:59:49 <TallTed> q+
18:59:58 <kcoyle> +1 to Harold
19:00:24 <hsolbrig> TallTed: Yes, it is useful to know that I got a string instead of an integer, it isn't built that way today...
19:00:48 <hsolbrig> ... an engine isn't going to know.  It will just know that it is not an integer.
19:01:19 <hsolbrig> ericp: It is going to be difficult to prescribe what the error response is
19:01:23 <ericP> q?
19:02:47 <hsolbrig> TallTed: We're not giving any prioritization. Say we've got 3 levels -- if I'm got a violation on the third level and a warning on the first, why should I care?
19:03:44 <hsolbrig> ericP: first level is whether different levels are treated differently....
19:03:55 <hsolbrig> ericp: ... second level is what happens with nested.
19:04:53 <hsolbrig> TallTed: given no nesting, everything should be reported the same -- severity level and what the issue is.
19:04:53 <kcoyle> q+
19:04:59 <ericP> ack next
19:05:00 <ericP> ack next
19:05:47 <hsolbrig> kcoyle:  How much validation should be built into SHACL?  I'm thinking that less would be better?
19:05:52 <hsolbrig> q+
19:06:22 <ericP> q+
19:06:23 <ericP> ack next
19:06:46 <ericP> hsolbrig: the term "error" implies a specific use case
19:07:02 <ericP> ... i've stated that "to be a customer, it must have an integer shoeSize"
19:07:13 <ericP> ... if it doesn't, it's not necessarily and error
19:07:20 <ericP> ... it could just be a predicate failure
19:07:46 <ericP> ... i think we need to differentiate !errors! (e.g. ununderstandable shacl)
19:08:10 <TallTed> s/necessarily and error/necessarily an error/
19:08:12 <ericP> ... the less we say about it the better because otherwise we presuppose use cases
19:09:03 <ericP> ack next
19:09:10 <hsolbrig> kcoyle: error validation on this level should be in the implementation. SHACL should be informational rather than error checking.
19:09:28 <hsolbrig> ericp: we need to be able to say how we test this
19:10:51 <hsolbrig> ericp: How attached to error levels are these?
19:11:26 <hsolbrig> ericp: If violation levels were removed from SHACL, would that bother you?
19:11:46 <hsolbrig> Dimitris: I think they are very helpful, I would not remove them.  Violation levels are optional
19:12:02 <hsolbrig> ericP: how can we test?
19:12:13 <pano> by violation levels do we mean severities?
19:13:09 <hsolbrig> ericp: If I associate "informational" with a shoe size violation, should I expect it in the list of errors?
19:13:19 <kcoyle> pano - yes
19:13:33 <kcoyle> q+
19:13:43 <hsolbrig> dimitris:  for every violation that is found in the data graph, expect a violation result.
19:13:43 <Dimitris> http://w3c.github.io/data-shapes/shacl/#results
19:14:36 <hsolbrig> ericp:  If I say it's supposed to be an integer and it is a string, we don't know what error I'm going to report... no integer, cardinality violation, type violation...
19:15:04 <hsolbrig> .. but do you propose that, in that report, one of those messages should be at the severity level attached to the constraint?
19:16:55 <kcoyle> q-
19:16:55 <hsolbrig> kcoyle: how does the engine know the severity?
19:17:11 <hsolbrig> Dimitris: from the shapes graph.  Default is sh:violation, but you can override it.
19:18:24 <hsolbrig> ericp:  We don't know whether it is one or more error ...
19:18:46 <hsolbrig> Dimitris:  One result per value
19:19:08 <hsolbrig> ericp: that may not be what the SPIN approach will return.
19:19:37 <ericP> q?
19:20:15 <hsolbrig> q+ to ask what "flat severity" means
19:20:42 <Dimitris> PROPOSAL: SHACL does not treat sh:Violation different from other severities to determine if a node validates against a shape
19:20:53 <hsolbrig> q-
19:21:33 <kcoyle> PROPOSAL: SHACL does not treat sh:Violation differently from other severities to determine if a node validates against a shape
19:22:15 <hsolbrig> +1
19:22:17 <Dimitris> +1
19:22:24 <kcoyle> +1
19:22:38 <TallTed> +0.5 that language seems odd ...  it's more about reporting than determination
19:23:19 <Dimitris> TallTed, we want to amend this "A node validates against a shape iff either it does not validate against some filter of the shape or none of the constraints in the shape produce a validation result with severity sh:Violation or a failure for the node."
19:25:39 <Dimitris> "A node validates against a shape iff either it does not validate against some filter of the shape or none of the constraints in the shape produce a validation result  or a failure for the node."
19:26:57 <TallTed> "A node validates against a shape iff none of the constraints in the shape produce a failure for the node."
19:29:28 <hsolbrig> ericp:  I propose that we go back to kcoyl's proposal and use what is in the log as advice to the editor.
19:29:28 <pano> 0
19:30:01 <ericP> RESOLVED: SHACL does not treat sh:Violation differently from other severities to determine if a node validates against a shape
19:30:15 <ericP> ADJOURN
19:31:15 <Dimitris> Dimitris has left #shapes
21:36:03 <Zakim> Zakim has left #shapes