See also: IRC log
scribenick pfps
<Arnaud> PROPOSED: Approve minutes of the 3 September Telecon: http://www.w3.org/2015/09/03-shapes-minutes.html
arnaud: minutes for 3 September and last week's F2F
pfps: I had trouble plowing through the resolutions for ISSUE-44, but when you look at the issue, it's not so bad
<kcoyle> call in user #2 needs to mute, thx
RESOLUTION: Approve minutes of the 3 September Telecon: http://www.w3.org/2015/09/03-shapes-minutes.html
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
pfps: aside from the ISSUE-44 issue, I don't see any problems
... and the ISSUE-44 issue is OK
RESOLUTION: 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
arnaud: next meeting next week
arnaud: there were quite a few raised issues
... ISSUE-85 may already be resolved, but let's do the usual thing
<Arnaud2> PROPOSED: Open ISSUE-85, ISSUE-86, ISSUE-87, ISSUE-88, ISSUE-89
arnaud: any problems with opening these five issues?
RESOLUTION: Open ISSUE-85, ISSUE-86, ISSUE-87, ISSUE-88, ISSUE-89
arnaud: ISSUE-85 is about the definition of XOR and Holger already has a solution
holger: XOR is generally defined as an odd number of true values, so I've applied that change
pfps: that's fine by me
Eric: XOR was one of
harold: I don't see much use for for actual XOR
arthur: one of might have been useful, but it is expensive
... having a odd of constraints being true is odd
<Arnaud> https://github.com/w3c/data-shapes/commit/7210fdb94ba1413086c1a524e312e815cb2ae957
<aryman> I am looking at http://w3c.github.io/data-shapes/shacl/#xor
pfps: XOR is defined as odd number so that it works right
eric: I don't think that any one wants XOR
holger: the editor's draft has the odd number definition
<ericP> propose to drop it
holger: I implemented XOR the way that it seemed more useful, but changed it to match the namme
pfps: I'm not sure what good one of is
... I see XOR as being more useful than one of
arthur: is there any use case for XOR with more than two arguments?
<ericP> PROPOSAL: drop XOR constraint
arnaud: I was hoping that this would be quick
... holger modified the definition to match the name
... but now the interest is in one of
... there are two possible operations - xor and one of
... at least now the name is correct for the definition
... we could close ISSUE-85 based on the current draft
... then there could be a new issue to determine whether to keep XOR and replace with one of
arthur: there was a one of from ShEx. I assume that this was mistranslated to XOR
... so why keep it?
arnaud: so if the current definition of XOR is not useful, then raise an issue
arthur: technically all we need is the binary versions of the booleans
<Zakim> ericP, you wanted to say that i'm happy to drop XOR and oneOf
<ericP> or replace them with COUNT* or MD5SUM
eric: I'm happy to have neither XOR nor one of
arnaud: how about dropping XOR
<hsolbrig> I'm happy to see it go
<ericP> PROPOSAL: drop XOR constraint
<Arnaud> PROPOSED: Close ISSUE-85, dropping XorConstraint altogether
karen: I'm not so sure about one of
<hknublau> +1
<hsolbrig> +1
<ericP> +1
<aryman> +1
+1
<kcoyle> +1
<Labra> +1
RESOLUTION: Close ISSUE-85, dropping XorConstraint altogether
arnaud: if anyone wants a one of operation, open an issue for it
arnaud: holger implemented the resolutions from the F2F
... pfps reviewed it
... let's hear from holger if there any more edits planned
holger: no more significant edits planned, except for removing XOR
... let's publish
pfps: progress is being made
... I think that the role of SPARQL needs to be clarified before FPWD publication
... I haven't had a chance to look at Holger's recent edits
holger: I added a section of relationship between SPARQL and SHACL
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
holger: is this about infinite recursion?
pfps: no, this is not about infinite recursion
... right now the document implies that any constraint violation is reported back directly even if it is inside an or or a not
holger: I added something to clarify this concerning temporary reporting
arthur: this appears to be very implementation specific
holger: how should I then describe the situation?
pfps: I'll try to give the document another read to see if this has been fixed
arnaud: peter, are there more problems
pfps: I had several comments, really only the first two need to be completely address before FPWD publication
... the others, although significant, can be handled later
arnaud: that's rather encouraging
pfps: this is *not* a ringing endorsement of the document, however :-)
holger: what needs to be done before FPWD publication
arnaud: is it possible to be done with the edits by the end of the week?
holger: the last change can be done today
pfps: I haven't had a chance to look at the current version of the document
arnaud: so let's review the document for next week
holger: the diffs give a good notion of what had changed
arnaud: holger - please announce when you have done with your most recent changed
... next week there will be an attempt to go to FPWD
ISSUE-75
<trackbot> ISSUE-75 -- How to distinguish constraint violations from errors -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/75
arnaud: ISSUE-75 concerns the difference between violation reporting and run-time errors
<Arnaud1> http://www.w3.org/2015/09/10-shapes-minutes.html#resolution02
arnaud: there was a resolution to limit results to violations - this is a resolution for ISSUE-75
pfps: works for me
arthur: yes, the issue was about terminology
arnaud: there is an issue about the results vocabulary - ISSUE-51
... ISSUE-75 was how to distinguish between violations and errors
pfps: the F2F resolution solves ISSUE-75
<Arnaud1> PROPOSED: Close ISSUE-75 with F2F resolution "limit reporting to validation results, and not include runtime errors"
+1
<aryman> the F2F resolution was to only report constraint violations, all other problems are API issues
<kcoyle> +1
<hsolbrig> +1
<aryman> +1
<hknublau> +1
<Labra> +1
RESOLUTION: Close ISSUE-75 with F2F resolution "limit reporting to validation results, and not include runtime errors"
ISSUE-83
<trackbot> ISSUE-83 -- How should multiple definitions of sh:qualifiedValueShape of a property constraint be treated? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/83
arnaud: unfortuantely Simon is not here
pfps: my understanding is that this is not valid syntax
... somewhere there is wording to the effect that there can be only one of each of the bits of a property constraint
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.
pfps: I just pasted the relevant part of the spec
holger: syntactically invalid
<aryman> None of these properties can be repeated within the same sh:PropertyConstraint
arnaud: is everyone happy with that
<ericP> Dq+
pfps: if anyone wants to have multiples they have to come up with a syntax that works in the RDFS encoding
eric: how does this look from a user perspective?
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
eric: OK
arthur: what about multi-occurence of properties
eric: that's needed (and different)
arthur: what about allowedValues
eric: that works
arthur: it doesn't make sense to have two minCount
... the syntax for qualified value shapes appears to be bad language design
... I think that the language would be better if there was a way to have multiple qualified value shapes on the same property constraint
... so iSSUE-83 is about fixing the language design
holger: allowing multiple qualified value shapes is a significant change to the syntax
... the current design is uniform
arthur: ... use case ...
arnaud: simon put in an example
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)
... right now you could have a single property constraint with pieces
arnaud: if anyone wants a syntax change, then propose that directly
... the particular issue at hand is about the (current) treatment of multiple qualified value shapes
... if anyone thinks that there needs to be a change to the syntax, then propose the change
+1
http://w3c.github.io/data-shapes/shacl/#constraints-property, just before the list of properties for property constraints
<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
+1
<hknublau> +1
<Labra> 0
<aryman> +1
<hsolbrig> 0
<kcoyle> 0 (not sure I understand)
arthur: not that much support
harold: I don't understand the ramifications
arthur: you need multiple property constraints, each one with a qualified cardinality shape
holger: correct
RESOLUTION: 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)
arnaud: add a note saying that the effect can be achieved with multiple property constraints
<hsolbrig> +1
<hsolbrig> (now that I know that it still can be done)
arnaud: we have 20 minutes left - any issues to be considered
holger: we had touched upon the results vocabulary, so let's consider ISSUE-51
holger: I think that the current draft can be considered a resolution for the issue
ISSUE-51
<trackbot> ISSUE-51 -- What types of validation results should be returned -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/51
arnaud: we may have to wait until people take a look at the spec
pfps: I think that the issue can be closed, but I see that others may need to take a look
kcoyle: can we have a summary of the design
<Arnaud> https://w3c.github.io/data-shapes/shacl/#results
<aryman> the draft still uses sh:Error instead of sh:Violation
holger: there is a single class for validation results, with a severity property, with three values
... the other fields give details on the result
... the difference is dropping the other stuff - implementations can extend as necessary
arthur: my preference is to use violation instead of error for the severity level
arnaud: so information, warning, and violation
arthur: yes
holger: that's not how other frameworks do it
arthur: this is not a log, it is a validation report
... we are defining a domain-specific vocabulary so we should use terms relevant to the domain
+q to arthur
harold: I agree with arthur - violations are things that have not gone wrong, so we should avoid using error
<ericP> +1
<Zakim> pfps, you wanted to arthur
+1 to arthur
<kcoyle> I'm good with violation as well
arnaud: any other comments - if not I'll propose closing with the vocabulary change
<Arnaud> PROPOSED: Close ISSUE-51, adopting with the latest editor's draft renaming sh:Error as sh:Violation
+1
<hknublau> 0
<aryman> +1
<hsolbrig> +1
<kcoyle> +1
<Labra> +0
RESOLUTION: Close ISSUE-51, adopting with the latest editor's draft renaming sh:Error as sh:Violation
arnaud: arthur you want to make a different poiint
arthur: inheritance in templates is encoded as rdfs:subClassOf
holger: right
arthur: subtemplates can add arguments, ancestor templates are validated first and descendant templates later
... this is using rdfs:subClassOf in a way different from that in RDFS
... how can templates be considered to be classes
holger: this design has been used for many years in SPIN
... it is very natural to me to instantiate a template
... an argument declaration seems like a property declaration
... I think that that is very consistent
... changing this is a big change and I don't think that we need to change it
arnaud: the fact that it has been there since day 1 does not mean that it cannot be questioned
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
holger: I really don't see any problem
arthur: the use of classes in RDFS is that they classify resources, if it doesn't then it is not a class
<kcoyle> I think Arthur is on to something - much here seems to be very OO
<ericP> +1
holger: we could always use nodeShape and not use rdfs:subClassOf
arthur: template inheritance should use a different mechanism
holger: I think that the use is consistent with RDFS
arthur: where are the instances
holger: when you say that something is a closed shape then you make the shape an instance of ClosedShape
arthur: when you use the templates that's an instance of the template class
pfps: holger is talking about templates as instances of classes, but the issue is about instances of templates, which is completely different
... 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
arnaud: this is worth future discussion
arthur: I might open an issue on this
<Arnaud> trackbot, end meeting