18:01:18 <RRSAgent> RRSAgent has joined #shapes
18:01:18 <RRSAgent> logging to http://www.w3.org/2015/09/17-shapes-irc
18:01:20 <trackbot> RRSAgent, make logs rdf-data-shapes
18:01:20 <Zakim> Zakim has joined #shapes
18:01:22 <trackbot> Zakim, this will be SHAPES
18:01:22 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
18:01:23 <trackbot> Meeting: RDF Data Shapes Working Group Teleconference
18:01:23 <trackbot> Date: 17 September 2015
18:01:38 <Arnaud1> present+ hsolbrig, kcoyle, pfps, Arnaud, ericP, aryman
18:02:32 <hknublau> present+ hknublau
18:03:03 <kcoyle> present+ kcoyle
18:04:23 <Labra> Labra has joined #shapes
18:05:04 <pfps> scribenick pfps
18:05:30 <pfps> topic: admin
18:05:36 <Arnaud> PROPOSED: Approve minutes of the 3 September Telecon: http://www.w3.org/2015/09/03-shapes-minutes.html
18:05:45 <pfps> arnaud: minutes for 3 September and last week's F2F
18:05:47 <pfps> q+
18:05:58 <Arnaud> ack pfps
18:07:29 <pfps> pfps: I had trouble plowing through the resolutions for ISSUE-44, but when you look at the issue, it's  not so bad
18:07:39 <kcoyle> call in user #2 needs to mute, thx
18:07:41 <Arnaud1> Arnaud1 has joined #shapes
18:07:45 <pfps> 	RESOLVED: Approve minutes of the 3 September Telecon: http://www.w3.org/2015/09/03-shapes-minutes.html
18:08:40 <pfps> PROPOSED: Approve minutes of the 8, 9, and 10 September F2F: http://www.w3.org/2015/09/08-shapes-minutes.html, http://www.w3.org/2015/09/09-shapes-minutes.html, http://www.w3.org/2015/09/10-shapes-minutes.html
18:09:03 <pfps> pfps: aside from the ISSUE-44 issue, I don't see any problems
18:09:20 <Arnaud1> Arnaud1 has joined #shapes
18:09:55 <pfps> pfps: and the ISSUE-44 issue is OK
18:10:15 <pfps> RESOLVED: Approve minutes of the 8, 9, and 10 September F2F: http://www.w3.org/2015/09/08-shapes-minutes.html, http://www.w3.org/2015/09/09-shapes-minutes.html, http://www.w3.org/2015/09/10-shapes-minutes.html
18:10:32 <pfps> arnaud: next meeting next week
18:10:41 <pfps> Topic: Raised issues
18:10:49 <pfps> arnaud: there were quite a few raised issues
18:11:01 <Arnaud1> q?
18:11:11 <Arnaud2> Arnaud2 has joined #shapes
18:11:15 <pfps> arnaud: ISSUE-85 may already be resolved, but let's do the usual thing
18:11:19 <Arnaud2> PROPOSED: Open ISSUE-85, ISSUE-86, ISSUE-87, ISSUE-88, ISSUE-89
18:11:28 <pfps> arnaud: any problems with opening these five issues?
18:11:59 <Arnaud2> RESOLVED: Open ISSUE-85, ISSUE-86, ISSUE-87, ISSUE-88, ISSUE-89
<pfps> topic: ISSUE-85
18:12:26 <pfps> arnaud: ISSUE-85 is about the definition of XOR and Holger already has a solution
18:12:57 <pfps> holger: XOR is generally defined as an odd number of true values, so I've applied that change
18:13:03 <pfps> pfps: that's fine by me
18:13:52 <aryman> q+
18:14:16 <pfps> Eric: XOR was one of
18:14:55 <Arnaud> Arnaud has joined #shapes
18:15:01 <Arnaud> q?
18:15:01 <pfps> harold: I don't see much use for for actual XOR
18:15:02 <Arnaud> ack aryman
18:15:36 <pfps> arthur: one of might have been useful, but it is expensive
18:15:40 <hsolbrig> hsolbrig has joined #shapes
18:16:04 <pfps> arthur: having a odd of constraints being true is odd
18:16:06 <Arnaud> https://github.com/w3c/data-shapes/commit/7210fdb94ba1413086c1a524e312e815cb2ae957
18:16:06 <pfps> q+
18:16:16 <Arnaud> ack pfps
18:16:30 <aryman> I am looking at http://w3c.github.io/data-shapes/shacl/#xor
18:16:53 <pfps> pfps: XOR is defined as odd number so that it works right
18:17:08 <pfps> eric: I don't think that any one wants XOR
18:17:38 <pfps> holger: the editor's draft has the odd number definition
18:18:02 <ericP> propose to drop it
18:18:16 <pfps> holger: I implemented XOR the way that it seemed more useful, but changed it to match the namme
18:18:23 <pfps> q+
18:18:33 <Arnaud> ack pfps
18:18:48 <pfps> pfps: I'm not sure what good one of is
18:19:17 <pfps> pfps: I see XOR as being more useful than one of
18:19:47 <pfps> arthur: is there any use case for XOR with more than two arguments?
18:19:59 <ericP> PROPOSAL: drop XOR constraint
18:20:10 <pfps> arnaud: I was hoping that this would be quick
18:20:20 <pfps> arnaud: holger modified the definition to  match the name
18:20:33 <pfps> arnaud: but now the interest is in one of
18:20:43 <pfps> arnaud: there are two possible operations - xor and one of
18:21:13 <pfps> arnaud: at least now the name is correct for the definition
18:21:35 <pfps> arnaud: we could close ISSUE-85 based on the current draft
18:21:54 <aryman> q+
18:22:03 <pfps> arnaud: then there could be a new issue to determine whether to keep XOR and replace with one of
18:22:05 <Arnaud> ack aryman
18:22:42 <pfps> arthur: there was a one of from ShEx.  I assume that this was mistranslated to XOR
18:22:58 <pfps> arthur: so why keep it?
18:23:24 <pfps> arnaud: so if the current definition of XOR is not useful, then raise an issue
18:24:31 <ericP> q+ to say that i'm happy to drop XOR and oneOf
18:24:34 <pfps> arthur: technically all we need is the binary versions of the booleans
18:24:54 <Arnaud> ack ericP
18:24:54 <Zakim> ericP, you wanted to say that i'm happy to drop XOR and oneOf
18:24:57 <ericP> or replace them with COUNT* or MD5SUM
18:25:14 <pfps> eric: I'm happy to have neither XOR nor one of
18:25:27 <pfps> arnaud: how about dropping XOR
18:25:27 <hsolbrig> I'm happy to see it go
18:25:32 <ericP> PROPOSAL: drop XOR constraint
18:25:46 <Arnaud> PROPOSED: Close ISSUE-85, dropping XorConstraint altogether
18:25:47 <pfps> karen: I'm not so sure about one of
18:25:53 <hknublau> +1
18:25:54 <hsolbrig> +1
18:25:56 <ericP> +1
18:26:04 <aryman> +1
18:26:05 <pfps> +1
18:26:25 <kcoyle> +1
18:26:36 <Labra> +1
18:26:47 <Arnaud> RESOLVED: Close ISSUE-85, dropping XorConstraint altogether
18:27:36 <pfps> arnaud: if anyone wants a one of operation, open an issue for it
18:28:02 <pfps> topic: SHACL spec
18:28:20 <pfps> arnaud: holger implemented the resolutions from the F2F
18:28:29 <pfps> arnaud: pfps reviewed it
18:28:44 <pfps> arnaud: let's hear from holger if there any more edits planned
18:29:04 <pfps> holger: no more significant edits planned, except for removing XOR
18:29:24 <pfps> holger: let's publish
18:29:55 <pfps> pfps: progress is being made
18:30:18 <pfps> pfps: I think that the role of SPARQL needs to be clarified before FPWD publication
18:30:39 <pfps> pfps: I haven't had a chance to look at Holger's recent edits
18:31:04 <pfps> holger: I added a section of relationship between SPARQL and SHACL
18:31:25 <pfps> q+
18:31:29 <Arnaud> ack pfps
18:32:18 <pfps> pfps: the other big issue concerns violations in embedded constraints and shapes - currently it appears that a violation under a negation would be reported back and cause failure
18:33:23 <pfps> holger: is this about infinite recursion?
18:33:43 <pfps> pfps: no, this is not about infinite recursion
18:35:05 <pfps> pfps: right now the document implies that any constraint violation is reported back directly even if it is inside an or or a not
18:35:54 <pfps> holger: I added  something to clarify this concerning temporary reporting
18:36:24 <pfps> arthur: this appears to be very implementation specific
18:36:43 <pfps> holger: how should I then describe the situation?
18:37:03 <pfps> q+
18:37:18 <pfps> ack pfps
18:37:39 <pfps> pfps: I'll try to give the document another read to see if this has been fixed
18:38:37 <pfps> arnaud: peter, are there more problems
18:39:25 <pfps> pfps: I had several comments, really only the first two need to be completely address before FPWD publication
18:39:37 <pfps> pfps: the others, although significant, can be handled later
18:39:53 <pfps> q-
18:39:56 <Arnaud1> Arnaud1 has joined #shapes
18:40:17 <pfps> arnaud: that's rather encouraging
18:40:34 <pfps> pfps: this is *not* a ringing endorsement of the document, however :-)
18:41:01 <pfps> holger: what needs to be done before FPWD publication
18:41:45 <pfps> arnaud: is it possible to be done with the edits by the end of the week?
18:41:48 <pfps> q+
18:42:10 <pfps> holger: the last change can be done today
18:42:21 <Arnaud1> ack pfps
18:42:45 <pfps> pfps: I haven't had a chance to look at the current version of the document
18:43:01 <pfps> arnaud: so let's review the document for next week
18:43:20 <pfps> holger: the diffs give a good notion of what had changed
18:43:49 <pfps> arnaud: holger - please announce when you have done with your most recent changed
18:44:10 <pfps> arnaud: next week there will be an attempt to go to FPWD
18:44:21 <pfps> topic: ISSUE-75
18:44:24 <pfps> ISSUE-75
18:44:24 <trackbot> ISSUE-75 -- How to distinguish constraint violations from errors -- open
18:44:24 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/75
18:44:51 <pfps> arnaud: ISSUE-75 concerns the difference between violation reporting and run-time errors
18:44:52 <Arnaud1> http://www.w3.org/2015/09/10-shapes-minutes.html#resolution02
18:45:28 <aryman> q+
18:45:32 <pfps> arnaud: there was a resolution to limit results to violations - this is a resolution for ISSUE-75
18:45:34 <pfps> q+
18:45:34 <Arnaud1> ack aryman
18:45:37 <pfps> pfps: works for me
18:45:57 <pfps> arthur: yes, the issue was about terminology
18:46:11 <pfps> arnaud: there is an issue about the results vocabulary - ISSUE-51
18:46:19 <Arnaud1> ack pfps
18:46:31 <pfps> arnaud: ISSUE-75 was how to distinguish between violations and errors
18:46:45 <pfps> pfps: the F2F resolution solves ISSUE-75
18:46:47 <Arnaud1> PROPOSED: Close ISSUE-75 with F2F resolution "limit reporting to validation results, and not include runtime errors"
18:46:52 <pfps> +1
18:47:11 <aryman> the F2F resolution was to only report constraint violations, all other problems are API issues
18:47:11 <kcoyle> +1
18:47:15 <hsolbrig> +1
18:47:18 <aryman> +1
18:47:50 <hknublau> +1
18:47:55 <Labra> +1
18:48:02 <Arnaud1> RESOLVED: Close ISSUE-75 with F2F resolution "limit reporting to validation results, and not include runtime errors"
18:48:18 <pfps> topic: ISSUE-83
18:48:22 <pfps> ISSUE-83
18:48:22 <trackbot> ISSUE-83 -- How should multiple definitions of sh:qualifiedValueShape of a property constraint be treated? -- open
18:48:22 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/83
18:49:09 <pfps> arnaud: unfortuantely Simon is not here
18:49:12 <pfps> q+
18:49:29 <Arnaud1> ack pfps
18:49:33 <pfps> pfps: my understanding is that this is not valid syntax
18:50:38 <pfps> pfps: somewhere there is wording to the effect that there can be only one of each of the bits of a property constraint
18:51:24 <pfps> The following sections provide details on the properties that may be used with sh:PropertyConstraint. None of these properties can be repeated within the same sh:PropertyConstraint. In order to define multiple constraints using the same property, such as multiple sh:hasValue constraints, the shape must use multiple sh:property definitions.
18:51:29 <Arnaud> Arnaud has joined #shapes
18:51:35 <Arnaud> q?
18:51:40 <pfps> pfps: I just pasted the relevant part of the spec
18:52:00 <pfps> holger: syntactically invalid
18:52:11 <aryman> None of these properties can be repeated within the same sh:PropertyConstraint
18:52:25 <pfps> arnaud: is everyone happy with that
18:52:29 <pfps> q+
18:52:29 <ericP> Dq+
18:52:34 <Arnaud> ack pfps
18:53:19 <aryman> q+
18:53:22 <pfps> pfps: if anyone wants to have  multiples they have to come up with a syntax that works in the RDFS encoding
18:53:54 <pfps> eric: how does this look from a user perspective?
18:56:31 <Arnaud> ack aryman
18:56:36 <pfps> pfps: the motivation is that graphs don't have parenthesis - you need something to separate them - that's currently done by having multiple property constraints
18:56:44 <pfps> eric: OK
18:57:04 <pfps> arthur: what about multi-occurence of properties
18:57:16 <pfps> eric: that's needed (and different)
18:57:36 <pfps> arthur: what about allowedValues
18:57:38 <pfps> eric: that works
18:58:03 <pfps> arthur: it doesn't make sense to have two minCount
18:58:29 <pfps> arthur: the syntax for qualified value shapes appears to be bad language design
18:58:57 <pfps> arthur: I think that the language would be better if there was a way to have multiple qualified value shapes on the same property constraint
18:59:26 <pfps> arthur: so iSSUE-83 is about fixing the language design
18:59:26 <hknublau> q+
18:59:28 <pfps> q+
18:59:32 <Arnaud> ack hknublau
19:00:10 <pfps> holger: allowing multiple qualified value shapes is a significant change to the syntax
19:00:35 <pfps> holger: the current design is uniform
19:00:54 <pfps> arthur:  ... use case ...
19:01:01 <Arnaud> ack pfps
19:01:03 <pfps> arnaud: simon put in an example
19:01:55 <pfps> pfps: so if one wanted to "fix" the syntax, then there are lots of fixes that I think should be put in, starting with not have omnibus property constraints, which just cause problems (although they look nice)
19:02:39 <pfps> pfps: right now you could have a single property constraint with pieces
19:02:58 <pfps> arnaud:  if anyone wants a syntax change, then propose that directly
19:03:38 <pfps> arnaud: the particular issue at hand is about the (current) treatment of multiple qualified value shapes
19:03:57 <pfps> arnaud: if anyone thinks that there needs to be a change to the syntax, then propose the change
19:04:03 <pfps> +1
19:05:04 <pfps> http://w3c.github.io/data-shapes/shacl/#constraints-property, just before the list of properties for property constraints
19:05:39 <Arnaud> PROPOSED: Close ISSUE-83, the specification says this is actually invalid syntax in section 3.1  https://w3c.github.io/data-shapes/shacl/#constraints-property
19:05:58 <pfps> +1
19:06:04 <hknublau> +1
19:06:13 <Labra> 0
19:06:45 <aryman> +1
19:06:48 <hsolbrig> 0
19:07:01 <kcoyle> 0 (not sure I understand)
19:07:40 <aryman> q+
19:07:49 <Arnaud> ack aryman
19:07:57 <pfps> arthur: not that much support
19:08:08 <pfps> harold: I don't understand the ramifications
19:08:33 <pfps> arthur: you need multiple property constraints, each one with a qualified cardinality shape
19:08:40 <pfps> holger: correct
19:09:06 <Arnaud> RESOLVED: Close ISSUE-83, the specification says this is actually invalid syntax in section 3.1  https://w3c.github.io/data-shapes/shacl/#constraints-property (note that the same result can however be achieved using multiple property constraints)
19:09:15 <pfps> arnaud: add a note saying that the effect can be achieved with multiple property constraints
19:09:19 <hsolbrig> +1
19:09:35 <hsolbrig> (now that I know that it still can be done)
19:10:02 <pfps> arnaud: we have 20 minutes left - any issues to be considered
19:10:10 <aryman> q+
19:10:42 <pfps> holger: we had touched upon the results vocabulary, so let's consider ISSUE-51
<pfps> topic: ISSUE-51
19:11:03 <pfps> holger: I think that the current draft can be considered a resolution for the issue
19:11:09 <pfps> ISSUE-51
19:11:09 <trackbot> ISSUE-51 -- What types of validation results should be returned -- open
19:11:09 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/51
19:11:37 <pfps> arnaud: we may have to wait until people take a look at the spec
19:12:35 <kcoyle> q+
19:12:43 <Arnaud> ack kcoyle
19:12:44 <pfps> pfps: I think that the issue can be closed, but I see that others may need to take a look
19:13:20 <pfps> kcoyle: can we have a summary of the design
19:13:23 <Arnaud> https://w3c.github.io/data-shapes/shacl/#results
19:13:30 <aryman> the draft still uses sh:Error instead of sh:Violation
19:13:40 <pfps> holger: there is a single class for validation results, with a severity property, with three values
19:13:57 <pfps> holger: the other fields give details on the result
19:14:45 <pfps> holger: the difference is dropping the other stuff - implementations can extend as necessary
19:14:51 <Arnaud> ack aryman
19:15:18 <pfps> arthur: my preference is to use violation instead of error for the severity level
19:15:27 <pfps> arnaud: so information, warning, and violation
19:15:31 <pfps> arthur: yes
19:15:45 <pfps> holger: that's not how other frameworks do it
19:16:01 <pfps> arthur: this is not a log, it is a validation report
19:16:29 <pfps> arthur: we are defining a domain-specific vocabulary so we should use terms relevant to the domain
19:16:43 <hsolbrig> q+
19:16:50 <Arnaud> ack hsolbrig
19:16:51 <pfps> +q to arthur
19:17:27 <pfps> harold: I agree with arthur - violations are things that have gone wrong, so we should avoid using error
19:17:37 <ericP> +1
19:17:41 <pfps> s/have/have not/
19:17:50 <Arnaud> ack pfps
19:17:50 <Zakim> pfps, you wanted to arthur
19:18:05 <pfps> +1 to arthur
19:18:18 <kcoyle> I'm good with violation as well
19:18:52 <pfps> arnaud: any other comments - if not I'll propose closing with the vocabulary change
19:18:56 <Arnaud> PROPOSED: Close ISSUE-51, adopting with the latest editor's draft renaming sh:Error as sh:Violation
19:18:59 <pfps> +1
19:19:00 <hknublau> 0
19:19:03 <aryman> +1
19:19:04 <hsolbrig> +1
19:19:04 <kcoyle> +1
19:19:42 <Labra> +0
19:19:55 <Arnaud> RESOLVED: Close ISSUE-51, adopting with the latest editor's draft renaming sh:Error as sh:Violation
19:20:31 <pfps> arnaud: arthur you want to make a different poiint
<pfps> topic: rdfs:subClassOf in Templates
19:21:10 <pfps> arthur: inheritance in templates is encoded as rdfs:subClassOf
19:21:13 <pfps> holger: right
19:22:11 <pfps> arthur: subtemplates can add arguments, ancestor templates are validated first and descendant templates later
19:22:39 <pfps> arthur: this is using rdfs:subClassOf in a way different from that in RDFS
19:22:57 <pfps> arthur: how can templates be considered to be templates
19:23:09 <hknublau> q+
19:23:28 <Arnaud> ack hknublau
19:23:30 <aryman> s/how can templates be considered to be templates/how can templates be considered to be classes/
19:23:43 <pfps> holger: this design has been used for many years in SPIN
19:23:56 <pfps> holger: it is very natural to me to instantiate a template
19:24:10 <pfps> holger: an argument declaration seems like a property declaration
19:24:14 <aryman> q+
19:24:20 <pfps> holger: I think that that is very consistent
19:24:34 <pfps> holger: changing this is a big change and I don't think that we need to change it
19:24:56 <pfps> arnaud: the fact that it has been there since day 1 does not mean that it cannot be questioned
19:25:16 <Arnaud> ack aryman
19:25:54 <pfps> arthur: I think that the design makes sense for OO programming, but from an RDFS point of view there does not seem to be any use for a node whose type is a template
19:26:01 <pfps> holger: I really don't see any problem
19:26:22 <pfps> arthur: the use of classes in RDFS is that they classify resources, if it doesn't then it is not a class
19:26:24 <kcoyle> I think Arthur is on to something - much here seems to be very OO
19:26:27 <ericP> +1
19:26:46 <pfps> holger: we could always use nodeShape and not use rdfs:subClassOf
19:27:45 <pfps> arthur: template inheritance should use a different mechanism
19:28:02 <pfps> holger: I think that the use is consistent with RDFS
19:28:07 <pfps> arthur: where are the instances
19:28:38 <pfps> holger: when you say that something is a closed shape then you make the shape an instance of ClosedShape
19:28:42 <pfps> q+
19:29:04 <pfps> arthur: when you use the templates that's an instance of the template class
19:29:25 <Arnaud> ack pfps
19:29:48 <pfps> pfps: holger is talking about templates as instances of classes, but the issue is about instances of templates, which is completely different
19:32:11 <pfps> pfps: an analogy would be homo sapiens - it can be considered to be an instance of species - it can also be considered to be the class of humans - these two relationships are completely different
19:32:39 <pfps> arnaud: this is worth future discussion
19:32:50 <pfps> arthur: I might open an issue on this
19:33:44 <hknublau> hknublau has left #shapes
19:34:03 <Arnaud> agenda: https://www.w3.org/2014/data-shapes/wiki/Meetings:Telecon2015.09.17
19:34:07 <Arnaud> chair: Arnaud
19:34:34 <Arnaud> regrets: simonstey
19:34:47 <Arnaud> regrets: simonstey, dimitris
19:34:53 <Arnaud> trackbot, end meeting
19:34:53 <trackbot> Zakim, list attendees
19:34:53 <Zakim> As of this point the attendees have been hsolbrig, kcoyle, pfps, Arnaud, hknublau
19:35:01 <trackbot> RRSAgent, please draft minutes
19:35:01 <RRSAgent> I have made the request to generate http://www.w3.org/2015/09/17-shapes-minutes.html trackbot
19:35:02 <trackbot> RRSAgent, bye
19:35:02 <RRSAgent> I see no action items