07:42:50 <RRSAgent> RRSAgent has joined #shapes
07:42:50 <RRSAgent> logging to http://www.w3.org/2015/09/10-shapes-irc
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> agenda: https://www.w3.org/2014/data-shapes/wiki/F2F4#Day_3_-_Thursday_September_10
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> hello
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
<hsolbrig> present+ hsolbrig
08:01:15 <pfps> present+ pfps
08:01:51 <iovka> iovka has joined #shapes
08:03:01 <aryman> aryman has joined #shapes
<aryman> present+ aryman
08:03:48 <hknublau> scribenick: hknublau
08:04:39 <simonstey> simonstey has joined #shapes
<simonstey> present+ simonstey
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> q+
08:08:34 <aryman> q+
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> q+
08:15:22 <Arnaud> ack aryman
08:15:59 <pfps> q+
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> http://www.w3.org/TR/owl2-primer/
08:16:57 <pfps> q-
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> q+
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> q+
08:23:22 <aryman> q+
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> q+
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> +1
08:40:12 <Dimitris> +1
08:40:13 <simonstey> +1
08:40:14 <hsolbrig> +0
08:40:18 <aryman> +1
08:40:19 <Labra> 0
08:40:23 <kcoyle> +1
08:40:28 <ericP> +1
08:40:32 <pfps> +1
08:40:33 <iovka> +0.5
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> http://www.w3.org/TR/2015/WD-shacl-ucr-20150414/
08:44:37 <Arnaud> http://w3c.github.io/data-shapes/data-shapes-ucr/
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> q+
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> q+
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> s/recorded/reported/
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> q+
09:03:17 <Dimitris> q+
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> https://github.com/AKSW/RDFUnit/blob/master/ns/rdfunit_ontology_diagram.png
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> q+
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> q+
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> +q
09:11:16 <Arnaud> ack hknublau
09:11:27 <pfps> again - like SPARQL without definting what queries return
09:12:30 <pfps> q+
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> +q
09:14:57 <hknublau> ericP: we are working on this problem too with ShEx
09:15:21 <aryman> q+
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> q+
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> q-
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> -q
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> http://w3c.github.io/data-shapes/data-shapes-ucr/#r10-vocabulary-for-constraint-violations
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> q-
09:25:10 <pfps> q+
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> q+
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> q-
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> q+
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> q+
09:37:38 <hknublau> q+
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> q+
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> q+
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> q+
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> q-
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> q+
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> q+
09:54:29 <Arnaud> ack pfps
09:54:51 <Arnaud> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Sep/0025.html
09:54:54 <hknublau> pfps: I had sent a proposal
09:55:11 <Dimitris> q+
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> q+
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> q+
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> +1
10:04:50 <pfps> works for me
10:04:52 <ericP> kcoyle: +1
10:04:53 <Dimitris> +1
10:04:54 <hsolbrig> +1
10:05:00 <simonstey> +1
10:05:00 <Labra> 0
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 http://www.w3.org/2015/09/10-shapes-minutes.html trackbot
10:07:42 <trackbot> RRSAgent, bye
10:07:42 <RRSAgent> I see no action items