17:58:30 <RRSAgent> RRSAgent has joined #shapes
17:58:30 <RRSAgent> logging to http://www.w3.org/2015/08/27-shapes-irc
17:58:32 <trackbot> RRSAgent, make logs rdf-data-shapes
17:58:32 <Zakim> Zakim has joined #shapes
17:58:34 <trackbot> Zakim, this will be SHAPES
17:58:34 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
17:58:35 <trackbot> Meeting: RDF Data Shapes Working Group Teleconference
17:58:35 <trackbot> Date: 27 August 2015
18:00:32 <Arnaud> present+ Arnaud
18:01:04 <hsolbrig> hsolbrig has joined #shapes
18:01:08 <Dimitris> Dimitris has joined #shapes
18:01:21 <simonstey> present+ simonstey
18:02:19 <hknublau> present+ hknublau
18:03:36 <Dimitris> present+ dimitris
18:04:31 <Dimitris> Dimitris has left #shapes
18:04:42 <Dimitris> Dimitris has joined #shapes
18:05:17 <Arnaud> present+ kcoyle
18:05:40 <Arnaud> present+ ericp
18:06:01 <kcoyle> kcoyle has joined #shapes
18:06:24 <Arnaud> present+ TallTed
18:07:24 <Arnaud> agenda: https://www.w3.org/2014/data-shapes/wiki/Meetings:Telecon2015.08.27
18:07:28 <Arnaud> chair: Arnaud
18:07:32 <kcoyle> present+ kcoyle
18:08:14 <Arnaud> regrets: aryman, pfps, labra
18:08:22 <hsolbrig> present+ hsolbrig
<ericP> topic: Admin
18:08:46 <Arnaud> PROPOSED: Approve minutes of the 20 August Telecon: http://www.w3.org/2015/08/20-shapes-minutes.html
18:08:56 <kcoyle> none
18:09:08 <Arnaud> RESOLVED: Approve minutes of the 20 August Telecon: http://www.w3.org/2015/08/20-shapes-minutes.html
18:10:13 <ericP> Arnaud: iovka has set up badges and directions
18:10:20 <ericP> ... i took a pass at the agenda
18:10:39 <ericP> ... the agenda will probably evolve over time
18:10:50 <ericP> ... let's look at the time frame and the objectives
18:11:10 <ericP> ... folks need to know what we need to cover, but i want you to tell me if i'm missing something
18:11:32 <ericP> ... the time slots don't matter so much as makking sure there's a placeholder for everything we need to cover
18:11:46 <ericP> ... the main piece is of course the shacl spec itself
18:12:04 <ericP> ... i expect to take advantage of the increased bandwidth to resolve issues
18:12:23 <ericP> ... we have an open action item to try to publish FPWD next week
18:12:45 <ericP> ... by the end of the meeting we should know what we need to do to get a CR
18:13:00 <ericP> ... (we can have other working drafts in the process)
18:13:29 <ericP> ... we deferred pulishing a couple things: vocab and @@1
18:13:52 <ericP> ... we need to know how to create a test suite by the end of the meeting
18:14:06 <ericP> ... for now we have holger who has been editing and implementing
18:15:10 <ericP> ... it's unclear how much expressivity we can get from shacl
18:15:36 <ericP> ... i don't want to delay working on the compact syntax because it may impact the lower level
18:16:35 <ericP> ... we don't have much flexibility for lunch time so we have to be firm on the meeting start time (4am US west coast)
18:16:57 <ericP> ... we'll go until 6pm
18:17:43 <ericP> ... we may want to spend more time on the user-friendly syntax if we get into tech discussions
18:17:56 <ericP> ... we have a lot of time for shacl issues so that serves as a buffer
18:18:11 <ericP> ... (the only thing i'm sure of is that there will be shacl issues.)
18:19:09 <hknublau> q+
18:19:14 <Arnaud> ack hknublau
18:19:27 <ericP> hknublau: the meeting will end very late for me (3am)
18:19:38 <ericP> ... if there are topics where i'm needed less, i'd like them at the end
18:19:48 <ericP> ... e.g. test suite or compact syntax
18:20:35 <ericP> Arnaud: understood, though i also want a buffer for them to overrun
18:21:17 <ericP> topic: ISSUE-83
18:21:59 <ericP> simonstey: when Axel and I read the spec we ran across the defn of qualified value shapes
18:22:00 <Arnaud> issue-83
18:22:00 <trackbot> issue-83 -- How should multiple definitions of sh:qualifiedValueShape of a property constraint be treated? -- raised
18:22:00 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/83
18:22:46 <ericP> ... in the current spec there is no clarification saying that you are only allowed one qualified value shape per property
18:23:14 <ericP> ... if you have several qualified value shapes, then one would trigger for all matching triples
18:23:28 <ericP> ... you'd have to define two property constraints to cover that.
18:23:49 <ericP> ... the API should raise an error if you have more than one qualified property constraint.
18:24:21 <ericP> ... i'm still concearned that the qualified{min,max} does not appear in the property constraint
18:25:29 <ericP> Arnaud: ok to open the issue?
18:25:35 <Arnaud> PROPOSED: Open ISSUE-83: multiple sh:qualifiedValueShapes
18:25:42 <ericP> +1
18:25:43 <Dimitris> +1
18:25:46 <kcoyle> +1
18:25:50 <TallTed> +1
18:25:51 <simonstey> +1
18:26:11 <hsolbrig> +1
18:26:18 <hknublau> 0
18:26:25 <Arnaud> RESOLVED: Open ISSUE-83: multiple sh:qualifiedValueShapes
18:27:19 <ericP> Arnaud, should we discuss issue-70, noting that pfps isn't here?
18:27:25 <ericP> ... skipping for today
18:27:30 <ericP> topic: ISSUE-51
18:27:30 <Arnaud> issue-51
18:27:30 <trackbot> issue-51 -- What types of validation results should be returned -- open
18:27:30 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/51
18:27:57 <ericP> Arnaud: the question is about how the results are reported to the calling application.
18:28:15 <ericP> kcoyle: said she was concearned that success was signalled by silence
18:29:06 <ericP> hknublau: in a sense, i agree
18:29:17 <Dimitris> +q
18:29:24 <ericP> ... i think the vocabulary should @@2
18:29:37 <ericP> ... it should say that shapeX was executed succussfully
18:29:45 <ericP> ... if only for recording what happened
18:30:04 <ericP> ... the last time we talked about it, i had a proposal on a branch.
18:30:33 <ericP> ... i implemented what Dimitris suggested: the three error levels (implemented as severity classes)
18:31:03 <ericP> ... there are validation results
18:31:12 <ericP> ... there are errors for e.g. recursion not supported
18:31:23 <ericP> ... and there's success, which defaults to no message
18:31:44 <TallTed> I'd prefer that the success objects be generated by default (with switch available to not).  silence is rarely as useful as positive affirmation.
18:31:52 <ericP> ... pfps made an alternate proposal, but we decided later it was too simplistic
18:32:12 <ericP> Arnaud: why is success only returned as an option?
18:32:21 <TallTed> q+
18:32:22 <ericP> hknublau: there could be thousands of successes
18:33:17 <ericP> ... since everything goes into a results graph, it could entail too much in that graph
18:34:00 <ericP> Arnaud: kcoyle, you said you want to know the difference between the successful validation vs. the machine stopped.
18:34:11 <ericP> ... so a boolean flag would work
18:34:28 <ericP> kcoyle: fine for me, i can imagine developers would want to see more
18:34:33 <Arnaud> ack Dimitris
18:34:43 <ericP> Dimitris: hknublau mostly covered me
18:35:06 <Arnaud> ack TallTed
18:35:09 <ericP> ... reporting only errors is frequently errors, but yes we sometimes need to see what was validated
18:35:22 <ericP> ... happy for the default to be silent success
18:36:01 <ericP> TallTed: i'd like simple success to be the default because silence doesn't tell me that the process was run
18:36:35 <ericP> hknublau: isn't that outside of the spec?
18:37:26 <ericP> ... there's some API that's called and when the caller gets no errors, it can do somethig on the interface.
18:37:44 <ericP> TallTed: we need something like shell's return code
18:37:55 <ericP> hknublau: [differs]
18:38:08 <ericP> s/differs/disagrees/
18:38:15 <ericP> Arnaud: i agree that this is an API issue
18:38:28 <ericP> +1 to API issue
18:39:08 <ericP> hknublau, the branch is pretty up-to-date but also has numeric severity levels (which can be dropped)
18:39:56 <ericP> Arnaud: can you clean up that branch and send it to the list?
18:41:15 <ericP> simonstey: even a test that succeeds can have a severity level
18:42:20 <ericP> hknublau: by following the link back to the constraint, you can get the severity
18:42:31 <ericP> simonstey: then maybe we should remove it from errors as well
18:43:14 <ericP> Arnaud: does what he's describing sound reasonable to people?
18:43:36 <kcoyle> works for me
18:43:39 <ericP> ... we went back and forth between a system that was too limited and one that was too complicated.
18:43:59 <ericP> ... i think what hknublau just described is where we left it
18:44:24 <ericP> ... i know that pfps may have issues about the class hierarchy
18:44:33 <ericP> ... but we should agree on the basic idea
18:46:29 <ericP> Arnaud: welcome Scott Henninger (Dean Alemang's group)
18:46:47 <ericP> topic: ISSUE-74
18:46:37 <Arnaud> issue-74
18:46:37 <trackbot> issue-74 -- Should SHACL support validating RDF graphs accessible via unmodified SPARQL endpoints -- open
18:46:37 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/74
18:47:18 <ericP> Arnaud: pfps raised this, but hknublau, can you introduce it?
18:47:42 <ericP> hknublau: there's a SPARQL Protocol to talk to databases over the web
18:47:58 <ericP> ... the question is whether all the shacl constructs need to work over such a connection
18:48:28 <ericP> ... the protocol has some limitations making it impossible to work with bnodes
18:48:29 <ericP> q+
18:48:55 <ericP> ... i propose that we don't require 100% compatibility with the protocol.
18:49:28 <ericP> ... we can have a separate deliverable which describes what of shacl you can and can't do
18:49:47 <ericP> Arnaud: just the instance graph to be validated or the shapes graph or both?
18:50:07 <ericP> hknublau: we still have a separate topic re: whether we can see the shapes graph
18:50:25 <ericP> ... there are several cases that cannot be solved without access to the shapes graph
18:50:51 <ericP> Arnaud: this issue seems to be about the validation graph
18:51:07 <ericP> hknublau: in principle, you can reduce everything to SPO queries
18:51:13 <Arnaud> ack ericP
18:51:13 <ericP> ... but it's not very fast.
18:52:46 <ericP> ericP: SPARQL doesn't have "told blank nodes"
18:53:59 <ericP> Arnaud: i think pfps wanted us to say that is should be possible to execute SHACL with an unmodified SPARQL endpoint
18:54:13 <ericP> TallTed: possible doesn't mean efficient
18:54:15 <ericP> q+
18:54:25 <Arnaud> ack ericP
18:55:51 <ericP> ericP: you can keep track of how you arrived at a bnode
18:56:04 <ericP> hknublau: but if you get to bnodes, you can't tell them apart
18:56:33 <ericP> ericP: true, but you also can't give a distinct validation result unless you've grabbed their properties
18:56:53 <ericP> TallTed: this is an implementation detail.
18:57:09 <ericP> hknublau: if we carelessly say yes, there are lots of things we have to change
18:57:31 <ericP> TallTed: we could also say "if you can't see the whole graph, you can't validate shapes against it."
18:58:28 <ericP> ... the input to SHACL validation is a shape, a graph, and possibly some focus nodes in that graph
18:58:44 <ericP> ... the input is not a shape, a SPARQL endpoint, ...
18:59:20 <ericP> ... there are lots of graphs behind a SPARQL endpoint, but if the SHACL processor can't see the entire graph, then that graph is not an input
18:59:41 <ericP> hknublau: i proposed to extend the SPARQL protocol to ship shapes to endpoints.
19:01:17 <ericP> Arnaud: this reminds me of inferencing. we say that inferencing is outside of shacl.
19:01:28 <ericP> ... we can say the same thing for SPARQL endpoints
19:01:43 <hsolbrig> +q
19:01:51 <ericP> hknublau: i would be happy to have a separate deliverable
19:02:09 <kcoyle> (Arnaud contemplates infinity)
19:02:20 <Arnaud> ack hsolbrig
19:02:55 <ericP> hsolbrig: i like TallTed's assertion but i think it could be modified to say that shape validation can assume that the entire graph is visible
19:03:16 <ericP> ... we can spec it as if the whole graph is visible.
19:03:37 <ericP> ... however you want to make that happen is up to you.
19:03:46 <Dimitris> +q
19:03:54 <Arnaud> ack Dimitris
19:03:59 <ericP> +1 to hsolbrig's characterisation
19:04:44 <ericP> Dimitris: i'm in favor of SPARQL endpoints, but i won't object. i'd like to minimize the damage as hknublau suggested
19:04:49 <ericP> Arnaud: how much work is that?
19:05:54 <ericP> hknublau: in the simplest form, we can have a paragraph that says "you can wrap an endpoint" and an appendix that enumerates limitations like access graphs
19:06:01 <ericP> Arnaud: this is all informative
19:06:06 <ericP> hknublau: yes
19:06:18 <ericP> Arnaud: satisfied, Dimitris?
19:06:31 <ericP> Dimitris: depends how the spec evolves.
19:06:42 <ericP> ... most of the spec can be formed for endpoints
19:07:03 <ericP> Arnaud: i hear Dimitris saying we shouldn't arbitrarily make it hard for people to do this.
19:07:19 <ericP> ... but we're not bound by this constraint
19:09:08 <kcoyle> i can scribe temporarily
19:09:08 <ericP> ... i can't imagine anyone is opposed to hknublau's proposal to add informative text
19:09:17 <kcoyle> oh, you're back
19:09:33 <ericP> Dimitris: maybe an algorithm to do stuff in a single query
19:09:40 <ericP> TallTed: i don't think that's possible
19:10:02 <ericP> Arnaud: i'm happy for people to work on this, but i don't want to count on it
19:10:13 <ericP> ... we could publish a note
19:11:13 <ericP> ... for issue-74, we're going to answer with a "no" with the caveat that we'll add some informative text to the spec talking about the pitfalls of validating against a SPARQL endpoint and we should keep this in mind so we don't make it arbitrarily difficult
19:12:33 <Arnaud> PROPOSED: Close ISSUE-74, answer is no but we'll add some informative text to the spec talking about the pitfalls of validating against a SPARQL endpoint and we should keep in mind that some people will want to validate against an endpoint so we don't make it arbitrarily difficult
19:13:34 <hknublau> +1
19:13:57 <hsolbrig> +1 (although I think it should say "not always possible" vs. just not)
19:14:08 <kcoyle> +1
19:14:30 <TallTed> +1 "may but also may not be possible, depending on your graph and shape and ......"
19:14:41 <Dimitris> -0.9 for no +1 for informative text and easing sparql endpoint validation
19:16:12 <ericP> Arnaud, Dimitris would you want to limit SHACL to what's implementable over a SPARQL endpoint?
19:16:26 <hknublau> Let’s not forget that SHACL also supports other languages than SPARQL.
19:16:37 <ericP> Dimitris: i think it's a common use case, at least for me. this decision whittles out half of my endpoint
19:16:52 <ericP> TallTed: how much of your data includes bnodes?
19:17:08 <ericP> Dimitris: not much, but i don't want to put everything in memory
19:17:31 <ericP> Arnaud: so maybe the right thing to do is to ship the shape to the endpoint
19:21:09 <ericP> ericP: the sparql protocol is a red herring. SPARQL does not support told bnodes.
19:21:56 <ericP> hknublau: i think we need a statement that bnodes have consistent identifiers
19:22:14 <ericP> ... most vendors have moved to stable identifiers
19:22:34 <Arnaud> RESOLVED: Close ISSUE-74, answer is no but we'll add some informative text to the spec talking about the pitfalls of validating against a SPARQL endpoint and we should keep in mind that some people will want to validate against an endpoint so we don't make it arbitrarily difficult
19:22:42 <ericP> ... but ericP is right that SPARQL does not say bnodes have stable identifiers
19:23:24 <ericP> topic: ISSUE-81
19:23:24 <Arnaud> issue-81
19:23:24 <trackbot> issue-81 -- Shall SHACL Core include support for disjoint properties and other property pair constraints? -- open
19:23:24 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/81
19:23:59 <ericP> hknublau: we got feedback from the outside, which is always appreciated
19:24:17 <ericP> ... we got suggestions like two properties are disjoint
19:24:22 <ericP> q+
19:24:28 <Arnaud> ack ericP
19:25:35 <ericP> ericP: can a shape have properties :a and :b and either :c or :d
19:25:57 <ericP> hknublau, this is about disjoint values
19:26:06 <ericP> hknublau: this is about disjoint values
19:26:17 <ericP> ericP: oops
19:26:36 <Dimitris> +q
19:26:44 <ericP> TallTed: seems like a useful pattern, includeing < > ≠
19:26:53 <ericP> Arnaud: we have an issue about ≠
19:27:15 <ericP> ... simon raised an issue about how to access another property
19:27:21 <Arnaud> ack Dimitris
19:27:36 <ericP> ... but it seems that if we go down this route, we need the normal operators
19:27:42 <shenninger> shenninger has joined #shapes
19:27:49 <TallTed> "disjoint" is the wrong descriptor here -- "not equal" is the meaning from the issue
19:28:03 <kcoyle> q+
19:28:22 <Arnaud> ack kcoyle
19:28:26 <ericP> Dimitris: i would prefer to have < > ≠ = in the core library
19:29:06 <ericP> kcoyle, the skos example is important for the cultural heritage community
19:29:30 <ericP> ... saying that label and preflabel are ≠ or that the language tags have to be unique
19:30:05 <ericP> Arnaud: if the issue you have ordered property constraint
19:30:07 <TallTed> "ordered" was about "greater/less than" -- date values...
19:30:19 <ericP> hknublau: it's only to say that the first is smaller than the second
19:30:31 <TallTed> = ≠ ≥ ≤ < >
19:30:53 <ericP>  ¬ ∧ ∨ ∀ ∃ ∄ ∅ ∈ ∊ ∉ ∋ ∌ ∍
19:32:41 <shenninger> shenninger has left #shapes
19:32:42 <Arnaud> present+ shenninger
19:33:01 <Arnaud> trackbot, end meeting
19:33:01 <trackbot> Zakim, list attendees
19:33:01 <Zakim> As of this point the attendees have been Arnaud, simonstey, hknublau, dimitris, kcoyle, ericp, TallTed, hsolbrig, scott
19:33:09 <trackbot> RRSAgent, please draft minutes
19:33:09 <RRSAgent> I have made the request to generate http://www.w3.org/2015/08/27-shapes-minutes.html trackbot
19:33:10 <trackbot> RRSAgent, bye
19:33:10 <RRSAgent> I see no action items