IRC log of shapes on 2015-09-10

Timestamps are in UTC.

07:42:50 [RRSAgent]
RRSAgent has joined #shapes
07:42:50 [RRSAgent]
logging to
07:42:52 [trackbot]
RRSAgent, make logs rdf-data-shapes
07:42:52 [Zakim]
Zakim has joined #shapes
07:42:54 [trackbot]
Zakim, this will be SHAPES
07:42:54 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
07:42:55 [trackbot]
Meeting: RDF Data Shapes Working Group Teleconference
07:42:55 [trackbot]
Date: 10 September 2015
07:43:13 [Arnaud]
present+ Arnaud, iovka, ericP, kcoyle
07:43:33 [Arnaud]
07:43:37 [Arnaud]
chair: Arnaud
07:44:48 [Arnaud]
present+ labra
07:55:33 [hknublau]
hknublau has joined #shapes
07:57:19 [Dimitris]
Dimitris has joined #shapes
07:57:29 [Labra]
Labra has joined #shapes
07:58:44 [Arnaud]
07:58:56 [Arnaud]
we're on, so feel free to call in
07:59:25 [Dimitris]
present+ dimitris
08:00:04 [pfps]
pfps has joined #shapes
08:00:30 [hknublau]
present+ hknublau
08:00:47 [hsolbrig]
hsolbrig has joined #shapes
08:01:15 [pfps]
present+ pfps
08:01:51 [iovka]
iovka has joined #shapes
08:03:01 [aryman]
aryman has joined #shapes
08:03:48 [hknublau]
scribenick: hknublau
08:04:39 [simonstey]
simonstey has joined #shapes
08:05:34 [hknublau]
topic: Primer
08:05:57 [hknublau]
Arnaud: we started with a Primer which then got abandoned.
08:06:13 [hknublau]
… Not mandatory, although a lot of WGs do it
08:06:35 [hknublau]
… how terse shall the spec be, different audiences
08:06:40 [kcoyle]
kcoyle has joined #shapes
08:07:41 [hknublau]
… entirely up to the WG to decide, middle ground might be to make the spec reasonably readable
08:08:07 [hknublau]
… Primer adds to the workload
08:08:15 [hknublau]
08:08:34 [aryman]
08:08:48 [Arnaud]
ack hknublau
08:10:14 [Arnaud]
ack aryman
08:10:17 [hknublau]
hknublau: we are spread thinly, we should rather wait with a Primer
08:10:33 [hknublau]
aryman: My preference is to make the spec readable, with plenty of examples
08:10:48 [hknublau]
… XML Schema spec is IMHO unreadable
08:11:09 [hknublau]
… counter example: SPARQL spec is both a good reference and readable
08:11:38 [hknublau]
… let’s try to make the spec self-contained.
08:12:27 [hknublau]
Arnaud: Anyone in favor of a Primer now? Assuming we can find a middle-ground, we should continue
08:13:09 [hknublau]
ericP: We still have our old document that could be resurrected.
08:13:46 [hknublau]
Arnaud: Takes too much time, proposing to not worry about Primer now.
08:15:11 [hknublau]
hknublau: Where to put SPARQL queries (to make it readable) - appendix or in the middle
08:15:17 [aryman]
08:15:22 [Arnaud]
ack aryman
08:15:59 [pfps]
08:16:01 [hknublau]
aryman: Either variation works. Order by readership, SPARQL might confuse inexperienced users.
08:16:34 [hknublau]
… Precise prose with examples, semantics chapter (mean repeating the structure)
08:16:52 [simonstey]
08:16:57 [pfps]
08:16:58 [simonstey]
was about to say that
08:17:16 [hknublau]
hknublau: Details could be optional, open by click
08:17:50 [hknublau]
aryman: I did something like this before, works quite well.
08:18:37 [hknublau]
… SPARQL is also normative, so it can be in the same document with collapsible sections
08:19:11 [kcoyle]
08:19:18 [Arnaud]
ack kcoyle
08:19:30 [hknublau]
kcoyle: how does this work for printing?
08:20:06 [hknublau]
Arnaud: we can do anything, may require programming
08:20:32 [hknublau]
aryman: JavaScript is now stable enough by all browsers, so we could do anything
08:20:58 [hknublau]
ericP: CSS print directives, e.g. some sections can be hidden if in print mode
08:21:29 [hknublau]
aryman: could have pre-generated PDF versions
08:22:26 [hknublau]
aryman: suggesting to in-line SPARQL, then we can make it interactive. (Agreement)
08:22:38 [pfps]
08:23:22 [aryman]
08:23:31 [Arnaud]
ack pfps
08:23:36 [hknublau]
hknublau: how to format the SPARQL, e.g. what about helper functions
08:24:01 [hknublau]
pfps: SPARQL functions should be completely vanilla
08:25:01 [pfps]
pre-binding isn't vanilla SPARQL
08:25:02 [Arnaud]
ack aryman
08:25:19 [pfps]
My opinion is that the SPARQL snippets have to be completely vanilla
08:26:35 [hknublau]
aryman: we try to use SPARQL-as-is, WG members can suggest alternatives
08:28:26 [hknublau]
aryman: Implementation strategy should not shine through
08:29:17 [hknublau]
… spec should be decoupled from implementation strategy
08:30:08 [pfps]
08:32:08 [Arnaud]
ack pfps
08:32:29 [hknublau]
hknublau: we could put a short introduction explaining how the snippets are to be interpreted
08:32:45 [hknublau]
pfps: pre-binding sounds like an implementation details
08:33:00 [hknublau]
aryman: instead of pre-bound variables, just use an example?
08:33:05 [pfps]
I'm worried that several bits of the implementation details are going to bleed through to the snippets
08:34:25 [hknublau]
aryman: maybe inject a VALUES clause for the variables
08:34:51 [pfps]
I think that it would be better to have meta-variables, i.e., non-SPARQL syntax that is substituted by an argument to the construct
08:35:33 [hknublau]
pfps: we still don’t have a description of pre-binding
08:35:50 [Dimitris]
what about %var1%
08:36:07 [hknublau]
pfps: could just be SPARQL variables
08:36:45 [hknublau]
… much of this depends on wording
08:37:01 [hknublau]
aryman: our argument variables use $ sign, others use ?
08:37:56 [hknublau]
hknublau: strongly agreed
08:38:56 [hknublau]
PROPOSAL: all SPARQL snippets should use $ for variables that represent arguments, e.g. $minCount, while all other variables remain ?
08:39:45 [hknublau]
08:40:12 [Dimitris]
08:40:13 [simonstey]
08:40:14 [hsolbrig]
08:40:18 [aryman]
08:40:19 [Labra]
08:40:23 [kcoyle]
08:40:28 [ericP]
08:40:32 [pfps]
08:40:33 [iovka]
08:40:37 [Arnaud]
RESOLVED: all SPARQL snippets should use $ for variables that represent arguments, e.g. $minCount, while all other variables remain ?
08:41:18 [hknublau]
topic: UC&R document
08:41:43 [hknublau]
Arnaud: unsure what the status is, it hasn’t been republished.
08:42:03 [hknublau]
… we ought to publish an update
08:43:04 [hknublau]
simonstey: I started to refactor it, I wanted to restructure it all, to Use Cases. But lack of time.
08:43:30 [hknublau]
(I use Colloquy)
08:43:56 [hknublau]
simonstey: I would like to republish better version
08:44:07 [Arnaud]
08:44:37 [Arnaud]
08:44:48 [hknublau]
Arnaud: the published version has significant differences
08:44:57 [hknublau]
simonstey: additional use cases
08:46:03 [hknublau]
… my changes are in a different place
08:47:04 [hknublau]
… for next telco I could have a version that we could publish
08:47:22 [hknublau]
Arnaud: we need another week of review anyway
08:48:13 [hknublau]
… current editor draft has lots of improvement, Simon, feel free to take a couple of weeks and let us know.
08:48:18 [pfps]
+1 to try to have a reviewable version next week or the next - I'll try to review it
08:49:08 [hknublau]
Next: ISSUEs?
08:49:26 [hknublau]
Arnaud: suggestion to talk about Results vocabulary
08:50:09 [hknublau]
topic: ISSUE-51
08:50:52 [hknublau]
Arnaud: I wonder how much details we really need.
08:51:07 [hknublau]
… different modes of operation?
08:52:18 [hknublau]
… in case of Success, we said this should be optional
08:52:54 [hknublau]
… at a minimum a boolean result should suffice
08:53:55 [hknublau]
… we discussed it may lead to an infinite number of results
08:54:21 [pfps]
08:54:25 [hknublau]
…compared to a C compiler, it’s all clearly defined if the code is correct, but error handling is undefined
08:54:51 [aryman]
08:55:00 [hknublau]
… implementation may have modes and flags
08:55:23 [Arnaud]
ack pfps
08:55:46 [hknublau]
pfps: I don’t like the analog to syntax errors. Misleading. Better analog would be queries.
08:56:04 [hknublau]
… when you run a query you may have syntax errors, and maybe only the first ones.
08:56:15 [hknublau]
… the validation results are like the answers of the query
08:57:03 [hknublau]
… contract should be that everything gets reported
08:57:26 [ericP]
E20935 Server vaporized by meteor
08:57:29 [hknublau]
… some implementations may decide to limit
08:57:50 [hknublau]
Arnaud: two different question: 1) how much info needs to be recorded 2) how do we report it
08:57:52 [Arnaud]
ack aryman
08:58:08 [Arnaud]
08:58:17 [hknublau]
aryman: different modes possible, e.g. at development time you want verbose reporting
08:58:28 [hknublau]
… yet at runtime less info may be needed
08:59:21 [hknublau]
… analogy with syntax checking: 1 error in your code may trigger lots of other errors, which are clutter
08:59:49 [hknublau]
… could we have a dependency graph between constraints?
09:00:39 [hknublau]
… e.g. minCount 1 then check on actual value
09:01:37 [hknublau]
pfps: sounds difficult
09:01:50 [hknublau]
aryman: each constraint could have a priority
09:02:10 [hknublau]
… optimizer could overrule that decision
09:02:47 [hknublau]
09:03:17 [Dimitris]
09:03:33 [pfps]
This seems like a significant extension to both the syntax and the meaning of SHACL
09:04:05 [Arnaud]
ack hknublau
09:04:10 [Dimitris]
I have something similat in rdfunit (TestCaseDependency) but not yet implemented
09:04:13 [Dimitris]
09:04:15 [ericP]
hknublau: these feels complicating to specify and use
09:04:34 [ericP]
... but in cases like hasValue, we could just return one violation
09:04:40 [ericP]
... but that's an implementation detail
09:04:50 [ericP]
... in the test cases we need to look for all of the possible errors
09:05:04 [ericP]
... how to specify it is more important than what they report
09:05:12 [hknublau]
(thanks eric)
09:05:17 [Arnaud]
ack Dimitris
09:05:18 [ericP]
... there will be variation between implementations
09:05:34 [hknublau]
Dimitris: agreed this gets complicated
09:05:39 [hknublau]
… sounds like a nice to have
09:06:04 [hknublau]
… about reporting: multiple modes would be good, e.g. summary and details
09:06:42 [hknublau]
Arnaud: nobody wants to drop the details?
09:07:06 [hknublau]
… Option: we skip all this together, just a boolean
09:07:09 [pfps]
part of the raison d'etre of SHACL is reporting violations - leaving the reporting undefined thus seems rather counterproductive
09:07:19 [hknublau]
+1 peter
09:07:32 [pfps]
it's like if SPARQL didn't define what queries are supposed to return
09:07:51 [hknublau]
… Another option is to define all details of what needs to be reported under what options
09:07:55 [aryman]
09:08:05 [Dimitris]
+1 to peter
09:08:42 [Arnaud]
ack aryman
09:09:05 [hknublau]
aryman: just saying it’s invalid is not useful
09:09:06 [pfps]
my complaint about violation reporting in the current spec is that it is unclear just what reporting is going on
09:09:28 [hknublau]
… in source code we have line numbers, in RDF we only have triples
09:09:32 [hknublau]
09:10:12 [hknublau]
… we need a mechanism to guide people to source of a problem
09:10:57 [hknublau]
Arnaud: difference between what is expected and what is required for conformance
09:11:03 [Dimitris]
09:11:16 [Arnaud]
ack hknublau
09:11:27 [pfps]
again - like SPARQL without definting what queries return
09:12:30 [pfps]
09:12:40 [ericP]
hknublau: in my impl, i report the violating triple or the relevent component, e.g. s,p for cardinality constraint
09:13:36 [ericP]
... SHACL compliance (at some conformance level) should permit boolean and another should include everything (which still needs to be defined)
09:13:38 [pfps]
q+ to say that the normal mode of SHACL reporting should be full reporting, and all SHACL implentations have to have this mode
09:13:39 [Arnaud]
ack Dimitris
09:14:07 [hknublau]
Dimitris: maybe to also accommodate ShEx: focus node, links to shapes and constraint
09:14:28 [iovka]
09:14:57 [hknublau]
ericP: we are working on this problem too with ShEx
09:15:21 [aryman]
09:15:38 [hknublau]
… a boolean might be sufficient as in some cases there is no way to correct the input anyway
09:15:39 [hsolbrig]
09:16:31 [hknublau]
ericP: challenge is which of the many fixes to report back
09:17:04 [hknublau]
… example… two solutions may exist
09:17:32 [pfps]
09:19:07 [hknublau]
… what about nested violations (sh:valueShape)
09:19:39 [Arnaud]
ack iovka
09:19:43 [hknublau]
iovka: best thing would be interactive error reporting
09:20:38 [hknublau]
Dimitros: interactive cannot work with an engine
09:20:50 [iovka]
09:20:56 [Arnaud]
ack aryman
09:21:12 [hknublau]
aryman: we should be looking at this from use cases perspective
09:21:47 [hknublau]
… e.g. input form should have a red star next to a field that requires fixing
09:22:42 [hknublau]
… requirements document indicate we need enough reporting
09:22:47 [ericP]
q+ to explore Dimitris's proposal
09:22:48 [simonstey]
09:23:30 [hknublau]
Arnaud: reducing the format may speed up the spec process
09:23:48 [hknublau]
… (with a chair’s hat on)
09:24:56 [hsolbrig]
09:25:10 [pfps]
09:25:20 [ericP]
hknublau: i don't know what we would save if we abandoned this and it's already specified
09:25:47 [aryman]
09:26:16 [Arnaud]
ack ericP
09:26:16 [Zakim]
ericP, you wanted to explore Dimitris's proposal
09:26:37 [hknublau]
ericP: Dimitris’ proposal sounds promising
09:27:21 [pfps]
the version of the spec document that I reviewed had significant problems with violation reporting not related to the violation/error/success difference
09:27:26 [pfps]
09:27:35 [hknublau]
… if I validate X as a Y, and that entails validating V as a W we can still easily capture that tree
09:28:22 [hknublau]
… simple thing: just return focus node and shape
09:29:21 [hknublau]
kcoyle: how would that handle Arthur’s form use case
09:30:23 [hknublau]
ericP: question of modularity, some implementations may report less or more
09:30:30 [hsolbrig]
09:30:43 [Arnaud]
ack hsolbrig
09:31:01 [pfps]
again, these are not errors - they are violations
09:31:01 [hknublau]
hsolbrig: Error handling in XSLT works pretty well
09:31:22 [hknublau]
… they tie error messages to test cases
09:31:43 [pfps]
the best XSLT analogue is the result of the transformation
09:31:48 [hknublau]
… test case 43 says this data should fail due to cardin constraint
09:32:03 [hknublau]
… at runtime, all test cases return the same error number
09:32:35 [hknublau]
… a uniform consistently “error number” should be sufficient
09:32:54 [Arnaud]
ack aryman
09:33:29 [hknublau]
aryman: two parts: 1) what is the syntax for error reporting
09:33:59 [hknublau]
… should have the capability to point at the source of the error and perhaps a human-readble message
09:34:17 [hknublau]
… 2) minimum: if something is wrong we need at least one error
09:34:43 [hknublau]
… details should be left to implementations
09:35:31 [pfps]
it would be easy to specifty exactly what gets reported - just say that it is the results of the SPARQL+ query
09:36:01 [ericP]
what if we use SHACL to validate the validation report and it's invalid?
09:37:01 [hknublau]
Arnaud: WG seems to want at least one violation
09:37:32 [pfps]
09:37:38 [hknublau]
09:37:55 [Arnaud]
ack pfps
09:38:05 [hknublau]
pfps: Disagree
09:38:24 [hknublau]
… Typical use case: find the violations in a large RDF graph
09:38:42 [hknublau]
… if all you get back is one violation then this is useless
09:39:36 [aryman]
09:39:36 [ericP]
the C spec still doesn't mandiate reporting more than one error
09:40:00 [ericP]
the C spec didn't address your screw case; the implementors did that independently
09:40:14 [hsolbrig]
How about at least one error per focus node?
09:40:21 [pfps]
09:40:23 [ericP]
there's *0* standardization ebtween MSVC, g++, clang, ...
09:40:27 [hknublau]
Arnaud: what compliance level is needed
09:40:37 [hknublau]
… order of violations reporting should not matter
09:41:13 [Arnaud]
ack hknublau
09:41:26 [ericP]
hknublau: disagree.
09:41:45 [pfps]
I don't think that anyone would argue that the order of violation reporting can be specified
09:41:52 [ericP]
... in the SPARQL spec, there's a protocol and if you utter a query, you get the same response back
09:41:59 [Dimitris]
09:42:10 [ericP]
... so you can build code that works against any SHACL implementation
09:42:26 [Arnaud]
ack aryman
09:42:41 [ericP]
... in SPARQL there's SELECT and ASK; ASK is equivalent to gettting a boolean response
09:43:31 [hknublau]
aryman: for reference implementation performance characteristics should not matter
09:43:38 [hknublau]
… lowering the bar
09:43:48 [Arnaud]
ack pfps
09:44:30 [Arnaud]
ack Dimitris
09:44:39 [ericP]
q+ to observe that the sun is out in Lille
09:44:50 [ericP]
09:45:07 [hknublau]
Dimitris: we define output format, leave details about time out
09:46:51 [hknublau]
Arnaud: Compliance levels one-star, two-star etc sounds complex (?)
09:47:25 [hknublau]
… Peter suggested failures should be separated
09:48:03 [hknublau]
pfps: Draft with Success, ValidationResults and Failures seem to be 3 different things
09:48:34 [hknublau]
… risk of smushing together: implementations could produce some violations and quit
09:49:33 [hknublau]
… only report violations, everything else is handled by another mechanism
09:50:01 [aryman]
+1 to separating constraint violations from other failure/success signals
09:50:04 [hknublau]
Arnaud: Terminology…
09:50:56 [hknublau]
… severity levels: info, warning, error, then Failures for the runtime errors
09:51:02 [pfps]
I would prefer, and have previously stated, that constraint violations should not be called errors
09:51:34 [aryman]
+1 to calling a violation a Violation
09:51:56 [simonstey]
do we have to report runtime errors? if not, info/warning/failure for the 3 levels
09:52:19 [hsolbrig]
What is an example runtime error?
09:52:21 [aryman]
09:52:30 [Dimitris]
I am also open to separate failures/success from violation instances
09:52:32 [Arnaud]
ack aryman
09:52:55 [simonstey]
+1 to that
09:53:22 [pfps]
I am against putting syntax "failures" into the results graph
09:53:24 [hknublau]
aryman: in some cases you cannot even report a result object, it should be an API issue
09:54:07 [pfps]
09:54:29 [Arnaud]
ack pfps
09:54:51 [Arnaud]
09:54:54 [hknublau]
pfps: I had sent a proposal
09:55:11 [Dimitris]
09:55:29 [Arnaud]
ack Dimitris
09:56:08 [hknublau]
Dimitris: Similar to Holger’s latest draft, but removing Success and Failures, I would be OK with minor changes.
09:56:14 [aryman]
09:56:23 [Arnaud]
ack aryman
09:56:39 [hknublau]
aryman: agree except where it references an API
09:57:41 [pfps]
if "API" is not something to say, then "result of the operation" is a suitable replacement
09:58:05 [aryman]
holger broke up
09:58:05 [simonstey]
*brbl* *grmbl*
09:59:19 [ericP]
i think that was more *brbl* *grmbl* *bggl* "and then we're done"
09:59:29 [Dimitris]
09:59:40 [Arnaud]
ack Dimitris
09:59:46 [hknublau]
Dimitris: even an Info is violation
10:00:27 [hknublau]
hknublau: we are going back and forth
10:00:37 [simonstey]
but peter is calling them validationresults in his proposal isn't he?
10:00:46 [hknublau]
… constraint violation -> validation results -> constraint violation
10:01:12 [pfps]
again, I think that "error" is the wrong word to use for any kind of constraint violation
10:02:31 [hknublau]
Suggest a class ValidationResult with severity. Keep Error as a level because it’s used in many places like this
10:04:17 [simonstey]
+1 to validationresults
10:04:28 [Arnaud]
RESOLVED: limit reporting to validation results, and not include runtime errors
10:04:39 [aryman]
10:04:50 [pfps]
works for me
10:04:52 [ericP]
kcoyle: +1
10:04:53 [Dimitris]
10:04:54 [hsolbrig]
10:05:00 [simonstey]
10:05:00 [Labra]
10:06:07 [hknublau]
Arnaud: I think we had a good meeting, let’s stay motivated and full of energy
10:06:22 [hknublau]
hknublau has left #shapes
10:07:33 [Arnaud]
trackbot, end meeting
10:07:33 [trackbot]
Zakim, list attendees
10:07:33 [Zakim]
As of this point the attendees have been Arnaud, iovka, ericP, kcoyle, labra, dimitris, hknublau, pfps
10:07:41 [trackbot]
RRSAgent, please draft minutes
10:07:41 [RRSAgent]
I have made the request to generate trackbot
10:07:42 [trackbot]
RRSAgent, bye
10:07:42 [RRSAgent]
I see no action items