See also: IRC log
<AndyS> I'll scribe
<AndyS> scribenick: AndyS
<pfps> OK - the punishment for bad scribing is expulsion from the group, right?
<ericP> Approve minutes of the 23 June 2016 Telecon: http://www.w3.org/2016/06/23-shapes-minutes.html
<pfps> minutes looked fine to me
<ericP> PROPOSED: Approve minutes of the 23 June 2016 Telecon: http://www.w3.org/2016/06/23-shapes-minutes.html
RESOLUTION: Approve minutes of the 23 June 2016 Telecon: http://www.w3.org/2016/06/23-shapes-minutes.html
pfps: 171 and 172 are more like glitches
... 170 is the SPARQL issues.
... as my leaving present to you all.
EricP: thanks to pfps for his contributions on the working group.
... quite a lot of discussion
<TallTed> +1 open all three...
<ericP> PROPOSED: raise issue-170
EricP: any objections to raising 170?
<ericP> PROPOSED: open issue-170
<pfps> +3, distributed evenly
RESOLUTION: open issue-170
<hsolbrig> ... pfps: 171 and 172 are glitches bordering on editorial
<ericP> scribenick: hsolbrig
<trackbot> issue-171 -- sh:classIn SPARQL definition incorrect -- raised
<trackbot> issue-172 -- the sh:nodeKind SPARQL definition is unnecessarily complex -- raised
<ericP> PROPOSED: open issue-171, issue-172
RESOLUTION: open issue-171, issue-172
<trackbot> issue-41 -- Using property paths to refer to values/types? -- open
simonstey: issue raised more than a year ago. About including property paths...
... issue was resolved back then as "nice feature" but could be done through native sparql
... issue was revived and Holger made a proposal that was similar to original.
Couldn't hear Dimitris' response
Dimitris: Idea was accomodidate Simon's issue
... remove reverse property constraint and use sh:predicate for forward predicate or list based path
<AndyS> scribenick: AndyS
Dimitris: only simple paths e.g. inverse
EricP: not * and + what about "/"
Dimitris: it's a list so each element is a path step
EricP: SPARQL is all ways to satisfy the path
<pfps> the question is whether there is, in effect, a DISTINCT in the query
<ericP> PROPOSED: change PropertyConstraint and InversePropertyConstraint to one type of Constraint with either a predicate (which implies arcs-out) or a path. The path does not include * or + and cardinalities on the resulting node value set are satisfied by combination of cardinalities on the steps.
pfps: This is a new kind of thing - (noises)
<pfps> is this something new? before all that counted was the number of values, now this appears to be counting paths of course, the two where (roughly) the same before.
hsolbrig: how does inverse realised in this design?
<Dimitris> sh:path ( sh:invesre ex:p)
hsolbrig: how is inverse predicate realised in this design?
<Dimitris> I do not remember the exact syntax Holger proposed but is similar to the above
EricP: we have a fixed series of steps inc reverse path
<Dimitris> sh:path ( ex:p1 [sh:invesre ex:p2] ex:p3)
SPARQL -- ex:p1/^ex:p2/ex:p3
<ericP> sh:path ( ex:p1 ex:p2b ex:p3 ) . ex:p2b sh:inverse ex:p2 .
EricP: In my example - I put in an IRI for the bnode.
Dimitris: deals to be sorted out
... can also have nested paths with nested () which are bnodes in the grap.
EricP: ready to vote?
<simonstey> I made a proposal a year ago https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Jul/0070.html (but it's not using lists and is a bit verbose though)
EricP: this proposal unblocks progress on syntax.
<ericP> PROPOSED: change PropertyConstraint and InversePropertyConstraint to one type of Constraint with either a predicate (which implies arcs-out) or a path. The path does not include * or + and cardinalities on the resulting node value set are satisfied by combination of cardinalities on the steps. Exact syntax (e.g. nested paths, behavior of bnodes) to be resolved.
simonstey: pointer in minutes is good.
EricP: advice to editors - tentative support
RESOLUTION: change PropertyConstraint and InversePropertyConstraint to one type of Constraint with either a predicate (which implies arcs-out) or a path. The path does not include * or + and cardinalities on the resulting node value set are satisfied by combination of cardinalities on the steps. Exact syntax (e.g. nested paths, behavior of bnodes) to be resolved.
EricP: email -- https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jun/0159.html on shex/shacl syntax
... was up to date until the path resolution above
pfps: Didn't see a need for an abstract syntax.
jamsden: What is the purpose here?
EricP: Purpose is to have a terse semantics and relate a shex parse tree to shacl (for the overlap)
... e.g. SPARQL does abstract syntax to algebra
... this is a "shapes algebra" equivalent
jamsden: it creates redundancy in defn terms
... how does it affect the reSpec?
EricP: This is not huge. Little or no automation needed.
... not a machine readable tool
jamsden: suggest non-normative appendix?
simonstey: xtext in Eclipse useful? Auto generate parsers from this.
EricP: Purpose today is to highlight its existence.
<trackbot> issue-139 -- Can all constraint properties be applied in all scenarios? -- open
pfps: worry is that language is complex, many restrictions and rules, so maybe make any constraint anywhere - there has been push back.
... everything is a constraint.
... interacts with path
<ericP> NC, PC, IPC table
pfps: see table in sec 4 ... quite complicated ... so let anything happen
... alternative is to remove the SHACL rules in the table and allow all possible uses even if they do not have much usefulness.
pfps: in some places e.g. can't have literals in some places in RDF - we are charged to future proof SHACL so may change. And some tripestores allow it.
<Dimitris> all this are now solved with the new path syntax
<Dimitris> there is no longer a distinction between PC & IPC
pfps: effect of my proposal is to put check marks everywhere.
Dimitris: only NC and paths now
... table will by modified / removed.
<pfps> so far, this is not about performance - that's a separate issue
TallTed: some strictly silliness is useful to check for silly data.
<Zakim> ericP, you wanted to describe the 3 apparent classes of Property
TallTed: it is a valid validation
pfps: sounds reasonable
<trackbot> issue-133 -- syntax simplification and regularization -- open
pfps: some of this has already been resolved.
... ducks example
... shape or constraint : striped syntax leads to a constraint just to keep two shapes apart.
... we can have just constraints
EricP: shex - just triple constraints
<ericP> I heard that as "ConApe" as in "ConstrationShape"
pfps: constraint or shape in any place
<pfps> This is recapping a long discussion of quite some time ago.
Ptr to email?
Dimitris: closer to pfps's syntax now - diff is that he works on sets
... node constraints else quite similar.
pfps: things on sets can't be in NCs
Dimitris: not intuitive how it would work.
... link to info or violations
... an area for discussion to get to a proposal.
... sh:Warning with sh:Violation and also sh:Info inside
pfps: issues with composition of shapes
EricP: preprocessing step for nested constraints/violations?
pfps: handles level at runtime to pass highest priority
... separately how do the messages come out?
Dimitris: I proposed treat everything as an error
<pfps> my problem with violation levels is that a shape that produces only informational results can't be used inside another shape
<pfps> Dimitris's proposal would at least change the validation reports that are emitted, so it is not just editorial
Dimitris: can make proposal for a resolution
<kcoyle> bye Peter!
EricP: suggest Dimitris writes consolidated proposal
<Dimitris> bye Peter!
Farewell to Peter!
<simonstey> bye peter
<ericP> trackbot, end meeting?