IRC log of shapes on 2016-08-25

Timestamps are in UTC.

18:18:52 [RRSAgent]
RRSAgent has joined #shapes
18:18:52 [RRSAgent]
logging to
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]
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
18:25:23 [trackbot]
Created ACTION-40 - Send a thank you to pfps, linking [on Dimitris Kontokostas - due 2016-09-01].
18:27:11 [ericP]
topic: Raised Issues
18:27:22 [ericP]
18:27:22 [trackbot]
ISSUE-176 -- Should SHACL include a (simple) rules feature -- raised
18:27:22 [trackbot]
18:28:08 [pano]
18:28:55 [ericP]
-> 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]
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]
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]
18:37:04 [Dimitris]
18:37:05 [pano]
18:37:05 [TallTed]
18:37:10 [kcoyle]
18:37:11 [ericP]
18:37:29 [hsolbrig]
ericP: Will add to next weeks agenda
18:37:48 [ericP]
topic: ISSUE-150
18:38:16 [TallTed]
18:38:16 [trackbot]
issue-150 -- Treatment of nested severities -- open
18:38:16 [trackbot]
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]
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]
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]
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]
18:57:48 [hsolbrig]
ericP: how do we test warning levels
18:57:49 [hsolbrig]
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]
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]
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]
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]
19:06:22 [ericP]
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]
19:13:43 [hsolbrig]
dimitris: for every violation that is found in the data graph, expect a violation result.
19:13:43 [Dimitris]
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]
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]
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]
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]
19:22:17 [Dimitris]
19:22:24 [kcoyle]
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]
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]
19:31:15 [Dimitris]
Dimitris has left #shapes
21:36:03 [Zakim]
Zakim has left #shapes