See also: IRC log
<kcoyle> scribenick: hsolbrig
<ericP> PROPOSED: Approve minutes of the 11 August 2016 Telecon: http://www.w3.org/2016/08/11-shapes-minutes.html
RESOLUTION: Approve minutes of the 11 August 2016 Telecon: http://www.w3.org/2016/08/11-shapes-minutes.html
Next meeting: Sept 1
ericP: SHACL published, Abstract Syntax was not...
... not sure whether it will be normative, editor proposed "SHACL Abstract Syntax" as its name
... 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.
... Both have been fixed.
<ericP> PROPOSED: publish updated Abstract Syntax Draft as shortname shacl-abstact-syntax
+1
<Dimitris> +1
<TallTed> +1
<kcoyle> +1
<pano> 0
RESOLUTION: publish updated Abstract Syntax Draft as shortname shacl-abstact-syntax
ericP: pfps commented on SHACL on the public mailer
<ericP> pfps's comments on last SHACL draft
<ericP> response to pfps's comments
ericP: there has been no review. Suggest that we write responses in the form: (ii) response... where ii is your initials
kcoyle: someone will have to turn that into a formal response on the mailing list. Who will do this?
ericP: Holger is the most viable candidate, but he isn't here...
<ericP> Dimitris: can reply saying we've created this page and will create issues for non-editorial comments
kcoyle: We got more specific in our earlier responses, but gave answers to some of the questions
<ericP> Dimitris: based on holger's page, we can say "thank you"; we won't be able to reply [substantively] for a few weeks
<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 [recorded in http://www.w3.org/2016/08/25-shapes-irc]
<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].
<ericP> ISSUE-176
<trackbot> ISSUE-176 -- Should SHACL include a (simple) rules feature -- raised
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/176
<pano> SWRL?
<ericP> SHACL rules wiki
harolds: Would changes to the data graph be permanant or temporary?
ericp: would all rules have to run before matching happens?
... 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
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
... ... can't feel good about adding to the standard.
ericp: should we open this issue or postpone?
<ericP> PROPOSED: open ISSUE-176
<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
+1
<Dimitris> +1
<pano> +1
<TallTed> +1
<kcoyle> +1
RESOLUTION: open ISSUE-176
ericP: Will add to next weeks agenda
<TallTed> issue-150?
<trackbot> issue-150 -- Treatment of nested severities -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/150
<ericP> Dimitris: holger said he'd not object if we treat all severities the same way
I can't hear Dimitris -- someone else needs to transcribe
<kcoyle> dimitris: when you have nested shapes, and you have a warning, then the nested severity succeeds
<kcoyle> ... my proposal was to have everything flat and the developer can do as they wish
kcoyle: I didn't realize that SHACL document actually determines what you do with a violation.
Dimitris: it does... what we do here is just remove the severity restriction
<Dimitris> http://w3c.github.io/data-shapes/shacl/#validation
<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."
ericP: where else do we talk about when something validates?
... is it used elsewhere or just advice for a tool (thumbs up or thumbs down)?
Dimitris: Section 3 describes it...
kcoyle: Is the issue getting down to one validation type or refining how validation types work?
... I don't see a rule in the document that says an engine treats a violation in a different way
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)...
... where is it useful to say "there is a notion of validation" -- warning mean you do, critical you don't
Dimitris: Different requirements -- some people, warnings have impact, others not.
... we should have levels of violation, but we shouldn't have any priority. Should be neutral on how severity is integrated
ericp: that takes away the notion of "validation" as well?
kcoyle: does removing the notion of validation fix this?
... how would you change the first bullet
dimitris: ... we let the people who wrote the shape determine the significance of the violation level
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?
dimitris: we leave the notion, but people can define their own severities.
pano: what is use of sh:warning
dimitirs: predefined for convenience
<ericP> hsolbrig: the notion of validation vs. conformance used to be a critical topic
<ericP> ... i frequently use shapes to ask if a node in a data graph conforms with a shape
<ericP> ... i want yes/no and not a whole lot more
Uh oh - I think I lost audio?
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
... harold and arnaud disagreed on whether XML Shema group gave specified errors.
... how do we test warning levels
Dimitris: right now we keep the severity levels
<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
<kcoyle> +1 to Harold
TallTed: Yes, it is useful to know that I got a string instead of an integer, it isn't built that way today...
... an engine isn't going to know. It will just know that it is not an integer.
ericp: It is going to be difficult to prescribe what the error response is
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?
ericP: first level is whether different levels are treated differently....
... ... second level is what happens with nested.
TallTed: given no nesting, everything should be reported the same -- severity level and what the issue is.
kcoyle: How much validation should be built into SHACL? I'm thinking that less would be better?
<ericP> hsolbrig: the term "error" implies a specific use case
<ericP> ... i've stated that "to be a customer, it must have an integer shoeSize"
<ericP> ... if it doesn't, it's not necessarily an error
<ericP> ... it could just be a predicate failure
<ericP> ... i think we need to differentiate !errors! (e.g. ununderstandable shacl)
<ericP> ... the less we say about it the better because otherwise we presuppose use cases
kcoyle: error validation on this level should be in the implementation. SHACL should be informational rather than error checking.
ericp: we need to be able to say how we test this
... How attached to error levels are these?
... If violation levels were removed from SHACL, would that bother you?
Dimitris: I think they are very helpful, I would not remove them. Violation levels are optional
ericP: how can we test?
<pano> by violation levels do we mean severities?
ericp: If I associate "informational" with a shoe size violation, should I expect it in the list of errors?
<kcoyle> pano - yes
dimitris: for every violation that is found in the data graph, expect a violation result.
<Dimitris> http://w3c.github.io/data-shapes/shacl/#results
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...
... but do you propose that, in that report, one of those messages should be at the severity level attached to the constraint?
kcoyle: how does the engine know the severity?
Dimitris: from the shapes graph. Default is sh:violation, but you can override it.
ericp: We don't know whether it is one or more error ...
Dimitris: One result per value
ericp: that may not be what the SPIN approach will return.
<Dimitris> PROPOSAL: SHACL does not treat sh:Violation different from other severities to determine if a node validates against a shape
<kcoyle> PROPOSAL: SHACL does not treat sh:Violation differently from other severities to determine if a node validates against a shape
+1
<Dimitris> +1
<kcoyle> +1
<TallTed> +0.5 that language seems odd ... it's more about reporting than determination
<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."
<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."
<TallTed> "A node validates against a shape iff none of the constraints in the shape produce a failure for the node."
ericp: I propose that we go back to kcoyl's proposal and use what is in the log as advice to the editor.
<pano> 0
RESOLUTION: SHACL does not treat sh:Violation differently from other severities to determine if a node validates against a shape
<ericP> ADJOURN